От веб-приложений 1.0 к HTML5

Оглавление

Оглавление. 1

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

Предисловие. 5

1. Краткая история разметки. 6

От IETF до W3C: путь к HTML 4. 6

XHTML 1: HTML по правилам XML. 6

XHTML 2: терпению пришел конец. 7

Раскол: WHATWG TF?. 7

От веб-приложений 1.0 к HTML5. 8

Объединение. 8

XHTML умер: да здравствует синтаксис XHTML. 9

Развитие HTML5. 9

2. Устройство HTML5. 11

Принципы устройства. 11

Ближе к реальности. 11

Обработка ошибок. 12

Доктайп, скажите честно, я буду жить?. 12

Будем проще. 13

Синтаксис: размечайте, как хотите. 14

Мы так не разговариваем.. 15

Было приятно познакомиться, чао. 16

Перемен, мы ждем перемен!. 17

Анонимная цитата. 17

Элемент a на стероидах. 18

Новые игрушки! API JavaScript. 19

3. Мультимедиа. 20

Canvas. 20

Танец вокруг архитектуры: как рисовать с помощью кода. 22

Canvas. Ага! И для чего он нужен?. 22

Доступ запрещен. 23

Умный Canvas. 24

Audio. 26

Вырваться из-под контроля. 27

Буферизация. 28

Его вам сразу вклю́чат, а может быть, включáт. 29

Запасной вариант. 30

Доступ на все уровни. 31

Video. 32

Нативный режим.. 34

4. Веб-формы 2.0. 35

Placeholder. 35

Autofocus. 36

Required. 37

Autocomplete. 38

Datalist. 38

Типы полей ввода. 40

Поиск. 40

Контакты.. 40

Ползунки. 41

Проверка. 42

Счетчики. 43

Дата и время. 43

Выбор цвета. 45

Сделай сам.. 45

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

5. Семантика. 47

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

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

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

Новые элементы.. 49

mark. 49

time. 50

meter. 51

progress. 51

Структура. 51

section. 52

header. 52

footer. 53

aside. 53

nav. 54

article. 54

Лекарство от избытка дивов?. 56

Модели содержимого. 57

Содержимое, разбивающее на секции. 57

Алгоритм содержания. 60

hgroup. 61

Корневые элементы разделов. 62

Переносимость. 62

Локальные стили. 63

6. Использование HTML5 сейчас. 65

Стили. 65

Заголовки. 65

Aria. 66

Валидация. 67

Тестирование функций. 67

Выберите собственную стратегию.. 68

Ресурсы.. 68

Включайтесь!. 69

Будущее. 69

Об авторе. 71

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

Предисловие

Когда мы с Мэнди Браун и Джейсоном Санта-Мария организовали издательство A Book Apart, мы считали особенно животрепещущей одну конкретную тему, и был только один автор, который мог бы с ней справиться.

Ни одна другая тема, ни «полноценные шрифты», ни CSS3, не волнуют сообщество разработчиков, работающих по стандартам, больше, чем неминуемое появление HTML5. Эта новая вариация общего языка веба, зародившаяся из-за неудовлетворенности медленным темпом развития и консервативной политикой W3C, задуманная для Сети, состоящей из приложений (а не только документов), – в равной мере воодушевляет, злит и запутывает сообщество веб-разработчиков.

У Джереми Кита есть уникальная способность разъяснять HTML5 и писать сразу о том, что имеет значение для дизайнеров/разработчиков, стремящихся делать доступный для технологий специальных возможностей и основанный на стандартах дизайн. Джереми уже предельно доступно описал DOM и JavaScript и делает то же самое в этой книге, в которой ровно столько слов и иллюстраций, сколько необходимо.

О HTML5 есть другие книги, а будет их гораздо больше. Появятся написанные техническим языком пятисотстраничные книги для разработчиков приложений, потребности которых во многом стимулировали развитие HTML5. Будут и еще более объемные книги – для разработчиков браузеров, в которых будут даваться решения технических проблем, о которых – хвала небесам! – нам с вами никогда не придется думать.

Но эта книга для вас – человека, который создает контент для веба, который делает осмысленную, семантическую разметку веб-страниц, который разрабатывает доступные для технологий специальных возможностей интерфейсы. Можно назвать эту книгу инструкцией по использованию HTML5. Ее цель – как и всех книг, которые выходят в каталоге A Book Apart, – пролить ясный свет на запутанный предмет, и сделать это быстро, чтобы вы могли сразу вернуться к работе.

Джеффри Зельдман

Краткая история разметки

HTML – связующий язык Всемирной паутины. С помощью простых тегов, которые содержит этот язык, род человеческий сумел создать ошеломительно разнообразную сеть документов, связанных между собой гиперссылками – от Amazon, eBay и Wikipedia до личных блогов и страничек, посвященных котикам, похожим на Гитлера.

HTML5 – последняя на данный момент итерация этого лингва-франка, и хотя это и самое амбициозное изменение в нашем Всеобщем Наречии, но обновляется HTML не впервые. Язык начал развиваться с самого начала.

Как и собственно веб, гипертекстовый язык разметки (HyperText Markup Language, HTML) был детищем сэра Тима Бернерса-Ли, который в 1991 году составил документ под названием HTML Tags, предложив в нем около 20 элементов, которые можно было использовать для написания веб-страниц.

Не сэр Тим придумал использовать теги, состоящие из слов в угловых скобках; такие теги уже существовали в формате SGML (Standard Generalized Markup Language, стандартный обобщенный язык разметки). Вместо того чтобы изобретать новый стандарт, сэр Тим увидел все преимущества того, чтобы разрабатывать язык как надстройку к уже существующему стандарту, – эта тенденция заметна и сейчас, в разработке HTML5.

От IETF до W3C: путь к HTML 4

Такой вещи, как HTML 1, никогда не было. Первой официальной стала спецификация HTML 2.0, опубликованная IETF (Инженерный совет Интернета, Internet Engineering Task Force). Многие из пунктов появились в этой спецификации потому, что они уже существовали на практике. Например, лидировавший на рынке веб-браузер Mosaic уже в 1994 году позволял авторам веб-страниц вставлять в документы картинки с помощью тега <img>. Впоследствии элемент img появился в спецификации HTML 2.0.

На смену IETF пришел W3C, Консорциум Всемирной паутины (World Wide Web Consortium), который публиковал последующие обновления стандарта HTML на сайте http://www.w3.org. Во второй половине девяностых появился целый шквал исправлений в спецификации, пока в 1999 году не была наконец опубликована спецификация HTML 4.01.

В этот момент HTML подошел к своей первой развилке.

XHTML 1: HTML по правилам XML

Следующая после HTML 4.01 версия языка называлась XHTML 1.0. «X» означало «экстремальный», и каждый веб-разработчик, когда начинал произносить название языка, был строго обязан скрещивать руки в форме буквы «Х».

Ладно, на самом деле нет. «X» значило eXtensible, «расширяемый», а скрещивать руки, в общем, было необязательно.

Содержимое спецификации XHTML 1.0 было совершенно идентично спецификации HTML 4.01. Не было добавлено никаких новых элементов и атрибутов. Единственная разница заключалась в синтаксисе языка. Если HTML давал авторам большую свободу в том, как писать элементы и атрибуты, то XHTML требовал следовать правилам XML, гораздо более строгого языка разметки, на основе которого W3C строил большинство своих технологий.

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

Публикация стандарта XHTML 1.0 совпала с началом поддержки CSS в браузерах. По мере того как веб-разработчики стали принимать только что появившиеся веб-стандарты (это началось с Web Standards Project), более строгий синтаксис XHTML стал рассматриваться как передовая практика в написании разметки.

Потом W3C опубликовал спецификацию XHTML 1.1.

Если XHTML 1.0 – это был простой HTML, пересказанный средствами XML, то XHTML 1.1 стал настоящим XML, беззаветно и полностью. Таким образом, сервер не мог отдавать его с MIME-типом text/html. Но если же авторы публиковали документ с MIME-типом XML, то самый распространенный браузер в мире на тот момент – Internet Explorer – вовсе не мог отобразить документ.

Казалось, что W3C стал утрачивать чувство реальности и того, что действительно происходит с публикацией документов в вебе.

XHTML 2: терпению пришел конец

Если бы персонаж Дастина Хоффмана в фильме «Выпускник» был веб-разработчиком, W3C сказал бы ему одно слово, ровно одно: XML.

С точки зрения W3C разработка HTML закончилась на версии 4. Они начали работать над XHTML 2, который был спроектирован так, чтобы привести веб к светлому, основанному на XML будущему.

И хотя название XHTML 2 звучало достаточно похоже на XHTML 1, между ними не было ничего общего. В отличие от XHTML 1, в XHTML 2 не предусмотрено обратной совместимости с существующим веб-содержимым и даже с предыдущими версиями HTML. Это должен быть чистый язык, неотягощенный неряшливой историей предыдущих спецификаций.

Наступила полная катастрофа.

Раскол: WHATWG TF?

Внутри W3C назрело восстание. Со стороны казалось, что консорциум формулировал теоретически чистые стандарты, никак не связанные с нуждами веб-разработчиков. Представители Opera, Apple и Mozilla были недовольны этим направлением развития. Им хотелось, чтобы большее внимание уделялось технологиям, позволяющим создавать веб-приложения.

Конфликт перешел в критическую фазу на семинаре в 2004 году. Ян Хиксон (Ian Hickson), который в то время работал в Opera Software, предложил идею расширения HTML с целью сделать возможным создание веб-приложений. Это предложение было отвергнуто.

Недовольные повстанцы организовали свою собственную группу: рабочую группу по разработке гипертекстовых приложений для веба (Web Hypertext Application Technology Working Group, или сокращенно WHATWG).

От веб-приложений 1.0 к HTML5

С самого начала WHATWG стала работать совершенно не так, как W3C. В W3C использовался подход, основанный на согласии: вопрос поднимается, обсуждается, затем по нему голосуют. В WHATWG вопросы тоже поднимаются и обсуждаются, а окончательное решение по тому, что войдет в спецификацию, а что нет, принимает редактор – Ян Хиксон.

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

Сначала основной объем работы в WHATWG был разбит на две спецификации: веб-форм (Web Forms 2.0) и веб-приложений (Web Apps 1.0). Обе спецификации должны быть расширениями для HTML. Со временем они объединились в одну спецификацию, которая называлась просто HTML5.

Объединение

Пока в WHATWG разрабатывали HTML5, W3C продолжала работать над спецификацией XHTML 2. Нельзя сказать, что она летела по шоссе в никуда. Она ехала в никуда очень-очень медленно.

В октябре 2006 года сэр Тим Бернерс-Ли написал пост в блоге, в котором признал, что попытка заставить веб перейти с HTML на XML не имеет шансов на успех. Несколько месяцев спустя W3C выпустил новый договор для рабочей группы HTML. Вместо того чтобы начинать с нуля, они мудро решили, что в качестве фундамента для любой будущей версии HTML нужно использовать наработки WHATWG.

Эта остановка и новый запуск привели к несколько запутанной ситуации. Получилось, что W3C одновременно работал над двумя разными, несовместимыми типами разметки: XHTML 2 и HTML 5 (обратите внимание на пробел перед пятеркой). В то же время отдельная организация, WHATWG, работала над спецификацией под названием HTML5 (без пробела), которая должна быть использована в качестве основы для одной из спецификаций W3C!

Если вы относитесь к тем веб-разработчикам, которые пытаются в этом разобраться, то знайте, что проще расшифровать смысл фильмов «Мементо», «Детонатор» и всей фильмографии Дэвида Линча, даже если смотреть их подряд.

XHTML умер: да здравствует синтаксис XHTML

Туман неразберихи начал рассеиваться в 2009 году. W3C объявил, что договор на XHTML 2 не будет продлеваться. Формат был мертвым уже несколько лет, и это объявление стало только официальным свидетельством о смерти.

Как ни странно, смерть XHTML 2 не прошла незамеченной. Напротив, противники XML отреагировали на нее злорадно и использовали это объявление для того, чтобы высмеять всех, кто когда-либо использовал XHTML 1, – даже несмотря на то, что между XHTML 1 и XHTML 2 не было практически ничего общего.

В то же время авторы, которые пислали на XHTML 1 с тем, чтобы следовать более строгому стилю написания кода, стали волноваться, что HTML5 будет означать возвращение к небрежной разметке.

Как вы скоро увидите, это не обязательно так. Вы можете писать на HTML5 и небрежно, и строго – как захотите.

Развитие HTML5

Текущее состояние HTML5 не такое запутанное, как было когда-то, но все равно не до конца понятное.

Над HTML5 работают две группы. WHATWG создает спецификацию HTML5 в рамках процесса «утвердить, потом пересмотреть». Рабочая группа по HTML W3C берет эту спецификацию и проводит ее через процесс «пересмотреть, потом утвердить». Как вы легко можете представить, это непростой политический союз. По крайней мере, кажется, наконец появилось единодушие по этому назойливому вопросу – с пробелом или без пробела? (На тот случай, если вам вдруг интересно, HTML5 решили писать без пробела.)

Пожалуй, самая сбивающая с толку проблема для тех веб-разработчиков, которые пробуют кончиком ноги воду HTML5, – ответ на вопрос «когда он будет готов?»

Ян Хиксон в интервью сказал, что ожидает, что HTML5 получит статус предложенной рекомендации[1] в 2022 году. За этим последовала волна общественного негодования от ряда веб-разработчиков. Они не понимали, что значит «предложенная рекомендация», но уж точно знали – на руках нет столько пальцев, чтобы пересчитать, сколько лет пройдет до 2022 года.

Для негодования не было повода. В данном случае для того чтобы получить статус «предложенной рекомендации», нужно иметь две полных реализации HTML5. Учитывая объем спецификации, эта дата невероятно амбициозна. В конце концов, у браузеров не самая лучшая репутация в плане реализации существующих стандартов. Internet Explorer потребовалось больше десятилетия, чтобы добавить поддержку – всего-то – элемента abbr.

Та дата, которая действительно имеет значение для HTML5, – 2012 год. В этом году спецификация должна стать кандидатом в рекомендации. Это на жаргоне стандартов значит «сделано и отшлифовано».

Но даже эта дата не особенно важна для веб-разработчиков. Имеет значение тот момент, когда браузеры начнут поддерживать функциональность HTML5. Мы начали использовать части спецификации CSS 2.1, как только начали выпускаться браузеры с поддержкой этих частей. Если бы мы ждали, пока каждый браузер начнет полностью поддерживать CSS 2.1, и только потом стали его использовать, мы ждали бы до сих пор.

С HTML5 ровно то же самое. Не будет никакого четкого момента, когда мы могли бы объявить, что язык готов к использованию. Однако, мы можем начинать использовать части спецификации по мере того, как веб-браузеры начинают поддерживать эти функции.

Помните, что HTML5 – это не новый язык, созданный с нуля. Это скорее эволюционное, чем революционное изменение в продолжающейся истории разметки. Если сейчас вы создаете сайты на любой версии HTML, вы уже используете HTML5.

Устройство HTML5

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

Десятичное время было полным провалом. Никто не стал использовать эту систему. То же можно сказать о XHTML 2. W3C на своем опыте усвоила урок революционной Франции: изменять существующее поведение в высшей степени сложно.

Принципы устройства

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

Если XHTML 2 намеревался отбросить все то, что было до него, то HTML5 основывается на уже существующих спецификациях и реализациях. Бóльшая часть HTML 4.01 вошла в HTML5.

В числе других принципов разработки есть, например, такие: «Не изобретайте велосипед» и «Асфальтируйте тропинки» – то есть если среди веб-разработчиков есть широко распространенный способ выполнять задачу – даже если он необязательно лучший, – именно этот способ должен быть записан в HTML5. Сказать по-другому: «Если ничего не ломается, не начинай чинить».

Многие из этих принципов дизайна могут быть вам знакомы, если вы когда-либо заглядывали в сообщество по микроформатам (http://microformats.org). HTML5-сообщество разделяет этот же самый прагматичесный подход: нужно запустить формат в реальный мир, а не волноваться слишком сильно из-за теоретических проблем.

Эта точка зрения четко выражена в принципе устройства, озаглавленном «Приоритет пользователей», в котором сказано: «В случае конфликта ставьте интересы пользователей выше разработчиков, разработчиков – выше конкретных реализаций, реализации – выше спецификаций, спецификации – выше теоретической чистоты».

Ян Хиксон несколько раз говорил, что настоящие судьи в споре того, что окажется в HTML5, а что нет, – разработчики браузеров. Если компания-разработчик браузера откажется поддерживать какое-либо предложение, нет смысла добавлять это предложение в спецификацию, потому что тогда спецификация окажется всего лишь фиктивным документом. Согласно приоритету пользователей наш (веб-разработчиков) голос имеет еще больший вес. Если мы откажемся использовать какую-либо часть спецификации, это также сделает спецификацию фиктивной.

Ближе к реальности

Определяющим фактором в разработке HTML5 стало постоянное внутреннее напряжение. С одной стороны, эта спецификация должна быть достаточно мощной, чтобы поддерживать создание веб-приложений. С другой стороны, HTML5 должна поддерживать существующее содержимое даже с учетом того, что бо́льшая часть существующего содержимого – неудобоваримая каша. Если спецификация слишком отклонится в одном направлении, ее постигнет та же судьба, что и XHTML 2. Но если она пойдет слишком далеко в другом направлении, тогда выйдет, что спецификация будет рекомендовать использование тегов <font> и таблиц для разметки – поскольку в конце концов именно с использованием этих приемов построено огромное количество веб-страниц.

Здесь нужно выдержать очень тонкий баланс, и это требует прагматического, уравновешенного подхода.

Обработка ошибок

Спецификация HTML5 не просто объявляет, что должны делать браузеры, когда они обрабатывают синтаксически правильную разметку. Впервые за всю историю HTML спецификация также объявляет, что́ браузеры должны делать, когда им встречаются документы с ошибками разметки.

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

Определение того, как нужно обрабатывать ошибки, в HTML5 – невероятно амбициозная задача. Даже если бы в HTML5 были только элементы и атрибуты из HTML 4.01, без добавления каких бы то ни было новых возможностей определить то, как нужно обрабатывать все ошибки, к 2012 году, – все равно было бы геркулесовым трудом.

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

Доктайп, скажите честно, я буду жить?

Декларация типа документа, или сокращенно «доктайп», обычно используется для того, чтобы определить, какой именно версией разметки написан документ.

Доктайп для HTML 4.01 выглядит так (переносы строки обозначены»):

<!DOCTYPE HTML PUBLIC"-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">

Вот доктайп XHTML 1.0:

<!DOCTYPE html PUBLIC"-//W3C//DTD XHTML 1.0 Strict //EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Не сильно человекочитаемо, но по-своему эти доктайпы просто говорят: «этот документ написан на HTML 4.01» и «и этот документ написан на XHTML 1.0».

Наверное, вы ожидаете, что в доктайпе, объявляющем «этот документ написан на HTML5», где-то будет цифра «пять». Не будет. Доктайп для HTML5 выглядит так:

<!DOCTYPE html>

Он настолько короткий, что я даже могу его запомнить.

Но это же безумие! Если в доктайпе нет номера версии, как мы сможем определить следующие версии HTML?

Когда я в первый раз увидел доктайп HTML5, я подумал, что это верх гордыни. «Неужели они действительно думают, – спросил я себя, – что это будет последняя спецификация разметки, написанная на Земле?»

В общем, казалось, что это случай из учебника по мышлению «с нуля».

На самом деле, однако, доктайп HTML5 весьма прагматичен. Так как HTML5 должен поддерживать существующее содержимое, этот доктайп может быть применен и к существующему документу на HTML 4.01 или XHTML 1.0. Любая будущая версия HTML тоже должна будет поддерживать существующее содержимое, написанное на HTML5, так что сам концепт применять номера версий к документам разметки имеет значительный изъян.

На деле доктайпы не имеют принципиального значения. Например, вы поставили в документ доктайп HTML 4.01. Если в этом документе окажется элемент из другой спецификации – например, из HTML 3.2 или из HTML5, – браузер все равно отобразит эту часть документа. Браузеры поддерживают функциональность, а не доктайпы.

Декларации типа документа предназначались не для браузеров, а для валидаторов. Единственный случай, в котором браузер обращает какое-либо внимание на доктайп, – когда он «переключает доктайп», – это маленький умный хак, который переключает режим отображения между нестандартным (quirks mode) и стандартным режимами в зависимости от присутствия подходящего доктайпа.

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

Будем проще

Доктайп – не единственная вещь, оказавшаяся упрощенной в HTML5.

Если вы хотите особо указать кодировку вашего документа разметки, лучший способ сделать это – проверить, что ваш сервер посылает правильный HTTP-заголовок Content-Type. Если вы хотите быть вдвойне уверенным, можно также определить кодировку с помощью тега <meta>. Вот как выглядит декларация meta для документа, написанного на HTML 4.01:

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

Вот гораздо более легкий для запоминания способ сделать то же самое в HTML5:

<meta charset="UTF-8">

Как и с доктайпом, это упрощенное объявление кодировки содержит минимальный набор символов, который необходим браузерам для правильной интерпретации.

Тег <script> – еще одно место, где мы можем позволить себе немножко сбросить вес. Обычная практика – добавлять к элементам script атрибут type со значением "text/javascript":

<script type="text/javascript" src="/storage/public/books/c3/f0/c3f0bf21-f7c0-4c8e-a8c5-58aa37eb5140/file.js"></script>

Браузерам этот атрибут не нужен. Они и так примут за данность, что этот скрипт написан на JavaScript, самом популярном языке скриптов в вебе (давайте будем честными – на единственном языке скриптов в вебе):

<script src="/storage/public/books/c3/f0/c3f0bf21-f7c0-4c8e-a8c5-58aa37eb5140/file.js"></script>

Точно также не нужно указывать значение type – "text/css" каждый раз, когда вы делаете ссылку на CSS-файл:

<link rel="stylesheet" type="text/css" href="file.css">

Можно просто написать:

<link rel="stylesheet" href="file.css">

Синтаксис: размечайте, как хотите

Некоторые языки программирования, например Python, обязывают писать инструкции специфическим образом. Обязательно использовать пробелы для отступа кода – пробелы и переносы строк имеют значение. Другие языки программирования (например, JavaScript) не обращают никакого внимания на форматирование – сколько пробелов в начале строки, совершенно неважно.

Если хотите бесплатно развлечься вечером, соберите в одной комнате несколько программистов и произнесите слова: «табы или пробелы». Ближайшие несколько часов можете греться от жарких споров, которые разгорятся немедленно.

В сердце спора о значимых пробелах лежит фундаментальный философский вопрос: должен ли язык навязывать определенный стиль написания кода – или авторы должны иметь возможность писать в любом стиле, в каком хотят?

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

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

XHTML 1.0 обязывает следовать синтаксису XML. Все теги должны быть написаны в нижнем регистре. Все атрибуты должны быть в кавычках. У всех элементов должен быть закрывающий тег.

В особенном случае самостоятельных элементов, например br, требование закрывающего тега заменяется требованием закрывающей косой черты: <br/>.

В случае HTML5 все подходит. Прописные, строчные буквы, в кавычках, без кавычек, самозакрывающиеся элементы или нет – решение здесь полностью за вами.

Я использовал доктайп XHTML 1.0 в течение многих лет. Мне нравится, что я должен писать в каком-то одном специфическом стиле, и мне нравится, что валидатор W3C обязывает меня писать в этом стиле. Теперь, когда я использую HTML5, я сам должен обязать себя писать в том стиле, в каком хочу.

Я понимаю, почему некоторым людям не нравится нетребовательность синтаксиса HTML5. Получается, что мы как будто закрываем глаза на годы, за которые накопились передовые практики. Некоторые даже говорят, что нестрогий синтаксис HTML5 поощряет плохую разметку. Я не думаю, что это так, но могу понять, почему это причина для волнения. Случилось то же самое, как если бы язык программирования, который обязывал использовать значимые пробелы и переводы строк, внезапно переключился бы на правила, которые позволили бы делать это не всегда, а с какими-то исключениями.

Лично у меня нет проблем с бессистемностью синтаксиса HTML5. Я смирился с тем, что мне придется самому обязывать себя писать так, как я хочу. Но мне хотелось бы видеть больше инструментов, которые позволили бы мне проверять, насколько моя разметка соответствует тому или иному стилю. В мире программирования такие инструменты называются «линтерами» – программы, которые отмечают ненадежные места в коде. Линтер для разметки отличается от валидатора, который проверяет соответствие разметки доктайпу; но было бы замечательно, если бы оба они могли быть соединены в одну подкачавшуюся и готовую работать машину для линтирования и валидации.

Кто напишет такую программу, заслужит вечное уважение и восхищение веб-разработчиков по всему миру.

Мы так не разговариваем

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

В HTML5 нет исключенных элементов или атрибутов. Но зато есть огромное количество устаревших элементов и атрибутов.

Нет, это не очередной случай выжившей из ума политкорректности. «Устаревший» имеет несколько иное значение, чем «исключенный».

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

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

Если вы будете настаивать на использовании устаревшего элемента или атрибута, ваш документ станет «несоответствующим». Браузеры будут отображать все как и прежде, но вы, может случиться, заметите, что сайты по соседству поглядывают на вас неодобрительно.