Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Хорошая работа, спасибо.
Обязательно буду использовать.
Обязательно буду использовать.
Все бы хорошо, но конкретная реализация в демо мне не понравилась. Почему как только я встаю курсором в текстовое поле, возникает красная подсказка? Причем я не имею ничего против подсказки, но она не должна пугать своим красным фоном — я ведь пока никаких ошибок не делал. Почему бы не показывать ошибки валидации после потери фокуса полем?
И насчет ограничения пароля минимум 8 символами соврали — один символ валидацию проходит.
ЗЫ. ФФ4, последнее демо
И насчет ограничения пароля минимум 8 символами соврали — один символ валидацию проходит.
ЗЫ. ФФ4, последнее демо
что-то мне не нравится пути развития css3 и html5. почему смушивается оформление и поведение?
[input id=«password» pattern="(?=^.{8,}$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*" /]
[input id=«password» pattern="(?=^.{8,}$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*" /]
Может, я что-то не понял, но где в приведённом Вами коде есть смешивание оформления и поведения?
в данном примере то, что заключено в атрибут pattern.
«идеологически», в хтмл должны указываться лишь элементы, а уже через id (для скриптов) или же class (для css) ими можно оперировать как угодно, т.е. указывать необходимые паттерны или же размер шрифта. в данном же случае есть возвращение к html4.1, где бэкграунд задавался через аттрибут background, например.
«идеологически», в хтмл должны указываться лишь элементы, а уже через id (для скриптов) или же class (для css) ими можно оперировать как угодно, т.е. указывать необходимые паттерны или же размер шрифта. в данном же случае есть возвращение к html4.1, где бэкграунд задавался через аттрибут background, например.
паттерн валидации — это поведение, а не оформление
да, в первом посте опечатолсо :)
я про то, что поведение (так же как и оформление) должно быть отдельно от представления.
я про то, что поведение (так же как и оформление) должно быть отдельно от представления.
Ну как бы так объяснить…
Безусловно, они должны быть разделены.
Но вэб идет по направлению разгрузки серверов и переноса части задач на клиента.
Если все это разделять, то нужно было бы добавить еще некую сущность, или какой-то протокол…
Что-то типа HTML/CSS/JS/BP (behavoir patterns), что принесло бы массу проблем и сложностей.
Решение перенести часть поведенческих функций из JS на HTML — возможно спорное, но у него есть некоторые преимущества, как например, обеспечение корректной работы в случае выключения яваскрипта.
Конечно, это не исключает серверную валидацию, но чтобы сделать web app более «rich» и не дергать при этом на каждый чих сервер — самое оно
Безусловно, они должны быть разделены.
Но вэб идет по направлению разгрузки серверов и переноса части задач на клиента.
Если все это разделять, то нужно было бы добавить еще некую сущность, или какой-то протокол…
Что-то типа HTML/CSS/JS/BP (behavoir patterns), что принесло бы массу проблем и сложностей.
Решение перенести часть поведенческих функций из JS на HTML — возможно спорное, но у него есть некоторые преимущества, как например, обеспечение корректной работы в случае выключения яваскрипта.
Конечно, это не исключает серверную валидацию, но чтобы сделать web app более «rich» и не дергать при этом на каждый чих сервер — самое оно
Я тоже считаю, что это спорный момент. Как я это вижу — мы, с помощью регулярного выражения, описали, что мы хотим видеть в данном поле. Согласен, что это влияет на поведение самого поля.
О чем, кстати, можно забыть, а значит это усложняет процесс программирования. Да-с, момент очень даже спорный. Поэтому стоит хорошо подумать, прежде чем все это применять на практике взамен жесткого разделения как сейчас.
О чем, кстати, можно забыть, а значит это усложняет процесс программирования. Да-с, момент очень даже спорный. Поэтому стоит хорошо подумать, прежде чем все это применять на практике взамен жесткого разделения как сейчас.
оно не должно быть «взамен», оно должно быть «в дополнение»
Вот об этом тоже стоит крепко подумать — взамен или вместе? Да, стоит сразу уточнить, что проверку на стороне сервера я не отменял. А вот использовать на стороне клиента одновременно проверку регэкспом и яваскриптом — спорное решение. Изменяем правила проверки — и изменять нужно и регэксп, и яваскрипт. То есть дополнение внешнее может быть(что опять же нагружает функциями оформления яваскрипт), а вот саму операцию проверки на стороне клиента я бы сосредоточил в одном месте.
Надеюсь я правильно понял Ваш комментарий?
Надеюсь я правильно понял Ваш комментарий?
Спасибо, отличная работа! Хотелось бы про возможности валидации поля файл почитать.
Я думаю не хватает тэга alistapart
ИМХО — это спорное направление развития. С одной стороны да, хорошо, меньше велосипедов изобретать придётся и меньше кодить клиентской части. Но опять же немного разное поведение разных браузеров, ну вроде как при валидации url убивает многие эти фичи. Лучше уж самому писать по одним правилам, чтобы работало всегда однозначно.
Да и вообще, при использовании этого всего серверную проверку никто не отменял. Она обязательна. Т.к. существуют инструменты редактирования html кода, а следовательно и правил, прямо в браузере. js может быть просто отключен (крайне редко конечно это сейчас, но мало ли… да и мобильный браузеры не всегда поддерживают это всё).
И потом, программист-новичок не видевший ничего кроме css3 и html5, создаст поле с проверкой в браузере телефона, к примеру. И будет уверен что ему придут только цифры, а не sql инъекция.
Да и вообще, при использовании этого всего серверную проверку никто не отменял. Она обязательна. Т.к. существуют инструменты редактирования html кода, а следовательно и правил, прямо в браузере. js может быть просто отключен (крайне редко конечно это сейчас, но мало ли… да и мобильный браузеры не всегда поддерживают это всё).
И потом, программист-новичок не видевший ничего кроме css3 и html5, создаст поле с проверкой в браузере телефона, к примеру. И будет уверен что ему придут только цифры, а не sql инъекция.
Самому писать по одним правилам не получится хотя бы потому, что бразеры по разному реализуют javascript. Эта статья скорее о будущем, нежели о настоящем. Ни html5, ни css3 пока не являются стандартами. Но как только они таковыми станут, их можно будет использовать и это будет работать в большинстве современных браузеров.
Серверную проверку конечно же никто не отменял, она всегда нужна. То что новички этого могут не понимать, не является проблемой стандрата, это является проблемой отдельно взятых людей.
Серверную проверку конечно же никто не отменял, она всегда нужна. То что новички этого могут не понимать, не является проблемой стандрата, это является проблемой отдельно взятых людей.
И потом, программист-новичок не видевший ничего кроме css3 и html5, создаст поле с проверкой в браузере телефона, к примеру. И будет уверен что ему придут только цифры, а не sql инъекция.
True! Всё изложенное в топике не стоит и гроша, если сервер не (пере)проверяет поступившие данные. :)
AJAX и Flash-формы в этом отношении тоже ощутимо усыпляют бдительность разработчиков.
я думаю что при валидации URL нужно всетаки позволять вводить его без схемы, для большенства людей http, https, ftp и т.д. — просто загадочные буковки, на сервере уже можно проверять урл на наличие схемы, перед этим добавив http:// в фильтре, если схемы нет.
Наверное, в заголовке статьи нужно указать, что эта статья об использовании новых возможностей CSS для валидации форм. А то я уж подумал, тут про супердвижок на, скажем, PHP речь идет :)
Что-то в демке плейсхолдеры как-то убого реализованы и явно не через соответствующий атрибут в HTML5. По крайней мере в Хроме, котоый точно его поддерживает, если дать элементу фокус, увести его и снова вернуь фокус в него — текст плейсхолдера становится текстом в инпуте.
Не стоит забывать про то, что на стороне сервера придется делать все тоже самое.
Иначе пользователь сохранит форму на диск, уберет все ваши чудо-проверки и вуаля!
Иначе пользователь сохранит форму на диск, уберет все ваши чудо-проверки и вуаля!
Последняя демка некорректа в FF — приняло за валидное мыло mail@mail а в поле телефон где 10 цифр, принимает и больше цифр… сыровата эмуляция…
такое оущение, что тот, кто придумал записывать паттерны валидации в html, никогда ничего сложнее hello world не писал.
ведь на стороне сервера тоже придется делать такой паттерн
ведь на стороне сервера тоже придется делать такой паттерн
раз уж всё-равно нужно реализовывать в ручную для старых браузеров, то почему бы не использовать её и для новых? какой профит тут от нативной поддержки перед единообразной?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Развитие валидации форм