1 Введение

1.1 Предыстория

Этот раздел не является нормативным.

Языком разметки документов Всемирной Паутины (World Wide Web) всегда был HTML. HTML был первоначально разработан как язык семантического описания научных документов, но со временем его развитие сделало возможным использование этого языка для описания и других типов документов.

Главной областью, которая не была адекватно адресована HTML, был непонятный субъект под названием Вэб-приложение (Web Application). В данной спецификации сделана попытка исправить это и одновременно обновить HTML-спецификации в вопросах, поднятых за последние несколько лет.

1.2 Целевая аудитория

Этот раздел не является нормативным.

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

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

В частности, необходимо знакомство с DOM для полноты понимания некоторых технических разделов этой спецификации. Понимание Web IDL, HTTP, XML, Unicode, кодировки символов, JavaScript и CSS также пригодится, но не настолько важно.

1.3 Сфера рассмотрения

Этот раздел не является нормативным.

Данная спецификация ограничивается предоставлением языка разметки семантического уровня и ассоциированных API скриптинга (сценариев) для создания вэб-страниц в диапазоне от статических документов до динамических приложений.

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

Областью рассмотрения данной спецификации не является описание операционной системы в целом. В частности, конфигурация железа, программное обеспечение, утилиты для работы с изображениями и приложениями, с которыми пользователь может ежедневно работать на высокоуровневом РС, находятся вне рамок рассмотрения. В терминах приложений эта спецификация нацелена именно на те приложения, которые могут быть использованы конечными потребителями нерегулярно, или регулярно, но в разных местах, с невысокими требованиями к CPU. Среди примеров таких приложений – онлайн-системы продаж, поисковые системы, игры (особенно многопользовательские онлайн-игры), публичные телефонные или адресные книги, средства коммуникации (e-mail клиенты, месенджеры, дискуссионные программы), программы редактирования документов etc.

1.4 История развития

Этот раздел не является нормативным.

За пять лет (1990-1995) HTML претерпел несколько ревизий и расширений, первоначально на базе CERN, а затем – IETF.

После создания W3C развитие HTML началось в новом месте. Первая неудачная попытка расширения HTML в 1995, известная как HTML 3.0, привела к более прагматичному подходу, известному как HTML 3.2, который был завершён в 1997. HTML4 появился вскоре, в том же году.

На следующий год коллектив W3C решил остановить развитие HTML и начать работу над эквивалентом не основе XML, названном XHTML. Эта работа началась с переформулирования HTML4 в XML, известного как XHTML 1.0, в котором ничего нового не появилось, кроме сериализации, и завершилась в 2000. После XHTML 1.0 внимание W3C переключилось на то, чтобы облегчить другим рабочим группам расширение XHTML под знаменем XHTML Modularization. Параллельно с этим W3C также работал над новым языком, который был несовместим с предшествующими HTML и XHTML и назывался XHTML2.

Примерно в то время, когда развитие HTML остановилось, в 1998, части API для HTML, разработанные создателями браузеров, были специфицированы и опубликованы под названием DOM Level 1 (в 1998) и DOM Level 2 Core и DOM Level 2 HTML (начиная с 2000 и по 2003). Эта инициатива затем заглохла на спецификации DOM Level 3, опубликованной в 2004, но рабочая группа была закрыта до того, как все проекты Level 3 были завершены.

В 2003 публикация XForms, технологии, которая позиционировалась как следующее поколение вэб-форм, пробудило интерес к развитию самогó HTML, вместо поиска замены для него. Этот интерес возродился с момента развёртывания XML и привёл к появлению совершенно новых технологий (вроде RSS и Atom), вместо замещения уже существующих технологий (вроде HTML).

Доказательство того, что можно было расширить HTML4-формы для предоставления более интересных возможностей, нежели давала XForms 1.0, без требования к браузерам реализовать машины отображения, которые были несовместимы с существующими HTML-страницами, стало первым результатом возрождения этого интереса. На этой ранней стадии, когда проект уже был в открытом доступе, а информация поступала из всех источников, эта спецификация была исключительно под правами Opera Software.

Идея, что следует продолжить развивать HTML, была проверена на W3C workshop в 2004, где некоторые принципы, на которых основана работа HTML5 (описано далее), также как и вышеупомянутый проект, покрывающий работу с формами, были представлены в W3C совместно Mozilla и Opera. Предложение было отклонено на том основании, что оно конфликтует с ранее избранным направлением развития Web: руководство и сообщество W3C проголосовали за продолжение работы над XML-заменами.

Вскоре после этого Apple, Mozilla и Opera совместно анонсировали намерение продолжить работу на новой площадке, названной WHATWG. Были созданы публичные списки рассылки, и проект переместился на сайт WHATWG. В авторские права были внесены поправки о совместной собственности всех трёх производителей и разрешении на использования этой спецификации.

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

Последнее требование, в частности, требовало, чтобы область спецификации HTML5 охватывала то, что ранее было специфицировано в трёх отдельных документах: HTML4, XHTML1 и DOM2 HTML. Оно также подразумевало большую детализацию, нежели ранее.

В 2006 W3C проявил интерес к участию в разработке HTML5, и в 2007 образовалась рабочая группа, уполномоченная для работы с WHATWG над разработкой спецификации HTML5. Apple, Mozilla и Opera разрешили W3C публиковать эту спецификацию под авторскими правами W3C, сохраняя версию с менее ограничительной лицензией на сайте WHATWG.

В течение ряда лет обе группы работали вместе с одним редактором: Ian Hickson. В 2011 группы пришли к заключению, что у них разные цели: W3C хотел подвести финальную черту для HTML5 Recommendation, а WHATWG хотела продолжить работать над Living Standard for HTML, постоянно поддерживая спецификацию и добавляя новые возможности. В середине 2012 нова редакторская команда была создана в W3C для обеспечения создания HTML5 Рекомендаций и подготовке Working Draft следующей версии HTML.

С тех пор W3C HTML WG собирала урожай, беря патчи от WHATWG, где фиксировались баги, зарегистрированные в W3C HTML-спецификации, или более точно была представлена реализация в пользовательских агентах. На время публикации данного документа патчи от WHATWG HTML specification были объединены вплоть до ревизии 8152 включительно. W3C HTML-редакторы добавили также исправления, ставшие результатом обсуждения и решений, принятых W3C HTML WG, а также исправления багов, не поддержанные WHATWG.

Опубликован отдельный документ с описанием отличий между HTML, специфицированным в данной спецификации, и языком, HTML4. [HTMLDIFF]

1.5 Замечания по дизайну

Этот раздел не является нормативным.

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

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

Таким образом, возможности возникали из множества источников и не всегда разрабатывались какими-то конкретными способами. Кроме того, из-за уникальных характеристик Web баги реализаций часто становились де-факто, а теперь и де-юре, стандартами, поскольку содержимое часто непреднамеренно создавалось способами, основанными на ошибках, прежде чем они были исправлены.

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

1.5.1 Возможность сериализации выполнения скриптов

Этот раздел не является нормативным.

Чтобы не подвергать вэб-авторов сложностям работы с многопоточностью, API в HTML и DOM разработаны так, чтобы никакой скрипт не мог когда-либо обнаружить одновременное выполнение других скриптов. Даже с workers цель состоит в том, чтобы поведение реализации представлялось как полная сериализация выполнения всех скриптов во всех контекстах браузинга.

 Метод navigator.yieldForStorageUpdates() в данной модели эквивалентен разрешению другим скриптам работать, пока вызывающий скрипт блокирован.

1.5.2 Соответствие другим спецификациям

Этот раздел не является нормативным.

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

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

Этот раздел не является нормативным.

В HTML имеется широкий спектр механизмов расширения, которые могут использоваться для добавления семантики безопасным способом:

1.6 HTML и XHTML

Этот раздел не является нормативным.

Данная спецификация определяет абстрактный язык для описания документов и приложений и некоторые API для взаимодействия с внутренними представлениями ресурсов, которые используют этот язык.

Это внутреннее представление (in-memory representation) известно как "DOM HTML" или, для краткости, "DOM".

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

Первый такой синтаксис – это HTML-синтаксис. Этот формат рекомендуется для большинства авторов. Он совместим с большинством известных вэб-браузеров. Если документ передаётся с text/html MIME-типом, то он будет обработан как HTML-документ браузерами. Данная спецификация определяет версию 5.0 синтаксиса HTML, известного как "HTML 5".

Второй конкретный синтаксис – это XHTML-синтаксис, являющийся XML-приложением. Если документ передаётся с XML MIME-типом, таким, как application/xhtml+xml, то он рассматривается как XML-документ вэб-браузерами, и будет обработан XML-процессором. Напоминаем авторам, что процессинги XML и HTML различаются: в частности, даже минимальная синтаксическая ошибка не даст полностью отобразить документ, помеченный как XML, в то время как такие ошибки будут проигнорированы в HTML-синтаксисе. Данная спецификация определяет версию 5.0 XHTML-синтаксиса, известного как "XHTML 5".

DOM, HTML-синтаксис и XHTML-синтаксис не могут представлять одно и то же содержимое. Например, пространства имён не могут быть отображены с использованием HTML-синтаксиса, но они поддерживаются в DOM и XHTML-синтаксисе. Аналогично документы, использующие noscript, могут быть представлены с использованием HTML-синтаксиса, но не могут быть представлены в DOM или XHTML-синтаксисе. Комментарии, содержащие строку "-->" , могут быть представлены только в DOM, но не в HTML и XHTML-синтаксисах.

1.7 Структура данной спецификации

Этот раздел не является нормативным.

Данная спецификация имеет следующие большие разделы:

Введение
Ненормативные материалы, предоставляющие контекст для HTML-стандарта.
Общая инфраструктура
Соответствующие классы, алгоритмы, определения и общие средства остальной части спецификации.
Семантика, структура и API HTML-документов
Документы построены из элементов. Эти элементы образуют дерево с использованием DOM. Этот раздел определяет возможности этой DOM, а также содержит введение в возможности, общие для всех элементов, и понятия, используемые при определении элементов.
Элементы HTML
Каждые элемент имеет предопределённое значение, которое объясняется в этом разделе. Даны также правила для авторов об использовании элементов и требования к пользовательским агентам (ПА) по обработке каждого элемента. Сюда входят такие широкие возможности HTML, как проигрывание видео и субтитров, элементы управления формами и отправкой форм и API 2D-графики, известный как HTML-канва (canvas).
Загрузка Web-страниц
HTML-документы существуют не в безвоздушном пространстве — в этом разделе определены многие возможности, влияющие на окружение, которое работает с множеством страниц, такие как вэб-браузеры и офлайн-кэширование вэб-приложений.
API вэб-приложений
Данный раздел вводит базовые возможности скриптинга (сценариев) приложений в HTML.
Взаимодействие с пользователем
HTML-документы могут предоставлять пользователю механизмы взаимодействия с содержимым и его изменения, описанные в данном разделе, такие как фокус ввода.
HTML-синтаксис
XHTML-синтаксис
Все эти возможности будут бесполезны, если они не могут быть представлены в сериализованной форме и отправлены другим людям, поэтому эти разделы определяют синтаксисы HTML и XHTML, а также правила разбора (парсинга) содержимого с помощью этих синтаксисов.
Отображение
Этот раздел определяет правила по умолчанию для отображения в вэб-браузерах.

Имеются также приложения, перечисляющие устаревшие функции и элементы и вопросы по IANA, и несколько индексов.

1.7.1 Как читать эту спецификацию

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

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

Например, "значение атрибута foo должно быть целым числом" – это требование к производителям, так как указывает допустимые значения; напротив, требование "значение атрибута foo должно разбираться с использованием правил парсинга целых" – это требование для потребителей, так как описывает, как обрабатывать содержимое.

Требования к производителям не имеют никакого отношения к потребителям.

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

1.7.2 Типографские соглашения

Это определение, требование или объяснение.

 Это примечание.

Это пример.

Это открытый вопрос.

Это предупреждение.

interface Example {
  // это IDL-определение
};
variable = object . method( [ optionalArgument ] )

Это примечание для авторов с описанием использования интерфейса.

/* это фрагмент CSS */

Определение экземпляра термина отмечается так. Использование термина отмечается так или так.

Определение экземпляра элемента, атрибута или API отмечается так. Ссылки на этот элемент, атрибут или API отмечаются так.

Другие фрагменты кода отмечаются примерно так.

Переменные отмечаются так.

В алгоритме шаги в последовательных разделах отмечаются знаком ⌛.

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

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

1.8 Вопросы конфиденциальности

Этот раздел не является нормативным.

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

В целом, из-за архитектуры Internet, одного пользователя можно отличить от другого пользователя с помощью его IP-адреса. IP-адреса не точно соответствуют пользователю: пользователь может переходить с одного устройства на другое или от сети к сети, его IP-адрес будет меняться; аналогично NAT-маршрутизация, прокси-серверы, компьютеры общего пользования посылают пакеты, которые для всех видны как исходящие с одного IP-адреса, но в реальности отображающиеся в разных пользователей. Такие технологии, как onion-маршрутизация, могут использоваться для анонимных запросов таким образом, что запросы от одного пользователя на одном узле Internet будут казаться исходящими от многих отдельных пользователей в сети.

Однако IP-адреса, используемые для пользовательских запросов, это не единственный механизм, с помощью которого пользователи и запросы могут быть связаны друг с другом. Куки, например, специально предназначены для этого, и являются основой большинства возможностей вэб-сессий, что даёт Вам возможность заходить на сайт, требующий наличия учётной записи/акаунта.

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

Группирование запросов таким способом, особенно по множеству сайтов, может использоваться как для "правильных" целей, так и злонамеренно. Примером добропорядочного использования может быть определение того, предпочитает ли данный человек сайты с фотографиями собак, а не кошек (на основе того, как часто он посещает такие сайты по запросу), а затем автоматически использовать предпочитаемые иллюстрации при последующих посещениях сайтов-участников. Злонамеренные цели, однако, могут заключаться в обработке правительством такой информации, как домашний адрес (определяемый по адресам, используемым при направлении на один сайт) с политическими предпочтениями (определяемыми по форумам, в которых пользователь участвует), чтобы предотвратить возможное участие человека в голосовании на выборах.

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

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

Возможности из данной спецификации, которые могут использоваться для идентификации пользователя, помечены, как в этом абзаце. (This is a fingerprinting vector.)

Другие возможности на этой платформе, которые можно использовать для указанных целей, это (и не только):

1.9 Краткое введение в HTML

Этот раздел не является нормативным.

Базовый HTML-документ выглядит примерно так:

<!DOCTYPE html>
<html>
 <head>
  <title>Пример страницы</title>
 </head>
 <body>
  <h1>Пример страницы</h1>
  <p>Это <a href="demo.html">простой</a> пример.</p>
  <!-- это комментарий -->
 </body>
</html>

HTML-документы состоят из дерева элементов и текста. Каждый элементов в исходном коде обозначается открывающим (стартовым/начальным) тэгом, как "<body>", и закрывающим (конечным) тэгом, как "</body>". (Определённые открывающие и закрывающие тэги могут в определённых обстоятельствах отсутствовать и подразумеваются другими тэгами.)

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

<p>Это <em>совершенно <strong>неверно</em>!</strong></p>
<p>Это <em><strong>корректно</strong>.</em></p>

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

Элементы могут иметь атрибуты, управляющие работой элементов. В примере ниже имеется гиперссылка, образованная с помощью элемента a с атрибутом href:

<a href="demo.html">простой</a>

Атрибуты помещаются внутри открывающего тэга и состоят из имени/name и значения/value, разделённых символом "=". Значение атрибута может быть без кавычек, если не содержит пробельных символов или символов " ' ` = < или >. В противном случае значение атрибута должно быть закавычено одинарными или двойными кавычками. Значение, вместе с символом "=", может быть опущено, если значением является пустая строка.

<!-- пустые атрибуты -->
<input name=address disabled>
<input name=address disabled="">

<!-- атрибуты со значением -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">

Пользовательские агенты (ПА) HTML (напр., вэб-браузеры) затем разбирают эту разметку, превращая её в дерево DOM (Document Object Model). DOM-дерево это in-memory представление документа.

DOM-деревья содержат узлы нескольких разновидностей, в частности узел DocumentType, узлы Element, узлы Text, узлы Comment и, в некоторых случаях, узлы ProcessingInstruction.

Кусок кода в начале этого раздела может быть превращён в следующее DOM-дерево:

Корневым элементом этого дерева является элемент html, который всегда является корневым в HTML-документах. Он содержит два элемента: head и body, а также узел Text между ними.

Имеется много узлов Text в DOM-дереве, нежели можно предположить, поскольку исходник содержит несколько пробелов (представленных здесь как "␣") и переводов строки ("⏎"), которые все заканчиваются как Text-узлы в DOM-дереве. Однако, по историческим причинам, не все пробелы и разрывы строк в оригинальной разметке отображаются в DOM. В частности, все пробелы после стартового тэга head отбрасываются втихую, а все пробелы после конечног тэга body помещаются в конце body.

Элемент head содержит элемент title, который в свою очередь содержит Text-узел с текстом "Простая страница". Аналогично элемент body содержит элементы h1, p и комментарий.


С этим DOM-деревом можно работать из скриптов на странице. Скрипты (обычно на JavaScript) это небольшие программки, которые можно встроить в страницу элементом script или через атрибуты содержимого обработчика события. Например, вот форма со скриптом, который устанавливает в элемент output этой формы значение "Hello World":

<form name="main">
 Result: <output name="result"></output>
 <script>
  document.forms.main.elements.result.value = 'Hello World';
 </script>
</form>

Каждый элемент в DOM-дереве представлен объектом, и эти объекты имеют API, поэтому ими можно манипулировать. Например, ссылка (например, элемент a в вышеприведённом дереве) может иметь атрибут "href" изменённый разными способами:

var a = document.links[0]; // получить первую ссылку в документе
a.href = 'sample.html'; // изменить целевой URL этой ссылки
a.protocol = 'https'; // изменить только часть протокола в URL
a.setAttribute('href', 'http://example.com/'); // изменить непосредственно атрибут содержимого

Поскольку DOM-деревья используются как способ представления HTML-документов, когда они обрабатываются и отображаются реализациями (особенно интерактивными реализациями вроде вэб-браузеров), эта спецификация в основном формулируется в терминах DOM-деревьев, а не маркировки.


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

В следующем примере страница будет жёлтое-на синем с помощью CSS.

<!DOCTYPE html>
<html>
 <head>
  <title>Sample styled page</title>
  <style>
   body { background: navy; color: yellow; }
  </style>
 </head>
 <body>
  <h1>Sample styled page</h1>
  <p>This page is just a demo.</p>
 </body>
</html>

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

1.9.1 Создание безопасных приложений с помощью HTML

Этот раздел не является нормативным.

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

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

Модель безопасности Web основана на понятии "источников/origins" и, соответственно, многие потенциальные атаки в Web происходят с привлечением разных источников. [ORIGIN]

Отсутствие проверки пользовательского ввода
Кросс-сайтовый скриптинг (XSS)
SQL-инъекция
При приёме ненадёжного ввода, например, сгенерированного пользователем содержимого вроде текстовых комментариев, значений URL-параметров, сообщений со сторонних сайтов etc., важно, чтобы эти данные были проверены до начала их использования и правильно мнемонизированы при отображении. Если этого не делать, то можно дать злонамеренному пользователю возможность выполнять атаки, от потенциально безвредных, таких как предоставление поддельной пользовательской информации вроде отрицательного возраста, до серьёзных, таких как запуск скрипта всякий раз, когда пользователь просматривает страницу с информацией, потенциально распространяя информацию, вплоть до катастрофических последствий вроде удаления всех данных с сервера.

При написании фильтров для проверки пользовательского ввода важно, чтобы фильтры работали на базе белого списка, разрешая заведомо безопасные конструкции и запрещая любой другой ввод. Фильтры на основе чёрного списка, отключающие известный негативный ввод и разрешающие всё остальное, не являются безопасными, поскольку не всё опасное уже известно (например, может быть изобретено в будущем).

Вот, например, страница, разбирающая URL-строку запроса для определения того, что отображать, а сайт затем перенаправляет пользователя на эту страницу для отображения сообщения:

<ul>
 <li><a href="message.cgi?say=Hello">Say Hello</a>
 <li><a href="message.cgi?say=Welcome">Say Welcome</a>
 <li><a href="message.cgi?say=Kittens">Say Kittens</a>
</ul>

Если сообщение будет просто отображаться без мнемонизации, злоумышленник может затем обработать URL, содержащий элемент скрипта:

http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

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

Это называется кросс-сайтовая скриптовая атака.

Имеется много конструкций, которые могут быть использованы, чтобы заставить сайт выполнить исполняемый код. Вот несколько советов авторам при работе с фильтрами и белым списком:

Cross-site request forgery (CSRF)/Кросс-сайтовая подделка запроса
Если сайт разрешает пользователю отправлять форму со специфическими пользовательскими действиями, например, размещение сообщений на форуме под фамилией пользователя, выполнение покупок или получение паспорта, важно проверять, что запрос был сделан пользователем намеренно, а не с другого сайта через неизвестный анонимный запрос.

Эта проблема существует, поскольку HTML-формы могут отправляться на другие источники.

Сайты могут предотвращать подобные атаки, заполняя формы скрытыми символами или проверяя заголовки Origin во всех запросах.

Clickjacking/Кликджэкинг
Страница, которая предоставляет пользователю интерфейс для выполнения действий, которые пользователю не нужны, должна быть сконструирована таким образом, чтобы исключить вовлечение пользователя в активацию вредоносного интерфейса.

Один из способов обмана пользователя – когда злонамеренный сайт помещает сайт-жертву в небольшой iframe, а затем предлагает пользователю щёлкнуть, например, предлагая сыграть в какую-нибудь игру. Когда пользователь играет, хакерский сайт может быстро поместить iframe под курсор мыши непосредственно перед тем, как пользователь должен щёлкнуть, и после щелчка запускается вредоносный интерфейс.

Чтобы исключить это, сайты, работающие без фрэймов, должны включать свой интерфейс только тогда, когда они определят, что они не во фрэйме (напр., сравнивая window-объект со значением атрибута top).

1.9.2 Обычные ловушки, которые следует избегать при использовании API-скриптинга

Этот раздел не является нормативным.

Скрипты в HTML имеют семантику "run-to-completion" (работать до завершения), означающую, что браузер обычно будет непрерывно выполнять скрипт, прежде чем выполнить что-то ещё вроде запуска события или продолжения парсинга документа.

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

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

Один из способов показать это – элементы img и событие load. Событие может быть запущено сразу после разбора элемента, особенно если изображение уже кэшировано (как чаще всего и бывает).

Здесь автор использует обработчик onload в элементе img для отлова события load:

<img src="games.png" alt="Games" onload="gamesLogoHasLoaded(event)">

Если элемент добавлен скриптом, то, пока обработчики события добавляются в том же самом скрипте, это событие не будет упущено:

<script>
 var img = new Image();
 img.src = 'games.png';
 img.alt = 'Games';
 img.onload = gamesLogoHasLoaded;
 // img.addEventListener('load', gamesLogoHasLoaded, false); // would work also
</script>

Однако, если автор сначала создаёт элемент img, а затем в отдельном скрипте добавляет обработчики, появляется запуск события load в этом промежутке, что может привести к его потере:

<!-- Не используйте этот стиль, в нём содержится условие для гонки! -->
 <img id="games" src="games.png" alt="Games">
 <!-- событие 'load' может запуститься здесь, поскольку парсер делает паузу, и Вы этого события не заметите! -->
 <script>
  var img = document.getElementById('games');
  img.onload = gamesLogoHasLoaded; // может никогда не наступить!
</script>

1.9.3 Как отлавливать ошибки при написании HTML: валидаторы и проверщики соответствия

Этот раздел не является нормативным.

Авторам рекомендуется использовать проверщики соответствия кода (известные также как валидаторы) для обнаружения типичных ошибок. W3C предоставляет ряд онлайн-сервисов для проверки кода, в том числе Nu Markup Validation Service.

1.10 Требования соответствия для авторов

Этот раздел не является нормативным.

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

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

1.10.1 Презентационная разметка

Этот раздел не является нормативным.

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

Использование презентационных элементов ухудшает доступность
Потому что презентационную разметку можно использовать способами, которые предоставляются пользователям вспомогательных технологий (ATs) с соответствующим опытом (напр., используя ARIA), а делать это намного сложнее, чем при использовании семантически подходящей разметки. Кроме того, даже использование такой техники не поможет сделать страницу доступной не-AT-пользователям и пользователям без графики, как в текстовых браузерах.

Использование медианезависимой разметки, с другой стороны, облегчает создание документов таким способом, что они становятся доступными большему числу пользователей (напр., текстовых браузеров).

Повышение затрат на обслуживание
Значительно легче обслуживать сайт, когда его разметка стилистически независима. Например, изменение цвета сайта, везде использующего <font color="">, требует изменений по всему сайту,  а аналогичные изменения на сайте с CSS можно произвести, изменив только один файл с таблицей стилей.
Больший размер документов
Презентационная разметка, как правило, более избыточна, что увеличивает размеры документов.

По этим причина презентационная разметка была исключена из HTML в этой версии. Это изменение не должно стать сюрпризом: HTML4 объявил презентационную разметку устаревшей много лет назад и предоставил режим (HTML4 Transitional), чтобы помочь авторам перейти от презентационной разметки; позднее XHTML 1.1 пошёл ещё дальше и вообще отменил эти функции.

Единственное, что осталось от презентационной разметки в HTML, это атрибут style и элемент style. Использование атрибута style не поощряется в рабочей среде, но он может пригодиться для быстрого прототипирования (где его правила позднее могут быть прямо перемещены в отдельную таблицу стилей) и для предоставления особых стилей в необычных случаях, когда отдельная таблица стилей не подходит. Аналогично элемент style может быть полезен в синдикации или для специфических для конкретной страницы стилей, но в общем внешняя таблица стилей более употребительная для применения стилей к нескольким страницам.

Следует также отметить, что некоторые элементы, бывшие презентационными ранее, были переопределены в данной спецификации в медианезависимые: b, i, hr, s, small и u.

1.10.2 Синтаксические ошибки

Этот раздел не является нормативным.

Синтаксис HTML ограничен, чтобы исключить множество проблем.

Неинтуитивное поведение обработки ошибок
Некоторые неверные синтаксические конструкции при разборе дают совершенно неинтуитивные результирующие DOM-деревья.

Например, следующий фрагмент разметки в DOM с элементом hr , который является родственником соответствующего элемента table:

<table><hr>...
Ошибки с опционным исправлением ошибок
Чтобы разрешить использование ПА в управляемом окружении без необходимости реализовывать более странные и запутанные правила обработки ошибок, ПАгентам разрешено прерывать работу при обнаружении ошибки парсинга.
Ошибки, когда поведение при обработке ошибок не совместимо с потоковыми ПА
Некоторое поведение при обработке ошибок, как для вышеприведённого примера <table><hr>... , несовместимо с потовыми ПА (ПА, которые обрабатывают HTML-файлы в один проход, без сохранения состояния). Чтобы избежать проблем совместимости с такими ПА, любой синтаксис, дающий такое поведение, считается неверным.
Ошибки, приводящие к принудительному ограничению infoset
Если ПА на базе XML подключается к HTML-парсеру, может быть, что определённые инварианты, которые форсирует XML, такие как комментарии, никогда не содержащие подряд два дефиса, будут нарушены HTML-файлом. Обработка такого случая может потребовать, чтобы парсер принудительно вставлял HTML DOM в XML-совместимый infoset. Большинство конструкций, требующих такой обработки, считаются неверными.
Ошибки, дающие непропорционально низкую производительность
Некоторые синтаксические конструкции могут давать в результате непропорционально низкую производительность. Чтобы препятствовать использованию таких конструкций, они обычно делаются несоответствующими.

Например, следующая разметка даст низкую производительность, поскольку все незакрытые элементы i должны быть реконструированы в каждом параграфе, что даёт всё больше элементов в каждом параграфе:

<p><i>He dreamt.
<p><i>He dreamt that he ate breakfast.
<p><i>Then lunch.
<p><i>And finally dinner.

Результирующая DOM будет:

Ошибки с использованием хрупких синтаксических конструкций
Существуют синтаксические конструкции, которые, по историческим причинам, являются относительно непрочными. Чтобы уменьшить количество пользователей, сталкивающихся с такими проблемами, эти конструкции сделаны несоответствующими/non-conforming.

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

В этом фрагменте значением атрибута является "?bill&ted":

<a href="?bill&ted">Bill and Ted</a>

В этом фрагменте, однако, значением атрибута является "?art©", а не ожидаемое "?art&copy", поскольку даже без конечной точки с запятой "&copy" обрабатывается так же, как "&copy;" и, таким образом, интерпретируется как "©":

<a href="?art&copy">Art and Copy</a>

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

Таким образом, корректным способом выразить эти случаи будет такой:

<a href="?bill&ted">Bill and Ted</a> <!-- &ted это ok, поскольку это не именованная ссылка на символ -->
<a href="?art&amp;copy">Art and Copy</a> <!-- & должен быть мнемонизирован, так как &copy это именованная ссылка на символ -->
Ошибки, связанные с проблемами совместимости с устаревшими ПА
Некоторые синтаксические конструкции могут приводить к малым и большим проблемам с устаревшими пользовательскими агентами и поэтому помечаются как несоответствующие/non-conforming, чтобы помочь авторам избегать их возникновения.
Например, по этой причине символ "`" (U+0060) недопустим в незакавыченных атрибутах. В некоторых старых ПА он иногда рассматривается как символ кавычки.
Другой пример – DOCTYPE, который требует включения режима no-quirks, поскольку поведение устаревших ПА в quirks-режиме часто не задокументировано.
Ошибки, увеличивающие риск попасть под атаку
Некоторые ограничения существуют для того, чтобы исключить проблемы с безопасностью.

Например, ограничение на использование UTF-7 существует только для того, чтобы авторы не стали жертвой известных кросс-сайтовых скриптовых атак с использованием UTF-7. [UTF7]

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

Например, непонятно, какой из заголовков автор имел в виду: h1 или h2:

<h1>Contact details</h2>
Случаи, похожие на опечатки
Если пользователь допускает простую опечатку, то лучше отловить ошибку как можно раньше, что поможет автору сэкономить время при отладке. Данная спецификация поэтому обычно считает ошибочным использование имён элементов, атрибутов и т. д., не соответствующих именам, определённым в данной спецификации.

Например, если автор пишет <capton> вместо <caption>, это может быть помечено как ошибка, которую автор немедленно должен исправить.

Ошибки, которые могут конфликтовать с новым синтаксисом в будущем
Чтобы дать возможность расширять синтаксис в будущем, некоторые вполне безобидные вещи запрещены.

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

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

1.10.3 Ограничения для моделей содержимого и значений атрибутов

Этот раздел не является нормативным.

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

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

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

Ошибки, связанные с конфликтом в выраженной семантике
Аналогично, чтобы обратить внимание автора на ошибки в использовании элементов, явные  противоречия в семантике также считаются ошибками соответствия.
В следующих фрагментах, например, семантика бессмысленна: сепаратором не может быть одновременно ячейка, радио-кнопка и индикатор выполнения.
<hr role="cell">
<input type=radio role=progressbar>

Другой пример – ограничения моделей содержимого элемента ul, который допускает в качестве потомков только элементы li. Список, по определению, состоит из 0 или более элементов списка, поэтому если элемент ul содержит что-то, кроме элемента li, не совсем понятно, что это означает.

Случаи, когда стили по умолчанию, вероятно, приведут к путанице
Некоторые элементы имеют стили или поведение по умолчанию, которые могут сделать определённые комбинации причиной путаницы. Там, где имеются эквивалентные альтернативы без этой проблемы, такие комбинации запрещены.

Например, элементы div отображаются как блок-боксы, а элементы span – как инлайн-боксы. Помещение блок-бокса внутрь инлайн-бокса излишне усложняет, поскольку вложение просто элементов div или span, или вложение элементов span внутрь элементов div служит той же самой цели, что вложение элемента div внутрь элемента span, но только в последнем случае блок-бокс помещается внутрь инлайн-бокса, поэтому данная комбинация запрещена.

Другой пример – как интерактивное содержимое не может вкладываться. Например, элемент button не может содержать элемент textarea, так как поведение по умолчанию таких вложенных интерактивных элементов может смутить пользователя. Вместо вложения этих элементов можно их разместить рядом.

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

Например, установка в атрибут disabled значения "false" запрещена, потому что появление элемента предполагает, что он включён, хотя фактически он отключён\disabled (поскольку для реализации имеет значение существование атрибута, а не его значение).

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

Например, атрибут shape в элементе area, хотя и принимает значения circ и circle как синонимы, запрещает использование circ, что упрощает учебники и другие средства обучения. Никакой пользы от возможности использования обоих значений нет, но это может привести к лишним проблемам при изучении языка.

Ошибки, связанные с особенностями парсера
Некоторые элементы анализируются несколько эксцентрически (обычно по историческим причинам), и их ограничения модели содержимого предназначены для того, чтобы избавить авторов от этих проблем.
Например, элемент form не разрешён внутри фразового содержимого, поскольку при разборе как HTML открывающий тэг элемента form будет подразумевать закрывающий тэг элемента p. Таким образом, следующая разметка даст в результате два абзаца, а не один:
<p>Welcome. <form><label>Name:</label> <input></form>

Она разбирается точно так:

<p>Welcome. </p><form><label>Name:</label> <input></form>
Ошибки, которые наверняка дадут облом в скриптах, который трудно будет отлаживать
Некоторые ошибки помогут предотвратить проблемы со скриптами, которые трудно будет отладить.

Поэтому, например, несоответствующим будет иметь два атрибута id с одним значением. Дублирующие IDs приведут к неверному выбору элемента, иногда с катастрофическими последствиями, причину которых будет трудно установить.

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

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

Ошибки, связанные с переходом к и от XHTML
Некоторые авторы любят писать файлы, которые могут интерпретироваться и как XML, и как HTML, с аналогичным результатом. Хотя такая практика не приветствуется из-за большого количества мелких сложностей (особенно при использовании скриптинга, стилей или автоматизированной сериализации любого рода), в данной спецификации имеется несколько ограничений, направленных на некоторое смягчение трудностей. Это облегчает авторам миграцию между HTML и XHTML.

Например, существуют довольно сложные правила относительно атрибутов lang и xml:lang, чтобы сохранить между ними синхронизацию.

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

Ошибки, связанные с областями, зарезервированными под будущие расширения
Как и с ограничениями синтаксиса под будущие расширения в новых ревизиях языка, некоторые ограничения моделей содержимого элементов и значений атрибутов предназначены для обеспечения в будущем расширения словаря HTML.

Например, ограничение значения атрибута target, которое начинается с символа "_" (U+005F) только конкретными предопределёнными значениями, позволят в будущем ввести новые предопределённые значения без конфликта с авторскими значениями.

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

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

1.11 Рекомендуемая литература

Этот раздел не является нормативным.

Следующие документы могут представлять интерес для читателей данной спецификации.

Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]

This Architectural Specification provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode Standard and ISO/IEC 10646. Topics addressed include use of the terms 'character', 'encoding' and 'string', a reference processing model, choice and identification of character encodings, character escaping, and string indexing.

Unicode Security Considerations [UTR36]

Because Unicode contains such a large number of characters and incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks. This is especially important as more and more products are internationalized. This document describes some of the security considerations that programmers, system analysts, standards developers, and users should take into account, and provides specific recommendations to reduce the risk of problems.

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG]

Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG]

Данная спецификация provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as by enabling, supporting, and promoting the production of accessible Web content by all authors.

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]

This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable.

Polyglot Markup: HTML-Compatible XHTML Documents [POLYGLOT]

A document that uses polyglot markup is a document that is a stream of bytes that parses into identical document trees (with the exception of the xmlns attribute on the root element) when processed as HTML and when processed as XML. Polyglot markup that meets a well defined set of constraints is interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification. Polyglot markup uses a specific DOCTYPE, namespace declarations, and a specific case — normally lower case but occasionally camel case — for element and attribute names. Polyglot markup uses lower case for certain attribute values. Further constraints include those on empty elements, named entity references, and the use of scripts and style.

HTML to Platform Accessibility APIs Implementation Guide [HPAAIG]

This is draft documentation mapping HTML elements and attributes to accessibility API Roles, States and Properties on a variety of platforms. It provides recommendations on deriving the accessible names and descriptions for HTML elements. It also provides accessible feature implementation examples.