Comments 62
Как и плагин samdark имеет один жирный минус.
При появлении окна из-за .lock {overlay:hidden} контент скачет.
Для меня это более неприятное поведение чем скролинг текста под модальным окном.
При появлении окна из-за .lock {overlay:hidden} контент скачет.
Для меня это более неприятное поведение чем скролинг текста под модальным окном.
Да, есть такое дело. Стоит в списке доработок.
var oldBodyOuterWidth = body.outerWidth(true);
var oldScrollTop = html.scrollTop();
html.css('overflow-y', 'hidden');
newBodyOuterWidth = body.outerWidth(true);
body.css('margin-right', (newBodyOuterWidth - oldBodyOuterWidth) + 'px');
html.scrollTop(oldScrollTop); // necessary for Firefox
решает проблему с передергиванием. Вроде 6 строчек, а уже 2 плагина, пиарящиеся на хабре даже так не умеют
Исправим :)
И скорее выкладывайтесь на github
Выложил: github.com/vjik/arcticModal
Не забыть еще про уже установленный отступ.
вы часто делаете margin-right для body? Хотя да, для полной переносимости лучше бы добавить
при открытии нескольких модальных окон каждый раз добавляется полупрозрачный фон, который в итоге стаёт чёрным (ну в даном примере), а это немного не утраивает меня… а в общем то работа заслуживает похвалы
Да, такое поведение и задумано — ведь предыдущие модальные окна нужно перекрывать.
Можно использовать разное оформление оверлеев.
Можно использовать разное оформление оверлеев.
А можно ли сделать так, чтобы при открытии нового (второго) модального окна, первое автоматически закрывалось? Или обязательно нужно вызывать .arcticmodal('close');?
возможно имеет смысл при открытии последующих окон, у передыдущих скрывался полупрозрачный фон, а при закрытии — возвращался, так вроде и блокируем и черноту не создаем
хорошая идея!
подумаю над этим
подумаю над этим
.arcticmodal-overlay~.arcticmodal-overlay {
background-color: transparent!important;
}
Вот и вся магия. А вообще у вас там какая-то верстка сложная. Если поддержка старых браузеров не нужна, то и смысла создавать кучу DOM-элементов нет. Вместо прозрачности можно использовать rgba / hsla только для фона перекрывающего слоя. С z-index'ами тоже как-то странно. Посмотрел firebug'ом, так там на каждый элемент прописывается новый z-index+1, а смысл? Он же и так друг на друга наклажывается… В общем СSS стоит подтянуть ;). Да и анимации всякие там можно на CSS перекинуть. Ну и куча багов из прошлого топика перекочевала и сюда :).
Нужна поддержка ИЕ7+, поэтому такая верстка.
z-index да, скорее всего уберу это.
А баги перекочевали также в to-do лист =)
z-index да, скорее всего уберу это.
А баги перекочевали также в to-do лист =)
Хм, ну с со старыми IE я работаю редко, но вроде как селектор "~" должен работать, rgba / hsla можно на полупрозрачный png заменить (быть может оно и не всем нужно). Ну и верстка таблицами, кхм, это же срадни извращению. Если нужно что-то там спозиционировать, а CSS для этого не хватает, то на помощь приходит JS :). Тем более тосленный jQuery используете… Там, по идее, на само окно с перекрывающей областью и кнопкой закрытия должно уходить от 3-х до 4-х элементов DOM даже в IE7.
Таблицы сделаны для того, чтобы корректно работало позиционирование по горизонтали и вертикали. Как я не старался, но дивами у меня это не получилось реализовать кроссбраузерно.
Ужас-то какой. Я где-то слышал, что кто-то недолюбливает IE за то, что он кривой и ничего не умеет. Хм, быть может оно так есть… Но! Если посмотреть здесь, «clientHeight» и «getBoundingClientRect()» вроде как умеет. Быть может и так сможет тогда:
За не имением IE7 проверить не могу :).
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Tree Example</title>
<style>
*{
margin:0;
}
#test{
width:100px;
height:100px;
background-color:red;
margin:0 auto;
position:fixed;
left:0;
right:0;
}
</style>
</head>
<body>
<div id="test">Test</div>
<script>
var
test=document.getElementById('test');
test.style.top=(document.body.clientHeight/2-test.getBoundingClientRect().height/2)+'px';
</script>
</body>
</html>
За не имением IE7 проверить не могу :).
Но это же ещё и пересчитывать надо на ресайз основного окна и на ресайз модального окна. Плюс ещё надо учитывать момент, когда модальное окно не влазит в экран. Я не вижу смысла отказываться от таблиц в данном случае и писать вместо этого JS, пусть уж лучше браузер сам занимается центрированием — у него это хорошо получается :)
Если отбросить всякие там спортивные интересы, то сие нужно только для отсталых браузеров. Для современных есть всякие там CSS calc()'и и CSS flex'ы. Просто мое видение плагинов в том, что это не пара строк кода, а достаточно емкое и продуманное решение. Вывести окошко по центру можно и без плагина, а вот вывести его красиво и при этом потратив минимум времени — задача плагина. Так вот у вас получается 8 элементов только на одно кошко с кнопкой закрытия и перекрывающей областью. Это слишком много, ибо дерево DOM засоряется лишними элементами. Если есть возможность сократить их колличество, так почему же ей не воспользоваться.
Сосбтвенно выбор за вами :).
Сосбтвенно выбор за вами :).
Это кол-во не сильно мешает, да и после закрытия окошка всё удаляется. А так мы немного сокращаем кол-во, зато увеличиваем нагрузку на JS.
В общем, когда уйдут от нас старые браузеры, тогда будет смысл отказываться от таблиц :)
В общем, когда уйдут от нас старые браузеры, тогда будет смысл отказываться от таблиц :)
И, да, я совсем забыл про expression'ы. Ведь, по идее, можно просто сделать отдельный CSS для старых IE с expression'ами и тогда везде все будет работать как надо. По этой теме что-то есть вот здесь. Мне кажется, что можно посидеть и сделать минимальную верстку для современных браузеров и дополнительную для устаревших.
Какраз что-то искал подобное, спасибо! Буду пользоваться )
Не могу понять, зачем плагин на jquery, если в jquery есть ВСЕ средства для работы с модальными окнами?
Такого функционала там, к сожалению, нет.
Какого именно или вохможно Вы хотите обойтись без jQuery-UI?
Именно, не хочется подключать монстра jQuery UI
На сайте можно собрать под себя, не включая ненужные компоненты, тогда оно малость полегче станет
По какому принципу jQuery UI монстр?
12 Кб ядро (core + утилиты widget и position). Учитывая, что widget и position можно использовать отдельно, помоему это вполне приемлимо, на мой взгляд.
Да, 11 Кб весит dialog, но тут скорее проблема в том что не всем нужен полный функционал.
P. S. Не агитирую за UI, но он помоему не самый «монструозный».
12 Кб ядро (core + утилиты widget и position). Учитывая, что widget и position можно использовать отдельно, помоему это вполне приемлимо, на мой взгляд.
Да, 11 Кб весит dialog, но тут скорее проблема в том что не всем нужен полный функционал.
P. S. Не агитирую за UI, но он помоему не самый «монструозный».
Я олдскульно использую модалки от jQuery UI.
Да, есть там всякие недостатки, но в принципе разок допилив напильником — работают.
А сторонние плагины, полезно конечно, но из практики — разработчики часто бросают их поддержку.
Да, есть там всякие недостатки, но в принципе разок допилив напильником — работают.
А сторонние плагины, полезно конечно, но из практики — разработчики часто бросают их поддержку.
А что не так с fancyBox?
Очень неплохо!
Однако как и у того плагина в Firefox клавиши Page Up и Page Down приводят к прокрутке страницы (а не модального окна).
Однако как и у того плагина в Firefox клавиши Page Up и Page Down приводят к прокрутке страницы (а не модального окна).
И да, кстати. как и у плагина SamDark, не реализовано правильное поведение клавиши Tab (оно вообще почти нигде не реализовано, надо отметить — так что, если сделаете, это будет большой плюс, я думаю). И плюс установка фокуса (у вас в примерах, впрочем, нажатие на Tab всё равно приводит к выбору первого элемента управления внутри модального окна, так как оно находится непосредственно после ссылки, которая использовалась для его открытия — но это, конечно, не вариант в том случае, если есть несколько ссылок, открывающих одно и то же модальное окно, либо, например, если его можно открывать с клавиатуры).
Вообще, установка фокуса в модальное окно сразу после его открытия нужна для соответствия стандартам секции 508 — потому что если это не происходит, то пользователь, нажимая на кнопку Tab, будет сначала выбирать элементы управления, находящиеся на странице, а не в модальном окне.
И это исправить, в принципе, легко. Сложнее сделать, чтобы элементы на заднем плане вообще не выбирались клавишами Tab и Shift + Tab. То есть чтобы после выбора последнего элемента управления в модальном окне выбирался первый элемент в модальном окне, и наоборот.
Пока что в голову пришли два варианта реализации — можно или временно привязывать к событию фокусировки следующего и предыдущего элемента после и до модального окна переключение на, соответственно, на первый и последний элемент самого модального окна, или вообще временно убирать элементы управления на заднем плане (а вместо них помещать элементы, которые выглядят так же, но не являются элементами управления), чтобы браузер даже не пытался ставить туда фокус. По сути, оба решения не очень простые, потому что тут надо делать аккуратно, и тестировать — чтобы не получалось так, что пользователь закрыл модальное окно, а элементы управления не появились обратно.
Впрочем, вспомнив, что в Google, например, клавиша Tab работает не самым обычным образом, решил ещё поискать, и действительно — клавишу Tab можно перехватывать по keydown (оно же onkeydown в IE). А это всё упрощает. Так что, скорее всего, именно на таком варианте и остановимся.
Кстати, делать правильное поведение для клавиши Tab стоит не только из-за обычного удобства, но и для тех пользователей, кто по каким-то причинам не может видеть картинку на экране, и использует screen reader'ы для автоматического чтения с экрана. И в этом случае, соответственно, если клавиша Tab не работает правильно, то они могут вообще не понять, где та часть страницы, которую они ищут.
Вообще, установка фокуса в модальное окно сразу после его открытия нужна для соответствия стандартам секции 508 — потому что если это не происходит, то пользователь, нажимая на кнопку Tab, будет сначала выбирать элементы управления, находящиеся на странице, а не в модальном окне.
И это исправить, в принципе, легко. Сложнее сделать, чтобы элементы на заднем плане вообще не выбирались клавишами Tab и Shift + Tab. То есть чтобы после выбора последнего элемента управления в модальном окне выбирался первый элемент в модальном окне, и наоборот.
Пока что в голову пришли два варианта реализации — можно или временно привязывать к событию фокусировки следующего и предыдущего элемента после и до модального окна переключение на, соответственно, на первый и последний элемент самого модального окна, или вообще временно убирать элементы управления на заднем плане (а вместо них помещать элементы, которые выглядят так же, но не являются элементами управления), чтобы браузер даже не пытался ставить туда фокус. По сути, оба решения не очень простые, потому что тут надо делать аккуратно, и тестировать — чтобы не получалось так, что пользователь закрыл модальное окно, а элементы управления не появились обратно.
Впрочем, вспомнив, что в Google, например, клавиша Tab работает не самым обычным образом, решил ещё поискать, и действительно — клавишу Tab можно перехватывать по keydown (оно же onkeydown в IE). А это всё упрощает. Так что, скорее всего, именно на таком варианте и остановимся.
Кстати, делать правильное поведение для клавиши Tab стоит не только из-за обычного удобства, но и для тех пользователей, кто по каким-то причинам не может видеть картинку на экране, и использует screen reader'ы для автоматического чтения с экрана. И в этом случае, соответственно, если клавиша Tab не работает правильно, то они могут вообще не понять, где та часть страницы, которую они ищут.
Можно дисейблить элементы вне окна, в принципе
Ну, я примерно это и имел в виду под «преобразованием» элементов управления. Например, динамически генерировать другой HTML (в котором целиком пройтись по DOM и автоматически заменить элементы), и временно замещать им содержимое страницы, а потом возвращать тот, что был. Но тут есть некоторые нюансы, связанные с тем, как именно браузер будет отображать отключённые элементы. То есть реально потребуется ещё и CSS редактировать соответствующим образом, чтобы они отображались так же, как и те же элементы в обычном состоянии.
Зачем так сложно? Просто пройтись по элементам вне формы, собрать все активные, запомнить, задисейблить, после закрытия модального окна раздисейблить.
Я думаю не нужно заморачиваться с тем что элементы будут иначе выглядеть, мы же открыли модальное окно, помоему логично что всё блокируется.
Я думаю не нужно заморачиваться с тем что элементы будут иначе выглядеть, мы же открыли модальное окно, помоему логично что всё блокируется.
В принципе, да — пожалуй, изменение вида форм на заднем плане может быть логичным (разве что не очень привычным). Но как вы отключите ссылки? Их обычно гораздо больше, чем элементов форм. И там disabled уже, конечно же, нету.
Вообще, конечно, есть один хак. Можно указывать tabindex="-1" — причём даже у div, например.
Но этого нет в спецификациях, и это именно хак. К тому же, он далеко не везде работает (к примеру, у меня в Firefox в Linux он не имеет никакого эффекта).
С другой стороны подобный способ мог бы быть лучше с той точки зрения, что он не позволяет с помощью клавиши Tab выбирать те элементы, которые находятся на заднем плане, но при этом оставляет возможность выбирать элементы окна браузера (я думаю, что такую возможность желательно оставлять — потому что иначе пользователь, по сути, теряет возможность перейти на другую вкладку и так далее, если, конечно, он не воспользуется подходящим сочетанием клавиш).
Вообще, конечно, есть один хак. Можно указывать tabindex="-1" — причём даже у div, например.
Но этого нет в спецификациях, и это именно хак. К тому же, он далеко не везде работает (к примеру, у меня в Firefox в Linux он не имеет никакого эффекта).
С другой стороны подобный способ мог бы быть лучше с той точки зрения, что он не позволяет с помощью клавиши Tab выбирать те элементы, которые находятся на заднем плане, но при этом оставляет возможность выбирать элементы окна браузера (я думаю, что такую возможность желательно оставлять — потому что иначе пользователь, по сути, теряет возможность перейти на другую вкладку и так далее, если, конечно, он не воспользуется подходящим сочетанием клавиш).
В The Modal будет верное поведение tab. Идеи как реализовать есть. Нужно чуточку времени.
«одновременное отображение нескольких окон» — это как-то уже не модальные окна.
Ну почему же, модальное окно блокирует интерфейс, а второе окно блокирует предыдущее и тд. То есть они являются модальными.
Видимо SamDark имеет в виду тот факт, что модальность заключается в блокировке рабочего процесса, ну а блокировка интерфейса уже является следствием первого. Следовательно, модальные окна должны открываться последовательно и добавляться в стек ожидания по необходимости. В общем-то так и реализованы модальные окна операционных систем.
Пожалуйста, закачайте исходник на GitHub.
Выложил: github.com/vjik/arcticModal
скажите, а имеется возможность выводить модульное окно например над курсором, или над определённым элементом? последнее было бы не плохо, например если форма загружена, и чтобы разделы(например) не выводить на общей страницу, по клику по ссылке открывалось окно для их выбора, но окно должно быть на против ссылки по которой кликаеш.
Sign up to leave a comment.
arcticModal — jQuery-плагин для модальных окон