Оглавление
Следующие примечания являются информативными , не нормативными, несмотря на наличие таких слов, как "должен" и "обязан". Все требования из этого раздела есть в спецификации.
Эта спецификация не определяет, как соответствующие ПА обрабатывают общие ошибки, в том числе - как ПА ведут себя при обнаружении элементов, атрибутов, значений атрибутов или объектов, не специфицированных в этом документе.
Однако, чтобы облегчить экспериментирование и взаимодействие между выполнениями различных версий HTML, мы рекомендуем следующую стратегию:
Мы также рекомендуем, чтобы ПА поддерживали оповещение пользователя о таких ошибках.
Поскольку ПА могут отличаться в том, как они обрабатывают ошибки, авторы и пользователи не должны полагаться на конкретное поведение ПА при обнаружении ошибки.
Спецификация HTML 2.0 ([RFC1866]) наблюдала, как различные пользовательские агенты HTML 2.0 устанавливали, что документ, не начинающийся объявлением типа документа, относится к спецификации HTML 2.0. Как показывает опыт, это неверное поведение, и данная спецификация не рекомендует этого делать.
Из соображений совместимости, авторы не должны "расширять" HTML за рамки существующего механизма SGML (напр., расширяя ОТД, добавляя новый набор определения объектов и т.д.).
Хотя URI не содержат не-ASCII значений (см. [URI], раздел 2.1), авторы иногда определяют не-ASCII значения в атрибутах, ожидаемых URI (т.е. определённых с %URI; в ОТД).
К примеру,
данное значение href недопустимо:
<A href="http://foo.org/Håkon">...</A>
Мы рекомендуем, чтобы ПА соблюдали следующее соглашение по обработке не-ASCII символов:
Результатом этой процедуры будет синтаксически допустимый URI (как определено в [RFC1738], раздел 2.2, или в [RFC2141], раздел 2), не зависящий от кодировки, в которой документ HTML, содержащий URI, может транскодироваться.
Примечание. Некоторые старые ПА упрощённо разбирают URI в HTML, используя байты кодировки полученного документа. Некоторые старые документы HTML придерживаются этой практики, и загрузка нарушается при транскодировании. ПА, которые обрабатывают такие старые документы, должны, при получении URI, содержащего символы за пределами допустимого набора, использовать соглашение, базирующееся на UTF-8. Только в том случае, если URI не разобран, они должны попытаться сконструировать URI на базе байтов кодировки полученного документа.
Примечание. Такое же соглашение, базирующееся на UTF-8, должно применяться к значениям атрибута name элемента A .
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-символов "&".
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>
Данные сценарияи стиля могут появляться как содержимое элемента или как значения атрибута. Следующий раздел очерчивает границы между разметкой HTML и другими данными.
Примечание. ОТД определяет, что данные сценария и стиля должны быть CDATA и для содержимого элемента, и для значений атрибута. Правила SGML не допускают символьных ссылок в содержимом элемента CDATA, но допускают их в значениях атрибута в CDATA. Авторы должны уделить особое внимание при вырезке и вставке данных сценариев и стиля между содержимым элемента и значениями атрибута.
Эта асимметрия также предполагает, что при транскодировании из более сложной в более простую кодировку транскодер не может просто заменить неконвертируемые символы в данных сценария или стиля на соответствующие цифровые мнемоники; он должен разобрать документ HTML и "знать" всё о синтаксисе языка сценария или стиля для того, чтобы трактовать данные корректно.
Когда данные сценария или стиля являются содержимым элемента (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>"
Если данные сценария или стиля являются значением атрибута (атрибуты style или внутренние события), авторы должны избегать появления ограничивающих одинарных или двойных кавычек внутри значений в соответствии с соглашением по языку стиля или сценария. Авторы должны также избегать применения "&", если "&" не является началом ссылки-мнемоники.
Таким образом, например, можно записать:
<INPUT name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
Системы SGML, соответствующие [ISO8879], должны распознавать ряд возможностей, которые не поддерживаются широко в настоящее время Пользовательскими Агентами HTML. Мы рекомендуем авторам избегать использования всех этих возможностей.
Авторы должны учитывать, что многие ПА распознают только минимизированные формы булевых атрибутов, а не полные формы.
Например, автор может определить:
<OPTION selected>
вместо
<OPTION selected="selected">
Маркированные разделы играют роль конструкции #ifdef, распознаваемой препроцессорами С.
<![INCLUDE[ <!-- это будет включено --> ]]> <![IGNORE[ <!-- это игнорируется --> ]]>
SGML также определяет использование маркированных разделов для содержимого CDATA, внутри которого "<" не рассматривается как начало тега, например:
<![CDATA[ <an> пример разметки <sgml>, that is not <painful> to write with < and such. ]]>
Знаком того, что ПА не распознает маркированный раздел, служит появление "]]>", который будет отображаться, если ПА ошибочно использует первый символ ">" в конце пространства тега, начавшегося с "<![".
Инструкции процесса - это механизм использования платформозависимых идиом. Инструкции процесса начинаются с <? и заканчиваются >
<?instruction >
Например:
<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>
Авторы должны учитывать, что многие ПА рассматривают инструкции процесса как часть текста документа.
Некоторые SGML SHORTTAG-конструкции сохраняют возможность передачи текста, но не добавляют выразительных возможностей приложению SGML. Хотя эти конструкции технически недвусмысленны, они снижают надёжность документов, особенно если язык расширяется для включения новых элементов. Таким образом, в то время, как SHORTTAG-конструкции SGML, относящиеся к атрибутам, широко используются и распространяются, эти же конструкции, относящиеся к элементам - нет. Документы, использующие их, соответствуют требованиям SGML, но работают по другому со многими существующими утилитами HTML.
Сомнительные SHORTTAG-конструкции:
<name/.../
<name1<name2>
<>
</>
В этом разделе даны некоторые простые советы, которые помогут сделать Ваши документы более доступными для поисковых машин.
<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="keywords" content="vacation,Greece,sunshine"> <META name="description" content="Idyllic European vacations">
<LINK rel="start"
type="text/html" href="page1.html"
title="General Theory of Relativity">
Если Робот заходит на сайт 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.
Элемент META позволяет авторам HTML сообщить роботу, может ли документ быть индексирован или использован для получения дополнительных ссылок. Для этого не требуется вмешательства администратора сервера.
В этом примере робот не должен ни индексировать документ, ни анализировать его на ссылки:
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
Список терминов здесь - ALL, INDEX, NOFOLLOW, NOINDEX.
Примечание. В начале 1997 г. только некоторые роботы выполняли это, но это должно изменяться по мере того, как внимание публики будет всё более привлекаться к использованию индексирующих роботов.
Модель таблиц HTML разработана на основе существующих моделей таблиц SGML, обработки таблиц в текстовых процессорах и табличной организации вывода информации в журналах, книгах и других бумажных документах.
Эта модель была выбрана для упрощения вывода простых таблиц с возможностью дополнительного
усложнения при необходимости. Имеет смысл создавать разметку для таблиц HTML в обычном текстовом редакторе. Это свойство было очень важно для продвижения HTML.
Постепенно стали создавать таблицы путём конвертации документов других форматов или прямо в редакторах типа WYSIWYG. Важно то, что модель таблиц HTML хорошо совмещалась со всеми этими утилитами. Она определяла, как отображаются ячейки, занимающие несколько рядов или столбцов, выравнивание и другие свойства, ассоциированные с группами ячеек.
Главным условием табличной модели HTML является то, что автор не должен контролировать, как пользователь будет размечать таблицу, какие шрифты будут использованы и т.д. Это делает рискованным установку ширины столбцов в абсолютном измерении (пикселах). Вместо этого таблицы должны иметь возможность динамически изменять размер в соответствии с текущим размером окна и шрифтами. Авторы могут определять относительную ширину столбцов, но ПА должны иметь уверенность, что столбцы имеют достаточную ширину для размещения самого широкого элемента содержимого ячейки. Если авторские установки должны быть переопределены, относительная ширина столбцов не должна кардинально меняться.
Для больших таблиц или при низкой скорости передачи данных в сети постепенное отображение таблиц частями имеет для пользователя важное значение. ПА должны иметь возможность начинать показ таблицы до того, как все данные будут получены. Стандартная ширина окна большинства ПА - 80 символов, и графика для большого количества с страниц HTML создаётся в расчёте на эти параметры. Определяя количество столбцов и предоставляя возможности управления шириной таблиц и столбцов, авторы могут подсказывать ПА, что имеется возможность отображения таблиц частями.
Для отображения по частям, браузеру нужно "знать" количество столбцов и их ширину. Ширина таблицы по умолчанию - это текущий размер окна (width="100%"). Это можно изменить установкой атрибута width элемента TABLE. По умолчанию все столбцы имеют одинаковую ширину, но Вы можете определить ширину столбцов установкой одного или более элементов COL перед началом данных таблицы.
Также нужно рассмотреть вопрос о количестве столбцов. Многие советуют дождаться загрузки первого ряда таблицы, но это может занять много времени, если в ячейках много данных. В целом, более правильно будет определить вывод частями, определив точно количество столбцов в элементе TABLE.
Авторам необходим способ сообщить ПА, использовать ли изображение по частям или размещать таблицу автоматически при заполнении ячеек. В двухступенчатом автоматическом режиме количество столбцов определяется на первой ступени. При отображении частями количество столбцов определяется предварительно (элементами COL или COLGROUP).
HTML различает структурную разметку - параграфы, кавычки, и идиомы языка - такие как поля, шрифт, цвет и т.п. - и как это влияет на вид таблиц.
Теоретически, выравнивание текста в таблице и обрамление ячеек - это вопрос передачи, а не структуры. На практике, однако, это объединяется с структурной
информацией, так как данные хорошо переносятся между приложениями. Модель таблиц HTML оставляет большую часть информации представления ассоциированным таблицам стилей. Модель, представленная в этой спецификации, разработана так, чтобы использовать преимущества таких таблиц стилей, но не требовать их
наличия.
Современные настольные издательские пакеты предоставляют полный контроль вида таблиц, и было бы непрактично воспроизводить это в HTML, не сделав при этом HTML широко распространённым текстовым форматом, таким как RTF или MIF. Эта спецификация в то же время даёт авторам возможность выбирать из обычно используемого набора классов обрамления. Атрибут frame управляет обрамлением всей таблицы, а атрибут rules - внутренним обрамлением. Более точный контроль поддерживается использованием аннотаций. Атрибут style может использоваться для определения вида отдельных элементов. Дополнительно информация представления задаётся элементом STYLE в заголовке документа или внедрёнными таблицами стилей.
При разработке этой спецификации были исследованы горы материала для определения разметки таблиц. Один из вопросов касался типа операторов. Включение поддержки увеличения и уменьшения кромки приводит к достаточно сложному алгоритму. Например, работа над включением в полный набор элементов таблицы
атрибутов frame и rules потребовала алгоритма из 24 шагов для определения, должна ли конкретная кромка ячейки размечаться или нет.
Даже такое усложнение не дало достаточного контроля над видом таблицы.
Данная спецификация намеренно придерживается простой интуитивной модели, достаточной для использования в большинстве случаев. Необходима дальнейшая экспериментальная работа, прежде чем более сложный подход будет стандартизован.
Эта спецификация является квинтэссенцией простой модели, разработанной ранее в HTML+. Таблицы представлены как сформированная после необязательного заглавия последовательность рядов, которые, в свою очередь, состоят из последовательности ячеек. Эта модель затем разделяет заголовочные ячейки и ячейки данных и позволяет ячейкам занимать несколько рядов или столбцов.
Следуя модели таблиц CALS (см. [CALS]), эта спецификация разрешает группировать ряды таблицы в разделы head, body и foot. Это упрощает воспроизведение информации представления и может быть использовано для повторения рядов head и foot при разрыве таблицы по границам страниц или для показа фиксированных заголовков в верхней части прокручиваемой панели. При разметке foot-секция размещается перед body-секциями. Эта оптимизация разделяется CALS при обработке очень больших таблиц. Это даёт возможность видеть foot, не ожидая вывода всей таблицы.
Для людей с проблемами зрения HTML предоставляет многообещающие возможности уравнять их в правах с обычными людьми при использовании базового графического пользовательского интерфейса Windows. Табличная модель HTML включает атрибуты для пометки каждой ячейки, чтобы поддержать высококачественный текст для речевого интерфейса. Эти же атрибуты могут использоваться при поддержке автоматизированного импорта и экспорта данных таблиц в базы данных или spreadsheets.
При наличии элементов COL или COLGROUP, они определяют количество столбцов, и таблица может быть представлена в фиксированном виде. Иначе должен быть использован алгоритм автовывода, описываемый ниже.
Если атрибут width не установлен, визуальные ПА должны принимать для форматирования значение по умолчанию 100%.
Рекомендуется, чтобы ПА увеличивали ширину таблицы сверх значений, установленных width, в случае, если компоненты содержимого ячейки переполнены. ПА, переопределяющие установленную ширину, должны делать это в рамках здравого смысла. ПА могут избрать перенос слов для избежания излишней горизонтальной прокрутки или если такая прокрутка непрактична и нежелательна.
ПА должны рассматривать заголовки таблиц (установленные элементом CAPTION) как ячейки. Каждый заголовок - это ячейка, занимающая все столбцы таблицы вверху или внизу, и ряды ряды слева и справа.
Этот алгоритм предполагает, что количество столбцов известно. По умолчанию столбцы должны иметь одинаковую ширину. Авторы могут переопределить это, установив относительную или абсолютную ширину столбца, используя элементы COLGROUP или COL.
По
умолчанию ширина таблицы равна пространству между левым и правым полями, но может быть переопределена с использованием атрибута width элемента TABLE или
установлена в абсолютных единицах. Чтобы совместить столбцы, ширина которых установлена в абсолютных и относительных единицах, нужно, во-первых, распределить пространство таблицы для столбцов, измеряемых в абсолютных единицах. После этого оставшееся пространство делится между столбцами, ширина которых
измеряется в относительных единицах.
Сам по себе синтаксис таблицы недостаточен для того, чтобы гарантировать соответствие значений атрибутов. Например, количество элементов COL и COLGROUP может не совпадать с количеством столбцов, занимаемых ячейками таблицы. Дополнительные проблемы возникают, если столбцы слишком узки, чтобы предотвратить переполнение содержимого ячеек. Ширина таблицы, установленная в элементах TABLE или COL, также может привести к переполнению ячеек. Рекомендуется, чтобы ПА пытались изящно обработать эту ситуацию, например, словами с дефисами и пересортировкой разделённых слов, если точки переноса не известны.
При наступлении события, когда невидимый элемент вызывает переполнение ячеек, ПА может предусматривать уточнение ширины столбцов и перерисовку таблицы. В худшем случае, может предусматриваться сжатие/clipping, если уточнение ширины столбцов и/или прокрутка содержимого ячеек невозможны. В ином случае, если содержимое ячейки разделено или сжато, это должно быть соответствующим образом сообщено пользователю.
Если количество столбцов не установлено элементами COL или COLGROUP, тогда ПА должен использовать алгоритм автовывода. Он использует два шага по данным таблицы и линеарно сканирует размер таблицы.
На первом этапе перенос строк запрещён, и ПА отслеживает минимальную и максимальную ширину каждой ячейки.
Максимальная ширина берётся по самой длинной строке. Пока перенос строк запрещён, параграфы рассматриваются как длинные строки, если только они не прерываются элементами BR.
Минимальная
ширина берётся по самому широкому элементу (слову, изображению и т.п.) с учётом ведущих отступов, значков списка и т.п. Другими словами, нужно определить минимальную ширину, которую ячейка может занимать в окне, прежде чем она начнёт переполняться. Разрешение для ПА разделять слова уменьшает необходимость
горизонтальной прокрутки или, в худшем случае, сжатия содержимого ячейки.
Этот же процесс применяется и к каждой вложенной в ячейке таблице. Минимальная и максимальная ширина ячеек во вложенной таблице используется, чтобы определить минимальную и максимальную ширину этих таблиц и, следовательно - самой ячейки родительской таблицы. Алгоритм линеарен по совокупному содержимому ячейки и, говоря шире, не зависит от глубины вложения.
Для определения выравнивания содержимого ячейки, алгоритм делает три прохода min/max для каждого столбца: Left или align char, right или align char и unaligned. Минимальная ширина столбца тогда: max(min_left + min_right, min_non-aligned).
Минимальная и максимальная ширина ячейки используются затем для определения соответствующих минимальной и максимальной ширины столбца. Они в свою очередь используются, чтобы найти минимальную и максимальную ширину таблицы. Обратите внимание, что ячейки могут содержать вложенные таблицы, но это не
усложняет код существенно.
Следующий шаг - установка ширины столбцов в соответствии доступным пространством (т.е. пространством между текущими правым и левым полями).
Для ячеек, занимающих несколько столбцов, простой подход состоит в распределении min/max ширины равномерно между всеми столбцами.
Слегка более усложнённый подход заключается в использовании min/max ширины нерасширенных ячеек для определения того, как распределяется ширина расширенных ячеек. Эксперименты
показывают, что соединение этих двух подходов даёт хорошие результаты для широкого круга таблиц.
Рамки таблицы и поля между ячейками должны учитываться при установке ширины столбцов. Есть три варианта:
Для каждого столбца 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 утилитами проверки значения атрибутов на
базе перечисляемых значений перевешивает необходимость в последовательном именовании.
Отображение по частям документов, загружаемых из сети, привело к увеличению количества проблем с формами. ПА должны предотвращать отправку форм до тех пор, пока не получены все элементы формы.
Отображение документов по частям выявило проблемы с табуляционной навигацией. Отображение документов по частям. Передача фокуса на наименьшее значение tabindex в документе имеет смысл только на первый взгляд. Это заставляет ждать, пока весь текст документа не будет загружен, а наименьшее значение tabindex может уже измениться. Если пользователь нажмёт клавишу tab до этого, для ПА резонно будет перевести фокус не наименьшее доступное в данный момент значение tabindex.
Если формы ассоциированы со сценариями на стороне клиента, потенциально могут появиться проблемы в будущем. Например, обработчик скрипта для данного поля может ссылаться на поле, которое ещё не создано.
Эта спецификация определяет ряд элементов и атрибутов достаточно мощных, чтобы справиться с общими задачами по созданию форм. Однако, всегда есть возможность для усовершенствований. Например, могут появиться следующие проблемы :
Другим возможным расширением может стать добавление атрибута usemap к INPUT для использования как карты изображений на стороне клиента, если "type=image". Элемент AREA, соответствующий нажатой ссылке, возможно, будет передаваться на сервер. Чтобы исключить необходимость модифицировать серверные скрипты в будущем, имеет смысл расширить AREA, чтобы предоставлять значения x и y для использования элементом INPUT.
Эта спецификация резервирует синтаксис для поддержки в будущем макросов скриптов в атрибутах HTML CDATA. Замысел в том, чтобы атрибуты устанавливались в зависимости от свойств объектов, появившихся ранее на странице. Синтаксис таков:
attribute = "... &{ macro body }; ... "
Тело макроса состоит из одного или более операторов на языке сценариев по умолчанию (как и у внутренних атрибутов событий). Точка с запятой перед правой скобкой необходима всегда, поскольку иначе символ "}" рассматривается как часть тела макроса. Нужно также отметить, что кавычки всегда необходимы для атрибутов, содержащих макросы сценариев.
Атрибуты CDATA обрабатываются так:
Обработка макросов имеет место при загрузке документа (или перезагрузке), но не происходит при изменении размера документа, перерисовке и т.п.
НЕ РЕКОМЕНДУЕТСЯ:
Вот несколько примеров с использованием 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 могут быть выделены кавычками с использованием знаков одиночной или двойной кавычки. Если Вы используете одиночные кавычки вокруг строки, можно включить двойные кавычки как часть содержимого строки. Другой подход заключается в использовании " для обозначения двойной кавычки:
<IMG src="&{logo(manufacturer("widget"))};" alt="logo">
Поскольку нет гарантии, что имя целевого/target фрэйма уникально, можно попробовать описать существующую практику поиска фрэйма, установленного как целевой:
Инициатива W3C по Доступности Вэб - Web Accessibility Initiative ([WAI]) даёт серию рекомендаций по повышению доступности Web для людей с ограниченными физическими возможностями. Есть три блока рекомендаций:
Якоря, внедрённые изображения и др. элементы, содержащие URI, как параметры могу модифицировать URI в ответ на действия пользователя. В этом случае, необходимо рассмотреть вопросы безопасности в [RFC1738], раздел 6. Широко используемы методы отправки данных формы - HTTP и SMTP - не гарантируют конфиденциальности. Провайдеры, запрашивающие частную информацию с помощью форм, - особенно через элемент INPUT, type="password" - должны быть уверены, и убедить своих пользователей, в конфиденциальности передачи информации.
ПА не должны пересылать все файлы, запрашиваемые пользователем. Таким образом, HTML ПА должны требовать подтверждения обработки любых файлов, которые могут быть запрошены в атрибуте value элемента INPUT. Скрытые элементы управления не должны специфицировать файлы.
Эта спецификация не содержит механизма шифровки данных; это должно выполняться каким-либо другим механизмом шифровки передачи данных.
Как только файл загружен, ПА должен обработать и сохранить его соответствующим образом.