Можно, но все зависит от вашей задачи. Если у вас есть парочка форм и у вас фокусируются только инпуты (не используются табиндексы), то тогда это хороший вариант. Но формы могут быть динамические(как в моей задаче), тогда нет гарантии, что последний инпут является последним фокусированным элементом и непонятно на какой элемент вешать блокирующий обработчик.
Да, вы правы, но тут тоже есть нюанс. В случае с блокировкой мы знаем точно, что в relatedTarget лежит элемент, который поддерживает фокусировку и он точно был сфокусирован и мы лишь переводим фокус на него, фактически не проводя никаких расчетов. В случае с обсуждаемым вариантом нет 100% гарантии, что следующий для фокусировки элемент должен быть <input />, так как это может быть элемент с проставленным tabindex. В таком случае требуется смотреть все tabindex, исключать 0 и -1, находить наименьший, что возможно тоже может привести к некорректному поведению. Чтобы избежать таких проблем я решил дефолтным поведением сделать блокировку, так как не думал, что круговое перемещение нужно. Из статьи увидел, что это тоже требуется, поэтому хочу реализовать эту возможность опционально. Спасибо за предложение)
Да, это удобный подход. Есть только один нюанс: надо иметь идентификаторы первого и последнего элемента, что ведет за собой дополнительную настройку. В текущем решении блокировка доступна из коробки и не требует ничего, кроме как передать элемент, который надо обернуть «воротами». Как вариант, можно сделать предложенный вами функционал опциональным.
Можно подробнее?) Дело в том, что данное решение нацелено на работу с табами и лишь блокирует некое нативное поведение браузера. Концептуально оно не должно реализовывать логику работы с другими кнопками.
Судя по всему я не умею гуглить, так как в статье похоже описываются инструменты, решающие обсуждаемую задачу. :)
Познавательно, буду изучать, спасибо