#детектив дня

Сегодня в чат пришёл подписчик с забавной проблемой.

Дано: форма с двумя полями, одно просто как HTML-тег, второе — React-компонент. Ну, очевидно, компонент тоже содержит поле ввода.

При нажатию на клавишу Ввод событие onSubmit не происходит, форма не отправляется. Хотя, вроде как, всем известно, что это — стандартное поведение.

Было замечено, что при удалении React-компонента всё отлично работает. И первым предположением стало, что React что-то испортил, или песочница кривая.

Кто-то догадался сделать ванильный пример, поведение сохранилось.

То есть, вот такое:

<form onSubmit="alert('aha')">
  <input type="text"/>
  <input type="text"/>
</form>

...просто-напросто не работает. Стали копать.

И докопались до спецификации 1995 года для HTML 2.0!

Вот она: https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2

И там написано следующее:

When the user indicates that the form should be submitted (using a submit button or image input), the form data set is processed according to its method, action URI and enctype.

Перевожу: чёрным по белому сказано, что форма должна отправляться по кнопке submit (или специальной картинке, но то такое).

То есть, наше предположение о том, что форма всегда должна отправляться по нажатию Ввода — уже неверное.

Но, буквально, в следующем же абзаце:

When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.

Так-так-так, а что тут у нас? А тут написано, что единственное текстовое поле — это частный случай и нажатие клавиши ввода должно рассматриваться как отправка формы!

Удивительное рядом, короче. По всей видимости, такое поведение связано с обработкой событий focus и blur, когда полей больше одного.

Короче, так как же решить проблему и не добавлять кнопку?

Очень просто, вставить в форму следующее:

<input type="submit" hidden/>

По-моему, пахнет лёгким бредом, но уж как есть.

И да, за много лет веб-разработки мне ни разу не понадобилась форма без кнопки, но расследование вышло забавным.

#html #form #submit

#заметка дня

Есть такой элемент — template. Название говорит само за себя: это шаблон.

Пишете в него некий HTML/SVG код, потом клонируете и вставляете куда вам надо.

На этом месте апологеты фреймворков ухмыльнулись, но вы же не одни на свете, да?

const content = template.content. firstElementChild.cloneNode(true);

Важно понимать, что содержимое шаблона — это фрагмент (обёртка над реальными нодами, если грубо), поэтому обращаться с ним надо соответственно.

Почему для этой цели не использовать просто скрытый div или — привет из прошлого — script type="text/template"?

Ну второе вообще не в кассу, это просто абьюз. А первое:
- Контент внутри темплейта не будет загружаться, пока не склонирован явно: ни картинки, ни стили, ни скрипты
- Валидатор игнорирует содержимое, хоть dd храните там, хоть td
- Поисковые системы знают про template и точно не индексируют. А с div hidden всё не так однозначно.
- Ну и именование говорит само за себя. Сахар все любят.

#html #template #бородач

#фишка дня

Как подсказать пользователю мобильного устройства, что сейчас произойдёт при отправке формы?

Места на экране мало, ещё и клавиатура съест.

Очень просто! Использовать атрибут enterkeyhint!

Спека: https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-enterkeyhint-attribute

Поддержка: https://caniuse.com/?search=enterkeyhint

Пользуемся!

#mobile #form #html #бородач

#статья дня

Пришло время вспомнить ещё одну статью Ахмада Шадида (Ahmad Shadeed, который не раз всплывал здесь и ещё много раз всплывёт). На этот раз – о важности учитывания высоты в разработке сайтов.

https://ishadeed.com/article/responsive-design-height/

Разработчики часто забывают, что посетители редко используют весь доступный экран. Не только по ширине, но и по высоте. А мода в современных макетах диктует вольготное использование вертикального пространства, но с обязательным условием: “Всё должно влезать в один экран!”. Это, коненчо, бред, но мода есть мода.

Мне не все примеры в блоге нравятся (особенно с модальным окном, я бы предпочёл прокрутку оверлея вместо уменьшения окна), но тему он поднимает важную, хоть и очевидную. Возможно, именно очевидность является причиной, по которой дизайнеры и разработчики игнорируют эту проблему. За деревьями не видят леса — это оно.

Статья есть в переводе на Хабре: https://habr.com/ru/company/skillfactory/blog/524996/

Не забывайте, что макеты должны адаптироваться под пользователя, а не пользователи — под макеты. И выступайте против глупых решений.

#css #html #перевод #бородач

#фишка дня

Сейчас возвращается мода (и, по-моему, это правильно) на сохранение состояния вашего веб-приложения в адресной строке браузера.

Буквально — используя параметры строки запроса (query string parameters).

Ну то есть что-то вроде https://buy.that?title=Product&action=buy&config=2&amount=3, классические GET-параметры, но управляемые с фронта.

А вот как позволить клиенту обновить страницу, сохранив эти параметры? Желательно, без лишней работы и без использования JS вообще.

А очень просто!

<a href="">Reload</a>

Да, вот так просто! Самое классное, что абсолютно валидно и есть в спеках: https://stackoverflow.com/questions/5637969/is-an-empty-href-valid/43340108#43340108

В спеке буквально прописано, что такая ссылка ведёт на текущий документ, со всеми его параметрами запроса.

Не пишите лишнего, котаны!

#http #html #trick #бородач

#заметка дня

#css #html #pp #pixelperfect

Один из самых проблемных вопросов верстальщиков — не обязательно начинающих — это так называемый “пиксель пёрфект” (pixel perfect). Проще говоря, свёрстанный макет должен полностью соответствовать дизайну вплоть до последнего пикселя.

Сейчас справедливо поднимется вой со всех сторон, что в 2021 году верстать с точностью до пикселя не надо, что у нас десятки разных разрешений экранов, множество возможных комбинаций ориентации и устройств ввода. Да и квалификация дизайнеров зачастую вызывает вопросы.

Но всё немного интереснее.

Давайте сразу определимся: правильно свёрстанный макет точен до пикселя по умолчанию. Точка.

Правильная вёрстка экономит время и силы. Даже если вы, как и я, верстаете итеративно, то есть набрасываете крупные блоки и потом начинаете приводить в нужный вид, пишите нужные значения сразу, не откладывая на потом.

У блока стоят поля и отступы по 16 пикселей? Нет ни одной причины ставить 10, чтобы “было легче считать” (и такое бывает), а потом проходить по всему макету заново. Ставьте сразу 16, а чтобы помочь себе — пользуйтесь расширениями для браузера, например https://www.welldonecode.com/perfectpixel/

Конечно, так можно дойти до крайности. Я много раз видел как люди бездумно копируют размеры из Sketch, Avocode или Figma наивно полагая, что уж кому как не им знать о размерах и положении. Это самая большая ошибка, и я уж молчу о том, что редакторы зачастую ставят абсолютное позиционирование всему подряд.

Будьте заранее готовы к тому, что макет – живой. Выделенный блок делится на секции? Используйте проценты во флексах или fr в гридах, делите его относительными единицами. Дизайнер поставил 63 px? Это явно дрогнула рука, не используйте нечётные значения никогда, округляйте до ближайших x4 (в данном случае — 64). Во всех размерах должна просматриваться логика, не могут три кнопки в ряду иметь один размер, а четвёртая – другой.

Почему кратно четырём? Потому что округление в пределах четырёх пикселей вполне укладывается в общепринятое понятие точной вёрстки, но на крайний случай у вас останется ещё как минимум два уровня деления. А при использовании нечётных значений transform или устройства с полуторной плотностью экрана дадут вам размытую картинку (к счастью, последние версии браузеров эту проблему часто решают за нас).

В скором времени я попробую затронуть тему вёрстки изначально неудобных макетов: что делать если вам выдали макет в 1920 пикселей, а большинство ноутбуков до сих пор имеют 1366 и как вести диалог с дизайнером и заказчиком в такой ситуации.

#заметка дня

Сразу с панча: не используйте input[type=“number”].

Он тащит за собой целый ворох проблем:

1. странно выглядит (ниже о том, почему);
2. плохо стилизуется;
3. не подчиняется стандартным атрибутам вроде maxlength (sick!);
4. имеет ARIA-роль spinbutton (ниже поясню, что это);
5. позволяет ввести e (10e9) и валидация даже не заикнётся;
6. в старых Safari и Chrome округляет введённые числа (например, номер кредитки) до мантиссы и экспоненты (по-моему, это уже конец);
7. во время ввода можно случайно нажать стрелку вверх или вниз (или даже тронуть колесо мышки на некоторых ос) и введённое число изменится.

Как видите, минусов немало. А откуда они вообще взялись?

А всё просто: input[type=“number”] создавался для имитации т. н. tally counter, ручного счётчика. Ну вы наверняка видели фильмы, где людей или скот считали надетым на палец устройством. Отсюда и ARIA-роль spinner (счётчик оборотов), и стрелки ввода.

Вот только числа с плавающей запятой или ввод мантиссы и экспоненты — это уже самодеятельность браузеров. Что приводит к идиотичным ситуациям вроде округления чисел.

Так что же делать?

А делать следующее:

<input type="text" inputmode="numeric" pattern="[0-9]*">

В 2024 году с такой конструкцией проблем у вас не возникнет. И с точки зрения доступности всё верно. И на мобильных клавиатура нужная встанет.

Да, это не предотвращает ввод букв, только даёт валидацию. Но вы в любом случае должны задать нужное поведение вашей формы скриптом, от этого никуда не деться. даже с number.

За подробностями можно обратиться к блогу разработчиков официального сайта правительства Великобритании: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

Крайне неожиданно было вообще узнать, что ребята из техотдела правительства Великобритании вообще свой блог ведут на официальных началах.

Я помню подобное было у многих государственных сайтов,. но почти все блоги исчезли со временем...

Подытожим: input[type=“number”] делался не для того, как его применяют.

Подумайте об этом.

#css #html #number #aria #semantics #a11y #бородач

#фишка дня

Многие (к сожалению, не все) кто хоть раз разрабатывал формы, сталкивались с элементом label (лейбл, ярлык, как вам угодно). И знают, что при правильном его использовании пользователю не приходится целиться мышью в галочку или радиокнопку.

Кто-то добавит при этом, что скринридеры могут ассоциировать лейбл с элементом ввода и пользователи с нарушением зрения могут легко сориентироваться в вашей форме.

Но не все знают, что лейбл можно повесить и на элемент button: https://codepen.io/alinaki/pen/XWjLedQ

Да, возможно, кнопке свой ярлык не нужен и даже MDN сообщает нам об этом, но!

Но в лейбл можно добавить дополнительную информацию, которая будет однозначно и семантично связана с кнопкой и поможет, например, скринридерам или при создании тултипа.

Лейблом можно продублировать кнопку без внесения лишней когнитивной нагрузки (но не стоит, фокус он не примет). Пожалуй, для каких-нибудь игровых интерфейсов вполне может быть приемлемо.

А вот если вы не используете кнопки и балуетесь role=“button” на div-ах (в лучшем случае) — этой возможности вы лишены в принципе.

#html #button #label #бородач

#фишка дня

Давайте что-нибудь наболевшее.

Вот, например, если установить атрибут translate="no" на тег, содержащий название компании, то он не подвергнется автоматическому переводу (типа Google Translate): https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/translate

Удобно, если ваша компания называется "Clean Beam" или ещё какая-то подобная глупость.

И вообще, не забывайте на html ставить атрибут lang с верным кодом языка. Вы не представляете, как бесит, когда финские и шведские сайты это игнорируют, и переводчик иногда отказывается работать.

#html #attribute #translate

#фишка дня

Многие (к сожалению, не все) кто хоть раз разрабатывал формы, сталкивались с элементом label (лейбл, ярлык, как вам угодно). И знают, что при правильном его использовании пользователю не приходится целиться мышью в галочку или радиокнопку.

Кто-то добавит при этом, что скринридеры могут ассоциировать лейбл с элементом ввода и пользователи с нарушением зрения могут легко сориентироваться в вашей форме.

Но не все знают, что лейбл можно повесить и на элемент button: https://codepen.io/alinaki/pen/XWjLedQ

Да, возможно, кнопке свой ярлык не нужен и даже MDN сообщает нам об этом, но!

Но в лейбл можно добавить дополнительную информацию, которая будет однозначно и семантично связана с кнопкой и поможет, например, скринридерам или при создании тултипа.

Лейблом можно продублировать кнопку без внесения лишней когнитивной нагрузки (но не стоит, фокус он не примет). Пожалуй, для каких-нибудь игровых интерфейсов вполне может быть приемлемо.

А вот если вы не используете кнопки и балуетесь role=“button” на div-ах (в лучшем случае) — этой возможности вы лишены в принципе.

#html #button #label #бородач