Официальная html 3 2 спецификация


Содержание

Правила построения HTML-документов

Всемирная паутина World Wide Web (WWW) соткана из Web-страниц, которые создаются с помощью так называемого языка разметки гипертекста HTML (HyperText Markup Language). Хотя многие говорят о программировании на этом языке, HTML вовсе не является языком программирования в традиционном понимании. HTML — язык разметки документа. При разработке HTML-документа выполняется разметка текстового документа точно так же, как это делает редактор при помощи красного карандаша. Эти пометки служат для указания формы представления информации, содержащейся в документе.

Специальные программы просмотра HTML-документов, которые часто называют браузерами, служат для интерпретации файлов, размеченных по правилам языка HTML, форматирования их в виде Web-страниц и отображении их содержимого на экране компьютера пользователя. Существует большое количество программ-браузеров, разработанных различными компаниями, однако, на сегодняшний день из всего разнообразия программ явно выделяются две программы-лидера — Netscape Communicator и Microsoft Internet Explorer.

Программа Netscape Navigator разработана компанией Netscape Communications Corporation. Как и у многих программных продуктов, существует ряд версий этой программы. Последней версией программы Netscape Communicator на момент написания книги являлась версия 4.7. Программа Internet Explorer разработана компанией Microsoft. Последняя версия этой программы — 5.0.

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

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

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

Чтобы понять, что собой представляет язык разметки, вспомним старые добрые времена, когда многие работали с текстовыми редакторами типа WordStar. В них для выделения какой-либо фразы, например, полужирным шрифтом, в ее начале и в конце ставились специальные отметки (/ B и / b ):

/ B Этот текст будет выведен полужирным шрифтом/ b

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

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

Этот текст будет выведен полужирным шрифтом

Символы включают полужирное начертание, а символы выключают его. Такие символы, которые управляют отображением текста и при этом сами не отображаются на экране, в языке HTML принято называть тэгами (от английского слова tag — ярлык, признак).

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

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

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

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

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

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

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

Тэги могут записываться с параметрами или атрибутами (от англ., attribute). В этой книге будем чаще всего использовать термин параметр. Наборы допустимых параметров индивидуальны для каждого тэга. Общие правила записи параметров заключаются в следующем. После имени тега могут следовать параметры, которые отделяются друг от друга пробелами. Порядок следования параметров тега произволен. Многие параметры требуют указания их значений, однако некоторые параметры не имеют значений или могут записываться без них, принимая значения по умолчанию. Если параметр требует значения, то оно указывается после названия параметра через знак равенства. Значение параметра может записываться в кавычках, так и без них. Единственным случаем, в котором без кавычек не обойтись, является случай, когда в значении параметра имеются пробелы. В значениях параметров (в отличие от названий тегов и самих параметров) иногда важен регистр записи. Приведем пример записи тега с параметрами:

Здесь для тега

задано два параметра. Первый параметр BORDER указан без значения. Второй параметр ALIGN имеет значение left.

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

Все тэги, которые допустимо использовать в разделе документа HTML, могут иметь параметры CLASS, ID, LANG, LANGUAGE, STYLE и TITLE. Использование этих параметров полезно, прежде всего, при стилевом оформлении документов, речь о котором пойдет во второй части книги.

Параметры CLASS, ID, STYLE поддерживаются Internet Explorer, начиная с версии 3.0, и Netscape, начиная с версии 4.0. Эти параметры нужны при использовании стилей.

Параметры LANG, LANGUAGE, TITLE — поддерживаются только Internet Explorer, начиная с версии 4.0. Эти параметры указывают, соответственно, используемый язык (например, для России: LANG=ru), язык записи скриптов (например, LANGUAGE=JavaScript), а также текст подсказки, выдаваемой при наведении указателя мыши на данный элемент (TITLE).

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

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

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

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

Работу по созданию спецификации HTML взяла на себя организация, называемая World Wide Web Consortium (сокращенно — W3C). В ее задачу входило составление спецификации, отражающей современный уровень развития возможностей языка с учетом разнообразных предложений компаний-разработчиков браузеров. Так, в ноябре 1995 г. появилась спецификация HTML 2.0, призванная формализовать сложившуюся к концу 1994 г. практику использования HTML.

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

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

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

Июль 1997 года ознаменовался выходом предлагаемой спецификации HTML 4.0, которая в декабре 1997 г. стала официальной рекомендацией. На сегодняшний день это последняя из принятых спецификаций.

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

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

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

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

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

Официальные сведения о спецификации HTML всегда можно получить с Web-сайта Консорциума W3C по адресу http://www.w3.org/TR/. Спецификация 4.0 находится по адресу http://www.w3.org/TR/REC-htmI40-971218.

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

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

Чаще всего тег используется без параметров. В предыдущих версиях использовался параметр VERSION, отмененный спецификацией HTML 4. 0 . На смену этому параметру пришел тег >.

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

Между парой тегов и располагается сам документ. Документ может состоять из двух разделов — раздела заголовка (начинающийся тэгом ) и раздела содержательной части документа (начинающийся тэгом ). Для документов, описывающих фреймовые структуры, вместо раздела BODY используется раздел FRAMESET (с тэгом ). Далее будут рассмотрены правила составления разделов документа HEAD и BODY. Построение документов, содержащих фреймы, рассматривается в главе 5.

Раздел документа HEAD

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

Раздел заголовка открывается тэгом . Обычно этот тег следует сразу же за тэгом . Закрывающий тег показывает конец этого раздела. Между упомянутыми тэгами располагаются остальные теги раздела заголовка.

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

Обязательность названия документа, вообще говоря, носит характер настоятельной рекомендации. Документ без тега также будет отображаться браузерами. При этом различные браузеры в качестве заголовка окна будут выдавать различную информацию. Так ранние версии браузера Netscape выдавали строчку «No title». Другие браузеры либо не показывают ничего, либо отображают адрес загруженного файла, повторяя информацию панели Location браузера.


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

По умолчанию текст, содержащийся в названии документа, используется при создании закладки (bookmark) для документа. Поэтому, для большей информативности, избегайте безликих названий (Home Page, Index и т. д.). Подобные слова, используемые в качестве названия закладки, обычно совершенно бесполезны. Название документа должно кратко характеризовать его содержание. Заметим, что при отображении на экране документов с фреймовой структурой, когда в каждый из фреймов загружается отдельный документ, имеющий свое название, на экране будет видно только название главного документа. Тем не менее, задавать название отдельных документов, предназначенных для загрузки во фреймы, также настоятельно рекомендуется. Более подробно этот вопрос рассматривается в главе 5.

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

Связь с другими документами

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

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

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

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

Тэг имеет один обязательный параметр HREF, после которого указывается полный URL-адрес документа. Ниже показан пример использования тега .

Указание базового адреса

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

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

Тэг

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

    Таблица 1.1. Параметры тега

  • HREF Указывает на URL-адрес другого документа
    REL Определяет отношение между текущим и другим документом
    REV Определяет отношение между другим документом и текущим (отношение, обратное REL)
    TYPE Указывает тип и параметры присоединенной таблицы стилей

    Приведем примеры тега
    с параметрами:

    Первая строка указывает на связь с файлом оглавления документа (toc.html — table of contents) с прямым отношением contents. Вторая строка описывает связь с URL-адресом автора документа (с обратным отношением made).

    Между документами может существовать множество различных отношений. Примеры других значений параметра REL: bookmark, copyright, glossary, help, home, index, toc, next, previous. Параметр REV может также принимать значения: author, editor, publisher, owner.

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

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

    Браузеры Netscape Navigator и Internet Explorer поймут эту запись как инструкцию ожидать 60 секунд, а затем загрузить новый документ. Такая инструкция часто используется при изменении местоположения документов. Небольшой документ с приведенной строкой может быть оставлен на старом месторасположении документа для автоматической ссылки на его новое месторасположение.

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

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

    Спецификация HTML не определяет каких-либо конкретных имен свойств, записываемых в тэге . Однако есть несколько часто применяемых свойств, например, description, keywords, author, robots и др.:

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

    Тэг может иметь параметры, указанные в табл. 1.2.

    Таблица 1.2. Параметры тега

    Параметр Назначение
    HTTP-EQUIV Определяет свойство для тэга
    NAME Обеспечивает дополнительное описание тэга. Если этот параметр опущен, он считается эквивалентным параметру HTTP-EQUIV
    URL Определяет адрес документа для свойства
    CONTENT Определяет возвращаемое значение для свойства

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

    HTML 3.2 Reference Specification

    W3C Recommendation 14-Jan-1997

    Status of this document

    This document has been reviewed by W3C members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C’s role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

    A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/pub/WWW/TR/.

    Abstract

    The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification defines HTML version 3.2. HTML 3.2 aims to capture recommended practice as of early ’96 and as such to be used as a replacement for HTML 2.0 (RFC 1866).

    Contents

    Introduction to HTML 3.2

    HTML 3.2 is W3C’s specification for HTML, developed in early `96 together with vendors including IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, and Sun Microsystems. HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.

    W3C is continuing to work with vendors on extensions for accessibility features, multimedia objects, scripting, style sheets, layout, forms, math and internationalization. W3C plans on incorporating this work in further versions of HTML.

    HTML as an SGML Application

    HTML 3.2 is an SGML application conforming to International Standard ISO 8879 — Standard Generalized Markup Language. As an SGML application, the syntax of conforming HTML 3.2 documents is defined by the combination of the SGML declaration and the document type definition (DTD). This specification defines the intended interpretation of HTML 3.2 elements, and places further constraints on the permitted syntax which are otherwise inexpressible in the DTD.

    The SGML rules for record boundaries are tricky. In particular, a record end immediately following a start tag should be discarded. For example:

    is equivalent to:

    Similarly, a record end immediately preceding an end tag should be discarded. For example:

    is equivalent to:


    Except within literal text (e.g. the PRE element), HTML treats contiguous sequences of white space characters as being equivalent to a single space character (ASCII decimal 32). These rules allow authors considerable flexibility when editing the marked-up text directly. Note that future revisions to HTML may allow for the interpretation of the horizontal tab character (ASCII decimal 9) with respect to a tab rule defined by an associated style sheet.

    SGML entities in PCDATA content or in CDATA attributes are expanded by the parser, e.g. é is expanded to the ISO Latin-1 character decimal 233 (a lower case letter e with an acute accent). This could also have been written as a named character entity, e.g. é . The & character can be included in its own right using the named character entity & .

    HTML allows CDATA attributes to be unquoted provided the attribute value contains only letters (a to z and A to Z), digits (0 to 9), hyphens (ASCII decimal 45) or, periods (ASCII decimal 46). Attribute values can be quoted using double or single quote marks (ASCII decimal 34 and 39 respectively). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa.

    Note that some user agents require attribute minimisation for the following attributes: COMPACT , ISMAP , CHECKED , NOWRAP , NOSHADE and NOHREF . These user agents don’t accept syntax such as COMPACT=COMPACT or ISMAP=ISMAP although this is legitimate according to the HTML 3.2 DTD.

    The SGML declaration and the DTD for use with HTML 3.2 are given in appendices. Further guidelines for parsing HTML are given in WD-html-lex.

    The Structure of HTML documents

    HTML 3.2 Documents start with a declaration followed by an HTML element containing a HEAD and then a BODY element:

    In practice, the HTML , HEAD and BODY start and end tags can be omitted from the markup as these can be inferred in all cases by parsers conforming to the HTML 3.2 DTD.

    Every conforming HTML 3.2 document must start with the declaration that is needed to distinguish HTML 3.2 documents from other versions of HTML. The HTML specification is not concerned with storage entities. As a result, it is not required that the document type declaration reside in the same storage entity (i.e. file). A Web site may choose to dynamically prepend HTML files with the document type declaration if it is known that all such HTML files conform to the HTML 3.2 specification.

    Every HTML 3.2 document must also include the descriptive title element. A minimal HTML 3.2 document thus looks like:

    Note: the word «Final» replaces «Draft» now that the HTML 3.2 specification has been ratified by the W3C member organizations.

    The HEAD element

    This contains the document head, but you can always omit both the start and end tags for HEAD . The contents of the document head is an unordered collection of the following elements:

    • The TITLE element
    • The STYLE element
    • The SCRIPT element
    • The ISINDEX element
    • The BASE element
    • The META element
    • The LINK element

    The %head.misc entity is used to allow the associated elements to occur multiple times at arbitrary positions within the HEAD. The following elements can be part of the document head: TITLE defines the document title, and is always needed. ISINDEX for simple keyword searches, see PROMPT attribute. BASE defines base URL for resolving relative URLs. SCRIPT reserved for future use with scripting languages. STYLE reserved for future use with style sheets. META used to supply meta info as name/value pairs. LINK used to define relationships with other documents.

    TITLE , SCRIPT and STYLE are containers and require both start and end tags. The other elements are not containers so that end tags are forbidden. Note that conforming browsers won’t render the contents of SCRIPT and STYLE elements.

    TITLE

    Every HTML 3.2 document must have exactly one TITLE element in the document’s HEAD . It provides an advisory title which can be displayed in a user agent’s window caption etc. The content model is PCDATA. As a result, character entities can be used for accented characters and to escape special characters such as & and TITLE element.

    Example TITLE element:

    STYLE and SCRIPT

    These are place holders for the introduction of style sheets and client-side scripts in future versions of HTML. User agents should hide the contents of these elements.

    These elements are defined with CDATA as the content type. As a result they may contain only SGML characters. All markup characters or delimiters are ignored and passed as data to the application, except for ETAGO (» ISINDEX element indicates that the user agent should provide a single line text input field for entering a query string. There are no restrictions on the number of characters that can be entered. The PROMPT attribute can be used to specify a prompt string for the input field, e.g.

    The semantics for ISINDEX are currently well defined only when the base URL for the enclosing document is an HTTP URL. Typically, when the user presses the enter (return) key, the query string is sent to the server identified by the base URL for this document. For example, if the query string entered is «ten green apples» and the base URL is:

    then the query generated is:

    Note that space characters are mapped to «+» characters and that normal URL character escaping mechanisms apply. For further details see the HTTP specification.

    Note in practice, the query string is resticted to Latin-1 as there is no current mechanism for the URL to specify a character set for the query.

    The BASE element gives the base URL for dereferencing relative URLs, using the rules given by the URL specification, e.g.

    The image is deferenced to

    In the absence of a BASE element the document URL should be used. Note that this is not necessarily the same as the URL used to request the document, as the base URL may be overridden by an HTTP header accompanying the document.

    The META element can be used to include name/value pairs describing properties of the document, such as author, expiry date, a list of key words etc. The NAME attribute specifies the property name while the CONTENT attribute specifies the property value, e.g.

    The HTTP-EQUIV attribute can be used in place of the NAME attribute and has a special significance when documents are retrieved via the Hypertext Transfer Protocol (HTTP). HTTP servers may use the property name specified by the HTTP-EQUIV attribute to create an RFC 822 style header in the HTTP response. This can’t be used to set certain HTTP headers though, see the HTTP specification for details.

    will result in the HTTP header:

    This can be used by caches to determine when to fetch a fresh copy of the associated document.

    LINK provides a media independent method for defining relationships with other documents and resources. LINK has been part of HTML since the very early days, although few browsers as yet take advantage of it (most still ignore LINK elements).

    LINK elements can be used in principle:

    1. for document specific navigation toolbars or menus
    2. to control how collections of HTML files are rendered into printed documents
    3. for linking associated resources such as style sheets and scripts
    4. to provide alternative forms of the current document

    href Specifies a URL designating the linked resource. rel The forward relationship also known as the «link type». It specifies a named relationship from the enclosing document to the resource specified by the HREF attribute. HTML link relationships are as yet unstandardized, although some conventions have been established. rev This defines a reverse relationship. A link from document A to document B with REV=relation expresses the same relationship as a link from B to A with REL=relation . REV=made is sometimes used to identify the document author, either the author’s email address with a mailto URL, or a link to the author’s home page. title An advisory title for the linked resource.

    Here are some proposed relationship values: rel=top The link references the top of a hierarchy, e.g. the first or cover page in a collection. rel=contents The link references a document serving as a table of contents. rel=index The link references a document providing an index for the current document. rel=glossary The link references a document providing a glossary of terms that are relevant to the current document. rel=copyright The link references a copyright statement for the current document. rel=next The link references the next document to visit in a guided tour. It can be used, for example, to preload the next page. rel=previous The link references the previous document in a guided tour. rel=help The link references a document offering help, e.g. describing the wider context and offering further links to relevant documents. This is aimed at reorienting users who have lost their way. rel=search The link references a page for searching material related to a collection of pages

    Example LINK elements:

    The BODY element

    This contains the document body. Both start and end tags for BODY may be omitted. The body can contain a wide range of elements:

    • Headings (H1 — H6)
    • The ADDRESS element
    • Block level Elements
    • Text level elements

    The key attributes are: BACKGROUND , BGCOLOR , TEXT , LINK , VLINK and ALINK . These can be used to set a repeating background image, plus background and foreground colors for normal text and hypertext links.

    Example: bgcolor Specifies the background color for the document body. See below for the syntax of color values. text Specifies the color used to stroke the document’s text. This is generally used when you have changed the background color with the BGCOLOR or BACKGROUND attributes. link Specifies the color used to stroke the text for unvisited hypertext links. vlink Specifies the color used to stroke the text for visited hypertext links. alink Specifies the highlight color used to stroke the text for hypertext links at the moment the user clicks on the link. background Specifies a URL for an image that will be used to tile the document background.

    Colors are given in the sRGB color space as hexadecimal numbers (e.g. COLOR=»#C0FFC0″ ), or as one of 16 widely understood color names. These colors were originally picked as being the standard 16 colors supported with the Windows VGA palette.

    Color names and sRGB values

    Black = «#000000» Green = «#008000»
    Silver = «#C0C0C0» Lime = «#00FF00»
    Gray = «#808080» Olive = «#808000»
    White = «#FFFFFF» Yellow = «#FFFF00»
    Maroon = «#800000» Navy = «#000080»
    Red = «#FF0000» Blue = «#0000FF»
    Purple = «#800080» Teal = «#008080»
    Fuchsia = «#FF00FF» Aqua = «#00FFFF»

    Block and Text level elements

    Most elements that can appear in the document body fall into one of two groups: block level elements which cause paragraph breaks, and text level elements which don’t. Common block level elements include H1 to H6 (headers), P (paragraphs) LI (list items), and HR (horizontal rules). Common text level elements include EM , I , B and FONT (character emphasis), A (hypertext links), IMG and APPLET (embedded objects) and BR (line breaks). Note that block elements generally act as containers for text level and other block level elements (excluding headings and address elements), while text level elements can only contain other text level elements. The exact model depends on the element.

    Headings

    H1 , H2 , H3 , H4 , H5 and H6 are used for document headings. You always need the start and end tags. H1 elements are more important than H2 elements and so on, so that H6 elements define the least important level of headings. More important headings are generally rendered in a larger font than less important ones. Use the optional ALIGN attribute to set the text alignment within a heading, e.g.

    The default is left alignment, but this can be overridden by an enclosing DIV or CENTER element.

    ADDRESS

    The ADDRESS element requires start and end tags, and specifies information such as authorship and contact details for the current document. User agents should render the content with paragraph-breaks before and after. Note that the content is restricted to paragraphs, plain text and text-like elements as defined by the %text entity.


    Block elements

    UL unordered lists These require start and end tags, and contain one or more LI elements representing individual list items. OL ordered (i.e. numbered) lists These require start and end tags, and contain one or more LI elements representing individual list items. DL definition lists These require start and end tags and contain DT elements that give the terms, and DD elements that give corresponding definitions. PRE preformatted text Requires start and end tags. These elements are rendered with a monospaced font and preserve layout defined by whitespace and line break characters. DIV document divisions Requires start and end tags. It is used with the ALIGN attribute to set the text alignment of the block elements it contains. ALIGN can be one of LEFT , CENTER or RIGHT . CENTER text alignment Requires start and end tags. It is used to center text lines enclosed by the CENTER element. See DIV for a more general solution. BLOCKQUOTE quoted passage Requires start and end tags. It is used to enclose extended quotations and is typically rendered with indented margins. FORM fill-out forms Requires start and end tags. This element is used to define a fill-out form for processing by HTTP servers. The attributes are ACTION , METHOD and ENCTYPE . Form elements can’t be nested. ISINDEX primitive HTML forms Not a container, so the end tag is forbidden. This predates FORM and is used for simple kinds of forms which have a single text input field, implied by this element. A single ISINDEX can appear in the document head or body. HR horizontal rules Not a container, so the end tag is forbidden. attributes are ALIGN , NOSHADE , SIZE and WIDTH . TABLE can be nested Requires start and end tags. Each table starts with an optional CAPTION followed by one or more TR elements defining table rows. Each row has one or more cells defined by TH or TD elements. attributes for TABLE elements are WIDTH , BORDER , CELLSPACING and CELLPADDING .

    Paragraphs

    The P element is used to markup paragraphs. It is a container and requires a start tag. The end tag is optional as it can always be inferred by the parser. User agents should place paragraph breaks before and after P elements. The rendering is user agent dependent, but text is generally wrapped to fit the space available.

    Paragraphs are usually rendered flush left with a ragged right margin. The ALIGN attribute can be used to explicitly specify the horizontal alignment: align=left The paragraph is rendered flush left. align=center The paragraph is centered. align=right The paragraph is rendered flush right.

    The default is left alignment, but this can be overridden by an enclosing DIV or CENTER element.

    Lists

    List items can contain block and text level items, including nested lists, although headings and address elements are excluded. This limitation is defined via the %flow entity.

    Unordered Lists

    Unordered lists take the form:

    The UL element is used for unordered lists. Both start and end tags are always needed. The LI element is used for individual list items. The end tag for LI elements can always be omitted. Note that LI elements can contain nested lists. The COMPACT attribute can be used as a hint to the user agent to render lists in a more compact style.

    The TYPE attribute can be used to set the bullet style on UL and LI elements. The permitted values are «disc», «square» or «circle». The default generally depends on the level of nesting for lists.

    • with
    • with
    • with

    This list was chosen to cater for the original bullet shapes used by Mosaic in 1993.

    Ordered (i.e. numbered) Lists

    Ordered (i.e. numbered) lists take the form:

    The OL START attribute can be used to initialize the sequence number (by default it is initialized to 1). You can set it later on with the VALUE attribute on LI elements. Both of these attributes expect integer values. You can’t indicate that numbering should be continued from a previous list, or to skip missing values without giving an explicit number.

    The COMPACT attribute can be used as a hint to the user agent to render lists in a more compact style. The OL TYPE attribute allows you to set the numbering style for list items:

    Type Numbering style
    1 Arabic numbers 1, 2, 3, .
    a lower alpha a, b, c, .
    A upper alpha A, B, C, .
    i lower roman i, ii, iii, .
    I upper roman I, II, III, .

    Definition Lists

    Definition lists take the form:

    DT elements can only act as containers for text level elements, while DD elements can hold block level elements as well, excluding headings and address elements.

    which could be rendered as: Term 1 This is the definition of the first term. Term 2 This is the definition of the second term.

    The COMPACT attribute can be used with the DL element as a hint to the user agent to render lists in a more compact style.

    DIR and MENU

    These elements have been part of HTML from the early days. They are intended for unordered lists similar to UL elements. User agents are recommended to render DIR elements as multicolumn directory lists, and MENU elements as single column menu lists. In practice, Mosaic and most other user agents have ignored this advice and instead render DIR and MENU in an identical way to UL elements.

    Preformatted Text

    The PRE element can be used to include preformatted text. User agents render this in a fixed pitch font, preserving spacing associated with white space characters such as space and newline characters. Automatic word-wrap should be disabled within PRE elements.

    Note that the SGML standard requires that the parser remove a newline immediately following the start tag or immediately preceding the end tag.

    PRE has the same content model as paragraphs, excluding images and elements that produce changes in font size, e.g. IMG , BIG , SMALL , SUB , SUP and FONT .

    A few user agents support the WIDTH attribute. It provides a hint to the user agent of the required width in characters. The user agent can use this to select an appropriate font size or to indent the content appropriately.

    Here is an example of a PRE element; a verse from Shelley (To a Skylark):

    which is rendered as:

    The horizontal tab character (encoded in Unicode, US ASCII and ISO 8859-1 as decimal 9) should be interpreted as the smallest non-zero number of spaces which will leave the number of characters so far on the line as a multiple of 8. Its use is strongly discouraged since it is common practice when editing to set the tab-spacing to other values, leading to misaligned documents.

    XMP, LISTING and PLAINTEXT

    These are obsolete tags for preformatted text that predate the introduction of PRE. User agents may support these for backwards compatibility. Authors should avoid using them in new documents!

    DIV and CENTER

    DIV elements can be used to structure HTML documents as a hierarchy of divisions. The ALIGN attribute can be used to set the default horizontal alignment for elements within the content of the DIV element. Its value is restricted to LEFT , CENTER or RIGHT , and is defined in the same way as for the paragraph element

    Note that because DIV is a block-like element it will terminate an open P element. Other than this, user agents are not expected to render paragraph breaks before and after DIV elements. CENTER is directly equivalent to DIV with ALIGN=CENTER . Both DIV and CENTER require start and end tags.

    CENTER was introduced by Netscape before they added support for the HTML 3.0 DIV element. It is retained in HTML 3.2 on account of its widespread deployment.

    BLOCKQUOTE

    This is used to enclose block quotations from other works. Both the start and end tags are required. It is often rendered indented, e.g.

    They went in single file, running like hounds on a strong scent, and an eager light was in their eyes. Nearly due west the broad swath of the marching Orcs tramped its ugly slot; the sweet grass of Rohan had been bruised and blackened as they passed.

    from «The Two Towers» by J.R.R. Tolkien.

    This is used to define an HTML form, and you can have more than one form in the same document. Both the start and end tags are required. For very simple forms, you can also use the ISINDEX element. Forms can contain a wide range of HTML markup including several kinds of form fields such as single and multi-line text fields, radio button groups, checkboxes, and menus. action This specifies a URL which is either used to post forms via email, e.g. action=»mailto:foo@bar.com» , or used to invoke a server-side forms handler via HTTP, e.g. action=»http://www.acme.com/cgi-bin/register.pl» method When the action attribute specifies an HTTP server, the method attribute determines which HTTP method will be used to send the form’s contents to the server. It can be either GET or POST , and defaults to GET . enctype This determines the mechanism used to encode the form’s contents. It defaults to application/x-www-form-urlencoded.

    Further details on handling forms are given in RFC 1867.

    HR — horizontal rules

    Horizontal rules may be used to indicate a change in topic. In a speech based user agent, the rule could be rendered as a pause.

    HR elements are not containers so the end tag is forbidden. The attributes are: ALIGN , NOSHADE , SIZE and WIDTH . align This determines whether the rule is placed at the left, center or right of the space between the current left and right margins for align=left , align=center or align=right respectively. By default, the rule is centered. noshade This attribute requests the user agent to render the rule in a solid color rather than as the traditional two colour «groove». size This can be used to set the height of the rule in pixels. width This can be used to set the width of the rule in pixels (e.g. w >) or as the percentage between the current left and right margins (e.g. w ). The default is 100%.

    Tables

    HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents.

    Tables take the general form:

    The attributes on TABLE are all optional. By default, the table is rendered without a surrounding border. The table is generally sized automatically to fit the contents, but you can also set the table width using the WIDTH attribute. BORDER , CELLSPACING and CELLPADDING provide further control over the table’s appearence. Captions are rendered at the top or bottom of the table depending on the ALIGN attribute.


    Each table row is contained in a TR element, although the end tag can always be omitted. Table cells are defined by TD elements for data and TH elements for headers. Like TR , these are containers and can be given without trailing end tags. TH and TD support several attributes: ALIGN and VALIGN for aligning cell content, ROWSPAN and COLSPAN for cells which span more than one row or column. A cell can contain a wide variety of other block and text level elements including form fields and other tables.

    The TABLE element always requires both start and end tags. It supports the following attributes: align This takes one of the case insensitive values: LEFT , CENTER or RIGHT . It specifies the horizontal placement of the table relative to the current left and right margins. It defaults to left alignment, but this can be overridden by an enclosing DIV or CENTER element. width In the absence of this attribute the table width is automatically determined from the table contents. You can use the WIDTH attribute to set the table width to a fixed value in pixels (e.g. W >) or as a percentage of the space between the current left and right margins (e.g. W ). border This attribute can be used to specify the width of the outer border around the table to a given number of pixels (e.g. BORDER=4 ). The value can be set to zero to suppress the border altogether. In the absence of this attribute the border should be suppressed. Note that some browsers also accept

    with the same semantics as BORDER=1 . cellspacing In traditional desktop publishing software, adjacent table cells share a common border. This is not the case in HTML. Each cell is given its own border which is separated from the borders around neighboring cells. This separation can be set in pixels using the CELLSPACING attribute, (e.g. CELLSPACING=10 ). The same value also determines the separation between the table border and the borders of the outermost cells. cellpadding This sets the padding in pixels between the border around each cell and the cell’s contents.

    The CAPTION element has one attribute ALIGN which can be either ALIGN=TOP or ALIGN=BOTTOM . This can be used to force the caption to be placed above the top or below the bottom of the table respectively. Most user agents default to placing the caption above the table. CAPTION always requires both start and end tags. Captions are limited to plain text and text-level elements as defined by the %text entity. Block level elements are not permitted.

    The TR or table row element requires a start tag, but the end tag can always be left out. TR acts as a container for table cells. It has two attributes: align Sets the default horizontal alignment of cell contents. It takes one of the case insensitive values: LEFT , CENTER or RIGHT and plays the same role as the ALIGN attribute on paragraph elements. valign This can be used to set the default vertical alignment of cell contents within each cell. It takes one of the case insensitive values: TOP , MIDDLE or BOTTOM to position the cell contents at the top, middle or bottom of the cell respectively.

    There are two elements for defining table cells. TH is used for header cells and TD for data cells. This distinction allows user agents to render header and data cells in different fonts, and enables speech based browsers to do a better job. The start tags for TH and TD are always needed but the end tags can be left out. Table cells can have the following attributes: nowrap The presence of this attribute disables automatic word wrap within the contents of this cell (e.g.

    ). This is equivalent to using the entity for non-breaking spaces within the content of the cell. rowspan This takes a positive integer value specifying the number of rows spanned by this cell. It defaults to one. colspan This takes a positive integer value specifying the number of columns spanned by this cell. It defaults to one. align Specifies the default horizontal alignment of cell contents, and overrides the ALIGN attribute on the table row. It takes the same values: LEFT , CENTER and RIGHT . If you don’t specify an ALIGN attribute value on the cell, the default is left alignment for

    and center alignment for although you can override this with an ALIGN attribute on the TR element. valign Specifies the default vertical alignment of cell contents, overriding the VALIGN attribute on the table row. It takes the same values: TOP , MIDDLE and BOTTOM . If you don’t specify a VALIGN attribute value on the cell, the default is middle although you can override this with a VALIGN attribute on the TR element. width Specifies the suggested width for a cell content in pixels excluding the cell padding. This value will normally be used except when it conflicts with the width requirements for other cells in the same column. height Specifies the suggested height for a cell content in pixels excluding the cell padding. This value will normally be used except when it conflicts with the height requirements for other cells in the same row.

    Tables are commonly rendered in bas-relief, raised up with the outer border as a bevel, and individual cells inset into this raised surface. Borders around individual cells are only drawn if the cell has explicit content. White space doesn’t count for this purpose with the exception of .

    The algorithms used to automatically size tables should take into account the minimum and maximum width requirements for each cell. This is used to determine the minimum and maximum width requirements for each column and hence for the table itself.

    Cells spanning more than one column contribute to the widths of each of the columns spanned. One approach is to evenly apportion the cell’s minimum and maximum width between these columns, another is to weight the apportioning according to the contributions from cells that don’t span multiple columns.

    For some user agents it may be necessary or desirable to break text lines within words. In such cases a visual indication that this has occurred is advised.

    The minimum and maximum width of nested tables contribute to the minimum and maximum width of the cell in which they occur. Once the width requirements are known for the top level table, the column widths for that table can be assigned. This allows the widths of nested tables to be assigned and hence in turn the column widths of such tables. If practical, all columns should be assigned at least their minimum widths. It is suggested that any surplus space is then shared out proportional to the difference between the minimum and maximum width requirements of each column.

    Note that pixel values for width and height refer to screen pixels, and should be multiplied by an appropriate factor when rendering to very high resolution devices such as laser printers. For instance if a user agent has a display with 75 pixels per inch and is rendering to a laser printer with 600 dots per inch, then the pixel values given in HTML attributes should be multiplied by a factor of 8.

    Text level elements

    Font style elements

    These all require start and end tags, e.g.

    Text level elements must be properly nested — the following is in error: User agents should do their best to respect nested emphasis, e.g.

    Where the available fonts are restricted or for speech output, alternative means should be used for rendering differences in emphasis. TT teletype or monospaced text I italic text style B bold text style U underlined text style STRIKE strike-through text style BIG places text in a large font SMALL places text in a small font SUB places text in subscript style SUP places text in superscript style

    Note: future revisions to HTML may be phase out STRIKE in favor of the more concise «S» tag from HTML 3.0.

    Phrase Elements

    These all require start and end tags, e.g. EM basic emphasis typically rendered in an italic font STRONG strong emphasis typically rendered in a bold font DFN defining instance of the enclosed term CODE used for extracts from program code SAMP used for sample output from programs, and scripts etc. KBD used for text to be typed by the user VAR used for variables or arguments to commands CITE used for citations or references to other sources

    Form fields

    INPUT , SELECT and TEXTAREA are only allowed within FORM elements. INPUT can be used for a variety of form fields including single line text fields, password fields, checkboxes, radio buttons, submit and reset buttons, hidden fields, file upload, and image buttons. SELECT elements are used for single or multiple choice menus. TEXTAREA elements are used to define multi-line text fields. The content of the element is used to initialize the field.

    INPUT text fields, radio buttons, check boxes, .

    INPUT elements are not containers and so the end tag is forbidden. type Used to set the type of input field:

    type=text (the default) A single line text field whose visible size can be set using the size attribute, e.g. size=40 for a 40 character wide field. Users should be able to type more than this limit though with the text scrolling through the field to keep the input cursor in view. You can enforce an upper limit on the number of characters that can be entered with the maxlength attribute. The name attribute is used to name the field, while the value attribute can be used to initialize the text string shown in the field when the document is first loaded. type=password This is like type=text, but echoes characters using a character like * to hide the text from prying eyes when entering passwords. You can use size and maxlength attributes to control the visible and maximum length exactly as per regular text fields. type=checkbox Used for simple Boolean attributes, or for attributes that can take multiple values at the same time. The latter is represented by several checkbox fields with the same name and a different value attribute. Each checked checkbox generates a separate name/value pair in the submitted data, even if this results in duplicate names. Use the checked attribute to initialize the checkbox to its checked state. type=radio Used for attributes which can take a single value from a set of alternatives. Each radio button field in the group should be given the same name . Radio buttons require an explicit value attribute. Only the checked radio button in the group generates a name/value pair in the submitted data. One radio button in each group should be initially checked using the checked attribute. type=submit This defines a button that users can click to submit the form’s contents to the server. The button’s label is set from the value attribute. If the name attribute is given then the submit button’s name/value pair will be included in the submitted data. You can include several submit buttons in the form. See type=image for graphical submit buttons. type=image This is used for graphical submit buttons rendered by an image rather than a text string. The URL for the image is specified with the src attribute. The image alignment can be specified with the align attribute. In this respect, graphical submit buttons are treated identically to IMG elements, so you can set align to left, right, top, middle or bottom. The x and y values of the location clicked are passed to the server: In the submitted data, image fields are included as two name/value pairs. The names are derived by taking the name of the field and appending «.x» for the x value, and «.y» for the y value.

    Note: image fields typically cause problems for text-only and speech-based user agents!

    type=reset This defines a button that users can click to reset form fields to their initial state when the document was first loaded. You can set the label by providing a value attribute. Reset buttons are never sent as part of the form’s contents. type=file This prov >size attribute to set the visible width of this field in average character widths. You can set an upper limit to the length of file names using the maxlength attribute. Some user agents support the ability to restrict the kinds of files to those matching a comma separated list of MIME content types given with the ACCEPT attribute e.g. accept=»image/*» restricts files to images. Further information can be found in RFC 1867. type=hidden These fields should not be rendered and provide a means for servers to store state information with a form. This will be passed back to the server when the form is submitted, using the name/value pair defined by the corresponding attributes. This is a work around for the statelessness of HTTP. Another approach is to use HTTP «Cookies». name Used to define the property name that will be used to identify this field’s content when it is submitted to the server. value Used to initialize the field, or to provide a textual label for submit and reset buttons. checked The presence of this attribute is used to initialize checkboxes and radio buttons to their checked state. size Used to set the visible size of text fields to a given number of average character widths, e.g. size=20 maxlength Sets the maximum number of characters permitted in a text field. src Specifies a URL for the image to use with a graphical submit button. align Used to specify image alignment for graphical submit buttons. It is defined just like the IMG align attribute and takes one of the values: top , middle , bottom , left or right , defaulting to bottom .

    SELECT menus

    SELECT is used to define select one from many or many from many menus. SELECT elements require start and end tags and contain one or more OPTION elements that define menu items. One from many menus are generally rendered as drop-down menus while many from many menus are generally shown as list boxes.

    SELECT attributes: name This specifies a property name that is used to identify the menu choice when the form is submitted to the server. Each selected option results in a property name/value pair being included as part of the form’s contents. size This sets the number of visible choices for many from many menus. multiple The presence of this attribute signifies that the users can make multiple selections. By default only one selection is allowed.

    OPTION attributes: selected When this attribute is present, the option is selected when the document is initially loaded. It is an error for more than one option to be so selected for one from many menus. value Specifies the property value to be used when submitting the form’s content. This is combined with the property name as given by the name attribute of the parent SELECT element.

    TEXTAREA multi-line text fields

    TEXTAREA elements require start and end tags. The content of the element is restricted to text and character entities. It is used to initialize the text that is shown when the document is first loaded.

    It is recommended that user agents canonicalize line endings to CR, LF (ASCII decimal 13, 10) when submitting the field’s contents. The character set for submitted data should be ISO Latin-1, unless the server has previously indicated that it can support alternative character sets. name This specifies a property name that is used to identify the textarea field when the form is submitted to the server. rows Specifies the number of visible text lines. Users should be able to enter more lines that this, so user agents should provide some means to scroll through the contents of the textarea field when the contents extend beyond the visible area. cols Specifies the visible width in average character widths. Users should be able to enter longer lines that this, so user agents should provide some means to scroll through the contents of the textarea field when the contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible without the need for scrolling.

    Special Text level Elements

    The A (anchor) element

    Anchors can’t be nested and always require start and end tags. They are used to define hypertext links and also to define named locations for use as targets for hypertext links, e.g.

    and also to define named locations for use as targets for hypertext links, e.g. name This should be a string defining unique name for the scope of the current HTML document. NAME is used to associate a name with this part of a document for use with URLs that target a named section of a document. href Specifies a URL acting as a network address for the linked resource. This could be another HTML document, a PDF file or an image etc. rel The forward relationship also known as the «link type». It can be used to determine to how to deal with the linked resource when printing out a collection of linked resources. rev This defines a reverse relationship. A link from document A to document B with REV=relation expresses the same relationship as a link from B to A with REL=relation . REV=made is sometimes used to identify the document author, either the author’s email address with a mailto URL, or a link to the author’s home page. title An advisory title for the linked resource.

    IMG — inline images

    Used to insert images. IMG is an empty element and so the end tag is forbidden. Images can be positioned vertically relative to the current textline or floated to the left or right. See BR with the CLEAR attribute for control over textflow.

    IMG elements support the following attributes: src This attribute is required for every IMG element. It specifies a URL for the image resource, for instance a GIF, JPEG or PNG image file. alt This is used to provide a text description of the image and is vital for interoperability with speech-based and text only user agents. align This specifies how the image is positioned relative to the current textline in which it occurs:

    align=top positions the top of the image with the top of the current text line. User agents vary in how they interpret this. Some only take into account what has occurred on the text line prior to the IMG element and ignore what happens after it. align=middle aligns the middle of the image with the baseline for the current textline. align=bottom is the default and aligns the bottom of the image with the baseline. align=left floats the image to the current left margin, temporarily changing this margin, so that subsequent text is flowed along the image’s righthand side. The rendering depends on whether there is any left aligned text or images that appear earlier than the current image in the markup. Such text (but not images) generally forces left aligned images to wrap to a new line, with the subsequent text continuing on the former line. align=right floats the image to the current right margin, temporarily changing this margin, so that subsequent text is flowed along the image’s lefthand side. The rendering depends on whether there is any right aligned text or images that appear earlier than the current image in the markup. Such text (but not images) generally forces right aligned images to wrap to a new line, with the subsequent text continuing on the former line.

    Note that some browsers introduce spurious spacing with multiple left or right aligned images. As a result authors can’t depend on this being the same for browsers from different vendors. See BR for ways to control text flow. width Specifies the intended width of the image in pixels. When given together with the height, this allows user agents to reserve screen space for the image before the image data has arrived over the network. height Specifies the intended height of the image in pixels. When given together with the width, this allows user agents to reserve screen space for the image before the image data has arrived over the network. border When the IMG element appears as part of a hypertext link, the user agent will generally indicate this by drawing a colored border (typically blue) around the image. This attribute can be used to set the width of this border in pixels. Use border=0 to suppress the border altogether. User agents are recommended to provide additional cues that the image is clickable, e.g. by changing the mouse pointer. hspace This can be used to provide white space to the immediate left and right of the image. The HSPACE attribute sets the width of this white space in pixels. By default HSPACE is a small non-zero number. vspace This can be used to provide white space above and below the image The VSPACE attribute sets the height of this white space in pixels. By default VSPACE is a small non-zero number. usemap This can be used to give a URL fragment identifier for a client-side image map defined with the MAP element. ismap When the IMG element is part of a hypertext link, and the user clicks on the image, the ISMAP attribute causes the location to be passed to the server. This mechanism causes problems for text-only and speech-based user agents. Whenever its possible to do so use the MAP element instead.

    Here is an example of how you use ISMAP :

    The location clicked is passed to the server as follows. The user agent derives a new URL from the URL specified by the HREF attribute by appending `?’ the x coordinate `,’ and the y coordinate of the location in pixels. The link is then followed using the new URL. For instance, if the user clicked at at the location x=10, y=27 then the derived URL will be: » /cgibin/navbar.map?10,27 «. It is generally a good idea to suppress the border and use graphical idioms to indicate that the image is clickable.

    Note that pixel values refer to screen pixels, and should be multiplied by an appropriate factor when rendering to very high resolution devices such as laser printers. For instance if a user agent has a display with 75 pixels per inch and is rendering to a laser printer with 600 dots per inch, then the pixel values given in HTML attributes should be multiplied by a factor of 8.

    APPLET (Java Applets)

    Requires start and end tags. This element is supported by all Java enabled browsers. It allows you to embed a Java applet into HTML documents. APPLET uses associated PARAM elements to pass parameters to the applet. Following the PARAM elements, the content of APPLET elements should be used to provide an alternative to the applet for user agents that don’t support Java. It is restricted to text-level markup as defined by the %text entity in the DTD. Java-compatible browsers ignore this extra HTML code. You can use it to show a snapshot of the applet running, with text explaining what the applet does. Other possibilities for this area are a link to a page that is more useful for the Java-ignorant browser, or text that taunts the user for not having a Java-compatible browser.

    Here is a simple example of a Java applet:

    Here is another one using a PARAM element: codebase = codebaseURL This optional attribute specifies the base URL of the applet — the directory or folder that contains the applet’s code. If this attribute is not specified, then the document’s URL is used.

    code = appletFile This required attribute gives the name of the file that contains the applet’s compiled Applet subclass. This file is relative to the base URL of the applet. It cannot be absolute.

    alt = alternateText This optional attribute specifies any text that should be displayed if the browser understands the APPLET tag but can’t run Java applets.

    name = appletInstanceName This optional attribute specifies a name for the applet instance, which makes it possible for applets on the same page to find (and communicate with) each other.


    w > height = pixels These required attributes give the initial width and height (in pixels) of the applet display area, not counting any windows or dialogs that the applet brings up.

    align = alignment This attribute specifies the alignment of the applet. This attribute is defined in exactly the same way as the IMG element. The permitted values are: top , middle , bottom , left and right . The default is bottom .

    vspace = pixels
    hspace = pixels These optional attributes specify the number of pixels above and below the applet ( VSPACE ) and on each side of the applet ( HSPACE ). They’re treated the same way as the IMG element’s VSPACE and HSPACE attributes.

    PARAM elements are the only way to specify applet-specific parameters. Applets read user-specified values for parameters with the getParameter() method. name = applet parameter name value = parameter value

    SGML character entities such as é and ¹ are expanded before the parameter value is passed to the applet. To include an & character use & .

    Note: PARAM elements should be placed at the start of the content for the APPLET element. This is not specified as part of the DTD due to technicalities with SGML mixed content models.

    Requires start and end tags. This allows you to change the font size and/or color for the enclosed text. The attributes are: SIZE and COLOR . Font sizes are given in terms of a scalar range defined by the user agent with no direct mapping to point sizes etc. The FONT element may be phased out in future revisions to HTML. size This sets the font size for the contents of the font element. You can set size to an integer ranging from 1 to 7 for an absolute font size, or specify a relative font size with a signed integer value, e.g. size=»+1″ or size=»-2″ . This is mapped to an absolute font size by adding the current base font size as set by the BASEFONT element (see below). color Used to set the color to stroke the text. Colors are given as RGB in hexadecimal notation or as one of 16 widely understood color names defined as per the BGCOLOR attribute on the BODY element.

    Some user agents also support a FACE attribute which accepts a comma separated list of font names in order of preference. This is used to search for an installed font with the corresponding name. FACE is not part of HTML 3.2.

    The following shows the effects of setting font to absolute sizes:

    size=1 size=2 size=3 size=4 size=5 size=6 size=7

    The following shows the effect of relative font sizes using a base font size of 3:

    size=-4 size=-3 size=-2 size=-1 size=+1 size=+2 size=+3 size=+4

    The same thing with a base font size of 6:

    size=-4 size=-3 size=-2 size=-1 size=+1 size=+2 size=+3 size=+4

    BASEFONT

    Used to set the base font size. BASEFONT is an empty element so the end tag is forbidden. The SIZE attribute is an integer value ranging from 1 to 7. The base font size applies to the normal and preformatted text but not to headings, except where these are modified using the FONT element with a relative font size.

    Used to force a line break. This is an empty element so the end tag is forbidden. The CLEAR attribute can be used to move down past floating images on either margin.
    moves down past floating images on the left margin,
    does the same for floating images on the right margin, while
    does the same for such images on both left and right margins.

    The MAP element provides a mechanism for client-side image maps. These can be placed in the same document or grouped in a separate document although this isn’t yet widely supported. The MAP element requires start and end tags. It contains one or more AREA elements that specify hotzones on the associated image and bind these hotzones to URLs.

    Here is a simple example for a graphical navigational toolbar:

    The MAP element has one attribute NAME which is used to associate a name with a map. This is then used by the USEMAP attribute on the IMG element to reference the map via a URL fragment identifier. Note that the value of the NAME attribute is case sensitive.

    The AREA element is an empty element and so the end tag is forbidden. It takes the following attributes: SHAPE , COORDS , HREF , NOHREF and ALT . The SHAPE and COORDS attributes define a region on the image. If the SHAPE attribute is omitted, SHAPE=»RECT» is assumed. shape=rect coords=»left-x, top-y, right-x, bottom-y«

    Where x and y are measured in pixels from the left/top of the associated image. If x and y values are given with a percent sign as a suffix, the values should be interpreted as percentages of the image’s width and height, respectively. For example:

    The HREF attribute gives a URL for the target of the hypertext link. The NOHREF attribute is used when you want to define a region that doesn’t act as a hotzone. This is useful when you want to cut a hole in an underlying region acting as a hotzone.

    If two or more regions overlap, the region defined first in the map definition takes precedence over subsequent regions. This means that AREA elements with NOHREF should generally be placed before ones with the HREF attribute.

    The ALT attribute is used to provide text labels which can be displayed in the status line as the mouse or other pointing device is moved over hotzones, or for constructing a textual menu for non-graphical user agents. Authors are strongly recommended to provide meaningful ALT attributes to support interoperability with speech-based or text-only user agents.

    Sample SGML Open Catalog for HTML 3.2

    This can be used with an SGML parser like nsgmls to verify that files conform to the HTML 3.2 DTD. It assumes that the DTD has been saved as the file «HTML32.dtd» and that the Latin-1 entities are in the file «ISOlat1.ent».

    SGML Declaration for HTML 3.2

    This uses the 8 bit ISO Latin-1 character set. The size limits on properties like literals and tag names have been considerably increased from their HTML 2.0 values, but it is recommended that user agents avoid imposing arbitrary length limits.

    HTML 3.2 Document Type Definition

    Character Entities for ISO Latin-1

    Table of printable Latin-1 Character codes

    Acknowledgements

    The author would like to thank the members of the W3C HTML Editorial Review Board, members of the W3C staff, and the many other people who have contributed to this specification.

    HTML5

    Грамматика и ассоциированные API для HTML и XHTML

    Оригинальная версия этой спецификации на английском языке находится по адресу: http://www.w3.org/TR/2014/REC-html5-20141028/

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

    Рекомендации W3C от 28 октября 2014 г.

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

    Эта спецификация также имеется в виде одностраничного HTML документа. См. также переводы на др. языки .

    Резюме

    Эта спецификация представляет собой пятую базовую версию ядра языка World Wide Web: Hypertext Markup Language (HTML). В этой версии появились новые возможности – в помощь авторам вэб-приложений, введены новые элементы на основе исследований текущей практики авторских разработок, также особое внимание уделено определению чётких критериев соответствия для пользовательских агентов в целях улучшения совместимости.

    Статус данного документа

    Этот параграф описывает статус данного документа на момент публикации. Другие документы могут заменить данный документ. Список текущих публикаций W3C и последняя редакция данного технического сообщения находятся в индексе технических сообщений W3C на странице http://www.w3.org/TR/.

    W3C HTML Working Group это рабочая группа W3C, отвечающая за работу над данной спецификацией. Эта спецификация – Рекомендации от 28 октября 2014 г.

    Если Вы хотите прокомментировать этот документ способом, который отслеживается W3C, пожалуйста, отправьте комментарий на нашу публичную базу багов (open bugs). Если Вы не можете это сделать, то отправьте e-mail на адрес public-html@w3.org (subscribe, archives), и будут приняты меры для представления Ваших комментариев в нашей public bug database. Приветствуем любые комментарии.

    Комплексный набор тестов для данной спецификации поддерживается и постоянно обновляется в рамках проекта WebPlatform Tests. См. также Working Group’s implementation report.

    Работа по совершенствованию данной спецификации проходит на http://www.w3.org/TR/html/. Эти HTML5 Recommendation являются важной вехой на пути разработки HTML, но это ещё далеко не конец пути, и улучшения идут полным ходом. Возможно, что будущие версии будут публиковаться не как единая спецификация, а как набор небольших модулей. Независимо от этого http://www.w3.org/TR/html/ будет поддерживаться как отправная точка всей технологии HTML.

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

    Основная часть текста данной спецификации имеется также в WHATWG HTML Living Standard по лицензии, которая разрешает использование текста данной спецификации.

    Этот документ был рассмотрен Членами W3C, разработчиками программного обеспечения и другими W3C-группами и заинтересованными сторонами и одобрен Директором в качестве W3C Рекомендаций. Это стабильный документ, который может использоваться в качестве справочника или цитироваться в других документах. Цель W3C при создании данных Рекомендаций – привлечение внимания к этой спецификации и содействие её широкому распространению. Это повышает функциональность и совместимость Web.


    Работа над данной спецификацией проходит также в WHATWG. W3C HTML working group активно продвигает совместимость спецификации HTML со стандартом WHATWG в рамках W3C HTML working group charter. Есть различные варианты отслеживать эту работу в WHATWG:

    • список рассылки Commit-Watchers (полный источник определений): http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
    • Аннотированное резюме унифицированных определений: http://html5.org/tools/web-apps-tracker
    • интерфейс Raw Subversion: svn checkout http://svn.whatwg.org/webapps/

    Следующие редакторские изменений появились со времени выхода Proposed Recommendation:

    • Разъяснены способы публикации обновлений данной спецификации.
    • IANA-регистрация для application/xhtml+xml была принята во время PR, что привело к небольшим изменениям соответствующего раздела.
    • «Decoder error» ошибочно было указано как относящееся URL-related определение, хотя фактически оно является Encoding-related.
    • «Parsed URL» получило соответствующее отображение в спецификации URL.
    • Улучшено информативное резюме некоторых элементов. (В основном – указатели на отсутствие тэга и ARIA-правила.)
    • Обновлено несколько ссылок на документы, у которых появились новые ревизии (RFC4281, RFC2313, RFC3490, MPEG-DASH), и сделана более стабильная ссылка на BECSS.
    • Добавлено несколько примечаний и сделано несколько уведомлений относительно URL-ссылки.
    • Были сделаны некоторые стилистические поправки и исправления опечаток.

    Этот документ создан группой, работающей на основании 5 February 2004 W3C Patent Policy. W3C поддерживает публичный список открытых патентов, сделанный в сотрудничестве с членами группы; на этой странице также имеются инструкции по раскрытию патента. Если человек знает о патенте, который, как он уверен, содержит Essential Claim(s), он обязан раскрыть информацию в соответствии с section 6 of the W3C Patent Policy.

    Официальная html 3 2 спецификация

    Несколько недель назад HTML5 получил статус W3C-рекомендации. Я воспользовался этим событием, чтобы обсудить на SitePoint пять интересных, но уже устаревших вещей. Проблема в том, что W3C-спецификации — это лишь одна сторона медали. Начиная с этой версии HTML, разработчики и производители браузеров могут выбирать между двумя разновидностями одного и того же языка разметки: спецификациями, разработанными консорциумом W3C, и тех, что разработаны WHATWG.

    По большей части эти спецификации одинаковы или очень похожи, но, с годами между ними возникает всё больше и больше различий. Стоит ли вам беспокоиться об этом? В большинстве случаев не стоит, потому что либо они мало что изменят для вас и ваших проектов, либо разработчики браузеров будут поддерживать оба стандарта. Однако, в краткосрочной перспективе другие различия могут иметь важное значения для вас, т.к. они влияют на реализацию нововведения. У каждого разработчика браузера есть свой собственный взгляд на то, какой спецификации следовать. Например, Дэвид Бэрон из Mozilla недавно заявил:

    Если HTML-спецификации W3C и WHATWG различаются, то мы стараемся следовать спецификации WHATWG.

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

    «HTML5» против «Живого стандарта HTML»

    Давайте начнём нашу дискуссию о различиях с простой темы: название стандарта. Версия спецификации WHATWG в начале 2011 года была переименована в «HTML», отбросив цифру «5» в конце названия. Затем в дальнейшем она была переименована в «Живой стандарт HTML», чтобы указать на то, что впредь она будет находиться в постоянной разработке, не ссылаясь на какой-то определённый номер версии.

    W3C-спецификации, напротив, всё ещё используют номера версии, как я упоминал в начале этой статьи — последняя стабильная версия — «5», соответственно «HTML5». Как следствие этого шага, консорциум теперь активно развивает новую версию стандарта, известную как «HTML5.1». В HTML5.1 обсуждаются некоторые элементы и атрибуты, которые не попали в HTML5, например, элемент dialog и новые типы input — month и week .

    Моё мнение

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

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

    Элемент main

    Элемент main — один из последних элементов, добавленных в спецификации, и его значение может быть разным в зависимости от версии. Спецификация W3C описывает его, как главное содержимое страницы — содержимое, которое описывает основную тему страницы или центральную функциональность приложения. Спецификация также утверждает, что документ не должен содержать более одного элемента main и что элемент main должен быть привязан к ARIA role=»main» или к эквиваленту в API вспомогательных технологий.

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

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

    Пример использования, основанного на спецификации WHATWG, может выглядеть так:

    Заметьте, что в вышеприведённом коде я использовал элемент main дважды.

    Моё мнение

    В отношении элемента main я за W3C, потому что сомневаюсь, что у людей есть потребность в нескольких основных областях в документе. Кроме того, я помню, что Стив Фолкнер (редактор спецификаций W3C) в почтовой рассылке несколько раз призывал Йена Хиксона (редактора спецификаций WHATWG) показать ему данные, которые доказали бы необходимость в использовании нескольких главных областей. Результат всегда был один и тот же — во всех случаях редактор WHATWG не мог предоставить такие данные.

    Элемент hgroup

    Элемент hgroup предназначен для группировки набора из одного или более элементов h1-h6 , что полезно, чтобы сгруппировать заголовок раздела и сопутствующий подзаголовок.

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

    Пример, показанный ниже, взят из моей статьи «5 устаревших вещей в HTML5»

    В апреле 2013 года этот элемент был удалён из спецификации W3C из-за отсутствия реализации, примеров реального использования, а также способствовал плохому стилю разметки. Напротив, спецификация WHATWG всё ещё включает hgroup .

    Моё мнение

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

    API веб-уведомлений

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

    Простой пример использования этого API показан ниже:

    API веб-уведомлений описаны в обеих спецификациях, как в W3C, так и в WHATWG, но но между двумя версиями есть некоторые различия. В частности в спецификации WHATWG отсутствуют события onclose и onshow . Таким образом, W3C-спецификации определяют четыре события ( onclick , onclose , onerror и onshow ), а спецификации WHATWG только два ( onclick и onerror ).

    Если у вас есть желание более подробно изучить различия между версиями этого API и узнать, какова его поддержка в основных браузерах, то вы можете посмотреть мою статью «Состояние API Веб-уведомления».

    Моё мнение

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

    Заключение

    В этой статье мы обсудили несколько самых важных различий между спецификациями W3C и WHATWG. Как вы видите, учитывая количество элементов и API, определённых в спецификациях, различий между ними пока не так уж много. Учитывая это, я не беспокоюсь о будущем, так как уверен, что, в конце концов, спецификации будут просто соответствовать действительности. Это означает, что независимо от того, что было указано обеими группами при появлении функции, браузеры и разработчики в силах поспособствовать успеху той или иной версии. Таким образом, браузеры и разработчики — игроки, которые решают, какая спецификация для них «выигрышная» путём её реализации или принятия. Так что для каждой спорной функции «проигравшая» группа в конечном итоге адаптирует спецификации в соответствии с реальностью.

    Под занавес стоит отметить, что в случае, если вы захотите открыть для себя ещё несколько различий, то можете посмотреть их на странице «Различия между спецификациями W3C HTML5.1 и WHATWG LS» на W3C Wiki.

    P.S. Это тоже может быть интересно:

    Если вам понравилась статья, поделитесь ей!

    Что нового в HTML 5.2?

    Дата публикации: 2020-02-01

    От автора: Меньше месяца назад HTML 5.2 стал официальной рекомендацией W3C (REC). Когда спецификация доходит до этапа REC, это значит, что она получила поддержку членов W3C и директора, и W3C официально рекомендует ее реализацию в браузерах, а также внедрение в веб-страницы авторами.

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

    Новые функции

    Нативный элемент dialog

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


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

    Диалоговое окно создается с помощью тега dialog.

    Как создать сайт самому?

    Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

    По умолчанию диалоговое окно скрыто из виду (и из DOM), пока не будет применен атрибут open.

    Атрибут open можно переключать, вызывая методы show() и close(), доступные на любом HTMLDialogElement.

    Тег dialog уже поддерживается в Chrome, в Firefox поддержка по флагу.

    Использование Payment Request API из iFrame

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

    До HTML 5.2 запросы по платежам нельзя было посылать из iframe’ов, вставленных в документ. Сторонние вставные решения по оплате (Stripe, Paystack) просто не могли использовать это API, так как их интерфейс оплаты обрабатывался только внутри iframe.

    HTML 5.2 представил атрибут allowpaymentrequest. Примененный к iframe, он позволяет использовать Payment Request API, пока пользователь находится на веб-странице хостинга.

    Размеры для иконок Apple

    Для определения иконки страницы мы используем
    в шапке документа. Для задания размеров иконок используется атрибут sizes.

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

    До HTML 5.2 атрибут sizes был валиден только, если связь в link была icon. Однако Apple устройства под управлением iOS не поддерживают атрибут sizes. Поэтому Apple представила специальную связь для своих устройств appple-touch-icon, которую можно использовать для определения используемой иконки на устройствах.

    В HTML 5.2 спецификация позволяет использовать атрибут sizes со связью apple-touch-icon, а не только icon. Это позволит загружать иконки разных размеров на разные устройства Apple. Насколько мне известно, устройства Apple до сих пор не поддерживают атрибут sizes. Это изменение будет полезно, когда появится поддержка.

    Новые валидные практики

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

    Несколько элементов main

    Элемент main представляет основной контент веб-страницы. Повторяющийся на нескольких страницах контент можно поместить в header, section и другие теги, а тег main предназначен для контента, который специфичен и уникален для определенной страницы. Поэтому до HTML 5.2 тег main должен был быть уникальным в DOM для страницы, чтобы пройти валидацию.

    Как создать сайт самому?

    Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

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

    В HTML 5.2 теперь можно использовать несколько тегов main в разметке, но только один должен быть виден пользователю в любое время. Все дополнительные теги необходимо прятать через атрибут hidden.

    Официальная html 3 2 спецификация

    Если у Вас появились сомнения в отношении точности формы, значения и ограничений на теги HTML, Вам необходимо проконсультироваться с официальным документом по HTML, доступном на странице World Wide Web Consortium:
    http://www.w3.org/pub/WWW/MarkUp/Wilbur/ ,
    особенно с Рекомендациями W3C HTML 3.2 Ссылочные спецификации

    Ссылочные спецификации содержат технический текст и относительно коротки. Могут быть также полезны консультации с прежней HTML 2.0 спецификацией (также известной как RFC 1866), так как текущие HTML 3.2 спецификации могут быть понятны иногда только при ознакомлении с HTML 2.0, как базовым документом.

    Чтобы понимать спецификации точно, требуется некоторая «беглость» в чтении SGML (метаязык, используемый для формального описания синтаксиса HTML). Для этого можно посмотреть SGML страницу Консорциума, или Предварительное введение в SGML , или SGML Web страницу , особенно Букварь SGML фирмы SoftQuad. (Если Вы знаете финский язык, Вы можете начать с Hyvin lyhyt johdatus SGML:ддn ).

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

    Официальная html 3 2 спецификация

    Если у Вас появились сомнения в отношении точности формы, значения и ограничений на теги HTML, Вам необходимо проконсультироваться с официальным документом по HTML, доступном на странице World Wide Web Consortium:
    http://www.w3.org/pub/WWW/MarkUp/Wilbur/ ,
    особенно с Рекомендациями W3C HTML 3.2 Ссылочные спецификации

    Ссылочные спецификации содержат технический текст и относительно коротки. Могут быть также полезны консультации с прежней HTML 2.0 спецификацией (также известной как RFC 1866), так как текущие HTML 3.2 спецификации могут быть понятны иногда только при ознакомлении с HTML 2.0, как базовым документом.

    Чтобы понимать спецификации точно, требуется некоторая «беглость» в чтении SGML (метаязык, используемый для формального описания синтаксиса HTML). Для этого можно посмотреть SGML страницу Консорциума, или Предварительное введение в SGML , или SGML Web страницу , особенно Букварь SGML фирмы SoftQuad. (Если Вы знаете финский язык, Вы можете начать с Hyvin lyhyt johdatus SGML:ддn ).

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

    Официальная html 3 2 спецификация

    Если у Вас появились сомнения в отношении точности формы, значения и ограничений на теги HTML, Вам необходимо проконсультироваться с официальным документом по HTML, доступном на странице World Wide Web Consortium:
    http://www.w3.org/pub/WWW/MarkUp/Wilbur/ ,
    особенно с Рекомендациями W3C HTML 3.2 Ссылочные спецификации

    Ссылочные спецификации содержат технический текст и относительно коротки. Могут быть также полезны консультации с прежней HTML 2.0 спецификацией (также известной как RFC 1866), так как текущие HTML 3.2 спецификации могут быть понятны иногда только при ознакомлении с HTML 2.0, как базовым документом.

    Чтобы понимать спецификации точно, требуется некоторая «беглость» в чтении SGML (метаязык, используемый для формального описания синтаксиса HTML). Для этого можно посмотреть SGML страницу Консорциума, или Предварительное введение в SGML , или SGML Web страницу , особенно Букварь SGML фирмы SoftQuad. (Если Вы знаете финский язык, Вы можете начать с Hyvin lyhyt johdatus SGML:ддn ).

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

    Официальная html 3 2 спецификация

    Если у Вас появились сомнения в отношении точности формы, значения и ограничений на теги HTML, Вам необходимо проконсультироваться с официальным документом по HTML, доступном на странице World Wide Web Consortium:
    http://www.w3.org/pub/WWW/MarkUp/Wilbur/ ,
    особенно с Рекомендациями W3C HTML 3.2 Ссылочные спецификации

    Ссылочные спецификации содержат технический текст и относительно коротки. Могут быть также полезны консультации с прежней HTML 2.0 спецификацией (также известной как RFC 1866), так как текущие HTML 3.2 спецификации могут быть понятны иногда только при ознакомлении с HTML 2.0, как базовым документом.

    Чтобы понимать спецификации точно, требуется некоторая «беглость» в чтении SGML (метаязык, используемый для формального описания синтаксиса HTML). Для этого можно посмотреть SGML страницу Консорциума, или Предварительное введение в SGML , или SGML Web страницу , особенно Букварь SGML фирмы SoftQuad. (Если Вы знаете финский язык, Вы можете начать с Hyvin lyhyt johdatus SGML:ддn ).

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

    Спецификации HTML и CSS

    Спецификации HTML и CSS — это свод правил и рекомендаций для вебразработчиков и производителей браузеров по синтаксису и трактовке данных языков веб-документов. Это необходимо для того, чтобы браузеры различных производителей отображали HTML-страницы не только одинаково, но и так, как задумывал автор. Разработкой этих правил занимается Консорциум всемирной паутины (W3C), возглавляемый Тимом Бернерсом-Ли — создателем Интернета, HTML, URL и многих других разработок.

    HTML 4.01 Specification — последняя актуальная на сегодняшний день спецификация по HTML от W3C (на английском).

    CSS 2.1 Specification — последняя актуальная на сегодняшний день спецификация по CSS от W3C (на английском).

    Рабочие версии HTML и CSS

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

    Editor’s Draft HTML 5 — рабочая версия HTML 5 от W3C, в которой появились новые теги, атрибуты и возможности. Большой упор делается на семантику кода, введена поддержка API (интерфейса прикладного программирования), благодаря которой, например, можно вставить видео на сайт без использования плагинов. Внешнее оформление HTML-страниц полностью передано под управление CSS. В отличие от предыдущей версии HTML, данная версия не будет иметь разделений на подверсии — только строгий синтаксис. Но при этом она будет иметь обратную совместимость, то есть, чтобы перейти с HTML 4.01 на HTML 5 достаточно будет просто поменять Доктайп в первой строчке кода страницы.

    CSS 3 Current Work — рабочая версия CSS 3 от W3C, появилось много новых свойств, различных значени и, соответственно, возможностей. Многое их того, что раньше делалось с помощью изображений и таких инструментов, как JavaScript, теперь можно делать с помощью одного CSS. Например, анимацию, создание теней, закругление углов элементов. При этом CSS 3 также имеет обратную совместимость с CSS 2.1

    Илон Маск рекомендует:  Of - Ключевое слово Delphi
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL