Спецификация языка HTML
         

Атрибуты


Почти все элементы, определяющие вид документа HTML (color, alignment, font, graphics и т.д.) не рекомендуется использовать. Вместо них нужно использовать каскадные таблицы стилей. В списке атрибутов в приложении отмечены не рекомендуемые атрибуты.Атрибуты id и class позволяют авторам указать name и class - информацию таких элементов в таблицах стилей, как anchors, scripting, объявление объектов и т.д.



Базовые типы данных HTML


Media - дескрипторы: Все символы в примерах теперь описаны с использованием 16-ричной нотации (а также ссылаются на ISO 10646, а не Unicode).



Данные meta


Авторы могут теперь установить профили, предоставляющие объяснения meta-данных, специфицированных элементами META или LINK.



Доступность


В HTML 4.0 внесены многочисленные изменения для того, чтобы обеспечить доступность:

Атрибут title может теперь быть установлен на практически каждый элемент.Авторы могу предоставить длинное описание таблиц (см. атрибут summary), изображений и фрэймов (см. атрибут longdesc).



Формы


17.2.1 Типы элементов управления: если ни одна кнопка radio первоначально не выбрана, поведение ПА по выбору кнопки не определено. Отличается от RFC 1866.17.3 Элемент FORM: добавление в атрибуте name для обратной совместимости.17.3 Элемент FORM: удалена ссылка на "mailto" URI в определении атрибута "action".17.3 Элемент FORM: удалён пример "mailto" в конце раздела, поскольку поведение этого вида не определено.17.3 Элемент FORM: атрибут accept добавлен к фрагменту ОТД/DTD. Также улучшено описание атрибута accept-charset.17.4 Элемент INPUT: добавлен "ismap" к элементу INPUT. Также, в определении value, добавлен "checkbox" к значениям type, требующим указания значения.17.6.1: если никакая опция не предустановлена, поведение ПА не определено. Авторы должны однозначно изменить опцию none, чтобы определить этот вариант. Такое поведение отличается от RFC 1866.



Фрэймы




16.4.1 NOFRAMES: добавлен текст к описанию NOFRAMES.16.4.1 NOFRAMES: добавлен текст относительно которого ОТД могу иметь NOFRAMES (frames, transitional).



Гиперссылки


12.2 Элемент A: описание атрибута type для элементов A и (LINK) изменено, чтобы подчеркнуть его информационный характер.12.2.3 Якоря с атрибутом id: для "name" и "id" недопустимо появляться в одном и том же начальном теге, если они оба определены для элемента. Они должны иметь идентичные значения.12.3.3 Гиперссылки и поисковые машины: в примере удалена ссылка на атрибут dir, так как он не относится к связываемому ресурсу (только к содержимому элемента и значениям атрибутов текста).12.4.1 Относительные URI: поскольку RFC 2616 не включает поле заголовка Link, следующее заявление квалифицировано для предыдущих версий HTTP 1.1: "Элементы ссылки, специфицированные в заголовками HTTP, обрабатываются точно как элементы LINK, явно появляющиеся в документе."



Информация о языке и направлении текста


Атрибут dir: разъясняется, что dir применяется к содержимому элемента, значениям атрибутов и направлению таблиц.



Интернационализация


HTML 4.0 интегрирует рекомендации [RFC2070] для интернационализации HTML.

Однако, эта спецификация и [RFC2070] отличаются в следующем:

Атрибут accept-charset установлен для элемента FORM, а не для элементов TEXTAREA и INPUT.Спецификация HTML 4.0 даёт дополнительные разъяснения о двунаправленном алгоритме.Использование CDATA для определения элементов SCRIPT и STYLE не сохраняет возможность для транскодирования документов, как описано в разделе 2.1 в [RFC2070].



Изменения в HTML 3.2 и HTML 4.0 (18 декабря 1997 г.)


В этом разделе объясняется, чем версия спецификации HTML 4.0 от 18 декабря 1997 г. отличается от HTML 3.2 ([HTML32]).



Изображения, объекты и карты изображений


Элемент OBJECT допускает родовое включение объектов.Элементы IFRAME и OBJECT позволяют авторам создавать внедрённые документы.Атрибут alt требуется для элементов IMG и AREA.механизм создания карт изображений позволяет теперь авторам создавать более доступные карты изображений. Модель содержимого элемента MAP по этой причине изменена.



Известные проблемы с браузерами


Некоторые версии Netscape Navigator 4.0X зависают при чтении 3 Главы предыдущей версии этой спецификации. Netscape знает об этом и устранил это в версии 4.5. Чтобы работать без этого "жучка", отмените Style Sheets (и возможно - JavaScript) в меню Edit/Preferences/Advanced.



Не рекомендуемые элементы


Следующие элементы не рекомендуются: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE и U.



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


Новые элементы HTML 4.0: ABBR, ACRONYM, BDO, BUTTON, COL, COLGROUP, DEL, FIELDSET, FRAME, FRAMESET, IFRAME, INS, LABEL, LEGEND, NOFRAMES, NOSCRIPT, OBJECT, OPTGROUP, PARAM, S (не рекомендуемый), SPAN, TBODY, TFOOT, THEAD и Q.



Объекты, Изображения и Аплеты


13.2 Элемент IMG: дополнен атрибутом name для обеспечения обратной совместимости.13.2 Элемент IMG: добавлено примечание, что ПА обязаны предоставлять различные механизмы для доступа к "longdesc" URI (изображения/IMG) и "src" URI (якоря/A), если IMG является частью содержимого элемента A.13.3 Элемент OBJECT: добавлено примечание, что, если значения "type" для OBJECT и для заголовка Content-Type HTTP различны, то последнее имеет преимущество.13.3 Элемент OBJECT: добавлено указание использовать PARAM вместо совместного употребления атрибутов "data" и "classid" для OBJECT.13.4 Элемент APPLET: добавлено примечание, что, из соображений безопасности, только субдиректории просматриваются для атрибута "codebase" в APPLET.13.6.1 Клиентские карты изображений: определение атрибута "poly" дополнительно разъяснено, что, если многоугольник для атрибута "coords" в AREA не закрыт авторами, это должен сделать ПА.

13.6.1 Клиентские карты изображений:

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

13.7.2 и 13.7.3: определение атрибутов vspace и hspace выглядит теперь так же, как и определения других атрибутов.13.7.2 и 13.7.3: тип значений атрибутов vspace, hspace и border изменён с "length" на "pixels".13.8 Альтернативный текст: последнее указание раздела теперь обращено к разработчикам ПА и касается обработки пустого атрибута текста "alt".



Общая структура документа HTML


7.2 Информация о версии HTML: Обратите внимание, что

любые изменения в будущем ОТД в HTML 4 не будут отменять документы, соответствующие ОТД предыдущих спецификаций. The HTML Working Group резервирует право на исправление обнаруженных "жучков";программы, соответствующие ОТД существующих спецификаций, могут игнорировать возможности будущих ОТД HTML 4, которые они не могут распознать;

7.2 Информация о версии HTML: Используйте недатированные HTML 4 URI для системных идентификаторов. Эти URI также используются глобально во всех примерах.7.4.4 Meta-данные: примечания о текущей работе W3C над meta-данными удалены и заменены на заметки о RDF.7.4.4.2 Meta-данные: в конце раздела о заголовках HTTP пример автообновления убран (поскольку он не является частью Рекомендаций), и добавлены примечания о перенаправлениях на стороне сервера.



Общие изменения


Новые таблицы стилей для документов на базе стилей технических сообщений W3C.Краткое содержание.Обновлённые авторские права.Фиксированные скрипты для удаления тегов, могущих вызвать зависание некоторых браузеров.Благодарность Shane McCarron в разделе благодарности.В разделе 1.4 - убраны детали об авторских правах и сделана вместо этого ссылка на сайт W3C.Все ссылки на набор символов документа сделаны по ISO 10646 (и один раз - на UNICODE, чтобы обозначить эквивалентность). Ссылки на UNICODE относятся только к алгоритму двунаправленности.Примеры используют теперь датированные FPI.



Этот раздел описывает, чем версия


Этот раздел описывает, чем версия спецификации HTML 4.0 от 24 апреля 1998 г. отличается от версии 18 декабря 1997 г.


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


Набор символов документа: [ISO10646] используется теперь только для ссылок на набор символов документа. [UNICODE] зарезервирован для ссылок на двунаправленность.



о доступности, указывают теперь на


Примечания. Обновлены примечания о доступности, указывают теперь на Советы по Обеспечению Доступности Web.

Разъяснения


Раздел 3.2.1

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

Раздел 3.2.4

Добавлено положение, что комментарии являются метками.

Раздел 3.3.3

Во втором элементе списка изменить "конечный тег элемента" на "теги элементов".

Раздел 3.3.3.1

В определении модели содержимого, "A" означает, что "A" должно появляться один и только один раз. Также добавлены "+(A)" и "-(A)" к разделу синтаксиса модели содержимого.

Раздел 7.4.2

Разъяснено, что TITLE может не содержать комментариев.

Раздел 10.3

Все употребления "крэкер" в этом разделе и его подразделах заменены на "хакер". Также определения "хакер" и "nerd" взяты из "The Hacker's Dictionary".

Раздел 13.7.2

Употребление атрибутов hspace и vspace не рекомендуется.

Раздел 13.7.4

Атрибут align не рекомендован для IMG, OBJECT и APPLET.



Сценарии/scripting


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



SGML и HTML


Раздел 3.2.2: Значения атрибутов могут содержать точки и символы подчёркивания.



SGML - объявление


SGML - объявление в HTML 4: убран текст об up-to-date ссылках на ISO 10646. Заменено на: "Пересмотр спецификации HTML 4 может обновлять ссылку на ISO 10646 для включения дополнительных изменений."



Ссылки


обновлённые ссылки на RFC используют http://www.ietf.org/rfcсделаны ссылки в заглавиях;обновлена дата (27 авг. 1998) для [DATETIME]обновлена дата (11 янв. 1999) для [CSS1]зафиксирована дата публикации [CSS2][UNICODE] обновлён до версии 3.0[ISO10646] обновлён, новые назначения символов. Обратите внимание, что исправление 5 специально внесено;ожидается обновление [RFC1766][RFC2279] отменяет [RFC2044][RFC2616] отменяет [RFC2068][RFC2388] в дополнение к [RFC1867]адрес [LEXHTML] обновлён, добавлена дата;адрес [DCORE] обновлён;обновлён [WEBSGML]адрес [HTML3STYLE] обновлён;добавлен [RDF10] (заменил старый RDF)изменён [WAIGUIDE] -> [WAI]добавлены информационные ссылки [WCGL], [UAGL] и [ATGL]обновлён URI на [URI] (RFC 2396)



Strict - ОТД


атрибуты vspace/hspace/border в IMG, OBJECT, APPLET в пикселах;изменена модель содержимого MAP: ((%block;) | AREA)+добавлен атрибут "ismap" в INPUT;атрибут accept добавлен к фрагменту ОТД для элемента FORM;комментарий атрибута axis изменён в отношении списка, разделённого запятыми;атрибут archive элемента OBJECT принимает значение типа CDATA вместо типа %URI, так как значением является список URI, разделённых пробелами.



Таблицы


11.2.6 Ячейки: определения rowspan и colspan изменены. Теперь spans объединены в группы (рядов или столбцов);11.3.2 Выравнивание: если "char=align" не поддерживается ПА, поведение не определено.



так что авторы могут писать


HTML 4.0 поддерживает широкий набор media-дескрипторов, так что авторы могут писать таблицы стилей, чувствительные к типу устройства.

Таблицы стилей в документах HTML


14.6 Ссылка на таблицу стилей в заголовках HTTP: поскольку RFC 2616 не включает поле Link в заголовке, весь раздел квалифицирован только для предыдущих версий HTTP 1.1.



Текст


Новые возможности интернационализации позволяют авторам определять направление текста и язык.Элементы INS и DEL позволяют авторам помечать изменения в своих документах.Элементы ABBR и ACRONYM позволяют авторам помечать аббревиатуры и акронимы в своих документах.



Устаревшие элементы


Следующие элементы устарели: LISTING, PLAINTEXT и XMP. Вместо них авторы должны употреблять элемент PRE.



Алгоритм автовывода


Если количество столбцов не установлено элементами COL или COLGROUP, тогда ПА должен использовать алгоритм автовывода. Он использует два шага по данным таблицы и линеарно сканирует размер таблицы.

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

Максимальная ширина берётся по самой длинной строке. Пока перенос строк запрещён, параграфы рассматриваются как длинные строки, если только они не прерываются элементами BR.

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

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

Для определения выравнивания содержимого ячейки, алгоритм делает три прохода min/max для каждого столбца: Left или align char, right или align char и unaligned. Минимальная ширина столбца тогда: max(min_left + min_right, min_non-aligned).

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

Следующий шаг - установка ширины столбцов в соответствии доступным пространством (т.е. пространством между текущими правым и левым полями).

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

Рамки таблицы и поля между ячейками должны учитываться при установке ширины столбцов. Есть три варианта:

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


Максимальная ширина таблицы больше, чем доступное пространство, но минимальная ширина таблицы - меньше. В этом случае найдите разницу между доступным пространством и минимальной шириной таблицы, назовём её W. Назовём также D разность между минимальной и максимальной шириной таблицы.

Для каждого столбца d будет разностью между между минимальной и максимальной шириной этого столбца. Теперь установим ширину столбца на минимум плюс d раз W через D. Это установит столбцы с большей разностью максимальной и минимальной ширины более широкими, чем столбцы с меньшей разностью.



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

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

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

При использовании двухшагового алгоритма позиция выравнивания по умолчанию, при отсутствии явного или наследуемого атрибута charoff, может быть определена выбором позиции, которая центрирует строки, для которых ширина до и после символа выравнивания установлена в максимальные значения для любой из строк столбца, в которых align="char". Для вывода таблицы частями, рекомендуемое значение charoff="50%". В разных ячейках различных рядов, для одного столбца используйте выравнивание символов, затем по умолчанию все эти ячейки должны быть выровнены line up, независимо от того. какой символ используется для выравнивания. Правила обработки слишком широких для столбца объектов применяются, если явное или подразумеваемое выравнивание даёт в результате количество данных, превосходящее установленную ширину столбца.

Выбор имени атрибута. Лучше выбирать значения атрибута frame последовательно с атрибутом rules и значениями, используемыми для выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, SGML требует перечисляемых значений атрибута, уникальных для каждого элемента, не зависящих от имени атрибута. Это создаёт проблемы для "none", "left", "right" и "all". Значения атрибута frame выбирались так, чтобы исключить конфликты с атрибутами rules, align и valign. Это потребует в будущем большой корректуры, поскольку ожидается, что атрибуты frame и rules будут добавлены к другим элементам таблицы в последующих версиях спецификации. Альтернат ивой может стать установление frame атрибутом CDATA. Решением W3C HTML Working Group было то, что преимущества, даваемые использованием SGML утилитами проверки значения атрибутов на базе перечисляемых значений перевешивает необходимость в последовательном именовании.


Амперсанды в значениях атрибута URI


URI, конструируемый при отправке формы, может быть использован как ссылка в стиле якоря (напр., атрибут href элемента).

К сожалению, использование символа "&" для разделения полей пересекается с его использованием в значениях атрибутов SGML при разграничении мнемонических ссылок. Например, чтобы использовать URI "http://host/?x=1&y=2" как связующий URI, он должен быть записан

<A href="http://host/?x=1&#38;y=2">

или

<A href="http://host/?x=1&amp;y=2">

Мы рекомендуем, чтобы разработчики HTTP сервера и в особенности - разработчики CGI поддерживали использование ";" вместо "&" для предотвращения проблем с использованием escaping-символов "&".



Безопасность


Якоря, внедрённые изображения и др. элементы, содержащие URI, как параметры могу модифицировать URI в ответ на действия пользователя. В этом случае, необходимо рассмотреть вопросы безопасности в [RFC1738], раздел 6. Широко используемы методы отправки данных формы - HTTP и SMTP - не гарантируют конфиденциальности. Провайдеры, запрашивающие частную информацию с помощью форм, - особенно через элемент INPUT, type="password" - должны быть уверены, и убедить своих пользователей, в конфиденциальности передачи информации.



Будущие проекты


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

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

Другим возможным расширением может стать добавление атрибута usemap к INPUT для использования как карты изображений на стороне клиента, если "type=image". Элемент AREA, соответствующий нажатой ссылке, возможно, будет передаваться на сервер. Чтобы исключить необходимость модифицировать серверные скрипты в будущем, имеет смысл расширить AREA, чтобы предоставлять значения x и y для использования элементом INPUT.



Булевы атрибуты


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

Например, автор может определить:

<OPTION selected>

вместо

<OPTION selected="selected">



Динамическое форматирование


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



Доступность


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



Файл robots.txt


Если Робот заходит на сайт http://www.foobar.com/, он сначала проверяет наличие файла http://www.foobar.com/robots.txt. Если файл найден, робот анализирует его, чтобы определить, может ли документ быть запрошен. Вы можете указать в файле robots.txt применение только конкретных роботов и запретить доступ к определённым файлам или директориям.

Вот примеры из файла robots.txt, запрещающего роботу посещение всего сайта:

User-agent: * # применимо ко всем роботам Disallow: / # запрещает индексирование всех страниц

Робот просто ищет URI файла "/robots.txt" на Вашем сайте, определённом как HTTP сервер, запущенный на определённом хосте с определённым номером порта. Вот несколько примеров для файла robots.txt:

URI сайтаURI для файла robots.txt
http://www.w3.org/http://www.w3.org/robots.txt
http://www.w3.org:80/http://www.w3.org:80/robots.txt
http://www.w3.org:1234/http://www.w3.org:1234/robots.txt
http://w3.org/http://w3.org/robots.txt

На сайте может быть только один файл "/robots.txt". Вы не должны помещать "robots.txt" в пользовательский каталог, поскольку робот их никогда не просматривает. Если Вы хотите, чтобы пользователи могли создавать свой собственный файл "robots.txt", Вам нужно будет объединить все эти файлы в единый "/robots.txt". Если Вам это не нужно, Ваши пользователи могут использовать тег META.

Несколько замечаний:

URI чувствительны к регистру, поэтому строки в "/robots.txt" должны быть записаны в нижнем регистре.

Пустые строки в записях файла "robots.txt" недопустимы.

В записи может быть только одно поле "User-agent". Робот должен быть свободен в трактовке этого поля. Рекомендуются нечувствительные к регистру подстроки "name" без информации о версии.

Если значением является "*", запись описывает политику доступа по умолчанию для любого робота, если он не нашёл ничего в других записях. Не допускается наличие нескольких таких записей в файле "/robots.txt".

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

Disallow: /help запрещает доступ и к /help.html , и к /help/index.html, в то время, как Disallow: /help/ запрещает доступ к /help/index.html но разрешает к /help.html

Пустое значение параметра "Disallow" означает, что все URI могут быть запрошены. По меньшей мере одно поле "Disallow" должно присутствовать в файле robots.txt.



Фиксированный алгоритм вывода


Этот алгоритм предполагает, что количество столбцов известно. По умолчанию столбцы должны иметь одинаковую ширину. Авторы могут переопределить это, установив относительную или абсолютную ширину столбца, используя элементы COLGROUP или COL. По умолчанию ширина таблицы равна пространству между левым и правым полями, но может быть переопределена с использованием атрибута width элемента TABLE или установлена в абсолютных единицах. Чтобы совместить столбцы, ширина которых установлена в абсолютных и относительных единицах, нужно, во-первых, распределить пространство таблицы для столбцов, измеряемых в абсолютных единицах. После этого оставшееся пространство делится между столбцами, ширина которых измеряется в относительных единицах.

Сам по себе синтаксис таблицы недостаточен для того, чтобы гарантировать соответствие значений атрибутов. Например, количество элементов COL и COLGROUP может не совпадать с количеством столбцов, занимаемых ячейками таблицы. Дополнительные проблемы возникают, если столбцы слишком узки, чтобы предотвратить переполнение содержимого ячеек. Ширина таблицы, установленная в элементах TABLE или COL, также может привести к переполнению ячеек. Рекомендуется, чтобы ПА пытались изящно обработать эту ситуацию, например, словами с дефисами и пересортировкой разделённых слов, если точки переноса не известны.

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



Фрэймы


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

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



Группы рядов и столбцов


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

Следуя модели таблиц CALS (см. [CALS]), эта спецификация разрешает группировать ряды таблицы в разделы head, body и foot. Это упрощает воспроизведение информации представления и может быть использовано для повторения рядов head и foot при разрыве таблицы по границам страниц или для показа фиксированных заголовков в верхней части прокручиваемой панели. При разметке foot-секция размещается перед body-секциями. Эта оптимизация разделяется CALS при обработке очень больших таблиц. Это даёт возможность видеть foot, не ожидая вывода всей таблицы.



Инструкции процесса


Инструкции процесса - это механизм использования платформозависимых идиом. Инструкции процесса начинаются с <? и заканчиваются >

<?instruction >

Например:

<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>

Авторы должны учитывать, что многие ПА рассматривают инструкции процесса как часть текста документа.



Как помочь поисковой машине проиндексировать Ваш сайт


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

Определение языка документа

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

Определите языковые варианты данного документа

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

<LINK rel="alternate" type="text/html" href="mydoc-fr.html" hreflang="fr" lang="fr" title="La vie souterraine"> <LINK rel="alternate" type="text/html" href="mydoc-de.html" hreflang="de" lang="de" title="Das Leben im Untergrund">

Предоставление ключевых слов или фраз

Некоторые системы поиска просматривают элементы META, дающие разделённый запятыми список ключевых слов/фраз или короткое описание. Поисковые машины могут представить эти ключевые слова как результат поиска. Значение атрибута name, найденное поисковой машиной, не определено в этой спецификации. Рассмотрите пример:

<META name="keywords" content="vacation,Greece,sunshine"> <META name="description" content="Idyllic European vacations">

Обозначение начала коллекции

Коллекции текстовых документов или презентаций часто переводятся в коллекции документов HTML. Более быстрый поиск обеспечивается при установке ссылки на начало коллекции в дополнение к поиску страницы. Вы можете ускорить поиск, используя элемент LINK с rel="start" одновременно с установкой атрибута title:

<LINK rel="start" type="text/html" href="page1.html" title="General Theory of Relativity">

Давайте роботу инструкции по индексированию

Для многих может стать неожиданностью, что их сайты индексируются "роботом" и что робот может просматривать нежелательные разделы сайта. Многие Web-роботы облегчают администраторам сайта и провайдерам определение того, что робот может делать. Это достигается использованием двух механизмов: файла "robots.txt" и элемента META в документах HTML, как это описано ниже.



Конструировать рационально


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

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

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



Маркированные разделы


Маркированные разделы играют роль конструкции #ifdef, распознаваемой препроцессорами С.

<![INCLUDE[ <!-- это будет включено --> ]]>

<![IGNORE[ <!-- это игнорируется --> ]]>

SGML также определяет использование маркированных разделов для содержимого CDATA, внутри которого "<" не рассматривается как начало тега, например:

<![CDATA[ <an> пример разметки <sgml>, that is not <painful> to write with < and such. ]]>

Знаком того, что ПА не распознает маркированный раздел, служит появление "]]>", который будет отображаться, если ПА ошибочно использует первый символ ">" в конце пространства тега, начавшегося с "<![".



Не-ASCII символы в значениях атрибутов URI


Хотя URI не содержат не-ASCII значений (см. [URI], раздел 2.1), авторы иногда определяют не-ASCII значения в атрибутах, ожидаемых URI (т.е. определённых с %URI; в ОТД).

К примеру, данное значение href недопустимо:

<A href="http://foo.org/H&aring;kon">...</A>

Мы рекомендуем, чтобы ПА соблюдали следующее соглашение по обработке не-ASCII символов:

Представлять каждый символ в UTF-8 (см. [RFC2279]) как один или более байтов.Вводить эти байты с помощью Escape-механизма URI (т.е. конвертированием каждого байта в %HH, где HH - это 16-ричное изображение значения байта).

Результатом этой процедуры будет синтаксически допустимый URI (как определено в [RFC1738], раздел 2.2, или в [RFC2141], раздел 2), не зависящий от кодировки, в которой документ HTML, содержащий URI, может транскодироваться.

Примечание. Некоторые старые ПА упрощённо разбирают URI в HTML, используя байты кодировки полученного документа. Некоторые старые документы HTML придерживаются этой практики, и загрузка нарушается при транскодировании. ПА, которые обрабатывают такие старые документы, должны, при получении URI, содержащего символы за пределами допустимого набора, использовать соглашение, базирующееся на UTF-8. Только в том случае, если URI не разобран, они должны попытаться сконструировать URI на базе байтов кодировки полученного документа.Примечание. Такое же соглашение, базирующееся на UTF-8, должно применяться к значениям атрибута name элемента A.



Несоответствующие документы


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

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

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

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

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

Спецификация HTML 2.0 ([RFC1866]) наблюдала, как различные пользовательские агенты HTML 2.0 устанавливали, что документ, не начинающийся объявлением типа документа, относится к спецификации HTML 2.0. Как показывает опыт, это неверное поведение, и данная спецификация не рекомендует этого делать.

Из соображений совместимости, авторы не должны "расширять" HTML за рамки существующего механизма SGML (напр., расширяя ОТД, добавляя новый набор определения объектов и т.д.).



Обрыв строки


SGML (см. [ISO8879], раздел 7.6.1) определяет, что обрыв строки идущий непосредственно за начальным тегом, игнорируется, так же, как и обрыв строки непосредственно перед закрывающим тегом. Это применяется ко всем элементам HTML без исключения.

Следующие два примера идентичны:

<P>Thomas is watching TV.</P> <P> Thomas is watching TV. </P>

Как и следующие два примера:

<A>My favorite Website</A>

<A> My favorite Website </A>



Отображение частями


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

Отображение документов по частям выявило проблемы с табуляционной навигацией. Отображение документов по частям. Передача фокуса на наименьшее значение tabindex в документе имеет смысл только на первый взгляд. Это заставляет ждать, пока весь текст документа не будет загружен, а наименьшее значение tabindex может уже измениться. Если пользователь нажмёт клавишу tab до этого, для ПА резонно будет перевести фокус не наименьшее доступное в данный момент значение tabindex.

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



Рекомендуемый алгоритм вывода


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

Если атрибут width не установлен, визуальные ПА должны принимать для форматирования значение по умолчанию 100%.

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

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



Роботы и элемент META


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

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

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">

Список терминов здесь - ALL, INDEX, NOFOLLOW, NOINDEX.

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



Синтаксис, зарезервированный для будущих макросов сценариев


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

attribute = "... &{ macro body }; ... "



Содержимое элемента


Когда данные сценария или стиля являются содержимым элемента (SCRIPT и STYLE), данные начинаются непосредственно после начального тега элемента и заканчиваются перед первым ограничителем ETAGO ("</"), после которого следует первый символ начального тега ([a-zA-Z]). Обратите внимание, что это может не быть конечный тег данного элемента. Авторы, таким образом должны избегать использования "</" в теле содержимого. Escape-механизмы специфичны для каждого языка скриптов или стилей.

НЕВЕРНЫЙ ИСПОЛЬЗОВАНИЕ:

Данные скрипта некорректно используют последовательность "</" (как часть "</EM>") перед конечным тегом SCRIPT:

<SCRIPT type="text/javascript"> document.write ("<EM>Это не будет работать</EM>") </SCRIPT>

В JavaScript этот код может быть записан верно скрытием ограничителя ETAGO перед начальным символом имени SGML:

<SCRIPT type="text/javascript"> document.write ("<EM>This will work<\/EM>") </SCRIPT>

В Tcl это может быть выполнено так:

<SCRIPT type="text/tcl"> document write "<EM>Это будет работать<\/EM>" </SCRIPT>

В VBScript проблема может быть решена при помощи функции Chr():

"<EM>Это будет работать<" & Chr(47) & "EM>"



Спецификация не-HTML данных


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

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

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



Стенографическая разметка


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

Сомнительные SHORTTAG-конструкции:

NET теги:

<name/.../

закрытый начальный тег:

<name1<name2>

пустой начальный тег:

<>

пустой конечный тег:

</>



Структура и вид


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

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

Современные настольные издательские пакеты предоставляют полный контроль вида таблиц, и было бы непрактично воспроизводить это в HTML, не сделав при этом HTML широко распространённым текстовым форматом, таким как RTF или MIF. Эта спецификация в то же время даёт авторам возможность выбирать из обычно используемого набора классов обрамления. Атрибут frame управляет обрамлением всей таблицы, а атрибут rules - внутренним обрамлением. Более точный контроль поддерживается использованием аннотаций. Атрибут style может использоваться для определения вида отдельных элементов. Дополнительно информация представления задаётся элементом STYLE в заголовке документа или внедрёнными таблицами стилей.

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

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

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



Текущая практика для макросов сценариев


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

Атрибуты CDATA обрабатываются так:

Разборщик SGML вычисляет все мнемоники SGML (напр., "&gt;").Затем макросы сценариев вычисляются машиной скриптов.Наконец, результирующая строка символов предаётся приложению для последующей обработки.

Обработка макросов имеет место при загрузке документа (или перезагрузке), но не происходит при изменении размера документа, перерисовке и т.п.

НЕ РЕКОМЕНДУЕТСЯ:

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

<BODY bgcolor='&{randomrgb};'>

Возможно, Вы хотите уменьшить яркость фона в вечернее время:

<BODY bgcolor='&{if(Date.getHours > 18)...};'>

В следующем примере JavaScript использован для установки координат карты изображений, обрабатываемой на стороне клиента:

<MAP NAME=foo> <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt=""> </MAP> Этот пример устанавливает размер изображения на базе свойств документа: <IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">

Вы можете установить URI для ссылки или изображения:

<SCRIPT type="text/javascript"> function manufacturer(widget) { ... } function location(manufacturer) { ... } function logo(manufacturer) { ... } </SCRIPT> <A href='&{location(manufacturer("widget"))};'>widget</A> <IMG src='&{logo(manufacturer("widget"))};' alt="logo">

Последний пример показывает, как атрибуты SGML CDATA могут быть выделены кавычками с использованием знаков одиночной или двойной кавычки. Если Вы используете одиночные кавычки вокруг строки, можно включить двойные кавычки как часть содержимого строки. Другой подход заключается в использовании &quot; для обозначения двойной кавычки:

<IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">



Вопросы безопасности форм


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

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

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



Возможности SGML с ограниченной поддержкой


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



Вывод по частям


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

Для отображения по частям, браузеру нужно "знать" количество столбцов и их ширину. Ширина таблицы по умолчанию - это текущий размер окна (width="100%"). Это можно изменить установкой атрибута width элемента TABLE. По умолчанию все столбцы имеют одинаковую ширину, но Вы можете определить ширину столбцов установкой одного или более элементов COL перед началом данных таблицы.

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

Авторам необходим способ сообщить ПА, использовать ли изображение по частям или размещать таблицу автоматически при заполнении ячеек. В двухступенчатом автоматическом режиме количество столбцов определяется на первой ступени. При отображении частями количество столбцов определяется предварительно (элементами COL или COLGROUP).



Значения атрибутов


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

'"' должно быть записано "&quot;" или "&#34;"'&' должно быть записано "&amp;" или "&#38;"

Таким образом, например, можно записать:

<INPUT name="num" value="0" onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">