Комментарии 9
Я далеко не спец в Веб разработке. Сейчас вот довелось на работе поучавствовать в одном проекте, в котором клиентская часть должна работать полностью в браузере. Проблема всех «любителей» делать красиво состоит в том, что они совершенно забывают и игнорируют многие факты, относящиеся напрямую к юзабилити. В вашем случае жалобы будут со стороны пользователей, которые будут пытаться поменять состояние ваших радио- и чекбоксов- с помощью клавиатуры. Здесь ведь напрочь всеми этими «украшательствами» и «улучшательствами» на корню уничтожена возможность табуляции и смены состояния по пробелу например.
У нас в проекте ситуация такая же: берут к примеру тэг span, лепят к нему свой собственно определенный css — класс .button, который естественно ничего, кроме вызуального соответствия с настоящей push- кнопкой больше не имеет и кроме как мышкой его больше никак не «нажмешь». Потом вылазят такие косяки, например, как не работающий по умолчанию «Ок» в форме при нажатии Enter.
Грустно смотреть на всё это. Выросло поколение, которое другого способа кроме как «тыкать» пальцем в экран, больше ничего не знает.
У нас в проекте ситуация такая же: берут к примеру тэг span, лепят к нему свой собственно определенный css — класс .button, который естественно ничего, кроме вызуального соответствия с настоящей push- кнопкой больше не имеет и кроме как мышкой его больше никак не «нажмешь». Потом вылазят такие косяки, например, как не работающий по умолчанию «Ок» в форме при нажатии Enter.
Грустно смотреть на всё это. Выросло поколение, которое другого способа кроме как «тыкать» пальцем в экран, больше ничего не знает.
Согласен! Вообще, надо прописать свои стили для:
:focus — работа с клавиатурой
:hover — опционально
:active — ощущение, что "нажалось"
Carduelis, согласен с Вами. Но, только отчасти. Мои наблюдения показывают, что тех, кто пользуется клавишами при навигации по сайтам очень мало. И они, как правило, очень специфичны по профессии. Да-да, системщики в том числе.
Выход есть. Просто тут я его не описывал. Можно делать так:
input задавать размеры аналогичные визуальному, а последний позиционировать поверх input.
Выход есть. Просто тут я его не описывал. Можно делать так:
input задавать размеры аналогичные визуальному, а последний позиционировать поверх input.
Да не нужно это. Хватает css-свойства :checked и селектора +/~
<label><input /><i></i><span>Text</span></label>
input:checked + i {
}
input:focus + i {}
input:checked:focus:active ~ span {}Да дело ведь не только в том, что тех, кто пользуется клавишами при навигации мало, дело в том, что ломается полностью весь функционал, заложенный изначально в стандартное поведение предопределенных тегов. Так можно всё одними div-ами запрограммировать. Я же уже говорил в примере с «кнопкой» на форме. Открываешь такой код, а там ещё отдельно функция на клавиатуру, чтобы «ловить» Enter. «Кнопки» то теперь у нас как таковые отсутствуют. А ведь при нормальном подходе в форме было бы достаточно на OnSubmit всё что нужно спокойно обработать без лишнего говнокода.
Когда то я тоже как и вы ставил на input
не делайте так, и никогда не рекомендуйте делать так, если хотите «скрыть», то ставьте
и всегда размещайте input под кастомным элементом, так как браузер проигнорирует этот элемент, при том же флаге required
display: none;не делайте так, и никогда не рекомендуйте делать так, если хотите «скрыть», то ставьте
opacity: 0;и всегда размещайте input под кастомным элементом, так как браузер проигнорирует этот элемент, при том же флаге required
у последних версий Chrome выбранные checkbox стали гнусного цвета цианНачиная с Chrome 83, должны быть ярко-синие. Может быть, тема операционной системы влияет?
Это далеко не единственный способ, может быть вы что-то новое узнаёте:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Еще раз о визуализации input типа checkbox и radio. Для тех, кто забыл как