Комментарии 22
Ну надо же, в кои-то веки полезная переводная статья на Хабре!
Устройство может переопределять это поведение, если, например не обнаружит перед фронтальной камерой пользователя.
В оригинале
The device can override these hints if, for example, it doesn't have a user facing camera available
Кажется речь о том, что поведение может быть переопределено не 'например, если пользователя не обнаружит', а 'например, если фронтальная камера недоступна'
Сатанисты одобряют)))
Ладно, шучу, просто на примерах пентаграмма перевёрнутая. Статья хорошая, возьму на заметку.
Заголовок не соответствует действительности. бОольшая часть сайтов используют данные возможности и все реже встречаются сайты с ненастроенными инпутами
Я за 15 лет не узнал про inputmode, а теперь узнал.
Как-то мне для своих нужд была нужна клавиатура с цифрами для ввода цен, я сделал type=tel, а теперь буду знать, как правильно.
А можно было просто MDN почитать.
Чтобы пойти читать MDN, нужно иметь представление, что эта задача в принципе уже решена через атрибуты. Чтобы задать правильный вопрос, нужно уже знать часть ответа.
Золотые слова.
Если вы знали про type=tel, то логично было бы пойти ознакомиться с иными вариантами, а там и на inputmode набрести.
Я знал иные варианты из книги "HTML5. недостающее руководство", в ней про эти атрибуты ничего не было сказано, а на mdn я обычно целиком всю страницу не перечитываю, чтобы вдруг чего-то нового найти. Обычно я смотрю за описанием нововведений в браузерах, но так вышло, что inputmode я нигде не видел.
Вот только для ввода шестнадцатиричных чисел (в hex) и особенно шестидесятеричных (часы, градусы) толком и не предусмотрено. Например, набор шестнадцатеричных чисел показывать либо слитно, либо через пробел, указать банальным свойством какие конкретные числа группировать парой (в особых редких случаях – ещё и порядок этих байт в группе менять местами) или тройкой байт. А то для каждой вводимой "шестнадцатеричной цифры" пиши шаблон, да ещё и учитывание пробела — тьфу… Ибо "разделять" такие числа на разные input-поля – очень плохая идея, уже достаточно наплевались ими с вводом MAC-адресов в маршрутизаторах…
Ну и для шестидесятеричных чисел тоже не помешало бы: показывать запятые или же просто пробелы (с надчёркиваниями или без), с или без надстрочных "прим, секунд, терций, кварт, квинт…", чтоб пользователи сами выбирали, как эти числа им удобнее читать…
для input
с type=checkbox
атрибут readonly
не заработал
там же еще цвет есть, дата, время и еще что-то. и все это тоже меняет внешний вид.
если уж делаете такие статьи, могли бы и все значения описать.
Если вы собираетесь вводить адрес email, установите
inputmode
на@
зачем разбирать такой кейз, если правильно семантически и во всех остальных планах будет использовать type=email
без всяких инпутмодов?
Бывают сторонние библиотеки, которые почему-то работают только с type=text.
Мы пробовали type=email и type=number и отказались в пользу inputmode. Проблема в том, что кроме собачки ещё могут вываливаться совершенно неподходящие валидационные ошибки не в то время не в том месте, появляться лишние стрелочки или всё равно будет позволено ввести какую-то лажу.
Скажите, а как по-вашему, na.me+t.a.g@corp.tld — это валидный email?
Да, вполне валидный
Хм. тогда было бы любопытно взглянуть на примеры, на которых ломалась валидация… не смеха ради, а общего развития для
Скрытые возможности элемента <input>