Comments 99
Мы их не заслужили, но они нас преследуют везде.
По большей части — навязывая нам какую-то хрень: "вы уже уходите", "мы вам перезвоним", "оставьте ваш емейл"…
На мобильном в последнее время писк — открыть модальное окно без крестика (aka buttone close) — не закроешь — или оставляй телефон, или закрывай сайт нафиг.
Мне уже наплевать в таком случае на скролл.
Из-за такого использования модальные окна давно пора уже внести в bad practices и во всякие блокеры, аналогично window.open
Остановил бы статью на фразе давайте таглить класс со свойствами body { overflow: hidden;} и был бы молодец, но нет.
В разных критериях и манифестах качества есть такой пункт
не я так считаю
Тут больше проблема в том как сдать проект заказчику. Когда он зайдет на сайт, и увидит что при открытии модального окна скачут блоки у него явно будут вопросы.
Если в зависимости от того, видна ли полоса прокрутки, или нет — скачут блоки, дело швах задолго до модальных окон.
Решение .body { overflow: hidden;} — правильное, остальные — сразу в утиль.
Этого не достаточно. Остаются проблемы подёргивания блоков из-за изменения ширины страницы на ширину полосы прокрутки. И проблемы с фокусом не решаются тоже. Если не понимаете о каком подёргивании идёт речь — прямо на этой странице откройте консоль и выполните следующий код:
setInterval(function() {document.getElementsByTagName('body')[0].style.overflowY = document.getElementsByTagName('body')[0].style.overflowY === 'hidden' ? 'scroll' : 'hidden'}, 1024) Вот прямая цитата из комментария, на который вы отвечаете. Выделю жирным, для облегчения понимания.
Если в зависимости от того, видна ли полоса прокрутки, или нет — скачут блоки, дело швах задолго до модальных окон.
Но даже если не учитывать что скролл разный — padding-right для body на место скролла может вёрстку сайта. Просто напросто пользователь может свернуть браузер или переставить его в левую половину экрана и весь сайт обрежется пополам(так как для body стоит overflow:hidden)
Некоторые решения на просторах npm предлагают замену скролла отступом или блоком, который стилизован под скролл (простая серая полоска), много магии, но проблему они не исправляют.
у меня добавление отступа исправляет проблему, что я делаю не так? Да и магии в таком решении явно не больше чем в предложенном. Сейчас попробовал на действующем проекте после скролла страницы в инспекторе добавлять на body:
position: fixed;
overflow-y: scroll;
top: -100px;куча разных артефактов вылазит. Колбасит элементы уже имеющие position: fixed (явно не по причине несовпадения top: -100px с проскроленным значением) и сжимает body по ширине. Со вторым не проблема, нужно ещё width: 100% на body добавлять, а вот что происходит с фиксированными элементами нужно разбираться, но добавление отступа на body проблем не создавало.
если я вижу модальное окно на сайте то это последний раз когда я на него зашёл. есть более изящные способы донести до пользователя важную информацию, только если это не реклама
Последнее китайское предупреждение, в случае необратимых последствий, например, с вашими деньгами — никак иначе не решается (показывать целую пустую страницу с одной кнопкой — так себе альтернатива, а никакую другую отвлекающую информацию туда пихать нельзя по определению).
но к сожалению в этом случае мы увидим маленькие буковки с пятью сносками о том что сайт не отвечает за последствия… вот человек который заработал на адблок думаю заработает не меньше если сделает блокировку модальных окон. ни разу не видел чтобы они использовались с пользой для пользователя
ну да, тут с вами согласен. дело не в самих окнах конечно
Вместо запроса "Вы действительно хотите удалить?" лучше сразу скрывать с глаз пользователя данные и в уведомлении ему сообщить: «в течение такого-то времени вы можете данные восстановить, после они будут удалены навсегда», — а по истечении указанного интервала фактически уничтожить данные.
Именно.
Если это какая-нибудь "корзина" онлайн магазина, то позицию можно не убирать из списка, а зачёркивать/делать еле видимой и поверх неё разместить сообщение "товар удалён, через N секунд он исчезнет с экрана. Восстановить товар в корзине".
Если это какой-то сложный АРМ, где данные нужно убрать с экрана здесь и сейчас, то на странице историй действий оператора можно отдельно выводить доступное к восстановлению (отмене удаления) + в общем списке у того, что ещё не удалено фактически, выводить кнопку "отменить удаление". Или опция "показывать удалённые" на странице с объектами которыми оперирует пользователь.
Это сложнее для "разработать", но удобнее для "использовать". Модальные окна проще "написать", но заставляют пользователей совершать лишние действия. А пользователь лишних телодвижений должен совершать только если он сделал что-то неправильно. Когда человеку необходимо удалить несколько десятков объектов, он лучше пару раз "сходит" в "корзину" восстановить ошибочно удалённые данные, чем несколько десятков раз будет нажимать на "да, я уверен, что хочу это удалить"
В общем случае атрибут "удалено" содержащий дату и время "удаления" объекта и периодически запускаемая задача по удалению "всего, что удалено X минут назад" решают проблему. Излишним усложнением системы это тяжело назвать.
А вообще — да, надо думать и реализовывать. Собственно, это и отличает хороший продукт от основной массы. В одном сели и подумали, а в другом нафигачили как проще.
Да и если удаление достаточно редкая операция, в БД нам придется делать отдельный флаг и везде собственно его проверять.
Так же как гмыло делает с отправкой писем: "перезагружу VM через 10 секунд… отменить | перезагрузить незамедлительно"
если удаление достаточно редкая операция, в БД нам придется делать отдельный флаг и везде собственно его проверять
Или добавить отдельную таблицу, куда добавлять ссылки на объекты для удаления. Много места она не займёт. Или ещё как-нибудь. Смотреть на архитектуру надо.
Не хрен знает где, а во вполне определённом месте. Лучше это тем, что пользователю, которому не критично сию секунду в перезагрузку отправить гостя, не придётся отвлекаться на "да/нет?"
— Папа, а правда, что Windows многозадачная? Покажи!
— Сейчас, сынок, только дискету доформатирую…
Какие угодно. Может даже окно менеджера VM закрыть.
На что отвлекаться?
Неправильно ты, Дядя Фёдор, вопрос задаёшь. Ты о задачах польлзователя не думаешь, а надо их во главе угла держать, так ответ ты и сам найти сможешь.
Чем пользователь занимался до того, как ему VM перезагрузить потребовалось, тем и будет дальше заниматься. Или к другому занятию перейдёт.
Существуют ли сценарии, где пользователь будет нажимать "перезагрузить немедленно"? Существуют. Иначе бы зачем я вам про эту кнопку говорил?
Ровно так же существуют сценарии, где пользователь не будет нажимать эту кнопку. Зачем заставлять 100% пользователей нажимать 2 кнопки там, где можно обойтись одним действием?
Хороший продукт отличает соответствие бизнес-ожиданиям заказчика. Дизайн не вторичен даже, а вообще никому не вперся, кроме горстки людей, не умеющих ни во что, кроме.
Хороший продукт всегда есть продукт соответствующий бизнес-ожиданиям заказчика. Продукт соответствующий бизнес-ожиданиям заказчика не всегда есть хороший продукт.
И да, я не говорю: «модальные окна делают только люди не умеющие ни во что кроме». Почему вы себе позволяете подобные высказывания? Не хватает аргументов?
Почему вы себе позволяете подобные высказывания?
Потому что я свободный человек, живущий в свободном мире. Позволяю себе, знаете ли, что хочу.
любые другие модальные окна есть следствие непродуманности интерфейса
Вы начали с «совета космического масштаба и космической же глупости», потом продолжили советами про интерфейс, даже просто не удосужившись поинтересоваться спецификой бизнеса. Когда человек что-то начинает говорить про плашечки и прокруточки, до того, как он разобрался в бизнес-логике, разговор уже можно заканчивать, потому что результатом будет что-нибудь вроде новой московской схемы метро, которая катком проехалась по всем людям с неидеальным зрением, и отсекла возможность у всех, кто не орел, изучить схему линии, не вставая с места из-за «идеальности шрифта», который теперь чуть не вдвое меньше.
Есть куча бизнес-кейсов, когда переадресация в принципе не вариант, но вы же не спросили сначала «а можем ли мы покинуть страницу в принципе?», вы начали с ультимативного «всегда».
Аргументов у меня полно́, но какой смысл их приводить, если вы их не понимаете, а в ответ цитируете Горбунова и Бирмана? Чтобы нарваться еще на одну цитату из источника, который вообще никаким боком не может быть назван доверенным?
Потому что я свободный человек
Так давайте матом общаться, мы же свободные люди. А потом морды свободно друг другу набьём. Или таки останемся в рамках приличия?
даже просто не удосужившись поинтересоваться спецификой бизнеса
Финансы, аудит, проектирование, производство, творчество? Что это изменит? Бизнес логика никак не влияет на решение "модально или нет". Бизнес описывает последовательность действий и условий, у бизнеса нет модальных окон. UI дизайнер делает интерфейс под эту последовательность, решение "показать поверх модальное окно или отключить возможность изменения данных и вывести сообщение в текущем" принимает дизайнер. И если дизайнер не способен продумать интерфейс без модальных окон, они появляются в мире "бизнеса" и только тогда их выбирает бизнес, т. к. "профессионал" показал, что оно — лучший вариант.
Есть куча бизнес-кейсов, когда переадресация в принципе не вариант, но вы же не спросили сначала «а можем ли мы покинуть страницу в принципе?», вы начали с ультимативного «всегда».
Модальные окна бывают не только в интернете. И доступность переадресации здесь в принципе не играет роли. Что за бред, простите? Вы как-то модальный диалог показываете? Что мешает в том же скрипте, грубо, спрятать кнопку "перевести деньги" и показать кнопки "уточнить данные" и "подтвердить платёж"?
в ответ цитируете Горбунова и Бирмана?
Ну извините, что моё мнение в данном вопросе совпадает с их мнением. Шёл бы разговор о кириллизации названий иностранных компаний — я бы с ними спорил.
Аргументов у меня полно, но какой смысл их приводить
Чтобы ваши слова обрели хоть какой-либо вес в диспуте. Пока же кроме "я не знаю как без модального дива интерфейс платежа оформить" вы аргументов не привели.
Нет такой профессии «дизайнер».
Столяр, строитель, шахтёр — это профессии. Люди, которые хотят остричь все вокруг под горшок своих предпочтений могут быть даже востребованы и оплачиваемы, в некоторых местах, в определённое время. Но профессионалами им не стать никогда, просто в силу этимологии этого слова.
Сообщать пользователю "я удалил" тоже надо не просто для галочки, а так, чтобы он этим смог воспользоваться.
А на тему "конфирм спасёт от случайного удаления" в Бюро в советах давно хорошая заметка была: https://bureau.ru/bb/soviet/20151215/
Я не просто так про это говорю. Обожглись просто.
В свое время мы делали такое в одной популярной корпоративной CRM -системе. Выдавали такое предупреждение не модалкой, а на странице, назовем их «услугами» или «делами». Т.е. пользователь решив отредактировать свои услуги/дела/задачи и удаляя то, что ему как он думает не нужно, мы скрывали сразу, но рядом с кнопками перехода на другие страницы и вверху экрана мы выдавали такое сообщение, как вы и пишите, со ссылкой где данные можно восстановить. Эта же ссылка на восстановление была в личном кабинете пользователя, причем первая сверху.
Так вот тут и вскрылся один нюанс: если пользователь профессионал, то он спокойно все читает и если надо восстанавливает (администраторы, программисты работали без всяких проблем, даже получали фидбэк что им это удобно), но вот если системой пользовался простой пользователь (менеджер, работники call-центра, торговые представители), то у них сразу начиналась паника и вопли «куда все пропало?» и они судорожно закрывали все окна и открывали их заново, естественно «не замечая» ничего. Сделали модалку, тут все вопли прекратились.
Так что я думаю что прежде чем что-то реализовывать, надо изучить целевую аудиторию и уже от этого и исходить.
«Модальность создает фокусировку, не давая людям заниматься другими делами, прежде чем они не завершат задачу или не отклонят вызванное в модальном окне представление» — Apple
Вот еще
Непонимание пользователями произошедшего после нажатия на "удалить" означает, что ваш интерфейс не давал пользователю должного визуального отклика. А технари просто уже готовы тому, что интерфейс не всегда нагляден и что моргнувший значок в левом верхнем углу есть реакция на нажатие кнопки в нижнем правом.
Как быть, если "не заметил"? Не допускать этого. Сообщение о том, что элемент удалён не должно быть таким же как уведомление о новом сообщении (повисело в сторонке и пропало). Повторюсь, из списка услуг можно услугу не сразу убирать, а помечать её удалённой, пока есть возможность восстановить.
Или анимацией показать, что удалённый элемент "улетел в корзину".
ЦА знать надо, но тут есть нюанс. Не одного человека видел, который сначала в браузере набирает одним пальцем "яндекс", потом в яндекс вбивает "сбербанк", потом в выдаче яндекса переходит по ссылке и идёт в личный кабинет. Объясняешь ему, что можно сразу в строку написать "сбербанк" и сразу или на сайт сбера попасть (по подсказке из истории) или открыть ту же выдачу яндекса. Нет — это не так удобно. Это же не значит, что разработчикам браузеров следует идти за привычками подобных пользователей.
Не понял, если честно.
Вот у нас финтех. В какой-то момент пользователь должен подтвердить трансфер на €10М. Предложите, пожалуйста, альтернативу модальному окну.
10 немодальных по €1M?
я бы сделал переадресацию на другую страницу с подтверждением, так безопаснее
так безопаснее
Ровно наоборот, вообще-то. Но дело даже не в этом. Переадресация может сломаться, или занять какое-то время, что в случае, например, обмена валюты по текущему курсу — не вариант.
лучше сломается переадресация чем вывод модального окна. иногда скрипты не вызываются из-за какой-то ошибки до них, и что тогда? так что с точки зрения безопасности (именно неправильного проведения платежа) безопаснее всё-таки отдельная страница с подтверждением, потому что она идёт через отдельный серверный механизм, или даже через отдельный сервер (как в случае банковских платежей с 3D security)
У меня есть предложение: вы не даете беспощадных советов по теме, в которой явно мало, что понимаете, а я больше не спорю.
Спасибо.
у меня есть альтернативное предложение: поскольку это форум инженеров, и мы тут собрались не чтобы меряться мониторами, а чтобы помогать друг другу разобраться в сложных вещах, предлагаю конструктивно указывать на ошибки. просто стандартный генератор кода CRUD Entity framework в visual studio делает именно так — отдельный action для подтверждения удаления — и я понимаю почему. скрипт может не загрузиться и не отработать, скрипты могут быть вобще выключены в целях безопасности, и я вижу недостатки подхода модальных окон. на десктопе там понятно — одно и то же приложение отвечает за всё, поэтому другого подхода нет. а в вебе, где эти окна можно легко заменить на что-то более удобное и безопасное. в том виде в каком модельные окна используются сейчас в 99% случаев они только раздражают, как мне кажется. если вы видите в моих рассуждениях какую-то техническую ошибку, подскажите мне пожалуйста в чём я не прав и как правильно. если вы просто не хотите со мной общаться можете просто не отвечать на этот комментарий и на все другие
Заблокировать поля ввода и немодально вывести кнопки «Подтвердить платёж» и «Скорректировать данные» на той же странице.
Если пользователь хотел перевести деньги — он нажмёт кнопку подтверждения. Если пользователь опечатался — нажмёт на кнопку изменения данных, чем разблокирует форму и снова "перевести"→"подтвердить".
Если пользователь не хочет этот трансфер — он первым же кликом перейдёт на другую страницу по любой из ссылок в личном кабинете. С модальным окном ему придётся сначала закрыть это окно.
Если пользователь захочет уточнить какие-то данные (историю переводов, реквизиты получателя, основание трансфера) — он в новой вкладке откроет другую часть личного кабинета, уточнит данные и подтвердит платёж вернувшись во вкладку с трансфером. В случае с модальным окном ему придётся сначала закрыть окно, потом сходить за данными, потом заново открывать модальное окно и только тогда подтверждать платёж.
Заблокировать поля ввода и немодально вывести кнопки «Подтвердить платёж» и «Скорректировать данные» на той же странице.
Через 10 минут, после того, как мы это прикрутим, middle office будет блокирован шквалом звонков от пользователей «у меня все зависло, памагите!». Появившиеся кнопки заметит 10%. Для того, чтобы об этом узнать, достаточно один раз провести AB тестирование.
Если пользователь не хочет этот трансфер
Пользователь хочет, инфа 100%.
он в новой вкладке откроет другую часть личного кабинета
Пользователи примерно никогда не открывают ничего в соседней вкладке. Вы бы хоть UX статистику какую-нибудь посмотрели, прежде чем советовать.
Для того, чтобы об этом узнать, достаточно один раз провести AB тестирование.
Вы его, конечно, провели. Результатами и их анализом поделитесь? Ну и было бы неплохо посмотреть на реализацию, чтобы исключить проблему в её некорректности.
Результатами я поделился в комментарии, на который вы отвечаете. Анализ мы не делали, мы наивно решили, что если 9 из 10 человек предпочитают модальный диалог, велосипед мы изобретён где-нибудь в другом месте.
Если «мы не пойми как (возможно очень криво) сделали, и у нас не зашло» — результаты. То извините…
У нас 10 из 10 человек предпочитают, чтобы интерфейс лишний раз не блокировался без причины.
Ваши "результаты" против наших "результатов".
интерфейс лишний раз не блокировался без причины
О, а вот и передергивания в ход пошли. Никто не предлагал сделать весь интерфейс на модальных окнах. Но вы не понимаете причин (возможно, оттого, что не удосужились заметить разницу между сайтом и транзакционной платформой), и невзирая на это, бросаетесь сломя голову давать советы, грести под одну гребенку, и обобщать.
Под «Без причины» я понимаю «наш дизайнер не способен решить задачу грамотно, поэтому лепит модалки», а не отсутствие причины.
Как контраргумент оправдывающий существование модальных окон: запрос повышения прав. Здесь приложение не может дальше функционировать, пока пользователь не предоставит приложению больше прав через средства операционной системы. В остальных случаях ничего не мешает лучше продумать сценарии использования и реализовать удобный интерфейс.
По себе судите? Минусов столько поставить у меня запаса голосов не хватило бы. Так что это не я. А те несколько, что я поставил — исключительно за манеру общения с переходом на личности вместо конструктивного обсуждения, а не за отличное от моего мнение. И те, если не изменяет память, не вам.
Я с вами диспут пытаюсь вести, считая, что мы в IT сообществе технические аспекты обсуждаем, а вы тут базар устраиваете. Поэтому первую часть вашего комментария оставлю без ответа.
Если не помещается — что делать?
Очевидно, нужно переводить фокус на элемент "отредактировать". С фокусом браузер сам вам прокрутит.
Если не помещается — что делать?
Давай ТЗ и бюджет — обсудим, что делать в вашем конкретном случае. Разработчику голова дана не чтобы код копипастить шаблонный, а чтобы удобный инструмент для решения задач пользователей предоставлять.
я еще могу кучу проблем найти в таком примере, которых модалка не имеет.
Не стесняйтесь, оглашайте.
Я написал выше про проблемы со скролом
Это надуманные проблемы. Или проблемы вызванные плохой информативностью интерфейса.
когда разработчику дают задачи дизайнера начинается такой треш как у вас
А я — дизайнер, или разработчик? И какой треш? Я вам выше ссылку на Илью Бирмана давал. По данному вопросу я с ним солидарен. У него в голове тоже треш из серии "погромист в дезигнера играет"?
Но зачем блокировать прокрутку при открытом модальном окне? Это же наоборот удобно...
Вы меня простите за категоричность, но единственный способ сделать нормальное модальное окно — никогда не использовать модальные окна, исключение есть только для окна ОС с запросом пароля пользователя для повышения прав приложения, и то не факт.
Что «последние китайские предупреждения», что любые другие модальные окна есть следствие непродуманности интерфейса.
любые другие модальные окна есть следствие непродуманности интерфейса
Всегда любил веские, взвешенные, хорошо аргументированные, пуленепробиваемые аргументы. Жаль, что они так часто оказываются ахинеей.
Подобный аргумент на статью потянет, а то и не на одну.
Но если хотите, можете назвать ситуацию, где без модального окна ну никак не обойтись, я вам постараюсь ответить как сделать без него и лучше.
Завершение работы системы с открытым приложением, в котором есть несохранённые данные.
Что значит «есть несохранённые данные»? Если пользователь сутки трудился над проектом и у него электричество пропало, всё? Конец проекту?
Пользовательские данные — самое ценное, что есть на компьютере. Их нужно сохранять всегда. Вы либо делаете резервную копию оригинального файла, либо изменённый файл храните "у себя". Пользователю сообщаете «вы тут в прошлый раз не сохранили… а я изменения помню, могу сохранить сейчас. Или не надо?». Только делать это надо не как офисные пакеты, которые вываливают модальное окно "восстановить файлы?". Я сейчас другой документ открыть попытался, что ты ко мне пристаёшь? Выведи плашку сверху\сбоку, как будет возможность — приму решение.
И в настройки добавить "сохранять все изменения сразу", тогда можно просто всегда сохранять.
Пользовательские данные — это, в частности, открытая транзакция между нашим сервером и liquidity provider. Этих данных на клиентской машине нет, и быть не может.
Или вот другой вариант: у клиента установлена максимальная сумма транзакции в день, скажем, сто рублей. И три оператора. В разных странах. Все трое одновременно размещают заказ на 40 рублей. Третья по времени транзакция пройти не сможет (это знаем мы), но если вторую транзакцию отвергнет liquidity provider, то — снова сможет. Если мы переадресуем третьего пользователя куда-нибудь, то что делать, когда сервер поймет, что надо снова показать заленую кнопку? Серия редиректов? Ну-ну.
Поймите вы, наконец, что бложег для трех человек, и B2B — это разные вещи. И для B2B надо смотреть, что нравится вашим пользователям, а не что советуют люди, познающие мир по оформлению трамвайных билетов.
Этих данных на клиентской машине нет, и быть не может.
Если данных на клиентской машине нет — то всё ещё проще: сохранять-то нечего :-)
Если мы переадресуем третьего пользователя куда-нибудь, то что делать, когда сервер поймет, что надо снова показать заленую кнопку?
А что, собственно, помешает её показать?
то всё ещё проще: сохранять-то нечего
Данных-то нет, состояние-то есть.
А что, собственно, помешает её показать?
То, что в случае без модального окна — мы на странице с ошибкой из-за редиректа до этого. Прокрутка к «вспыхнувшей» кнопке, предложенная где-то вокруг — это просто ад, который не поймет ни один пользователь.
То, что в случае без модального окна — мы на странице с ошибкой из-за редиректа до этого
Так предусмотрите для пользователя возможность вернуться обратно-то!
Серьезно? Показать «мы не можем выполнить транзакцию», а потом спустя пять секунд сказать «а нет, шутка, можем»? И куда кнопку «вернуться» воткнуть? Вниз и снова блистательный вариант прокрутки к ней? Поверх всего — модальным окном?
Вы действительно хотите, чтобы из-за дизайнерских изысков пользователи считали нас дебилами?
Серьезно? Показать «мы не можем выполнить транзакцию», а потом спустя пять секунд сказать «а нет, шутка, можем»?
А разве не именно это вы делаете модальным окном? По вашему описанию я понял именно так.
Если модальные окна используются как-то по-другому — то расскажите как именно.
Мы показываем throttle на некоторое время, потом сообщаем о проблемах со связью и предлагаем подождать, если пользователь хочет. Когда мы получаем подтверждения по всем ранее запущенным транзакциям, показываем кнопку «выполнить», или «недостаточно средств» в зависимости от того, что там вернулось. Пользователь уютно продолжает думать, что он страницу не покидал, все под контролем, процесс идет.
Это последний комментарий, который я пишу в этой ветке (и, скорее всего, вообще), потому что, оказывается, у меня теперь не хватает кармы комментироват столько, сколько мне хочется.
Буду заниматься тем, ради чего и завел этот аккаунт: писать про Elixir.
Это что за B2B система у разработчиков которой "либо модальное окно, либо редирект"?
Рядом с кнопкой подтверждения написать "выполняю транзакцию" — вообще не вариант? Это даже дешевле будет с точки зрения ресурсов.
Или "что-то где-то зависнуть" может, а с модальным окном сразу все проблемы уходят?
Вы пытаетесь бизнес логикой оспорить оформление наглядного представления этой же самой логики. Если без "спрятать от пользователя всё, кроме одного сообщения" — это единственный способ донести информацию до пользователя, значит у вас интерфейс перегружен и\или нелогичен.
От вас не дождался примера в этой ветке. Ответил выше вам, + в соседней ветке: https://habr.com/ru/post/483114/#comment_21101194
Думаю эта проблема будет в малом количестве проектов, но обратить внимание на нее стоит. Например на сайте много баннеров которые на всю ширину страницы то справа сайт будет пустое пространство, которое портит общую картинку. В любом случае через стили это можно будет решить.
offScrollUnderBlock(_overlay) {
var _clientY = null;
_overlay.addEventListener("touchstart", function(event) {
if (event.touches.length === 1) {
_clientY = event.touches[0].clientY;
}
});
_overlay.addEventListener("touchmove", function(event) {
if (event.touches.length === 1) {
disableRubberBand(event);
}
});
_overlay.addEventListener("mousewheel", function(event) {
if (parseInt(event.wheelDelta || -event.wheelDeltaY) >= 0) {
if (_overlay.scrollTop === 0) {
event.preventDefault();
}
} else {
if (isOverlayTotallyScrolled()) {
event.preventDefault();
}
}
});
function disableRubberBand(event) {
var clientY = event.touches[0].clientY - _clientY;
if (_overlay.scrollTop === 0 && clientY > 0) {
event.preventDefault();
}
if (isOverlayTotallyScrolled() && clientY < 0) {
event.preventDefault();
}
}
function isOverlayTotallyScrolled() {
return (
_overlay.scrollHeight - _overlay.scrollTop <= _overlay.clientHeight
);
}
}
Здесь мы получаем легкое подергивание страницы. Код. Стоит отметить: проблема встречается только там, где скролл занимает место на странице, например, в Safari такой проблемы нет.
Chrome/Firefox, MacOS — никакого подергивания, все ОК. Насколько я знаю нa маке во всех браузерах по умолчанию полоски скролла скрыты.
Добавлю несколько советов от себя касательно доступности.
Заблокировать скролл, это наименьшая проблема. Куда важнее не выпускать фокус за пределы всплывающего окна.
При открытии модального окна, нужно обязательно переместить фокус на него. Чтобы скринридеры или ещё что — озвучили, что фокус сместился и куда. Да и при использовании какого-то телевизора, вам не придётся проходить табами всю страницу в поисках как добраться в модальное окно.
Обязательно использовать тег
<dialog>
Или секцию с соответствующей ролью
<section role="dialog">
Это нужно для того, чтобы ваш блок был семантически опознан как "Диалог".
Внутри модалки, обязательно нужен заголовок. Пусть даже скрытый, чтобы те же скринридеры и ТП озвучили что это за модалка
<section role="dialog"> <h2 class="show-screen-reader-only">Подтвердите действие</h2> </section>
Если логика модалки предполагает возможность закрыть его без подтверждения (по типу клика на крестик, или клик по кнопке "Отменить") то эту же функциональность необходимо назначить на клик по клавише esc. Так как во многих системах такое поведение является обычным и привычным пользователю. И его необходимо реализовывать в ваших кастомных модальных окнах.
Если модалное окно подразумевает отправку каких-то данных, то внутри обязательно должен быть тег
<form>, а саму модалку стоит автоматическии закрывать после успешной отправки данных.
После закрытия модалки, если вы никуда не перенаправляете пользователя, фокус необходимо вернуть туда, где он был на момент открытия модального окна. Сами понимаете, это выбесит любого, если вы перемещаетесь по странице табами, были где-то в середине, открылось модальное окно, а после него вас отправило в начало страницы. И вам снова табать по всему документу в поисках места где вы были.
Бонус: Все скрипты и стили, необходимые для модального окна выносите в отдельный файл. И загружайте непосредственно перед тем как отобразить модалку. Никогда не включайте её в общий бандл.
<body>
<input id="input" type="checkbox" hidden>
<div class="root">
<p>Lorem ipsum ...
<p>Lorem ipsum ...
<p>...
</div>
<div class="modal">
<div class="c1"><div class="c2"><div class="c3">
<p>Ahtung!
<label for="input"><button>Achtung?</button></label>
</div></div></div>
</div>
</body>* {
margin: 0; padding: 0;
line-height: inherit; font: inherit;
}
html, body, .root, .modal {
position: absolute;
top: 0; right: 0; bottom: 0; left: 0;
overflow: hidden;
}
body {
text-align: center;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
}
.root {
overflow-y: auto;
}
.modal {
right: -16em; left: -16em;
}
.c1 {
display: table;
width: 100%; height: 100%;
}
.c2 {
display: table-cell;
margin: 0 auto; vertical-align: middle; text-align: center;
}
.c3 {
display: inline-block;
margin: 0 auto;
width: 32em; height: 8em;
background: #ccc;
}Смысл: Контент выводится не в body, а в root. Два абсолютных блока, root и modal. В body есть скрытый input. Body не имеет прокрутки вообще. Root имеет прокрутку когда нужно. Modal не имеет прокрутки. Modal лежит поверх root-а.
Кнопки завязаны через лейблы на input и делают видимым/невидимым modal посредством input-а тупо через css. Ровно так же включается/отключается через css свойство user-select там где это нужно.
Это всё давно делается через css. Убогие скрипты тут совершенно никому не нужны.
Все каменты просматривать совершенно лень.
Накидано за минуту. Сами доделаете, кому нужно.
Модальные окна, которые мы заслужили