Опубликован: 19.05.2006 | Доступ: свободный | Студентов: 10026 / 1561 | Оценка: 4.29 / 4.03 | Длительность: 22:29:00
ISBN: 978-5-94774-648-8
Дополнительный материал 8:

Приложение B: Замечания относительно Исполнения, Разработки и Дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Представлять каждый символ в UTF-8 (см. "[RFC2279]" ) как один или более байтов.
  2. Вводить эти байты с помощью 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.

Амперсанды в значениях атрибута 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-символов " & ".

Ирина Кириллова
Ирина Кириллова

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