Comments 42
Можно, конечно, назвать это придиркой, но все же:
Это хороший пример, который показывает, что для сложной и действительно удобной для пользователя (а мы работаем на удовольствие наших пользователей), связка pattern+CSS является так себе средством.
А когда мы учтем все необходимые требования к каждому полю, а также (sic!) зависимости между полями, pattern будет неподъемным для понимания по сравнению с парой удобных функций JS.
Тю! Будьте аккуратны: на мобильной клавиатуре iOS по типу tel нет ни скобочек ни пробелов — потому если вы сделаете как предлагает ТС, то вы нахрен убьете часть пользователей, тк с мобильных эту форму невозможно заполнить.
Соответственно надо делать что-то иное.
Таким образом, не прибегая к JS мы с помощью двух строк в CSS смогли...
… подпортить нервы незадачливому пользователю, попавшему на наш сайт.
Ну правда. Не хочу обидеть автора, т.к. при неимении JS это отличный вариант, вот только кто сейчас сидит без JS? Я и 5 лет назад таких не видел в реальной жизни, а сейчас его отключают либо специально и сознательно, либо у них не работает абсолютно ничего. Давайте будем ориентироваться на реальных пользователей и предоставлять им удобные маски, подсказки «по проверке», а не при первом символе и возможность ввести ссылку без протокола.
Если вам так хочется сделать валидацию без JS, просто отпраляете форму и рендерите ошибки на стороне сервера. Там можно и телефон в порядок привести (79181234567 вполне себе валиден) и ссылке приписать протокол (google.ru и https://google.ru/ не отличает 99.9% пользователей).
Это пример уровня hello world. Реалии таковы что в боевых условиях js must have. Conditional validation когда валидность проверяется в купе с другими полями никак не сделать кроме как на js.
На бэкэнде валидировать надо чтобы умельцы всякие курлом туда мусор не гоняли как минимум :)
Тем более, что вот, например, начал вводить я свой электронный адрес, а мне прямо сразу бац — ошибку.
Можно это починить как-то так
input:invalid:not(:placeholder-shown):not(:focus) {border: red}
На JS починить можно, но решение из статьи тут уже не подойдет.
Вы: если поле теряет фокус, давайте перестанем рисовать ему красный бордер.
alix_ginger предлагает как раз обратное: когда невалидное заполненное поле теряет фокус, будем рисовать ему красный бордер.
Вы описываете необходимость и достаточность для корректной работы системы (отсечь мусор). Да, необходимо и достаточно проверять данные на бэкенде, чтобы в систему не попал мусор.
Но с точки зрения удобства пользователя этого может быть не достаточно — в качестве примера fsou11 привел работу приложения в условиях медленной сети, когда отсылка данных для проверки на сервер может занимать непредсказуемое время. Можно поиграть со стратегией проверки (либо отправлять запрос на валидацию после заполнения каждого отдельного поля, либо целиком форму), но пользователю всё равно будет неудобно.
Для удобства пользователя валидация должна быть мгновенной, чего можно достичь только валидацией на клиенте.
А сложности с дублированием и поддержанием эквивалентности логики на клиенте и сервере — это проблемы программиста, а не пользователя.
А если нужно валидировать поля по одному, по мере заполнения формы, то вы тоже будете посылать данные на сервер?
Особенно это важно для удобства длинных форм, чтобы пользователь не убивал много минут на заполнение формы, а получал фидбек по мере заполнения данными.
Вы прекрасно поняли вопрос и теперь строите из себя дурачкаВопрос я понял, и дал на него ответ. А вот как раз Вы начинаете строить из себя дурачка «такой ответ не принимается, условия выдуманные».
В мире мобильных устройств стабильность и скорость интернета — величина непостоянная, тут выдумывать ничего не надо.
Хотите ещё вариант загрузки бандла при хорошей сети, и работе в приложении при плохой сети? Их есть у меня. Берем web-приложение, берем Cordova, публикуемся в стор. Пользователь дома с прекрасным вай-файем ставит наше приложение, и идёт в парк погулять. А там, сидя на лавочке, запускает наше приложение и радуется, что ничего не может сделать, потому что на каждый чих нужен сервер.
мы убедились в том, что приведенное в посте решение — нерабочееЕсли кто-то забыл, то мы обсуждаем не конкретную реализацию, а вопрос, является ли достаточным и необходимым (и для чего именно) выполнять валидацию только на сервере, или она нужна и на клиенте.
Придется реализовывать валидацию с использованием какой-то сторонней либы. Что вызовет рост размера приложения.И что? Да, вызовет. Но пользователю будет при этом удобнее.
Все фронтэндщики одинаковые.
…
Я уже говорил, что все фронтэндщики одинаковые?
Сильно удивлю, если окажусь не фронтэнщиком?
Если кто-то забыл, то мы обсуждаем не конкретную реализацию, а вопрос, является ли достаточным и необходимым (и для чего именно) выполнять валидацию только на сервере, или она нужна и на клиенте.По сути обсуждаемого вопроса что-нибудь будет?
Господи, что за чушь только что я прочиталТогда почитайте для разнообразия про Background Sync.
Валидация это не новость. А вот попробуйте покопаться в autofill/autocomplete, вот где веселье-то.
Уывжаемый аытор! Буквально месяц назад, на РИТ++ был доклад на тему вашего изыскания. Попробуйте найти видео. Там были неплохие примеры работы не только с полями, но и вцелом с формой. Еще и вывод сообщений об ошибках в родной стилизации браузера (а-ля тайтлы для элементов) прикрутить можно.
Я рассматривал частный вариант, но часто вполне достаточный, чтобы без JS быстро валидировать форму и застилизовать ее как того пожелал дизайнер.
Вот не ожидал, что у меня такой тупой проверщик урлов будет… Я надеялся, что хотя бы слеши запросит, а вот нифига подобного, да и после этого заветного для него "http:" можно писать что угодно, хоть скобки, хоть пробелы, хоть слеши, и ладно бы в пути, тк нет, в ДОМЕНЕ, в котором вообще-то запрещены.
Простая валидация формы без JS