Pull to refresh

Comments 42

UFO just landed and posted this here
UFO just landed and posted this here

Можно, конечно, назвать это придиркой, но все же:


image


Это хороший пример, который показывает, что для сложной и действительно удобной для пользователя (а мы работаем на удовольствие наших пользователей), связка pattern+CSS является так себе средством.


А когда мы учтем все необходимые требования к каждому полю, а также (sic!) зависимости между полями, pattern будет неподъемным для понимания по сравнению с парой удобных функций JS.

Согласен, пример с вводом телефона сложен для валидации, именно поэтому я указал в статье, что я обычно в этом случае все таки прибегаю к маске ввода с помощью JS плагина. Если мы говорим именно о простой валидации которую можно сделать быстро, из личного опыта могу сказать, что использование паттерна + плагина jQuery Mask Plugin написать быстрее. Однако, цель тут была показать возможности использования атрибута pattern и его реакцию на псевдоклассы.

Тю! Будьте аккуратны: на мобильной клавиатуре iOS по типу tel нет ни скобочек ни пробелов — потому если вы сделаете как предлагает ТС, то вы нахрен убьете часть пользователей, тк с мобильных эту форму невозможно заполнить.


Соответственно надо делать что-то иное.

Спасибо, не знал про такую особенность iOS. Опять же, маска спасает, если мы говорим о номере телефона
Таким образом, не прибегая к JS мы с помощью двух строк в CSS смогли...

… подпортить нервы незадачливому пользователю, попавшему на наш сайт.

Ну правда. Не хочу обидеть автора, т.к. при неимении JS это отличный вариант, вот только кто сейчас сидит без JS? Я и 5 лет назад таких не видел в реальной жизни, а сейчас его отключают либо специально и сознательно, либо у них не работает абсолютно ничего. Давайте будем ориентироваться на реальных пользователей и предоставлять им удобные маски, подсказки «по проверке», а не при первом символе и возможность ввести ссылку без протокола.

Если вам так хочется сделать валидацию без JS, просто отпраляете форму и рендерите ошибки на стороне сервера. Там можно и телефон в порядок привести (79181234567 вполне себе валиден) и ссылке приписать протокол (google.ru и https://google.ru/ не отличает 99.9% пользователей).
… от рендеривать на стороне сервера… только вот данные будем туда сюда елозить ). Лучше уж через JS, а точнее готовое Inputmask.js использовать
Имхо, нужно всегда делать валидацию на сервере вдобавок к валидации на клиенте.
Просто с точки зрения безопасности.

Это пример уровня hello world. Реалии таковы что в боевых условиях js must have. Conditional validation когда валидность проверяется в купе с другими полями никак не сделать кроме как на js.

UFO just landed and posted this here
Валидация на backend не отменяет необходимость валидации данных на froentend если вам дороги серверные ресурсы. И не важно, SPA это или не SPA. Чем раньше пользователь обнаружит ошибку, тем более user-friendly окажется форма (не забываем так же и про принцип fail fast).

На бэкэнде валидировать надо чтобы умельцы всякие курлом туда мусор не гоняли как минимум :)

Добавлю так же, что в случае с валидацией на frontend уменьшается latency и используются ресурсы клиента. Принимая во внимание, что скорость соединения так же может являться bottleneck (возьмём удалённые host'ы или 3G соединения), считаю, что валидация на клиенте это признак хорошего и зрелого приложения, нежели ненужная прихоть.
UFO just landed and posted this here
Говоря про latency я подразумеваю издержки на соединение посредством сети. Выше уже упоминал, что в том случае когда соединение осуществляется посредством мобильного интернета- гонять туда/сюда данные из-за нежелания реализовать валидацию на frontend, на мой взгляд, является признаком плохого тона (как с точки зрения заботы о трафике пользователя, так и времени ответа).
UFO just landed and posted this here
Тем более, что вот, например, начал вводить я свой электронный адрес, а мне прямо сразу бац — ошибку.

Можно это починить как-то так
input:invalid:not(:placeholder-shown):not(:focus) {border: red}
UFO just landed and posted this here

На JS починить можно, но решение из статьи тут уже не подойдет.

Вы: если поле теряет фокус, давайте перестанем рисовать ему красный бордер.

alix_ginger предлагает как раз обратное: когда невалидное заполненное поле теряет фокус, будем рисовать ему красный бордер.
UFO just landed and posted this here
UFO just landed and posted this here
«Необходимость» и «достаточность» — не абсолютные понятия. Они зависят от ответа на вопрос «для чего?»

Вы описываете необходимость и достаточность для корректной работы системы (отсечь мусор). Да, необходимо и достаточно проверять данные на бэкенде, чтобы в систему не попал мусор.

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

А сложности с дублированием и поддержанием эквивалентности логики на клиенте и сервере — это проблемы программиста, а не пользователя.
UFO just landed and posted this here
Почему же не отвечу? Легко. Бандл легко может быть закэширован ServiceWorker-ом при первой загрузке приложения.
UFO just landed and posted this here

А если нужно валидировать поля по одному, по мере заполнения формы, то вы тоже будете посылать данные на сервер?


Особенно это важно для удобства длинных форм, чтобы пользователь не убивал много минут на заполнение формы, а получал фидбек по мере заполнения данными.

Давайте по порядку.

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

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

Хотите ещё вариант загрузки бандла при хорошей сети, и работе в приложении при плохой сети? Их есть у меня. Берем web-приложение, берем Cordova, публикуемся в стор. Пользователь дома с прекрасным вай-файем ставит наше приложение, и идёт в парк погулять. А там, сидя на лавочке, запускает наше приложение и радуется, что ничего не может сделать, потому что на каждый чих нужен сервер.

мы убедились в том, что приведенное в посте решение — нерабочее
Если кто-то забыл, то мы обсуждаем не конкретную реализацию, а вопрос, является ли достаточным и необходимым (и для чего именно) выполнять валидацию только на сервере, или она нужна и на клиенте.

Придется реализовывать валидацию с использованием какой-то сторонней либы. Что вызовет рост размера приложения.
И что? Да, вызовет. Но пользователю будет при этом удобнее.

Все фронтэндщики одинаковые.

Я уже говорил, что все фронтэндщики одинаковые?

Сильно удивлю, если окажусь не фронтэнщиком?
UFO just landed and posted this here
Если кто-то забыл, то мы обсуждаем не конкретную реализацию, а вопрос, является ли достаточным и необходимым (и для чего именно) выполнять валидацию только на сервере, или она нужна и на клиенте.
По сути обсуждаемого вопроса что-нибудь будет?

Господи, что за чушь только что я прочитал
Тогда почитайте для разнообразия про Background Sync.

Валидация это не новость. А вот попробуйте покопаться в autofill/autocomplete, вот где веселье-то.

А это нормально, что в поле «Ваш рост» можно поставить букву «e», но другие буквы нельзя.
Да, символ «e» или «E» является допустимым для ввода в числовое поле и обозначает следующее XeY = X+10^Y. Для примера число 2000000 можно записать как 2e6. Кстати, такую же историю можно использовать и в CSS. Правда я не знаю как хорошо это поддерживается) Хорошая тема, чтобы разобраться и написать статью.

Уывжаемый аытор! Буквально месяц назад, на РИТ++ был доклад на тему вашего изыскания. Попробуйте найти видео. Там были неплохие примеры работы не только с полями, но и вцелом с формой. Еще и вывод сообщений об ошибках в родной стилизации браузера (а-ля тайтлы для элементов) прикрутить можно.

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

Я рассматривал частный вариант, но часто вполне достаточный, чтобы без JS быстро валидировать форму и застилизовать ее как того пожелал дизайнер.
В принципе это можно использовать с поправками alix_ginger'а, чтобы не нервировать пользователя лишний раз. А вот форму с номером телефона я бы по другому реализовал бы. Например с чекбоксом выбора кода оператора, а дальше уже сам номер, но опять же в разных странах отличается.

Вот не ожидал, что у меня такой тупой проверщик урлов будет… Я надеялся, что хотя бы слеши запросит, а вот нифига подобного, да и после этого заветного для него "http:" можно писать что угодно, хоть скобки, хоть пробелы, хоть слеши, и ладно бы в пути, тк нет, в ДОМЕНЕ, в котором вообще-то запрещены.

Sign up to leave a comment.

Articles