Pull to refresh

Comments 20

Интерактивным элементом для открытия диалогового окна должна выступать кнопка.

Во-первых, почему? Всё остальное в посте очень хорошо объяснено, а в конкретно этот момент почему-то просто предлагается поверить. А на мой субъективный взгляд, кнопка наоборот менее семантична чем ссылка.


Во-вторых, а как делать кнопку, если я хочу, чтобы сайт был работоспособен без js? С ссылкой проще было бы. Кнопки закрытия это тоже касается.

Ссылка предполагает переход куда-то. Думая про ссылку, вы можете захотеть открыть её в новой вкладке, например, сохранить или переслать. Я считаю так: если компонент ссылается куда-то (на часть этого документа, на другой и т.д) то он может быть ссылкой. Но если он просто выполняет какие-то действия в пределах текущего документа — тогда это кнопка

Всё именно так — ссылка действительно ссылается на модальное окно и при клике переходит на него, и я на своих сайтах делаю такие модальные окна, которые можно открыть в новой вкладке (тогда вместо модальных окон будут обычные страницы). У моих модальных окон есть отдельные адреса (при наличии JS делаю history.pushState соответственно), и их и в самом деле можно сохранить или переслать :) Так что всё ещё не понял, почему не нужно использовать ссылку

Вы всё правильно делаете :) И в вашем примере, действительно, может использоваться ссылка. Но не все разработчики так хорошо понимают тонкости. Вот именно для тех кто не понимает разницы, или не думает о ней я и написал в столь категоричном ключе. Безусловно есть разные ситуации и исключения, но их понимание должно прийти с опытом.

Окей, тогда буду считать, что я опытный)
За весь остальной пост спасибо, буду подтягивать доступность своих модальных окон

В моей картине мира:

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

Если модальное окно не является диалоговым, т.е. оно несёт новое содержание (форма там например, текст аферты и т.д.) — то по идее можно отдельный роут на него заводить и открывать ссылкой (если говорить про SPA). Т.е. вполне вероятен кейс, когда юзер захочет пошарить это содержимое с кем-то (отправить ему ссылку).
Ссылка позволяет обеспечить переход на страницу с альтернативным контентом — той же формой или иной информацией — на случай сломанного / не приехавшего JS.

Очень хорошая мотивация, но вы упустили важное:


существует тег <dialog>. Его вы и должны использовать

Элемент <dialog> в нынешнем его состоянии использовать не рекомендуется. Почему — рассказывает Скотт Охара.


А что использовать? Например, вот этот компонент Filament Group.


Надеюсь, вы найдёте время поправить пост.

fg-modal, к сожалению, не блокирует перемотку фона

Прошла по ссылке на Скотта Охару, а там такое:

It’s now March of 2022, and Webkit 15.4 has shipped the <dialog> element, as well as Firefox 98. All major browsers now support the <dialog> element, and that’s really exciting.

Please note that you should definitely start (continue) tinkering with the <dialog> element. There are still ongoing discussions about some aspects of the <dialog> element, but things are looking promising.

Слава богу не все ещё разрабатывают только под веб. Можно как-то помечать в заголовке, что статья касается только его? Я блин весь первый абзац прочитал прежде чем понял ( в мобильном интерфейсе теги на нее открытой статье не видно )

Видимо, разрабатывать что-то эффективное теперь моветон. Спасибо, учту на будущее

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

Как бороться с автоматически всплывающей клавиатурой на тач-устройствах?
Если в диалоге предполагается ввод данных, то зачем «бороться» с клавиатурой?
Если не предполагается, то и не будет клавиатуры.
Просто на маленьких устройствах она занимает чуть ли не более 50% экрана. Минус статус-бары браузера и телефона, остаётся очень мало места, как раз для того одного инпута. И зачастую чтобы понять что от тебя хотят, нужно сначала убрать клавиатуру, окинуть взглядом всю форму, поскроллить туда-сюда при необходимости, и потом уже целенаправленно фокусироваться на нужном элементе.

Это я к тому, что на таких тач-устройствах всё-таки автоматический фокус на поле ввода — скорее ухудшит UX, особенно заметно на мамах\бабушках. Оно реально пугает их. Т.е. пока ты ещё не понял что от тебя хотят, а уже что-то вводить нужно.

Мне кажется это камень скорее в сторону дизайна.
Почему вашему пользователю нужно рассмотреть весь диалог, всю форму, чтобы понять что от него вообще хотят? Разве его предыдущие действия не привели его к этому окну? Если вы нажимаете на понятную кнопку "Подписаться" и попадаете в текстовое поле "Введите email" у вас не должно случаться конфуза. Другое дело, когда модалка выскакивает сама по себе, её внешний вид не расчитан на небольшие устройства, тогда да, всё что видит пользователь — одно текстовое поле. Но это не проблема юзабилити а следствие проблемы с дизайном, на мой взгляд.

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

Действительно, могут быть случаи, когда открытая клавиатура перекрывает слишком много, и не понятно, что от пользователя требуется.
вот тут уже должен UI/UX-разработчик хорошо думать.
Кстати, проверил (на Chrome/Android). Сейчас уже атрибут autofocus не вызывает автоматом клавиатуру пока не тапнешь по полю (хотя оно уже в фокусе). Хотя раньше это было. Видимо разработчики браузеров/OS и так к этому пришли..)
UFO just landed and posted this here
Sign up to leave a comment.

Articles