модальное окно что это

W3.CSS Модальные окна (Модалы)

Заголовок модального окна

Вернитесь на W3.CSS Модальные окна, чтобы узнать больше!

Нижний колонтитул модального окна Закрыть

W3.CSS Классы модального окна (модала)

W3.CSS предоставляет следующие классы для модальных окон:

Создать модальное окно (модал)

Класс w3-modal определяет контейнер для модального окна.

Класс w3-modal-content определяет модальный контент.

Модальным контентом может быть любой элемент HTML (элементы div, заголовки, абзацы, изображения и т.д.).

Пример

Какой-то текст в модальном окне..

Какой-то текст в модальном окне..

Открыть модальное окно

Можно использовать любой HTML элемент для открытия модального окна. Но обычно это кнопка или ссылка.

Добавьте атрибут onclick и укажите идентификатор модального окна (в нашем примере id01 ), используя метод document.getElementById().

Закрыть модальное окно

Чтобы закрыть модальное окно, добавьте класс w3-button к элементу вместе с атрибутом onclick, который указывает на идентификатор модального элемента (id01). Вы также можете закрыть его, нажав за пределами модального окна (см. Пример ниже).

Совет: × является предпочтительным объектом HTML для значков закрытия, а не буквы «x».

Модальные Header и Footer

Используйте классы w3-container для создания разных разделов внутри модального контента:

Источник

Модальные окна на CSS

В наше время для различных сайтов нормой стали всевозможные всплывающие модальные окна — popup’ы — для регистрации, авторизации, информационные окна, — всевозможных форм и размеров. Также существует огромное количество плагинов к тому же jQuery для простого и удобного создания таких попапов — тот же Shadowbox, например.

Внешний вид, размеры и оформление таких попапов совершенно разнообразными — с оверлеем, тенюшками, анимациями — всего не счесть. Объединяет их только, пожалуй, тот факт, что обычно они выводятся в самом центре страницы — как по горизонтали, так и по вертикали. И центрирование это производится средствами JS. Я не буду вдаваться в подробности этих расчетов, опишу их лишь вкратце:

HTML-код попапа обычно имеет такую структуру:

И CSS (здесь и ниже я умышленно буду опускать написание некоторых свойств, необходимых лишь для некоторых браузеров и их версий, оставив лишь самое основное):

Я по натуре своей перфекционист (знаю, порой это плохо), и частенько заморачиваюсь даже над мелкими деталями, пытаясь улучшить и добавить максимально возможную расширяемость этим деталям, и меня не мог не зацепить именно этот момент в работе всех этих плагинов. Возникла мысль, что всю работу по позиционированию попапа можно переложить с плеч JS на плечи самого браузера, то есть выполнять эту работу средствами CSS.

Ниже я приведу пример попапа, работающего во всех мажорных версиях основных браузеров. Для корректной его работы в IE div class =»popup__overlay»>
div class =»popup»> div >
div >

.popup__overlay <
position : fixed ;
left : 0 ;
top : 0 ;
width : 100% ;
height : 100% ;
z-index : 999
>
.popup <
>

Фиксированные размеры

Самый простой вариант. Ничего нового изобретать не нужно:

Отрицательные margin’ы в половину ширины и высоты — банально и скучно, ничего оригинального в этом нет. Идём дальше.

Размеры попапа зависят от содержимого

Сперва — выравнивание по горизонтали — это вроде бы проще. Если попап фиксированной ширины — то достаточно будет следующего:

На вертикальное выравнивание это никак не повлияет, и, к слову, если вам достаточно лишь горизонтального выравнивания, то на этом можно и остановиться, указав еще какой-нибудь верхний отступ попапа. Но нам этого мало! Идём дальше.

Вертикальное выравнивание. Здесь уже становится интересно. С такой задачей, конечно, без проблем справилась бы таблица или эмуляция таблицы с помощью display: table & display: table-cell, но заставить такое работать в старых IE — себе дороже. Таблица также отпадает — по понятным причинам.

Итак, margin уже отпадает — размеров мы не знаем. Вспоминаем, что же есть из свойств с подобными эффектами. Ага, text-align. Но только для инлайновых элементов. ОК. Кажется, сам Бог велел использовать display: inline-block — блочный элемент, к которому можно было бы применить свойства для инлайновых элементов. С поддержкой этого свойства у всех браузеров тоже всё, можно сказать, в порядке. Код становится примерно таким:

Остаётся вертикальное выравнивание — нам подойдёт vertical-align. В любой другой ситуации было бы также уместно использовать line-height, но поскольку у нас нет фиксированной высоты страницы (line-height в данном контексте), здесь использовать её нельзя. На помощь приходит один трюк с вертикальным выравниванием элементов неизвестных размеров. Я точно помню, что нашел этот способ на Хабре, но, к сожалению, не смог найти ссылку на тот топик. Заключается этот способ в следующем: добавляется inline-block элемент нулевой ширины и 100%-ой высоты родителя, который «расхлопывает» высоту строки до 100% высоты родителя, то есть до высоты рабочей области страницы. Сделаем это изящнее — вместо лишней разметки воспользуемся псевдоэлементами:

Осталось добавить полупрозрачное затемнение оверлея — с этим справится rgba. Всё! Теперь положение попапа регулируется только средствами браузера на уровне CSS.

Из замеченных минусов метода — порой возникают глюки с отображением в IE 6-7, в частности, при использовании флоатов.

Повторюсь — мой метод не избавляет от использования JS вообще, он лишь частично оптимизирует скорость работы всплывающих окон за счет переноса части нагрузки с JS на CSS.

Уверен, что метод можно улучшить — как визуально, так и изнутри, и буду рад любым идеям и предложениям по этому поводу, а также замечаниям по работе и отображению в различных браузерах.

Источник

Ох уж эти модальные окна или почему я полюбил render-функции в VueJs

Моя первая публикация прошла с неприятным осадком. Я обещал исправить это недоразумение и на ваш суд представляю свою первую статью-урок по VueJs. Надеюсь, она окажется полезной. Мыслей много, опыта тоже немало. Всю жизнь учусь по чужим статьям, урокам. Пришло время тоже делиться знаниями.

А будем мы творить модальные окна. Да опять они. Но не такие простые, как описаны в первой моей (не моей) публикации.

Много уже их создано для Vue. Пользовался всякими. И видимо, когда достигаешь какого-то определенного уровня владения инструментом (в данном случае Vue), сразу хочется сделать велосипед, но конечно со своими прибамбасами, типа, чтобы круче всех и т.д. И я не стал исключением из правил.

Из всех доступных модальных компонентов, использовал в основном этот — Vuedals.
Но решил я его проапгрейдить. В принципе от основы остался только EventBus и взаимодействие событий связанных с открытием-закрытием окон. Основной компонент переписан и стал оберткой-контейнером и добавлен новый компонент — само модальное окно.
Но обо всем по порядку. И статья получится очень немаленькая, кто осилит, тот красавчик 🙂

В основном модальные окна во всех примерах вызываются в таком стиле:

Вроде все красиво. Но!

Какие вижу недостатки такого подхода.

Во-первых, темплейт модального окна находится внутри родительского компонента, где мы его вызываем. И контекст окна не изолирован от родителя. Мне так не всегда удобно и нужно.
Во-вторых, если одно и то-же окно используется в нескольких местах, приходится дублировать код. Что не есть гуд!

В-третьих, и что наверно является самым главным недостатком — мы можем использовать модальное окно только внутри страниц или других компонентов Vue, а вот в местах типа Vuex, Router, да и вообще в любых скриптах не можем. Мне например, надо вызвать модальное окно входа/регистрации из роутера или из стора при каком-то событии. Примеров можно привести мильён.

Поэтому подход используемый в Vuedals, когда мы открываем/закрываем окна путем вызова функции с параметрами и передавая «сырой» компонент, вида —

или полноценный, который мы импортнули извне, мне оказался больше по душе.
Больше контроля, возможностей переиспользования и вызвать такое окно можно практически отовсюду.

Выглядит в общем это так, у нас есть компонент ModalWrapper, который мы импортируем в приложение и вставляем например в корневой App-компонент. Где нибудь внизу.

Потом в любом месте вызываем метод this.$modals.open(< component: SimpleModal, title: 'Simple modal'>), куда передаем настройки нашего окна и компонент, который будем показывать и видим наше модальное окошко, которое рендерится в ModalWrapper.

Есть куча событий, возникающие при всех манипуляциях с окнами, события эти управляются при помощи EventBus-а, и их можно прослушивать и как-то реагировать.

Это вводные данные, чтобы информация легче осваивалась. В принципе, статья больше для новичков в Vue. Но надеюсь, будет пара моментов интересных и для искушенных.

Буду кидать куски кода и попутно комментировать, что к чему. Ссылка на примеры и исходники в конце есть.

Ну и пожалуй начнем с главного файла —

В нем мы импортируем компоненты, используемые для наших модальных-премодальных окон:

Здесь мы создаем singleton-экземпляр EventBus-а, который может подписываться на события ($on) и вызывать ($emit) события. Думаю здесь объяснять особо нечего. EventBus собирает коллбеки и когда надо их вызывает. Дальше по ходу дела будет видно и понятно, как он связывает все наши компоненты.

А теперь по index.js

Здесь мы экспортируем по умолчанию дефолтную функцию install — для подключения наших окон к приложению (используя Vue.use()) и компоненты ModalWrapper, Modal и Bus. Ну и при подключении VueUniversalModal через script-тег в браузере, активируем наш компонент, если подключен глобальный VueJs на странице.

Здесь мы цепляем к глобальному VueJs (через prototype) экземпляр Vue под именем $modals.

В его методе created (который запустится сразу, после запуска приложения) мы подписываем наш EventBus к событиям opened (открытие окна), closed (закрытие окна) и destroyed (окон нет, убираем ModalWrapper). При возникновении этих событий EventBus будет эмитить события modals:opened, modals:closed и modals:destroyed в компонент $modals. Эти события мы можем слушать везде, где доступен самолично VueJs.

Вообще, я сначала хотел повыкидывать половину этих коммуникаций, так как некоторые совсем не обязательны, но подумав оставил. Может пригодиться для сбора какой-то статистики по модальным окнам, например. Да и начинающие, возможно что-то для себя поймут в этой, казалось бы, каше из $on, $emit — вызовов.

Здесь мы включаем прослушивание событий new, close, dismiss самим компонентом $modals. При возникновении этих событий, вызываются соответствующие методы компонента $modals. Которые в свою очередь открывают (open), закрывают (close) и отменяют (dismiss) окно.

Как вы видите, у нас есть два способа закрыть окно — dismiss (отменить или по буржуйски — cancel — из той же оперы) и close (закрыть). Разница в том, что при закрытии модального окна через close, мы можем передавать данные в функцию обратного вызова onClose (рассмотрим далее), которую мы цепляем к опциям нашего нового модального окна.

И собственно методы open, close и dismiss компонента $modals. В них мы и запускаем через EventBus, события new, close и dismiss в нашем ModalWrapper. Там уже и будет происходить вся магия.

И последнее в install-функции файла index.js.

Здесь мы расширяем через Vue-миксин всем компонентам Vue метод created, в котором при запуске включаем прослушку компонентами событий modals:new, modals:close и modals:dismiss и при их вызове, через EventBus опять же запускаем соответствующие события в ModalWrapper.

Все эти адовы вызовы здесь нужны для управления нашими модальными окнами. И дают нам 4 варианта запуска событий open, close и dismiss.

Первый способ вызова нашего модального окна в приложении:

И четвертый (для этого способа нам нужно импортировать Bus.js, но это дает нам возможность вызвать окно не из компонента Vue, а из любого скрипта):

Ну и close, dismiss по аналогии.

Тут как говорится — «на вкус и цвет».

Следующий больной — Modal.js или мы не ищем легких путей

Дальше пойдет код повеселее. С недавнего времени в своих компонентах использую render-функции (как стандартные так и в jsx-формате). Использовать начал повсеместно тогда, когда понял, что они дают больше возможностей для рендеринга. С render-функциями вся мощь Javascript-а плюс крутая внутренняя VueJs кухня с vNode дают ощутимые бонусы. В момент их появления я на них как-то косо глянул, подумал, нафиг надо и продолжил рисовать компоненты в template-шаблонах. Но теперь я знаю, где собака зарыта.

Modal — это полноценный компонент, который рендерит само модальное окно. У него куча входящих параметров:

В коде прокомментировал все параметры, чтобы было нагляднее. А код в спойлер кидаю, чтобы не получилась портянка. Итак текста немало.

Вначале импортируем иконку-крестик в виде функционального компонента, который рендерит ее в SVG-формате.

Зачем я ее так сообразил, даже не знаю.

Дальше параметр name — ну это стандартный ход.

А вот componentName здесь неспроста. Он нам нужен будет дальше, в ModalWrapper-е при рендеринге.

И вычисляемый параметр propsData:

А дело вот в чем. В оригинальном Vuedals все окна тоже вызываются с помощью тех 4-х способов, описанных выше. В каждом из них мы должны передавать компонент, который хотим показать в окне и параметры окна (все они сейчас есть во входящих параметрах Modal и плюс добавлены несколько новых). И если мы хотим запустить одно и то же окно в разных частях приложения, мы каждый раз передаем параметры окна (размеры, другие настройки). Что опять является дублированием. Да и запутаться недолго. А мы, программисты, существа крайне ленивые в основе своей. Поэтому и был создан этот компонент Modal.

Теперь мы можем создать компонент модального окна, например, вот так:

То есть, стандартный компонент. Обернутый нашим Modal (vu-modal). Этому vu-modal мы передаем нужные нам параметры. Они и будут значениями по умолчанию для этого окна.

И теперь мы вызываем это окно так:

Все нужные нам значения дефолтных настроек окна берутся автоматом из того самого компонента SimpleModal, снятых с обертки vu-modal. Мы один раз создали компонент окна с нужными нам настройками и потом используем его в любом месте не парясь о настройках. Более того, если нам надо переназначить те значения по умолчанию, мы указываем нужные нам значения при вызове этого окна:

Теперь параметр center заменит дефолтный параметр указанный в шаблоне окна — SimpleModal.

То есть приоритет такой при мерджинге (слиянии) параметров:

Так вот вычисляемое свойство propsData в компоненте vu-modal возвращает нам правильные входящие параметры (props), учитывая момент, является ли данный экземпляр vu-modal оберткой в каком-то компоненте (SimpleModal) или же нет.
Для этого при рендеринге окна в ModalWrapper, если компонент этого окна обернут в vu-modal мы будем передавать смердженные props-ы под именем vModal, в другом случае будем передавать обычные props-ы.

Но так как в случае, когда компонент обернут в vu-modal, при рендере props-ы будут попадать в этот компонент-родитель (SimpleModal), мы и проверяем, есть ли у компонента-родителя входящий параметр с именем vModal. Если есть, то берем эти значения, иначе стандартные props-ы.

А проверяем мы не у this.$parent.$options.propsData, а именно у this.$parent.$vnode.data.props, потому что если у компонента-родителя не прописан в props-ах параметр vModal, то при рендеринге этот vModal мы cможем увидеть только у this.$parent.$vnode.data.props. Сюда попадают все без исключения параметры, которые мы передали. А потом уже фильтруются и лишние отбрасываются.

Приведу еще раз этот кусок кода, он маленький, чтобы с мысли не сбивать.

Сейчас возможно не совсем все понятно. Информации много, и не совсем все стандартное, как во многих уроках. Пишу такого рода статью в первый раз, не совсем пока ясно, как лучше преподать. Во внутренностях Vue копаются наверняка многие, но мало кто пишет об этом. Сам долгое время искал инфу по таким моментам. Что-то находил, остальное ковырял сам. И хочется рассказывать о таких вещах.

Но более понятно станет, когда будем разбирать ModalWrapper. Там мы будем формировать и отправлять смердженные props-ы нашим окнам.

Ну и осталась render-функция нашего компонента Modal (vu-modal):

Здесь вроде ничего необычного.

Сначала вытаскиваем все наши параметры из ранее описанного вычисляемого значения propsData.

Выводим кнопку-крестик, которое вызывает событие dismiss (отмену окна), если свойство dismissable равно true.

Формируем header — если нашему vu-modal передан слот с именем header (this.$slots.header) рисуем этот слот, если передано свойство title — выводим его, иначе header вообще не показываем.

Формируем блок body с содержимым дефолтного слота (this.$slots.default).
И следом footer — если передан слот footer (this.$slots.footer).
Дальше мы определяем правильные значения для css-свойства transform: translate(x, y) нашего окна. А именно параметры X и Y в зависимости от переданных свойств нашему окну. И потом мы передаем при рендере этот transform главному div-у окна для правильного позиционирования.

Ну и рендерим все это дело, попутно вычисляя нужные класс.

И плюс вешаем на главный div.vu-modal__cmp onClick-обработчик, с event.stopPropagation(), чтобы клик по окну не всплывал выше, дабы не активировать клик по div-у (маске), которым обернуто каждое окно и которое реагирует на клик и вызывает dismiss. Иначе сработает это событие dismiss на маске и наше окно закроется.
Уффф!

Завершающий компонент — ModalWrapper

import ‘./style.scss’
import Bus from ‘./utils/bus’
import ModalCmp from ‘./modal’

В массиве modals мы будем хранить наши окна, которые активны в данный момент.

Ну и при монтировании и удалении нашего ModalWrapper-компонента вешаем обработчик keyup на window (если window есть), который запускает метод handleEscapeKey:

Который в свою очередь, если нажата Esc-клавиша и есть окно(а) и у текущего (запущенного последним) окна свойство escapable равно true, запускает метод dismiss, который закрывает это самое текущее окно.

Ну и пожалуй самое интересное началось. Попробую описывать происходящее прямо в коде, может так лучше будет.

При создании нашего ModalWrapper включаем прослушку событий от EventBus-а. Тех самых, которые запускаются в методах $modals, описанных раннее:

Источник

Модальные окна, которые понравятся каждому

К модальным окнам можно относиться как к отличному способу приобрести дополнительное экранное место, привлечь внимание пользователя сайта, предложить ему выбор или предупредить об изменениях. Или как к грязному хаку, позволяющему навязать посетителю информацию, на которую он иначе не обратил бы внимания.

Это – крайние точки на линейке, которой измеряется наши взаимоотношения с пользователем сайта. В зависимости от привычек, личных предпочтений и способа сёрфинга по сети модальные окна могут быть для пользователя благословением или проклятием.

Модальные окна заставляют пользователя быстро переключить внимание с одной части сайта на другую, содержание которой иногда не соотносится с тем, что пользователь только что просматривал.

Если появление модального окна произошло автоматически или просто не было в явном виде инициировано пользователем, оно может дезориентировать и раздражать. Это позволяет обвинять модальные окна в назойливости и вторжении в частное пространство пользователя.

Кажется, что модальные окна не могут серьёзно помешать пользователю, пока они содержат простые и хорошо заметные элементы управления. Всегда можно нажать « крестик » в углу экрана, пробежаться по тексту или заполнить, наконец, эту форму регистрации.

Но представьте себе, что вы управляете браузером при помощи клавиатуры интернет-киоска, дисплея Брайля или устройства голосового ввода, а появившееся модальное окно не переместило фокус ввода на свою кнопку или поле, а оставило его где-то под собой, в остальном контенте сайта. Это приведёт сайт в негодность для использования на нашем устройстве.

И такие случаи происходят чаще, чем можно ожидать при современном развитии юзабилити-практик и средств тестирования.

Семантика кода способствует доступности сайта

Простота использования и доступность сайта на любых устройствах часто страдает при использовании модальных окон. Независимо от цели использования модального окна, управление им должно быть простым и универсальным.

Чтобы добиться этого, мы должны внимательно отнестись к семантике разметки. Это требование кажется простым, но, к сожалению, оно часто не выполняется. Представьте себе следующий код окна с кнопкой « Закрыть »:

Чтобы можно было переместить фокус ввода на данный

Допустим, что многие пользователи устройств чтения экрана уже знают о том, что буква « X » означает « Закрыть ». Но если мы заменим эту букву на знак умножения (амперсанд-код ×) или крест (❌) ради визуального эффекта, содержимое нашего блока не будет прочитано.

Это лишь один небольшой пример того, как семантическая разметка упрощает пользование сайтом. Мы должны всесторонне внедрять семантический веб, чтобы создавать сайты, удобные для всех.

Делаем модальные окна удобными и доступными

Семантическая разметка поможет нам сделать наше модальное окно более удобным и доступным. А правильное использование стилей и скриптов поднимет юзабилити нашего сайта на новый уровень!

Добавление состояния :focus

Допустим вариант, когда вы объединяете состояния :focus и :hover :

Хотя, получение фокуса с клавиатуры и наведение указателя мыши – это всё же два различных состояния, и разумно будет дать им собственные, отличные от других стили:

Сохранение последнего активного элемента

При открытии модального окна и перемещении фокуса необходимо сохранять предыдущий активный элемент. Тогда при закрытии модального окна пользователь сможет продолжить своё взаимодействие с сайтом на том же месте, на котором модальное окно заставило его прерваться.

Это работает как подобие закладки. Без такой функции пользователь переместится к началу страницы, и будет вынужден искать нужный ему контент заново, что обескураживает. Проблему сохранения фокуса может решить вот такой скрипт:

Перемещение фокуса

При появлении модального окна фокус должен переместиться на него или на первый интерактивный элемент в нём. Тогда пользователю не придётся браться за мышь или перебирать клавишей “ Tab ” десятки полей и кнопок:

На полный экран

Если ваше модальное окно занимает весь экран, позаботьтесь о том, чтобы элементы управления в основном окне стали на время недоступны. Иначе любой пользователь может продолжить вводить что-то в основное окно, думая при этом, что взаимодействует с модальным. Обеспечить желаемое может скрипт, подобный этому:

Закрывая для пользователя основной экран, мы всё же должны обеспечить для него доступ к элементам управления браузером при помощи всё той же кнопки “ Tab ”. Такого поведения от нашего окна ожидают и обычные, зрячие пользователи.

Вышеприведённый скрипт предотвращает переход фокуса в основной документ, вместо этого перемещая его обратно к первому элементу модального окна.

Для этого необходимо сохранять в скрипте их идентификаторы. Когда пользователь нажмёт “Tab” в последнем элементе окна, вы переместите фокус на первый элемент. Нажатие “ Shift”+“Tab ” должно обрабатываться зеркально.

Есть и другие варианты обработки перемещения фокуса. Например, вы можете переназначать и использовать в скрипте списки элементов ввода, между которыми разрешён переход фокуса. Или устанавливать tabindex=-1 на скрываемые активные элементы.

Первый и второй методы делают меню и кнопки браузера недоступными при управлении с клавиатуры. При этом походе критичны хорошо заметный элемент закрытия окна и перехват нажатия клавиши “ Esc ” с той же целью. Иначе ваш сайт станет ловушкой для пользователей без мыши.

Третий подход сохранит возможность навигации по элементам управления браузером, но может быть весьма накладным с точки зрения быстродействия скрипта, ведь ему придётся перебрать множество активных элементов на сайте, как при открытии модального окна, так и при его закрытии – чтобы вернуть всем элементам основного контента возможность быть выбранными.

Понятно, что при выборе конкретного метода вы должны учесть все рассмотренные нами факторы.

Закрытие

Если диалог содержит много активных элементов, то гораздо лучше будет дать пользователю возможность закрыть его нажатием одной клавиши, нежели заставлять его пробегать по всем полям, чтобы добраться до кнопки « Закрыть »:

Кроме того, многие разработчики позволяют пользователям закрывать окно щелчком на его свободной области. Для этого можно использовать простой скрипт:

Очевидным исключением из правил будет тот случай, когда вы действительно не хотите, чтобы посетитель продолжал пользоваться вашим сайтом, пока он не введёт нужную информацию в модальном диалоге, скажем, не зарегистрируется или не авторизуется.

Дополнительные меры по обеспечению доступности сайта

Существуют и другие способы помочь пользователям с ограниченными возможностями ориентироваться во Всемирной паутине. Спецификации WAI-ARIA покрывают все области взаимодействия пользователя с сайтом. В одних случаях достаточно немного дополнить разметку или стили, в других требуется оснастить сайт скриптами.

ARIA-HIDDEN

Обратите внимание на весьма специфичный селектор. В общем случае мы не хотим прятать абсолютно все элементы с aria-hidden=true. Вспомните предыдущий пример с кнопкой « X », чтобы понять, что имеется в виду.

ROLE=»DIALOG»

Добавьте свойство role=»dialog» ко всем элементам, содержащим модальный контент. Это укажет так называемым техническим средствам реабилитации, что данный контент требует реакции пользователя. Описанные нами скрипты, зацикливающие перемещение фокуса ввода между допустимыми активными элементами, отлично дополнят эту разметку.

Для оповещений, требующих от пользователя простого подтверждения, используйте role=»alertdialog» совместно с теми же скриптами.

ARIA-LABEL

Как насчёт HTML5-диалогов?

Замечательно то, что элемент dialog обладает не только семантическим значением, но и теми свойствами, которые могут заменить применяемые нами сегодня скрипты и стили.

Например, чтобы показать или спрятать диалог, мы обычно используем такой скрипт:

Метод show() показывает диалог, вместе с тем оставляя пользователю доступ к остальному сайту. Метод showModal() запускает диалог и запрещает пользователю взаимодействовать с другими элементами сайта.

Элемент dialog имеет и другие полезные свойства. Хоть он и не готов пока для использования в массовой разработке, в недалёком будущем он может здорово упростить создание современных, доступных сайтов.

Что дальше?

Разрабатываете ли вы сайт « с нуля » или используете готовые комплексные библиотеки для фронтенда, я в любом случае посоветовал бы вам присмотреться к тому, как ваш сайт может работать для людей с ограниченными возможностями или на нестандартных устройствах.

Модальные окна не являются ключевым элементом современного Интернета, но они всё же достаточно распространены, чтобы попытки сделать их более дружелюбными для всех пользователей стоили затрачиваемых усилий.

Я подготовил демонстрацию модального окна, использующую все вышеперечисленные методы улучшения доступности.

Источник