arnold-sakhnov Sep 18 2010 at 16:02

HTML5 для веб-дизайнеров. Часть 4: Формы 2.0

11 min

22K

IT Standards*

Translation

+118

Comments 30

theOnlyBoy Sep 18 2010 at 16:29

Красивая статья.

Метод elementSupportsAttribute() можно записать в 1 строку:

return attribute in document.createElement(element);

+11

Serator Sep 18 2010 at 21:42

Если метод, то в 3 строки:

String.prototype.hasProperty=function(property){
return property in document.createElement(this);
};

+ нужно помнить, что это все же проверка свойства, а не атрибута:

'div'.hasProperty('contenteditable'); — вернет false

'div'.hasProperty('contentEditable'); — вернет true

Morro Sep 18 2010 at 16:30

Спасибо! Так неожиданно приятно развеяли осенний скучный день.

4NT1P0V Sep 18 2010 at 16:59

Верно, осталось дело за малым, 5 и 6 часть.

Serator Sep 18 2010 at 16:35

browser.autofocus=false; для firefox'а в about:config, по идее, и есть этот параметр, о котором написано «Ни один браузер, впрочем, пока это не позволяет, но все еще впереди.»

Отличие типов полей вроде «tel», «serach» и т.п. (возможно ошибся в названии, ибо по памяти пишу) еще и в том, что они на выходи от дают строку без пробелов в начале и в конце (по описанию с MDN (MDC)), а «email», «url» и т.п. еще и проверяются.

Ну и в css оно все отлично стилизуется через псевдо-классы вроде :valid и т.п.

Вообще статья интересная, если рассматривать как вводную. А за подробностями лучше уже обращаться в спеку и маны по различным браузерам.

Peretyaka Sep 18 2010 at 17:05

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

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

Datalist, тоже, в этом виде подойдет только для редких случаев.

На мой взгляд лет пять назад — это было бы актуально, но сейчас веб-интерфейсы ушли далеко вперед и это не намного лучше классических веб-форм.

Немного порадовали новые type в input, давно пора сделать веб более адаптированным для автоматического анализа, но опять же, можно было пойти намного дальше.

GrossHo Sep 18 2010 at 18:33

> Валидация форм на стороне клиента теперь станет намного проще — хоть и, понятное дело, всецело полагаться на нее все равно нельзя; нужно не забывать проверять данные и на стороне ~~клиента~~ сервера.

так правильней?

arnold-sakhnov Sep 19 2010 at 02:40

Да, в переводе ошибка. Спасибо, что заметили.

gag_fenix Sep 18 2010 at 19:13

Круто, веб-программисты получат элементы форм, которыми обычные программисты могут пользоваться уже лет 15 :)
Все эти инструменты нужно было вводить еще в HTML 4!

Vertex Sep 18 2010 at 21:29

Москва не сразу строилась… потом ее ломали и перестраивали… перетаскивали улицы и т.д… )

batollo Sep 18 2010 at 19:40

Хорошая статья и превосходные новости.

Пара помарок:

советую его надо использовать аккуратно

Javascript часто используется за проверки заполненности формы

squint Sep 18 2010 at 20:19

Очень полезные вещи. И что самое удивительное — понадобилось всего 15 лет развития интернета, чтобы эти функции наконец появились в браузерах. Аллилуя!

aps Sep 18 2010 at 20:24

>Плохая новость в том, что вам придется использовать регулярные выражения.
Чем? Меня радует.

..
Глаз цепляется за незакрытые теги в примерах.

arnold-sakhnov Sep 19 2010 at 02:42

Да, несмотря на то, что автор в прошлых частях говорил, что любит синтаксис XHTML, он нигде не использует закрывающиеся одиночные теги в последующих примерах. Хорошо хоть значения параметров в кавычках ставит.

StrangeAttractor Sep 18 2010 at 21:21

Так это будет выглядеть в браузере. Owl stretching ...

Одному мне птичку жалко?

dimmaq Sep 18 2010 at 23:37

> Плохая новость в том, что вам придется использовать регулярные выражения.

Почему плохая?

marazmiki Sep 19 2010 at 00:15

Отличная статья, спасибо. Но мне не даёт покоя один момент: автор утверждает, что все календари реализованы по-разному, и поэтому «неплохо иметь одно общее для браузера решение». Кажется, в этом месте подвох: каждый браузер начнёт отрисовывать календарь по-своему (хорошо хоть, если независимо от темы оформления браузера), и, соответственно, в разных браузерах страница будет выглядеть неодинаково.

То же самое справедливо и для некоторых других элементов, например, поля search.

Тут, на хабре, есть куча статей на тему стилизации файл-инпута, чтобы он одинаково выглядел во всех браузерах. Предрекаю немалое количество статей по рестайлингу html5-элементов. =)

egoserg Sep 19 2010 at 01:00

Отличная статья.
У меня есть замечание относительно Datalist
Я два года назад, его реализовал на JS
Но как показала практика, наши пользователи к этому еще были не готовы.
Их вводил в ступор данный элемент.

aps Sep 19 2010 at 02:50

>реализовал на JS. наши пользователи к этому еще были не готовы.
Странные у вас пользователи. Наверное они никогда не пользовались подсказками в Google и Яндексе при наборе запроса. В Google это появилось шесть(!) лет назад.

Mirror Sep 19 2010 at 01:39

О, про datalist не знал, классная штука! И color тоже удивил.
Спасибо вам за эти переводы, очень помогают.

Пара замечаний.

К сожалению, тип URL, например, пока работает коряво. К примеру, mailto:example@adress должен быть корректным URLом, а вот та же «Опера» его не пропустит. Кроме того, желательно позволять пользователю вводить URL без указания протокола, это пока тоже работает как-то не очень.

И реакция браузеров на ошибки так себе, некрасивая.
Но, думаю, всё устаканится ещё.

Теперь насчёт pattern, я считаю, что это вообще порочная идея. Не стоит мучать пользователя жёстким диктатом формата, пусть пишет как удобно, для чего у нас компьютер-то? Пусть считает, думает. Те же номера телефонов в 99% случаев можно программно определить из любого формата.

Хотя, может иногда и к месту эта штука, тоже про неё не знал, кстати.

А ещё совсем почти оффтопное замечание: зачем везде избыточный for в label? Label можно делать без всяких параметров, просто внутрь этого тега вкладывать input, так гораздо удобнее.

P.S. И опечаточку нашёл. Там в конце должно быть «на стороне сервера»:

Валидация форм на стороне клиента теперь станет намного проще — хоть и, понятное дело, всецело полагаться на нее все равно нельзя; нужно не забывать проверять данные и на стороне клиента.

IvanNovikov Sep 19 2010 at 15:11

"… светлое будущее уже явно не за горами, _МЫ_ видим первые его лучи и можем в них понежиться."

aps Sep 19 2010 at 16:07

The xForm is dead.
Long Live the xForm!

UFO just landed and posted this here

arnold-sakhnov Sep 19 2010 at 16:42

Какой ужас.

blia Sep 19 2010 at 17:21

еще можно дополнить, что type=«search» не просто рисует немного другой input, но и добавляет к нему автодополнение вашей истории поиска. Я думаю, это важно.

LIAL Sep 20 2010 at 12:14

Статьи супер, только исправьте плиз:

>когда горе-разработчики или -дизайнеры навящиво
навязчиво

kutsy Sep 22 2010 at 11:49

Господа, а как работать с ошибками при указанных «required» или регулярках в полях?
Использую самый последний Хром, но форму он отправляет, хотя должен как-то ругнутся на пустое поле или несовпадающую регулярку.

o_O_Tync Sep 23 2010 at 20:05

Хотелось бы взглянуть на функцию «inputSupportsType()», не приведённую в статье

arnold-sakhnov Sep 24 2010 at 06:13

function inputSupportsType(test) {
    var input = document.createElement('input');
    input.setAttribute('type',test);
    if (input.type == 'text') {
        return false;
    } else {
        return true;
    }
    }

Show the best of all time