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

[@theOnlyBoy]

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

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

return attribute in document.createElement(element);

[@Serator]

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

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

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

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

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

[@Morro]

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

[@4NT1P0V]

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

[@Serator]

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

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

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

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

[@Peretyaka]

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

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

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

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

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

[@GrossHo]

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

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

[@arnold-sakhnov]

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

[@gag_fenix]

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

[@Vertex]

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

[@batollo]

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

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

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

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

[@squint]

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

[@aps]

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

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

[@arnold-sakhnov]

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

[@StrangeAttractor]

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

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

[@dimmaq]

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

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

[@marazmiki]

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

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

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

[@egoserg]

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

[@aps]

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

[@Mirror]

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

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

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

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

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

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

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

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

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

[@IvanNovikov]

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

[@aps]

The xForm is dead.
Long Live the xForm!

[@arnold-sakhnov]

Какой ужас.

[@blia]

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

[@LIAL]

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

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

[@kutsy]

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

[@o_O_Tync]

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

[@arnold-sakhnov]

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