Comments 22
А почему обратно фокус-то возвращаете (не говоря о сомнительности задачи, но тут уж какое вам задание дали...)? Привычное поведение в формах (в нативе) – фокус бегает по кругу, т.е. после последнего элемента – на первый и наоборот.
Спасибо, интересное замечание. Про бег по кругу не задумывался. Этот вариант надо будет продумать и реализовать.
Обычно используют обход по кругу, реализовывается через 2 скрытых элемента: jsfiddle.net/dipish/F82Xj
2 элемента нужно чтобы работал обход в обратную сторону по Tab+Shift. Как видите, JS-кода тут совсем мало.
2 элемента нужно чтобы работал обход в обратную сторону по Tab+Shift. Как видите, JS-кода тут совсем мало.
Да, это удобный подход. Есть только один нюанс: надо иметь идентификаторы первого и последнего элемента, что ведет за собой дополнительную настройку. В текущем решении блокировка доступна из коробки и не требует ничего, кроме как передать элемент, который надо обернуть «воротами». Как вариант, можно сделать предложенный вами функционал опциональным.
Вы уже знаете первый и последний элементы – это два невидимых контрола. А первый и последний видимый – это тот, что за первым, и тот, что перед последним.
Да, вы правы, но тут тоже есть нюанс. В случае с блокировкой мы знаем точно, что в relatedTarget лежит элемент, который поддерживает фокусировку и он точно был сфокусирован и мы лишь переводим фокус на него, фактически не проводя никаких расчетов. В случае с обсуждаемым вариантом нет 100% гарантии, что следующий для фокусировки элемент должен быть <input />, так как это может быть элемент с проставленным tabindex. В таком случае требуется смотреть все tabindex, исключать 0 и -1, находить наименьший, что возможно тоже может привести к некорректному поведению. Чтобы избежать таких проблем я решил дефолтным поведением сделать блокировку, так как не думал, что круговое перемещение нужно. Из статьи увидел, что это тоже требуется, поэтому хочу реализовать эту возможность опционально. Спасибо за предложение)
А это вы видели? habr.com/ru/post/338130
Стоит отметить, что здесь отсутствует «ES6+» синтаксис, так как в основе лежит идея поддержки кода различными браузерами без подключения библиотек типа «Babel».
Babel — транспайлер, а не библиотека.
Не хватает перехода между элементами по Enter — у меня как-то просили такое поведение :)
Можно подробнее?) Дело в том, что данное решение нацелено на работу с табами и лишь блокирует некое нативное поведение браузера. Концептуально оно не должно реализовывать логику работы с другими кнопками.
Такой подход может сломать UX, всё же большинство привыкло что по Enter происходит сабмит формы.
Патчить нативный UX не самая лучшая идея: как выйти из этой формы не следующую? Как-то ради спортивного интереса писал навигацию с клавиатуры по всем интерактивным на странице. Идея в том, что внутри любой формы/менюшки навигация происходит стрелками клавиатуры и зацикливается также как в вашем примере. Навигация по Tab, Shift+Tab не патчится и ведет себя нативно. Еще вариант табом бегать только по формам/менюшкам, а внутри их стрелками клавиатуры.
Вообще об этом есть спека www.w3.org/TR/wai-aria-practices/#keyboard (даже с живыми примера)
Принцип наименьшего удивления не работает в данном решении
Что-то я не очень понял.
Зачем скрытые поля? Разве нельзя было просто запретить обработку нажатия tab по условию фокуса на последнем инпуте обычным return false?
Зачем скрытые поля? Разве нельзя было просто запретить обработку нажатия tab по условию фокуса на последнем инпуте обычным return false?
Можно, но все зависит от вашей задачи. Если у вас есть парочка форм и у вас фокусируются только инпуты (не используются табиндексы), то тогда это хороший вариант. Но формы могут быть динамические(как в моей задаче), тогда нет гарантии, что последний инпут является последним фокусированным элементом и непонятно на какой элемент вешать блокирующий обработчик.
Sign up to leave a comment.
Улучшение UX при работе с клавишей «Tab»