1. Введение.

Опубликовано: 5 декабря 2014      Перевод:

Перевод спецификации HTML Living standard, глава: 1 Introduction.

Последнее обновление: 26 сентября 2014.

1 Введение.

1.1 Место данной спецификации.

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

Место данной спецификации в стеке веб-стандартов.

1.2 Это HTML5 спецификация?

Этот параграф является ненормативным.

Если коротко — Да.

А если более детально — термин «HTML5» повсеместно используется как жаргонный, подразумевающий современные Веб-технологии, большинство которых (но, ни в коем случае не все) разработаны специалистами WHATWG. Этот документ один из них. Другие представлены в каталоге спецификаций WHATWG.

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

1.3 Основа.

Этот параграф является ненормативным.

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

1.4 Аудитория.

Этот параграф является ненормативным.

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

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

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

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

Этот параграф является ненормативным.

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

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

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

1.6 История.

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

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

В следующем году состав W3C консорциума решил остановить дальнейшее развитие HTML и взамен начал работы по созданию его эквивалента на основе XML, который получил название XHTML. Первой попыткой в этом направлении было переформулирование HTML 4 стандарта в формат XML, в результате чего был создан новый стандарт XHTML 1.0, который не добавлял ничего нового за исключением измененной формы сериализации. Работы по этому стандарту были завершены в 2000 году. Далее, после создания XHTML 1.0 стандарта, специалисты W3C организации сфокусировались на том, чтобы облегчить возложенную на другие рабочие группы задачу распространения XHTML и объявили о так называемой «XHTML модуляризации». Параллельно с этим в W3C велись работы по разработке нового XHTML 2 языка, который не был совместим с ранними версиями HTML и XHTML стандартов.

Примерно в тот же период времени, когда развитие 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).

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

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

На протяжении нескольких лет обе группы работали совместно. В 2011 году, организации пришли к выводу, что каждая из них, в сущности, преследует разные цели: W3C хотел опубликовать «законченную» версию HTML5 стандарта, в то время как WHATWG стремился к продолжению работ над «живой» версией HTML стандартаHTML Living Standard, то есть к постоянному развитию платформы путем добавления в нее новых свойств и возможностей, вместо «замораживания» ее на определенном этапе с уже существующими в ней проблемами.

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

1.7. Редакционные комментарии.

Этот параграф является ненормативным.

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

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

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

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

1.7.1 Сериализация выполнения скриптов.

Этот параграф является ненормативным.

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

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

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

Этот параграф является ненормативным.

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

1.7.3 Возможности расширенного использования.

Этот параграф является ненормативным.

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

  • С целью расширения возможностей элементов авторы могут использовать атрибут class, практически создавая таким образом собственные элементы, при этом применяя наиболее подходящие уже существующие «реальные» HTML элементы. В результате браузеры или другие средства, которые не могут распознать расширение элементов, все еще будут поддерживать их в достаточной степени. Этот прием, к примеру, используется механизмом микроформатов.
  • С помощью атрибутов data-*="" авторы могут включать данные, используемые встроенными скриптами на стороне клиента или же серверными скриптами общего назначения с последующей их обработкой. Такой способ гарантирует, что эти данные никогда не будут изменены браузерами, и к тому же он позволяет включать необходимую для скриптов информацию непосредственно в HTML элементы, которая может быть извлечена и использована по назначению.
  • Авторы также могут использовать механизм <meta name="" content=""> для включения метаданных, используемых в масштабах всей страницы, путем регистрации расширений предопределенного набора имен метаданных.
  • Для комментирования ссылок специфического назначения, авторы могут применять механизм rel="", путем регистрации расширений предопределенного набора типов ссылок. Этот прием тоже используется в микроформатах.
  • Авторы могут включать исходные данные для последующего использования встроенными либо серверными скриптами посредством применения механизма <script type=""> с настраиваемым типом.
  • Для запуска созданных плагинов авторы могут использовать элемент embed. Таким образом работает Flash.
  • У авторов также есть возможность расширения API интерфейсов с помощью механизма прототипирования JavaScript. Такой метод, например, широко используется скриптовыми библиотеками.
  • Авторы могут воспользоваться функционалом микроданных (атрибуты itemscope="" и itemprop="") для включения в документ вложенных пар данных имя-значение с целью их совместного использования другими приложениями и сайтами.

1.8 HTML vs XHTML

Этот параграф является ненормативным.

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

Содержащееся в памяти представление документа известно как DOM HTML или если коротко — DOM.

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

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

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

С помощью DOM, а также HTML и XHTML синтаксисов не может быть представлен один и тот же контент в его полной форме. Так, допустим, пространства имен не могут указываться с использованием HTML синтаксиса. Аналогичным образом наличие такого элемента как noscript допустимо только в рамках HTML синтаксиса и не может быть реализовано в DOM модели или с использованием XHTML синтаксиса. Содержащие строку "––>" комментарии могут использоваться только в контексте DOM модели и не допустимы HTML и XHTML синтаксисами.

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

Этот параграф является ненормативным.

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

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

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

1.9.1 Как следует читать данную спецификацию.

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

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

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

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

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

1.9.2 Типографические соглашения.

Так выглядит определение, требование или пояснение.

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

Это пример.

Так оформляется спорный вопрос.

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

IDL
interface  Example  {
// здесь размещается определение в формате IDL
};

Это ненормативное определение. Требования к его реализации приведены ниже.

variable = object . method ([optional Argument])

Здесь находится пояснение для авторов касательно использования интерфейса.

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

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

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

Смешанный и код общего назначения, примеры различных структур и т.п.
<!–– HTML код. ––>

или

/∗ CSS стили. ∗/

а фрагменты используемого внутри текста кода выглядят вот так.

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

Так оформлено требование к реализации.

Используемые в рамках приведенных алгоритмов шаги синхронных секций помечены таким маркером — ⌛.

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

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

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

Этот параграф является ненормативным.

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

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

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

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

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

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

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

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

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

  • Точный список поддерживаемых пользовательским агентом возможностей.
  • Максимально допустимая глубина стека рекурсии скрипта.
  • Компоненты, описывающие окружение пользователя. Такие как медиа запросы и объект Screen. [MQ] [CSSOMVIEW]
  • Часовой пояс пользователя.

1.10.1 Обмен информацией между сайтами.

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

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

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>

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

<!–– пустые атрибуты ––>
<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 дерево, которое является хранящимся в памяти компьютера представлением документа.

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

Разметка, используемая в верхнем сниппете этого параграфа будет трансформирована в следующее DOM дерево:

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

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

В состав элемента head входит элемент title, который в свою очередь содержит текстовый узел Text, представляющий текст названия документа "Sample page". Аналогичным образом элемент body содержит h1 и p элементы, а также комментарии.

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

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

Любой элемент DOM дерева представляется объектом, который обладает соответствующим API интерфейсом, используемым для манипуляции элементом. Так, допустим, атрибут href ссылки (к примеру, элемента a из приведенного выше фрагмента разметки), может быть изменен несколькими способами:

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

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

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 пространства основана на концепции «первоисточников» ("origns") и поэтому большинство потенциальных Web атак производятся посредством действий между различными первоисточниками ("cross-origin" действий). [ORIGIN].

Отсутствие проверки вводимых пользователем данных.
Cross-site scripting (XSS).
SQL injection.
При получении данных из недостоверных источников, таких, например, как формируемый пользователем контент в виде текста комментариев, значения 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>

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

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

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

Такие действия называют — атакой межсайтового скриптинга — XSS (Cross-site scripting).

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

  • Позволяя использовать такие, казалось бы, безобидные элементы, как img, очень важно вносить в белый список и все допустимые атрибуты. Поскольку, если разрешить все атрибуты без исключения, то для запуска случайного скрипта взломщик сможет использовать, допустим, атрибут onload.
  • Позволяя предоставление URL адресов (к примеру, для ссылок), в состав белых списков необходимо включать однозначные описания допустимых схем всех URL адресов, так как существует множество схем, содержащих небезопасные компоненты. Наиболее ярким примером может быть "javascript:", однако, пользовательские агенты могут привести в исполнение (известны реальные случаи таких реализаций) и другие варианты.
  • Допуская наличие элемента base, вы тем самым предоставляете возможность подмены любого из содержащихся на странице элементов script с относительными ссылками на скрипт злоумышленника, а также возможность редиректа данных форм при их отправке на враждебный сайт.
Фальсификация межсайтовых запросов.
Cross-site request forgery (CSRF).
Если сайт позволяет пользователю выполнять отправку формы, которая приводит к побочным действиям, напрямую связанным с пользователем, к примеру, размещением на форуме сообщения под своим именем, совершением покупок, предоставлением паспортных данных, очень важно удостовериться в том, что пользователь выполняет эти действия намеренно, а не делает это неосознанно вследствие обманных действий со стороны стороннего сайта.

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

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

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

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

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

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

Этот параграф является ненормативным.

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

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

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

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

В этом фрагменте для перехвата события load элемента img автор применяет обработчик onload:

<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);
// в данном случае тоже сработает
</script>

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

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

1.11.3 Способы определения ошибок при написании HTML кода: валидаторы и инструменты проверки соответствия стандартам.

Этот параграф является ненормативным.

С целью обнаружения наиболее распространенных ошибок авторам рекомендуется использовать средства проверки соответствия стандартам (известные также как валидаторы). WHATWG поддерживает и предоставляет вашему вниманию список подобных инструментов: https://validator.whatwg.org/.

1.12 Требования совместимости, предъявляемые к авторам.

Этот параграф является ненормативным.

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

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

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

Этот параграф является ненормативным.

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

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

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

Повышение затрат на сопровождение документа.
Сайт, который разработан таким образом, что его разметка не зависит от стилевого оформления, требует значительно меньше затрат в плане его обслуживания. Так, к примеру, для того, чтобы изменить цвет шрифта находящихся повсюду в рамках сайта фрагментов текста (<font color="">), вам понадобится внести изменения в каждый такой элемент, тогда как сходные, подобные этому изменения сайта, оформленного посредством CSS, могут быть произведены путем модификации единственного файла.
Увеличение объема документа.
Презентационному типу разметки свойственна избыточность, что, собственно, и приводит к увеличению размеров документа.

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

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

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

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

Этот параграф является ненормативным.

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

Режим обработки неинтуитивных ошибок.
В результате парсинга некоторых невали́дных синтаксических конструкций образуются DOM деревья с чрезвычайно сложной для восприятия структурой.

Пример кода:

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

<table><hr> . . .

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

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

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

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

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

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

В этом примере строка "?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 не создает проблем, так как это не является мнемоникой
символа ––>

<a href="?art&copy">Art and Copy</a> <!–– здесь необходимо
избежать использования символа &, поскольку &copy является
именной ссылкой на символ (мнемоникой) ––>

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

Взять, к примеру, символ грависа "̀ " (U+0060), который не разрешается использовать в не заключенных в кавычки значениях атрибутов. Это связано с тем, что некоторые существующие пользовательские агенты воспринимают данный символ как знак кавычки.

Другим примером может быть слово DOCTYPE, используемое для декларации типа документа, которая необходима для активации режима no-quirks mode («режим соответствия стандартам»), поскольку поведение устаревших пользовательских агентов в quirks mode режиме («режим обратной совместимости») нигде не задукоментировано.

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

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

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

Вот здесь, допустим, совершенно непонятно, заголовок какого уровня автор хочет использовать h1 или h2:

<h1>Contact details</h2>

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

Если, к примеру, автор вместо тега <caption> опечатался и указал <capton>, то последний вариант будет признан ошибкой. Подобные опечатки должны исправляться автором сразу же.

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

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

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

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

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

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

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

Взять, к примеру, атрибут 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 атрибутов с одинаковым значением. Дублирование идентификаторов элементов становится причиной выбора неверного элемента, что иногда может привести к катастрофическому результату, причину которого очень сложно выявить.
Ошибки, на исправление которых у авторов уходит много времени.
Некоторые конструкции не допустимы, поскольку из многолетнего опыта известно, что они приводят к пустой трате времени автора. Благодаря содействию в обходе подобных структур, авторы смогут сэкономить свое время и силы в будущем.

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

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

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

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

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

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

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

1.13 Рекомендованное чтение.

Этот параграф является ненормативным.

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

Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD].
Модель символа в WWW 1.0: Oсновные положения.
Эта архитектурная спецификация предоставляет авторам спецификаций, создателям программного обеспечения и разработчикам контента общедоступную справочную информацию по совместимым способам манипуляции текстом в рамках WWW, которые основаны на «Универсальном наборе символов», определенном стандартом Unicode совместно с ISO/IEC 10646. Обсуждаемые в документе темы включают такие вопросы как использование терминов «символ», «кодирование» и «строка», модель обработки ссылок, выбор и определение кодировки символов, экранирование символов и индексация строк.
Unicode Security Considerations [UTR36].
Оценка вопросов безопасности Unicode.
По причине того, что Unicode включает в себя огромное количество символов и объединяет различные системы письма мира, неверное их использование может подвергнуть программное обеспечение или системы в целом различным атакам безопасности. И в связи с ростом интернационализации программных продуктов данный вопрос становиться более актуальным. В этом документе рассматриваются вопросы безопасности, на которые необходимо обратить внимание программистам, системным аналитикам, разработчикам стандартов и пользователям, а также предоставляются особые рекомендации, способствующие снижению риска возникновения подобных проблем.
Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG].
Руководящие положения по обеспечению доступности веб-контента 2.0.
"Web Content Accessibility Guidelines (WCAG) 2.0" охватывает широкий спектр рекомендаций по созданию более доступного веб-контента. Соблюдение этих рекомендаций способствует образованию контента, доступного для более широкого круга людей с ограниченными возможностями, включая слепых и слабовидящих, глухих и слабослышащих, с нарушенной функцией обучаемости и когнитивными расстройствами, ограниченных в движении, с речевыми расстройствами, нарушением светочувствительности и комбинациями этих недостатков. Благодаря соблюдению данных рекомендаций создаваемый вами веб-контент будет к тому же более практичен для пользователей в общем.
Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG].
Руководящие положения по созданию доступных авторских средств разработки 2.0.
Эта спецификация предоставляет рекомендации по разработке авторских средств создания веб-контента, более дружелюбных для людей с ограниченными возможностями. Отвечающее требованиям данной спецификации средство разработки имеет повышенный уровень удобства благодаря доступности пользовательского интерфейса для авторов с различными недостатками. Такое программное обеспечение также способствует созданию, поддержке и развитию доступного веб-контента всеми авторами.
User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG].
Руководящие положения по созданию доступных пользовательских агентов 2.0.
Данный документ содержит нормативы, необходимые для создания пользовательских агентов, снимающих барьеры веб-доступности для людей с ограниченными возможностями. Под пользовательскими агентами подразумеваются браузеры и другие типы программного обеспечения, которое производит поиск и предоставляет их пользователям веб-контент. Пользовательский агент, удовлетворяющий требованиям этих рекомендаций, всячески способствует развитию доступности посредством собственного пользовательского интерфейса и другого внутреннего функционала, включая его способность взаимодействия с различными технологиями (в особенности с технологиями обеспечения доступности). Более того, отвечающие требованиям этой спецификации пользовательские агенты более удобны в использовании для всех пользователей, а не только для людей с ограниченными возможностями.