A.1.1 Изменения в спецификации

A.1.2 Замеченные ошибки

(Всё исправлено)

A.1.3 Исправленные опечатки

(Всё исправлено)

A.1.4 Разъяснения

A.1.4 Разъяснения

Раздел 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.

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

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

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

A.1 Отличия версий HTML 4.02 от 4 апреля 1998 г. и HTML 4.01 от 24 декабря 1999 г.

В этом разделе описаны отличия спецификации версии HTML 4.01 24 декабря 1999 г. от спецификации версии HTML 4.0 24 апреля 1998 г.

A.2.1 Замеченные ошибки

A.2.1 Замеченные ошибки

(Всё исправлено)

A.2.2 Исправленные опечатки

A.2.2 Исправленные опечатки

(Всё исправлено)

Отличия версий 18 декабря 1997

A.2 Отличия версий 18 декабря 1997 и 24 апреля 1998

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

A.3.1 Элементы

A.3.2 Атрибуты

A.3.2 Атрибуты

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

A.3.3 Доступность

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

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

A.3.4 Данные meta

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

A.3.5 Текст

A.3.5 Текст

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

A.3.6 Гиперссылки

A.3.6 Гиперссылки

Атрибут id делает любой элемент целевым элементом для якоря ссылки.

A.3.7 Таблицы

Модель таблиц HTML 4.0 превзошла всё до сих пор существовавшее в HTML+ и в HTML3.0. Предыдущие модели были расширены в соответствии с запросами провайдеров информации следующим образом:

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

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

Кроме того, важной целью является обеспечение обратной совместимости с широко применяемой разработкой таблиц фирмы Netscape. Другой целью является упрощение импортирования таблиц в соответствии с моделью SGML CALS. Последние разработки делают атрибут align совместимым с последними версиями популярных браузеров. Некоторые разъяснения были даны о роли атрибута dir и рекомендуемом поведении при смешивании абсолютных и относительных параметров ширины столбца.

Новый элемент COLGROUP введён для того, чтобы дать возможность группировать наборы столбцов различной ширины и выравнивания, установленных одним или несколькими элементами COL. Семантика COLGROUP разъяснена по сравнению с предыдущими разработками, и rules="basic" заменён на rules="groups".

Атрибут style включён, как предполагается, для расширения свойств, ассоциированных с кромками и внутренней частью групп ячеек. Например, стиль линий: dotted, double, thin/thick и т.п., заполнение цвет/паттерн для внутренней части, поля ячеек и информация о шрифте. Всё это будет объектом соответствующей спецификации таблиц стилей.

Атрибуты frame и rules модифицированы для устранения конфликтов имён SGML с другими и для избежания конфликтов с атрибутами align и valign. Эти изменения объясняются также желанием избежать в будущем проблем, если эта спецификация расширит использование атрибутов frame и rules с другими элементами таблиц.

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

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

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

A.3.9 Формы

В этой спецификации вводятся новые элементы, воздействующие на формы:

Атрибут accesskey позволяет авторам устанавливать прямой доступ с клавиатуры к элементам управления.Атрибут disabled позволяет авторам установить элемент управления в начальное положение "отключён".Атрибут readonly позволяет авторам запретить изменения элемента формы. Элемент LABEL ассоциирует надпись с определённым элементом формы. Элемент FIELDSET группирует связанные поля и, при ассоциации с элементом LEGEND, может использоваться для именования группы. Оба эти элемента дают больше возможностей для представления документа и интерактивности. Речевые браузеры могут лучше описать форму, а графические браузеры - сделать лэйблы чувствительными.Новый набор атрибутов, в сочетании со скриптами, дают возможность проверять данные, введённые пользователем, на стороне клиента.Элемент BUTTON и INPUT с type, установленным в "button", могут использоваться в комбинации со скриптами для создания сложных форм.Элемент OPTGROUP позволяет авторам группировать опции меню в SELECT, что особенно важно для доступности форм. Дополнительные изменения в интернационализации.

A.3.10 Таблицы стилей

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

A.3.11 Фрэймы

HTML 4.0 поддерживает фрэймы и inline/инлайн-фрэймы.

A.3.12 Сценарии/scripting

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

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

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

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

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

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

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

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

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

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

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

Мы рекомендуем, чтобы ПА соблюдали следующее соглашение по обработке не-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 .

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

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

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

B.2 Специальные символы в значениях атрибутов URI

B.3.1 Обрыв строки

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>

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

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

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

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

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

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

B.3.4 Булевы атрибуты

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

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

вместо

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

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

<![INCLUDE[  ]]> <![IGNORE[  ]]>

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

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

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

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

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

<?instruction >

Например:

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

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

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

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

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

NET теги: <name/.../закрытый начальный тег: <name1<name2>пустой начальный тег: <> пустой конечный тег: </>

B.3 SGML: Замечания

B.4.1 Поисковые машины (роботы)

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

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

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

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

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

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

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

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

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

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

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

B.5 Таблицы

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

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

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

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

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

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

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

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

B.6 Формы

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

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

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

B.7 Сценарии

B.8 Фрэймы

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

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

B.9 Доступность

Инициатива W3C по Доступности Вэб - Web Accessibility Initiative ([WAI]) даёт серию рекомендаций по повышению доступности Web для людей с ограниченными физическими возможностями. Есть три блока рекомендаций:

Web Content Accessibility Guidelines ([WCGL]) - для авторов и менеджеров сайтов. Пожалуйста, проконсультируйтесь в Web Content Accessibility Guidelines о том, как применять альтернативный текст для изображений, аплетов скриптов и т.д. User Agent Accessibility Guidelines ([UAGL]) - для разработчиков пользовательских агентов (ПА) (браузеров, мультимедиа плэйеров, технологий-помощников). Пожалуйста, используйте эти рекомендации как руководство по обработке альтернативного текста.Authoring Tool Accessibility Guidelines ([ATGL]) - для разработчиков авторских утилит.

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

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

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

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

B.10 Безопасность

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

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

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

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

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

Некоторые атрибуты играют роль булевых переменных (напр., атрибут selected элемента OPTION). Их появление в начальном теге элемента подразумевает, что значение атрибута - "true". Их отсутствие подразумевает, что значение - "false".

Булевы атрибуты могут принимать единственное значение: само имя атрибута (напр., selected="selected").

В этом примере атрибут selected является булевым атрибутом.

selected (selected) #IMPLIED -- опция предустановлена --

Этот атрибут установлен "true" в начальном теге элемента:

<OPTION selected="selected"> ...содержимое... </OPTION>

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

вместо:

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

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

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

Доступность

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