1 Вступление

1.1 Что описывает эта спецификация?

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

Спецификация состоит из всего, что выше таких ключевых технологий, как HTTP, URI/IRIs, DOM Core, XML, Unicode, и ECMAScript; ниже технологий уровня представления, таких как CSS, XBL и NPAPI; и рядом с такими технологиями, как Геолокация, SVG, MathML, и XHR.

1.2 Это HTML5?

Эта секция — неофициальная.

Коротко: Да.

Длиннее: Термин "HTML5" широко используется как модное словечко в отношении современных Web-технологий, многие из которых (хотя отнюдь не все) разрабатываются в WHATWG, в некоторых случаях - совместно с W3C и IETF.

Работа сообщества WHATWG публикуется в одной спецификации (той, что вы сейчас читаете), часть из которой переиздается в редакции, оптимизированной для Web-разработчиков (известной как HTML5).

Организация W3C также публикует части этой спецификации как отдельные документы. Одна из этих частей называется "HTML5"; это подмножество данной спецификации ("живой" стандарт HTML) пока, на конец июня 2012 года.

1.2.1 В чем различаются спецификации WHATWG и W3C?

Материал в обоих спецификациях WHATWG и W3C записан одним и тем же текстом за исключением следующих различий:

Следующие секции публикуются только в спецификациях WHATWG, и больше нигде:

1.3 Предпосылки

Эта секция — неофициальная.

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

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

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

Эта секция — неофициальная.

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

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

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

1.5 Область применения

Эта секция — неофициальная.

Эта спецификация ограничивается предоставлением языка разметки семантического уровня и связанных с ними скриптовых API-интерфейсов семантического уровня для авторинга понятных страниц в Сети, от статического документов до динамических приложений.

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

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

1.6 Предистория

Эта секция — неофициальная.

В течении своих первых пяти лет (1990-1995) HTML прошел через ряд изменений и получил ряд расширений, которые были первоначально размещены в CERN'е, а затем в IETF.

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

В следующем году члены W3C решили остановить эволюцию HTML и вместо этого начали работу над эквивалентом, основанным на XML и названным XHML. Эти старания начались с переформулировки HTML4 в XML, известной как XHMTL 1.0, которая не добавила новых возможностей, за исключением новой сериализации и была завершена в 2000г. После XHTML 1.0 фокус W3C переместился на то, чтобы другим рабочим группам было проще расширять XHTML, под знаменем модуляризации XHTML. Параллельно 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, технологии, которая позиционировалась как следующее поколение Web-форм, вызвала повышенный интерес к развитию самого HTML, а не нахождение замены для него. Этот интерес родился от осознания того, что ввод XML в качестве Web-технологии был ограничен полностью новыми технологиями (вроде RSS и затем Atom), а не был заменой для существующих технологий (вроде HTML).

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

Идея, что эволюцию HTML следует возобновить, была опробована на семинаре W3C в 2004г., на котором W3C от Opera и Mozilla были представлены некоторые принципы, лежащие в основе HTML5 (описанные ниже), а также вышеуказанное техническое предложение, касающееся только форм. Это предложение было отклонено на том основании, что оно противоречит ранее выбранному направлению эволюции Интернета; вместо этого сотрудники и члены 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.

С тех пор обе группы работают вместе.

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

1.7 Пояснения

Эта секция — неофициальная.

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

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

Потому возможности появлялись из многих источников, и они не всегда были спроектированы особенно логичным образом. Кроме того, из-за уникальных характеристик Интернета ошибки реализаций часто становятся de facto-, а теперь и de jure-стандартами, так как контент часто непреднамеренно пишется способами, что опираются на те стандарты, прежде чем те могут быть поправлены.

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

1.7.1 Возможность последовательного выполнения скрипта

Эта секция — неофициальная.

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

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

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

Эта секция — неофициальная.

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

1.8 HTML против XHTML

Эта секция — неофициальная.

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

Это представление в памяти известно как "DOM HTML" или "DOM" для краткости.

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

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

Второй конкретный синтаксис это XHTML, который использует XML. Когда документ передается с типом XML (тип XML MIME), таким как application/xhtml+xml, то он рассматривается Web-бразуерами как документ XML, и его следует парсить XML-обработчиком. Разработчикам известно, что обработка XML и HTML различаются; в частности, даже незначительные синтаксические ошибки помешают документу, помеченному как XML, быть отображенным полностью, в то время как они будут проигнорированы в случае синтаксиса HTML. Данная спецификация определяет самый последний синтаксис, известный просто как "XHTML".

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

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

Этот раздел — неофициальный.

Эта спецификация состоит из следующих основных разделов:

Общая инфраструктура
Классы соответствия, алгоритмы, определения и общие основы для остального материала спецификации.
Семантика, структура, и API HTML-документов.
Документы строятся из элементов. Эти элементы формируют дерево с помощью DOM. Этот раздел определяет возможности DOM, а также знакомит с возможностями, общими для всех элементов, и концепциями, задействованными при определении элементов.
Элементы HTML
Каждый элемент имеет предопределенное значение, которое определено в этом разделе. Даны правила для разработчиков о том, как использовать некий элемент, вместе с требованиями к агенту пользователя о том, как обращаться с каждым элементом.
Микроданные (Microdata)
Данная спецификация знакомит с механизмом добавления машиночитаемые аннотации к документам таким образом, что можно извлечь деревья пар имя-значение из документа. Этот раздел описывает данный механизм и несколько алгоритмов, которые могут быть использованы для конвертации документов HTML в другие форматы. Этот раздел также определяет некоторые словари Микроданных для контактной информации, календарных событий и лицензирования работ.
Загрузка Web-страниц
Документы HTML не существуют в вакууме — этот раздел определяет многие из особенностей, которые влияют на окружение, имеющее дело с множеством страниц.
API для Web-приложений
Этот раздел знакомит с базовыми возможностями по написанию скриптовых приложений в HTML.
Взаимодействие с пользователем
HTML-документы предоставляют ряд механизмов для взаимодействия с пользователем и изменения контента, что описывается в данном разделе.
Web-работники
Данная спецификация определяет API для фоновых потоков в JavaScript.
Web-хранилище
Данная спецификация определяет хранилище на стороне пользователя, основанное на парах имя-значение.
API коммуникаций
Этот раздел описывает некоторые механизмы, которые HTML-приложения могут использовать для коммуникации с другими приложениями из других доменов, выполняясь на том же клиенте. Раздел также знакомит с механизмом обмена сообщениями server-push, а также с двусторонним полнодуплексным протоколом сокетов для скриптов.
HTML-синтаксис
XHTML-синтаксис
Все эти функции были бы напрасными, если бы они не могли быть сериализованы и отправлены другим людям, и поэтому эти разделы определяют синтаксисы HTML и XHTML, а также правила по разбору содержимого с помощью тех синтаксисов.

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

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

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

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

Например, "значение атрибута foo должно быть valid integer" — это требование на производителя, так как оно определяет разрешенные значения; и наоборот, требование "значение атрибута foo должно быть распарсено, используя rules for parsing integers" есть требование на потребителей, так как оно описывает как обрабатывать контент.

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

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

1.9.2 Типографские обозначения

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

Это заметка.

Это пример.

Это открытый (нерешенный пока) вопрос.

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

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

Это замечание разработчикам, описывающее употребление интерфейса.

/* это фрагмент CSS-разметки */

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

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

Остальные отрывки кода помечаются вот так.

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

Это требование к реализации(ям).

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

Этот раздел — неофициальный.

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

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

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

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

Сгруппировав запросы таким образом, особенно для нескольких сайтов, (информация) может быть использована как для безобидных (и даже, возможно, положительных) целей, так и для злонамеренных. Примером достаточно безобидной цели было бы определение того, предпочитает ли конкретное лицо сайты с картинками собак в противовес с картинками кошек (на основе того, как часто оно посещает соответствующие сайты), и затем автоматически использовать предпочитаемые картинки при последующих визитах на сайты-участники. Злонамеренные цели, тем не менее, могли бы включать сопоставление информации, такой как домашний адрес пользователя (определенный "from the addresses they use when getting driving directions on one site") с его очевидной политической принадлежностью (определенной изучением сайтов-форумов, в беседах которых он участвует) для того, чтобы определить, следует ли помешать голосованию этого пользователя на выборах.

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

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

Возможности данной спецификации, которые могут быть использованы для идентификации пользователя (to fingerprint), помечаются как данный параграф.

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

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

Этот раздел — неофициальный.

Элементарный документ HTML выглядит следующим образом:

<!DOCTYPE html>
<html>
 <head>
  <title>Sample page</title>
 </head>
 <body>
  <h1>Sample page</h1>
  <p>This is a <a href="demo.html">simple</a> sample.</p>
  <!-- this is a comment -->
 </body>
</html>

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

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

<p>This is <em>very <strong>wrong</em>!</strong></p>
<p>This <em>is <strong>correct</strong>.</em></p>

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

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

<a href="demo.html">simple</a>

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

<!-- empty attributes -->
<input name=address disabled>
<input name=address disabled="">

<!-- attributes with a value -->
<input name=address maxlength=200>
<input name=address maxlength='200'>
<input name=address maxlength="200">

HTML-агенты пользователя (например Web-браузеры) затем парсят эту разметку, превращая ее в дерево DOM (Document Object Model, Объектная Модель Документа). Дерево DOM — это представление документа в памяти.

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

Фрагмент разметки в начале этого раздела превратился бы в следующее дерево DOM:

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

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

Элемент head содержит элемент title, который, в свою очередь, содержит узел Text с текстом "Sample page". Аналогично, элемент 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 во время их обработки и отображаются реализациями (главным образом интерактивными реализациями, Web-браузерами), то данная спецификация сформулирована, в основном, в терминах деревьев 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.11.1 Написание безопасных приложений с HTML

Этот раздел — неофициальный.

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

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

Модель безопасности Web-а основана на концепции "первоисточников"; соответственно, многие из потенциальных атак в Web-е включают в себя cross-origin-действия. [ORIGIN]

Отсутствие проверки пользовательского ввода
Cross-site scripting (XSS)
SQL-инъекция

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

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

Например, предположим, что страница смотрит на свою строку запроса 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>

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

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

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

Это называется атакой межсайтового скриптинга (cross-site scripting).

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

Подделка межсайтовых запросов (Cross-site request forgery, CSRF)

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

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

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

Clickjacking (click hijacking = похищение кликов)

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

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

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

1.11.2 Стандартные ошибки, которых следует избегать при использовании скриптовых API

Этот раздел — неофициальный.

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

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

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

Одним из способов установки связан с элементами 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 может быть возбуждено посередине, что приведет к его пропусканию:

<!-- Do not use this style, it has a race condition! -->
 <img id="games" src="games.png" alt="Games">
 <!-- the 'load' event might fire here while the parser is taking a
      break, in which case you will not see it! -->
 <script>
  var img = document.getElementById('games');
  img.onload = gamesLogoHasLoaded; // might never fire!
 </script>

1.12 Соответствие требованиям для разработчиков

Этот раздел — неофициальный.

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

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

1.12.1 Презентационная разметка (presentational markup)

Этот раздел — неофициальный.

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

Использование презентационных элементов ведет к более плохой доступности (accessibility)

Хотя вполне возможно использовать презентационную разметку таким образом, чтобы обеспечить пользователей реабилитационными технологиями (assistive technologies, ATs) на приемлемом уровне (например, используя ARIA), делать так гораздо труднее чем при использовании аналогичной семантической разметки. Далее, даже использование подобных методов не поможет создавать страницы, доступные для не-AT пользователей без графики, таких как пользователи текстовых браузеров.

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

Более высокая стоимость обслуживания

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

Бо́льшие размеры документов

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

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

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

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

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

Этот раздел — неофициальный.

Синтаксис HTML ограничен ради избежания широкого круга проблем.

Неинтуитивное поведение при обработке ошибок

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

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

<table><hr>...
Ошибки с возможностью восстановления

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

Об ошибках в условиях, когда обработка ошибок несовместима с вещанием (streaming) агентами пользователя

Иногда обработка ошибок как в случае поведения с <table><hr>... в примере, упомянутом выше, несовместима с вещанием для ПА (агентов пользователя, которые обрабатывают файлы HTML за один шаг, без сохранения состояния). Чтобы избежать проблем несовместимости с такими ПА, любой синтаксис в таких условиях считается неправильным.

Ошибки, которые могут приводить к вынужденному преобразованию в infoset (инфомножество).

Когда ПА, основанный на XML подсоединен к парсеру HTML, существует возможность, что некие инварианты, которые навязывает XML, такие как отсутствие 2х последовательных дефисов в комментариях, будут нарушены 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 для этого фрагмента может быть таким:

  • p
    • i
      • #text: He dreamt.
  • p
    • i
      • i
        • #text: He dreamt that he ate breakfast.
  • p
    • i
      • i
        • i
          • #text: Then lunch.
  • p
    • i
      • i
        • i
          • i
            • #text: And finally dinner.
Ошибки, влекущие хрупкие синтаксические конструкции.

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

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

В этом фрагменте значение атрибута есть "?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 is ok, since it's not a named character reference -->
<a href="?art&amp;copy">Art and Copy</a> <!-- the & has to be escaped, since &copy is a named character reference -->
Ошибки, влекущие известные проблемы совместимости в устаревших ПА

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

Например, именно поэтому символ U+0060 GRAVE ACCENT (`) не разрешен в незакавыченных атрибутах. В некоторых устаревших ПА он иногда рассматривается как символ кавычки.

Другой пример этого есть DOCTYPE, который обязан включать режим no-quirks mode, потому что поведение устаревших ПА в режиме quirks mode часто в значительной степени недокументировано.

Ошибки с риском подвергнуть разработчиков атакам безопасности

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

Например, запрет на использование UTF-7 существует исключительно для предотвращения того, что разработчики стали бы жертвами известных атак межсайтового скриптинга (cross-site-scripting), используя UTF-7.

Случаи, когда намерения разработчика неясны

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

Например, неясно, имел ли в виду разработчик h1- или h2-заголовок ниже:

<h1>Contact details</h2>
Случаи вероятных опечаток

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

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

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

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

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

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

1.12.3 Ограничения на контент-модели и на значения атрибутов

Этот раздел — неофициальный.

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

Ошибки, связанные с сомнительной семантикой контента

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

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

Ошибки, связанные с конфликтом в выражаемой семантике

Кроме того, чтобы привлечь внимание разработчика к ошибкам в использовании элементов, явные противоречия, выраженные в семантике также считаются ошибками соответствия.

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

<hr role="cell">
<input type=radio role=progressbar>

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

Случаи, когда стили по умолчанию, скорее всего, ведут к путанице

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

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

Другим примером может быть способ, каким интерактивный контент (interactive content) не может быть вложен. Например, элемент button не может содержать элемент textarea. Потому, что поведение по умолчанию подобного вложения интерактивных элементов могло бы быть излишне запутанным для пользователей. Вместо вложения этих элементов они могут быть помещены рядом друг с другом.

Ошибки, указывающие на вероятное непонимание спецификации

Иногда что-то запрещено, потому что разрешение этого, вероятно, вызвало бы путаницу у разработчика.

Например, установка атрибута disabled значением false запрещена, потому что несмотря на присутствие смысла в том, что элемент включен, на самом деле это означает, что элемент выключен (для реализаций имеет значение присутствие атрибута, а не его значение).

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

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

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

Ошибки, связанные с особенностями парсера

Некоторые элементы парсятся несколько эксцентричным способом (обычно по историческим причинам), и ограничения их контент-модели предназначены для того, чтобы не вовлекать разработчика в эти проблемы.

Например, элемент form не разрешен внутри phrasing content, потому что HTML-разбор начального тега элемента form повлечет конечный тег элемента p. Таким образом, следующая разметка приводит к двум параграфам, а не одному:

<p>Welcome. <form><label>Name:</label> <input></form>

Она парсится ровно следующим образом:

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

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

Вот почему, например, наличие двух атрибутов id с одним и тем же именем не соответствует требованиям. Дублированные ID ведут к выбору неверного элемента, иногда с ужасными последствиями, причины которых трудно определить.

Ошибки, которые тратят время разработчика

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

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

Ошибки, влияющие на миграцию авторов с и на XHTML

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

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

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

Ошибки, связанные с областями, зарезервированными для расширения в будущем

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

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

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

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

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

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

Этот раздел — неофициальный.

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

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

Данная Архитекторная Спецификация предоставляет разработчикам спецификаций, разработчикам ПО и content developers общий справочник для работы с текстом в World Wide Web совместимым образом, опираясь на Универсальный Набор Символов, определенный Unicode Standard совместно с ISO/IEC 10646. Затрагиваются такие вопросы, как использование терминов "character", "кодировка" (encoding) и "строка", "a reference processing model", выбор и определение кодировки символов, экранирование символов и индексирование строк.

Unicode Security Considerations [UTR36]

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

Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG]

Web Content Accessibility Guidelines (WCAG) 2.0 охватывает широкий спектр рекомендаций, чтобы сделать Web-контент более доступным. Следование этим рекомендациям сделает контент доступным широкому кругу людей с ограниченными возможностями, включая слепоту и слабое зрение, глухоту и потерю слуха, неспособность к обучению, когнитивные ограничения, ограниченное движение, трудности с речью, фоточувствительность и их комбинации. Следование этим рекомендациям во многих случаях также сделает ваш Web-контент более удобным для всех пользователей в целом.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG]

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

User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG]

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

Polyglot Markup: HTML-Compatible XHTML Documents [POLYGLOT]

Документ, который использует полиглот-разметку, есть поток байтов, который парсится в одинаковые деревья DOM (за исключением атрибута xmlns на корневом элементе) при обработке как HTML и при обработке как XML. Полиглот-разметка, которая отвечает определенному набору ограничений, понимается одинаково, вне зависимости от того, была ли она обработана как HTML или как XHTML, в соответствии с спецификацией HTML5. Полиглот-разметка использует специальный DOCTYPE, пространственные объявления и специальный регистр — обычно нижний, но иногда и camel-регистр — для элементов и имен атрибутов. Полиглот-разметка использует нижний регистр для некоторых значений атрибутов. Дальнейшие ограничения налагаются на пустые элементы, named entity references и использование скриптов и стилей.