Comments 42
И главное — не забываем на сервере валидировать входящие данные :)
За статью спасибо.
За статью спасибо.
Это конечно интересно, но без поддержки остальными браузерами и без возможности по своему отображать ошибку, вряд ли есть какая-то польза.
Crome в dev-версии и Opera 11.01 это уже поддерживается. В iOS Safari есть очень ограниченная поддержка, которая скорее влияет пока на ввод данных: если поле имеет тип email, то на виртуальной клавиатуре появляется собачка, если же url, то .com.
Насчет ios не знал, но задавался вопросом, как он определяет когда емейл, а когда нет :-) Спасибо.
А насчет оперы, в ней тоже нельзя кастомизировать отображение ошибок?
А насчет оперы, в ней тоже нельзя кастомизировать отображение ошибок?
В HTML5, по моему, вообще это не предусмотрено, считается, что пользователь пользуется одним обозревателем и привыкает к отображению ошибок. Особенно актуально для портативных устройств с небольшим экраном, где дизайнерские изыски могут затруднить чтение. В «бесконечном» HTML есть setCustomValidity, но там можно лишь указывать свой текст.
«Опера» года два уже это поддерживает, если что.
Хотя довольно уродливо.
Хотя довольно уродливо.
required в Опере работает уже пару лет как минимум)
Статус поддержки HTML5 форм разными браузерами: wufoo.com/html5/
<irony>IE, как всегда, впереди планеты всей. Интересно, почему MS не публикуют таблички типа этих в своих «независимых сравнениях»?</irony>
<irony>IE, как всегда, впереди планеты всей. Интересно, почему MS не публикуют таблички типа этих в своих «независимых сравнениях»?</irony>
А идея-то хорошая! Даёшь поддержку в остальные браузеры!
Не даешь. Главная проблема веба — это слоупочная поодержка его плюх разными браузерами. Поясню. Как это не печально, но моду задает ИЕ, точнее всех тормозит. Если в нем че то не поддерживается, то нет смысла делать несколько путей (хороший путь для новых браузеров, джаваскрипт-костыль для ИЕ). Потому что время — деньги да и неудобно плодить несколько путей. И поэтому разработчики, верстальщики выбирают 1н путь, но работающий везде. Будучи верстальщиком, могу сказать, что я только сейчас начинаю более менее часто использовать селлектор «E > E», потому что отмирает ИЕ6, который его не поддерживает. А ИЕ7 будет жить еще ооооочень долго, как и ие8. Сейчас объясню почему. На самом деле, моду задает не ИЕ, а виндоус с дефолтным браузерам. В США ИЕ6 12%. Это легко объяснить тем, что большинство компаний не видит смысла платить за 7 или висту, которые фактически кроме свистоперделов приносят тока увеличение аппаратных требований. А большинство тамошних работников вообще не знаю такого понятия, как «браузер».
И поэтому мы имеем, что имеем. Итак, ИЕ6 вроде подыхает, но еще дергается. ИЕ7 — браузер мертворожденной висты. ИЕ8 — браузер более менее сносной 7ки. И с ним мы будем дольше всех возиться, т.к. он еще и максимально доступный браузер в windows XP. Так что обо всяких SVG, canvas, html5, валидациях можно вообще пока не думать. Но это еще не самое печальное. Самое печальное будет дальше. ИЕ9 на момент выхода был уже хуже того же FF 3.6. Он не держит не только новые формы полей, но и еще много чего, например text-shadow. В результате, развитие веба было и будет ооочень тормозным процессом. На этот фоне, я даже рад некоторому доминированию маков в США, у них хоть сафари есть. И тем более на фоне таких перспектив ппц как рано говорить, что флеш костыль, да здравсвует хтмл5.
И поэтому мы имеем, что имеем. Итак, ИЕ6 вроде подыхает, но еще дергается. ИЕ7 — браузер мертворожденной висты. ИЕ8 — браузер более менее сносной 7ки. И с ним мы будем дольше всех возиться, т.к. он еще и максимально доступный браузер в windows XP. Так что обо всяких SVG, canvas, html5, валидациях можно вообще пока не думать. Но это еще не самое печальное. Самое печальное будет дальше. ИЕ9 на момент выхода был уже хуже того же FF 3.6. Он не держит не только новые формы полей, но и еще много чего, например text-shadow. В результате, развитие веба было и будет ооочень тормозным процессом. На этот фоне, я даже рад некоторому доминированию маков в США, у них хоть сафари есть. И тем более на фоне таких перспектив ппц как рано говорить, что флеш костыль, да здравсвует хтмл5.
Так что обо всяких SVG, canvas, html5, валидациях можно вообще пока не думать
Почему же, если проект сильно ориентирован на использование html5, можно выдавать IEшникам окно с просьбой установить Google Chrome Frame. И волки сыты (сайт нормально отображается), и овцы целы (chrome frame — плагин, а не браузер).
Да и процент людей, которые используют IE в СНГ, к счастью, довольно мал.
Покажите мне хоть 1ин проект, ориентированный на хтмл5, который зарабатывает деньги. Всякие поделки вроде chrome experements, не более. В серьезном продакшене это еще не скоро будет. Даже gmail в ИЕ6 прекрасно работает (неупрощенная версия).
> Да и процент людей, которые используют IE в СНГ, к счастью, довольно мал.
мал?? Суммарно он не менее 25% (6,7,8).
www.liveinternet.ru/stat/ru/browsers.html
> Да и процент людей, которые используют IE в СНГ, к счастью, довольно мал.
мал?? Суммарно он не менее 25% (6,7,8).
www.liveinternet.ru/stat/ru/browsers.html
А еще поддержку нативного «ползунка» (spinbox) и календаря(date pickers) (который пока тока в Opera работает) когда добавтя, вообще наступит рай.
Имхо, нативный календарь будет слишком сложен (или вообще ограничен) для кастомизации, так что все равно придется использовать кастомные календари.
В опере вполне симпатично и нативно для оперы.
Но бывают задачи (а точнее, их абсолютное большинство), когда нужно нативно не для оперы (хрома, фокса и прочего), а нативно для сайта на котором этот календарь.
Никто же не заморачивается внешним видом alert'ов или диалога выбора файлов или внешним видом диалога http аутентификации. ИМХО, это из той же оперы.
Уверенны?
Почему тогда на той же хабре вместо алертов используют синие и розовые окошки в правом верхнем углу? И на очень многих сайтах предпочитают отрисовывать диалоги с помощью некоего прозрачного(и не сильно прозрачного) дива, который блокирует другие элементы страницы и другого дива, который содержит заголовок, текст и несколько кнопок (например, «Ок» и «Отмена»). На вскидку пример — ВКонтакте. Там ни одного алерта, но множество диалогов, которые выполняют такую же функцию, но выглядят лаконично с дизайном сайта.
Диалог выбора файлов? Тут выбора нет. JS по причинам безопасности не имеет доступа к локальной файловой системе, а стандартный диалог кастомизировать просто невозможно. Была бы возможность, поверьте, заморачивались бы за милую душу.
http аутентификация? Если никто не заморачивается, то зачем вообще на сайтах делают формы входа, если можно просто выдавать этот диалог аутентификации? Правильно, потому что свою форму можно как угодно разрисовать с тем чтобы выглядело «в тему» дизайну. Кстати, а где сейчас особо этот диалог можно встретить? Особо и нигде. Разве что при ftp сессии в браузере, но там уж не до дизайна в принципе.
Почему тогда на той же хабре вместо алертов используют синие и розовые окошки в правом верхнем углу? И на очень многих сайтах предпочитают отрисовывать диалоги с помощью некоего прозрачного(и не сильно прозрачного) дива, который блокирует другие элементы страницы и другого дива, который содержит заголовок, текст и несколько кнопок (например, «Ок» и «Отмена»). На вскидку пример — ВКонтакте. Там ни одного алерта, но множество диалогов, которые выполняют такую же функцию, но выглядят лаконично с дизайном сайта.
Диалог выбора файлов? Тут выбора нет. JS по причинам безопасности не имеет доступа к локальной файловой системе, а стандартный диалог кастомизировать просто невозможно. Была бы возможность, поверьте, заморачивались бы за милую душу.
http аутентификация? Если никто не заморачивается, то зачем вообще на сайтах делают формы входа, если можно просто выдавать этот диалог аутентификации? Правильно, потому что свою форму можно как угодно разрисовать с тем чтобы выглядело «в тему» дизайну. Кстати, а где сейчас особо этот диалог можно встретить? Особо и нигде. Разве что при ftp сессии в браузере, но там уж не до дизайна в принципе.
Ну я примерно такой ответ и ожидал.
Что ж, остановимся на диалоге выбора файла. Вы уверены, что есть реальная необходимость его кастомизировать? Контекстное меню браузера тоже кастомизируют очень редко, только когда туда надо засунуть дополнительные элементы, нужные для конкретного приложения. Собственно, элементы, которые рисует браузер/ОС, есть и в этом нет ничего страшного.
Что ж, остановимся на диалоге выбора файла. Вы уверены, что есть реальная необходимость его кастомизировать? Контекстное меню браузера тоже кастомизируют очень редко, только когда туда надо засунуть дополнительные элементы, нужные для конкретного приложения. Собственно, элементы, которые рисует браузер/ОС, есть и в этом нет ничего страшного.
Смысл вполне может быть, т.к., например, если надо сделать множественный выбор файлов, то в одних браузерах это делается одним способом (вроде, аттрибут multipleselect или как-то вроде того), в других браузерах это задается атрибутом max, а третьи — вообще не поддерживают это. В таком случае имело бы смысл сделать кастомный диалог, который поведет себя одинаково в любом браузере. Контекстное меню? Ну тут соглашусь, его менять необходимости нет.
Дело в том, что элементы, которые рисуют браузеры/ОС уж больно разнятся как внешним видом (сравните тот же в файрфоксе, опере и сафари/хроме) но и техническими характеристиками (начиная от физических размеров и отступов, заканчивая наборами свойств и поведением). При всем при этом правильно написанные кастомные элементы и ведут себя независимо от платформы на которой запущены и выглядят именно так, как надо разработчикам сайта, а не разработчикам браузера/ОС.
Дело в том, что элементы, которые рисуют браузеры/ОС уж больно разнятся как внешним видом (сравните тот же в файрфоксе, опере и сафари/хроме) но и техническими характеристиками (начиная от физических размеров и отступов, заканчивая наборами свойств и поведением). При всем при этом правильно написанные кастомные элементы и ведут себя независимо от платформы на которой запущены и выглядят именно так, как надо разработчикам сайта, а не разработчикам браузера/ОС.
А в Chrome тоже работает (10.0.648.151 Linux)
Правда есть некий неприятный момент,
после нажатия сабмит выводится окошко что нужно заполнить форму, при продолжении чтото писать в это поле текст исчезает, а рамка — нет
Правда есть некий неприятный момент,
после нажатия сабмит выводится окошко что нужно заполнить форму, при продолжении чтото писать в это поле текст исчезает, а рамка — нет
Да, в хроме вообще странная реализация датапикеров ). Вроде как поддерживает, но, в тоже время, необычный результат. Вот тест remobred.ru/test/datepicker/
Вот когда все слделают стандартно, будет счастье.
Вот когда все слделают стандартно, будет счастье.
Действительно, как-то инопланетно сделано. Time при первом нажатии выдает какую-то дробную часть (т.е., например, так: «14:01:35.442») а при последующих нажатиях, только час и минуты (при этом пропадают секунды вообще). Datetime выдает вообще нечто неизвестное науке (например, «2011-03-22T11:03:01.875Z»). При этом, молчу что даты записаны в формате «Y-m-d».
Может все-таки не с одинарными кавычками будем верстать, а с двойными???
Кто-то встречал кросс-браузерные javascript-костыли для релизации этой красотени в других браузерах? Может заняться этим на досуге?
И да, стили по умолчанию с box-shadow — отстой. Я конечно понимаю, что зарисовались, показали сразу и поддержку box-shadow, но в общем это выглядит как-то не кошерно.
И да, стили по умолчанию с box-shadow — отстой. Я конечно понимаю, что зарисовались, показали сразу и поддержку box-shadow, но в общем это выглядит как-то не кошерно.
предвижу миллионы человекочасов, потраченные из-за «дизайнеров», требующих вводить номер телефона в строго определённом формате, или запрещающих пробелы в начале или конце текстового поля
Как раз проект, в котором нужна валидация формата телефонных номеров на этапе ввода :)
Но согласен с вами, в 99 случаях из ста это не нужно.
Но согласен с вами, в 99 случаях из ста это не нужно.
UFO just landed and posted this here
Хм. у меня всплывающее сообщение, если его не закрыть, при скроллинге не следует за страницей, а остается на одном месте. Это баг или фича?
<input required> вроде как не по xhtml. Каков синтаксис для xhtml? Где-то был <input required=«required»>
Что-то asdadsasd@mail.ru невалидный мейл, а asdadsasd@gmail.com валидный
Это, конечно, все круто, но я даже боюсь представить когда мы с вами сможем использовать возможности в продакшене.
Если бы кто-то продолжил начинание, то можно было бы и для IE автоматически костыли подставлять:
github.com/westonruter/webforms2
github.com/westonruter/webforms2
Sign up to leave a comment.
Валидация формы в Firefox 4, используя возможности HTML5