HTML5 для веб-дизайнеров - Кит Джереми

Выбор цвета

Пожалуй, самый амбициозный элемент в HTML5, заменяющий JavaScript-виджет, – тип ввода color. Он принимает значение в знакомом шестнадцатеричном формате: #000000 – черный, #FFFFFF – белый.

<label for="bgcolor">Цвет фона</label>

<input id="bgcolor" name="bgcolor" type="color">

План таков, что браузеры должны реализовать встроенные диалоги выбора цвета – точно такие же, какие есть практически в каждом другом приложении на вашем компьютере. Пока ни один браузер этого не реализовал, но когда они это сделают, будет, ну, решительно круто.

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

Сделай сам

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

Хорошие новости: вы можете использовать атрибут pattern для того, чтобы указать, какой именно род данных вы ожидаете. Плохие новости: придется использовать регулярные выражения:

<label for="zip">Почтовый индекс США</label>

<input id="zip" name="zip" pattern="[d]{5}(-[d]{4})">

Большую часть времени вам не придется использовать атрибут pattern. Что касается тех редких случаев, когда придется, – заранее вам сочувствую.

В ожидании будущего

Формы в HTML5 получили огромное развитие. Большое количество тяжелой ноши, которую до этого нес на себе JavaScript, переходит на плечи разметки. Прямо сейчас мы находимся в переходной фазе, когда только некоторая часть этой функциональности поддерживается лишь некоторыми браузерами. Мы пока не можем выбросить наш JavaScript на помойку, но мы уже не так далеки от светлого будущего.

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

Я уверен, что вы понимаете преимущества встроенных в браузер управляющих элементов для календарей и ползунков, но уверен, что у вас возникает вопрос: «Могу ли я применять к ним свои стили?»

Это хороший вопрос. На данный момент ответ: «нет». Придется смириться с решением рабочей группы CSS.

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

Я бы хотел, чтобы вы задали себе другой вопрос: «Нужно ли мне применять к элементам форм свои стили?»

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

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

Теперь давайте отложим формы в сторонку и посмотрим на новую сочную семантику, которая появилась в HTML5.

5. Семантика

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

У нас есть абзацы, списки и заголовки, но нет событий, репортажей и рецептов. HTML дает нам элемент, который позволяет разметить слово как аббревиатуру, но не дает элемента, чтобы разметить число как цену.

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

Перефразируя Уинстона Черчилля, HTML – худшая форма разметки, если не считать всех прочих, что были испробованы человечеством.

Расширяемость

Другие языки разметки позволяют вам изобретать любой элемент, какой пожелаете. В XML, если вы хотите, чтобы в вашем документе был элемент event или price, вы просто берете и создаете его. Недостаток этой свободы заключается в том, что вам нужно будет затем обучить парсер, что значит event и price. Достоинство ограниченного набора элементов HTML в том, что каждая программа, работающая с ним, знает о существовании каждого из этих элементов. В браузеры встроено знание HTML. Это было бы невозможно, если бы нам разрешалось придумывать названия элементов.

HTML предлагает очень удобный аварийный выход, который позволяет веб-разработчикам добавлять семантическое значение элементам – атрибут class. Этот атрибут позволяет нам отметить некоторые экземпляры элемента как относящиеся к особенному классу или типы этого элемента. То, что браузеры не понимают того словаря, который мы используем в своих атрибутах class, не влияет на отображение наших документов.

Если в этом месте вы думаете: «Погодите-ка, разве классы нужны не для CSS?», вы отчасти правы. CSS-селекторы по классам – один из примеров технологии, которая использует атрибут class, но это не единственная причина использовать классы. Классы могут использоваться при написании скриптов для DOM и даже могут использоваться браузерами, если названия классов следуют заранее согласованным правилам, как это происходит в случае микроформатов.

Микроформаты

Микроформаты – набор договоренностей, согласованных внутри сообщества. Эти форматы используют атрибут class для того, чтобы заделать самые зияющие дыры в HTML: hCard – для контактов, hCalendar – для событий, hAtom – для новостных репортажей. Поскольку внутри сообщества существует договоренность о том, какие имена классов следует использовать, существуют парсеры и расширения браузеров, которые работают именно с этими шаблонами.

Микроформаты ограничены по самой своей задумке. Они не пытаются предложить решение для любого возможного сценария использования. Напротив, они нацеливаются на тот плод, что низко висит. Они предлагают решения для 80% сценариев использования, при этом на их создание затрачивается всего 20% усилий. Решить, что считается «плодом, что низко висит», довольно просто: нужно просто посмотреть на содержимое, которое люди уже размечают. Другими словами, заасфальтировать тропинки.

Звучит знакомо? Микроформаты и HTML5 построены на одной философии. По сути, то, как я описал микроформаты – договоренности, согласованные сообществом, – вполне применимо и к HTML5.

Вскипятить океан

То, что микроформаты использовались в качестве модели для разработки HTML5, приходится не всем по вкусу. Хотя правило 80/20 достаточно хорошо работает для сермяжного мира наименований классов, действительно ли оно достаточно хорошо для самого важного языка разметки в мире?

Некоторые считают, что HTML должен быть бесконечно расширяемым. Это значит, что давать решения для большинства случаев недостаточно: язык должен предоставлять решения для любого возможного сценария.

Пожалуй, самый красноречивый аргумент такого типа привел Джон Олсоп (John Allsopp) в своей великолепной статье на A List Apart, «Семантика в HTML5» (http://bkaprt.com/html5/6)[11]:

Нам не нужно, чтобы в словарь HTML добавляли специфические термины, нам нужно добавить механизм, который позволит добавлять семантическую насыщенность к документу по мере необходимости.

Уже существуют технологии для того, чтобы делать именно это. RDFa позволяют авторам встраивать в HTML-документы собственные словари. Но в отличие от микроформатов – которые просто используют заранее оговоренный набор наименований классов, – RDFa использует пространства имен для бесконечного разнообразия форматов. Так, там, где микроформат будет использовать примерно такую разметку: <h1 class="summary">, RDFa будет использовать: <h1 property="myformat:summary">.

Нет никакого сомнения в том, что RDFa – потенциально очень мощный инструмент, но его выразительность имеет свою цену. Пространства имен вводит дополнительный уровень сложности, который не очень согласуется с относительно простой природой HTML.

Спор о пространствах имен не нов. В записи в своем блоге несколько лет назад Марк Ноттингем (Mark Nottingham) размышлял о потенциально деструктивных побочных эффектах (http://bkaprt.com/html5/7)[12]: