Для стилізації в нас є інструменти, але, на жаль, для зручної валідації вводу користувача все ще необхідний JavaScript. Я думаю, що з деякими додатковими можливостями в HTML, ми могли б значно спростити цей процес.
Привіт! Мене звати Робін, і я вже давно займаюсь створенням веб-сторінок. Багато з найкращих користувацьких інтерфейсів, які я створював за роки, дозволяли або вимагали вводу від користувачів. З самого початку Інтернету це робилося за допомогою HTML-форм. Спочатку ці форми надсилались на сервер, де їх валідували, і коли були виявлені помилки, відповідь поверталась назад у браузер.
Email
Ця електронна адреса неправильно відформатована
``` З тих пір, як вперше з'явилися ці форми, було зроблено спроби валідувати їх у браузері до того, як вони потраплять на сервер.
Це дає змогу надавати зворотний зв'язок відвідувачам раніше, дозволяючи їм виправити свої введення до відправки. Додавання регулярного виразу (regex) зробить елемент вводу в CSS стан `:invalid`:
Ця електронна адреса неправильно відформатована
``` Будь ласка, використовуйте кращий regex, але сподіваюсь, що суть зрозуміла. Ось де ми зараз знаходимося на веб-платформі. На жаль, це має кілька серйозних недоліків. 1. Ми виправляємо користувача ще до того, як він почав набирати, набагато краще дати йому шанс спочатку. Надавати негайний зворотний зв'язок до того, як користувач почне вводити, може виглядати нав'язливо і незручне. 2.
Ми не можемо допомогти користувачу детально, наприклад: чи використано незаконний символ, чи забули вони знак @ або чи порожнє поле форми.
3. Навіть коли введення заповнене неправильно, користувач все одно може надіслати форму на сервер.
Цей веб-стандарт має дуже низький рівень впровадження. Більшість вебсайтів використовують JavaScript для валідації. Веб-розробники використовують доступні компоненти або бібліотеки, які спрощують складну валідацію та зворотний зв'язок. Або вони пишуть власну логіку.
Але хіба не було б чудово змогти зробити це без JavaScript?
Я так вважаю. Це допомогло б з доступністю, що забезпечується браузером, збільшило б продуктивність завдяки зменшеному розміру пакету, а також зменшило б ймовірність помилок, оскільки менше коду потрібно писати та підтримувати.
То що нам потрібно?
Все, що йде далі, є гіпотетичним і суб'єктивним. Не очікуйте, що це буде працювати в браузері прямо зараз. Але я думаю, було б чудово, якби все працювало саме так.
По-перше, нам потрібно мати можливість контролювати момент зворотного зв'язку.
Для забезпечення зворотної сумісності я б запропонував два рішення.
...
Це додасть умову на рівні форми, що надсилання буде можливим лише на валідній формі. Коли користувач спробує надіслати будь-які інші дані, це буде заблоковано, після чого браузер має додати стан :submit-blocked до форми. Такий підхід дозволяє мати детальний контроль безпосередньо через CSS, зменшуючи потребу в втручанні через JavaScript. Потім ми можемо показувати зворотний зв'язок користувачу ось так.
form:submit-blocked input:invalid {
border:1px solid red;
/* TODO додати зворотний зв'язок для людей з порушенням кольорового сприйняття */
}
Додатково було б добре, якби браузер міг використовувати хеш-фрагмент для переходу до першого неправильного поля (наприклад, example.com/login#email). Це забезпечить видимість поля, і ми зможемо використовувати селектор :target для додаткового підсвічування.
Це зробить рідні форми набагато зручнішими, ми зможемо попросити користувачів спробувати згідно з нашими інструкціями та надавати допомогу лише в разі невдачі.
Але ми можемо зробити ще краще.
Детальний зворотний зв'язок
Часто для полів є більше ніж одне правило для їх валідності. Для таких полів, як електронні адреси, поштові індекси та паролі, очікується, що вони відповідатимуть певним правилам. Ці правила можна об'єднати в регулярний вираз (regex). Але якщо частина регулярного виразу не проходить перевірку, все поле введення буде позначене як недійсне, і ми не маємо рідного способу дізнатися, яка саме частина не пройшла. Це означає, що ми можемо сказати користувачу лише: "Ви не виконали одне або більше з правил цього списку", без уточнення, яке саме правило не виконано. Щоб бути більш конкретними, нам потрібно мати можливість розділяти правила. Розбиття правил на менші, незалежні одиниці дозволяє нам надавати конкретний зворотний зв'язок для кожного порушення правила, що покращує досвід користувача.
Я думаю, було б чудово, якби ми мали рідну маску вводу для цього.
Я думаю, нам потрібен елемент, подібний до input, який отримує значення з іншого input.
Пароль повинен відповідати таким вимогам:
Не менше 8 символів
Спеціальний символ
Цифра
Коли користувач намагається відправити пароль, він може не пройти перевірку через окремі правила в документі. Атрибути на масці будуть такими ж, як у input, тому ми можемо зробити їх прихованими.
Але з масками вводу ми можемо допомогти нашим відвідувачам ще більше. Ми могли б також інвертувати приховані правила.
і впровадити діапазони в маску.
Маски можуть робити набагато більше таким чином
Таким чином ми можемо створити поле для вводу номеру IBAN (Міжнародний номер банківського рахунку), яке має групи з 4 символів з пробілами між ними.
Оскільки маски застосовуються до одного поля вводу, користувач може продовжувати вводити текст, але код банку та цифри рахунку будуть візуально згруповані. Це допоможе їм, адже саме так ці числа форматуються в прикладі, який вони копіюють. Той самий підхід можна використовувати для телефонних номерів, номерів кредитних карток, кодів MFA та інших подібних випадків.
Інше застосування маски — це відображення поля в різних варіантах.
Наступний приклад показує, як показати і приховати пароль:
Показати пароль
Або ви можете використовувати маски, щоб дані, введені користувачем, з’являлися в іншому місці документа.
Як звуть твого друга?
Чи любить він квіти?
```  ## Як це зробити? Я розумію, що це не охоплює всі екзотичні випадки полів форм, з якими ми стикаємось у браузері, але я впевнений, що це покриє більшість типів введення та проблем з відгуками валідації.
Я знаю це, тому що саме таку логіку я застосовував з TypeScript або JavaScript до цього часу.
Я не знаю, як складно буде реалізувати це в усіх браузерах, але мені хотілося б заглибитися в специфікації браузерів для цього. Це трохи лякає, адже специфікації повинні бути визначені до найдрібніших деталей, і мені потрібно переконати багато людей, що це найкраще рішення. Але я можу спробувати.
Що ти думаєш про ці ідеї? Чи є інші функції, які ти хотів би бачити в рідній обробці форм? Давай обговоримо! Якщо ти маєш досвід роботи зі специфікаціями браузерів, будь-яка допомога буде також дуже цінною!
_П.С. Це моя перша стаття на Medium, помилки перевіряв chatGPT, але будь ласка, будь добрим._
_П.П.С. Я фрілансер, фронтенд/фулстек розробник в Амстердамі і я був би радий допомогти новій компанії вирішити їхні онлайн-завдання._
Перекладено з: [The missing parts for great web forms without javascript](https://medium.com/@reobwuein/the-missing-parts-for-great-web-forms-without-javascript-99ee264ebc47?source=rss------html-5)