Содержание
Следующие замечания являются информацтивными, а не нормативными. Несмотря на использование таких слов как "необходимо" и "следует", все требования данного раздела указаны в других частях спецификации.
В данной спецификации не определяется, как соответствующие агенты пользователей должна обрабатывать общие ошибочные состояния, включая поведение агентов пользователей в случае, когда они встречают элементы, атрибуты, значения атрибутов или объекты, не указанные в данном документе.
Однако с целью содействия экспериментам и совместимости между реализациями различных версий HTML рекомендуется следующее поведение:
кроме того, агентам пользователей рекомендуется уведомлять пользователей о таких ошибках.
Поскольку агенты пользователей могут по-разному обрабатывать ошибочные состояния, авторы и пользователи не должны полагаться на определенное поведение в случае возникновения ошибки.
В спецификации HTML 2.0 ([RFC1866]) замечено, что многие агенты пользователей HTML 2.0 предполагают, что документ, которые не начинается с объявления типа документа, относится к спецификации HTML 2.0. Как показывает опыт, это некорректное предположение, данная спецификация не рекомендует такое поведение.
Из соображений совместимости авторы не должны "дополнять" HTML имеющимися механизмами SGML (например, расширяя DTD, добавляя новый набор определений комбинаций и т.д.).
Хотя URI и не включают символы, не входящие в набор ASCII, (см. [URI], раздел 2.1) авторы иногда указывают их в значениях атрибутоах, в которых должны указываться URI (например, в атрибуты, определенные как %URI; в DTD). Например, следующее значение атрибута 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 для элемента A). К сожалению, использование символа "&" для разделения полей формы влияет на его использование в значениях атрибутов SGML для разделения ссылок на символы. Например, чтобы использовать URI "http://host/?x=1&y=2" как ссылку, его необходимо записать <A href="http://host/?x=1&y=2"> или <A href="http://host/?x=1&y=2">.
Мы рекомендуем разработчикам серверов HTTP, и особенно разработчикам CGI, обеспечивать поддержку использования ";" вместо "&", чтобы решить для атворов проблему выделения символов "&" в такой манере.
В SGML (см. [ISO8879], раздел 7.6.1) указано, что разрыв строки, непосредственно следующий за начальным тегом, должен игнорироваться, как и разрыв строки непосредственно перед конечным тегом. Это применяется ко всем элементам HTML без исключения.
Следующие два примера кода HTML должны представляться одинаково:
<P>Паша смотрит телевизор.</P>
<P>
Паша смотрит телевизор.
</P>
Также одинаково должны представляться следующие два примера:
<A>Мой любимый сайт</A>
<A>
Мой любимый сайт
</A>
Данные скрипта и стиля могут присутствовать как содержимео элемента или значение атрибута. В следующих разделах описано разграничение между разметкой HTML и другими данными.
Примечание. В DTD данные скрипта и стиля определяются как CDATA и для содержимого элемента, и для значений атрибутов. Парвила SGML не допускают ссылок на символы в содержимом элементов CDATA, но допускают их в значениях атрибутов CDATA. Авторам следует обращать особенное внимание при вырезании и вставке данных скриптов и стилей из содержимого элемента в значения атрибутов.
Такая ассимметрия, кроме того, означает, что при транскодировании из более обширной кодировки символов в менее обширную транскодер не может просто заменить непреобразуемые символы в данных скрипта или стиля на соответствующие числовые ссылки на символы; он должен провести синтаксический анализ документа HTML и иметь инфомрацию о синтакисисе каждого языка скриптов и стилей для корректной обработки данных.
Если данные скрипта или стиля являются содержимым элемента (SCRIPT и STYLE), данные начинаются непосредственно за начальным тегом элемента и заканчиваются первым разделителем ETAGO ("</"), за которым следует буква ([a-zA-Z]); обратите внимание, что это не обязательно конечный тег элемента. Поэтому авторам следует выделять последовательности "</" в содержимом. Механизмы такого выделения специфичны для каждого языка скриптов или таблиц чтилей.
ПРИМЕР НЕДОПУСТИМОГО ИСПОЛЬЗОВАНИЯ:
Следующие данные скрипта некорректно содержат последовательность "</" (как часть "</EM>") перед конечным тегом SCRIPT:
<SCRIPT type="text/javascript">
document.write ("<EM>Так работать не будет</EM>")
</SCRIPT>
В JavaScript этот код можно представить допустимым образом, скрыв разделитель ETAGO перед начальной буквой SGML:
<SCRIPT type="text/javascript">
document.write ("<EM>Так работать будет<\/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, "Справка")) {gethelp()}">
Системы SGML, соответствующие [ISO8879], должны распознавать ряд возможностей, не поддерживаемых всеми агентами пользователей HTML. Авторам рекомендуется избегать исопльзования этих функций.
Авторам следует знать, что многие агенты пользователей распознают только минимизированную форму логических атрибутов, но не полную.
Например, авторам можно указать:
<OPTION selected>
вместо
<OPTION selected="selected">
Отмеченные выбранные варианты играют роль, подобную конструкции #ifdef, распознаваемой препроцессором языка C.
<![INCLUDE[
<!-- это будет включено -->
]]>
<![IGNORE[
<!-- это будет игнорироваться -->
]]>
В SGML также определяется использование размеченных разделов для содержимого CDATA, в котором "<" обрабатывается не как начало тега, например,
<![CDATA[
<an> пример разметки <sgml>, не вызывающий
<проблем> при записи < и т.д.
]]>
Сигнальным символом того, что агент пользвоателя не распознает размеченный раздел, является представление "]]>", когда агент пользователя по ошибке использует первый символ ">" как конец тега, начинающегося с "<![".
Инструкции по обработке - это механизм захвата платформозависимых идиот\м. Инструкция начинается с <? И заканчивается символом >
<?инструкция >
Например:
<?>
<?style tt = font courier>
<?page break>
<?experiment> ... <?/experiment>
Авторам следует знать, что многие агенты пользвоателей представляют инструкции по обработке как часть текста документа.
Некоторые конструкции SGML SHORTTAG позволяют сэкономить время на набор, но не добавляют выразительных способностей в приложение SGML. Хотя такие конструкции технически не вносят двусмысленности, они снижают надежность документов, особенно если язык расширен и включает новые элементы. Таким образом, в то время как конструкции SHORTTAG SGML, относящиеся к атрибутам, широко используются и реализуются, те же конструкции, относящиеся к элементам, не распространены. Использующие их докменты являются соответствующими документами SGML, но вряд ли будут работать со многими существующими средствами HTML.
конструкции SHORTTAG:
<имя/.../
<имя1<имя2>
<>
</>
В этом разделе приводятся некоторые простые предложения, которые сделают документы более доступными для поисковых машин.
<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="отпуск,Греция,солнце">
<META name="description" content="Идиллический отпуск в Европе">
<LINK rel="begin"
type="text/html"
href="page1.html"
title="Общая теория относительности">
Когда робот просматривает Web-сайт, например, http://www.foobar.com/, сначала он проверяет файл http://www.foobar.com/robots.txt. Если этот документ обнаружен, он анализирует его содержимое и смотрет, позволено ли загрузить документ. Вы можете настроить файл robots.txt только для конкретных роботов и запретить доступ к определенным каталогам или файлам.
Вот пример файла robots.txt, запрещающего доступ ко всему сайт всем роботам
User-agent: * # применяется ко всем роботам
Disallow: / # запретить индексацию всех страниц
Робот просто найдет файл "/robots.txt" URI на Вашем сайте, где сайт - это сервер 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". Если Вы не сделаете так, пользователи могут использовать вместо этого тег Robots META.
Некоторые советы: URI учитывают регистр, и строка "/robots.txt" должна всегда быть в нижнем регистре. Пустые строки запрещены.
В каждой записи должно быть ровно одно поле "User-agent". Робот должен свободно интерпретировать это поле. Рекомендуется строка без учета регистра, совпадающая с именем и не включающая информацию о версии.
Если указано значение "*", запись описывает политику доступа по умолчанию для любого робота, не соответствующего другим записям. В файле "/robots.txt" не может быть несколько таких записей.
В поле "Disallow" задается частичный URI, который посещать запрещено. Это может быть полный или частичный путь; любой URI, начинающийся с этого значения, нельзя будет загрузить. Например,
Disallow: /help запрещает доступ к /help.html и /help/index.html, в то время как
Disallow: /help/ запретит доступ к /help/index.html, но разрешит доступ /help.html.
Пустое значение параметра "Disallow" означает, что все URI могут загружаться. В файле robots.txt должно быть по крайней мере одно поле "Disallow" .
Элемент META позволяет авторам документов HTML сообщать роботам о том, может ли документ быть проиндексирован или может ли он использоваться для получения дополнительных ссылок. Для этого не требуется вмешательство администратора сервера.
В следующем примере робот не будет ни индексировать сайт, ни анализировать ссылки.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
В атрибуте content могут содержаться следующие слова: ALL, INDEX, NOFOLLOW, NOINDEX. Значения атрибутов name и the учитывают регистр.
Примечание. В начале 1997 года это использовалось только несколькими роботами, но в этой области ожидается изменение с повышением интереса к управлению работой роботов.
Модель таблиц HTML явилась результатом изучения существующих моделей таблиц SGML, обработки таблиц в широко распространенных пакетах обработки текстов и широкого диапазона техник компоновки таблиц в журналах, книгах и других печатных документах. Эта модель выбрана так, чтобы позволить проще выражать таблицы с возможной дополнительной сложностью. Это позволяет производить разметку таблиц HTML с помощью текстовых редакторов и сокращает расходы на изучение и подготовку к работе. Это свойство очень важно для HTML.
Все чаще и чаще люди создают таблицы путем преобразования из документов других форматов или создавая их непосредственно в редакторах WYSIWYG. Очень важно, что модель таблиц HTML может использоваться в этих средствах разработки. Это влияет на представление ячеек, занимающих несколько строк или столбцов, и на выравнивание и другие свойства представления, связанные с группами ячеек.
Главным принципом модели таблиц HTML является то, что автор не управляет изменением размера таблицы пользователем, используемыми шрифтами и т.д. Это приводит к тому, что задавать ширину столбца в пикселах становится рискованно. Вместо этого таблицы должны поддерживать динамическое изменение размера и соответствовать текущему размеру окна и шрифтам. Авторы могут определять рекомендуемые параметры типа относительной ширины столбцов, но агенты пользователей должны проверять, достаточна ли ширина столбца для представления самого широкого элемента содержимого ячейки. Если спецификацию автора можно заменить, относительные ширины отдельных столбцов не должны слишком изменяться.
Для больших таблиц или медленных сетевых содинений очень важно последовательное представление таблиц. Агенты пользователей должны иметь возможность начинать отображение таблицы до получения всех данных. Ширина окна по умолчанию для большинства агентов пользователей составляет около 80 символов, а рисунки для большинства страниц HTML состаются с учетом этого числа. Указывая число столбцов и включая условия управления шириной таблицы и шириной различных столбцов, авторы могут дават агентам пользователей подсказки, обеспечивающие последовательное представление содержимого таблицы.
Для последовательного представления браузеру необходимо число столбцов и их ширина. Шириной таблицы по умолчанию считается текущий размер окна (width="100%"). Это можно изменить, установив атрибут width-TABLE элемента TABLE. По умолчанию все столбцы имеют одинаковую ширину, но можно определить ширину стольбца с помощью элементов COL до начала таблицы.
Остается еще проблема числа столбцов. Некоторые предлагают дождаться получения первой строки таблицы, но на это может потребоваться продолжительное время, если в ячейках содержится много информации. В целом при последовательном представлении авторм имеет смысл явно указывать число столбцов в элементе TABLE.
Авторам по-прежнему необходима возможность уведомелния агентов пользователей о том, следует ли использовать последовательное представление или определять размер таблицы автоматически для соответствия содержимому ячейки. В двухпроходном режиме автоматического определения рзмера число столбцов определяется на первом проходе. В последовательном режиме число столбцов должно устанавливаться с начала. Имеет смысл установить для атрибута cols значение, равное числу столбцов, а не использовать атрибуты "layout" (например, layout="fixed" или layout="auto").
В HTML различается структурная разметка, такая как абзацы и цитаты, и средства предствления, такие как поля, шрифты, цвета и т.д. Как это различие влияет на таблицы? С точки зрения пуриста выравнивание текста в ячейках таблицы и границы между ячейками являются вопросом отображения, а не структуры. На практике, однако, их имеет смысл группировать со структурной информацией, поскольку эти свойства легко переносятся из одного приложения в другое. Модель таблиц HTML перекладывает большую часть информации о представлении на связанные таблицы стилей. Модель, представленная в данной спецификации, разработана так, чтобы использовать преимущества таких таблиц стилей, но таблицы стилей не являются обязательными.
Используемые в настоящее время издательские пакеты предоставляют очень богатые возможности по представлению таблиц, и было бы непрактично воспроизводить эти возможности в HTML без превращения HTML в сложный текстовый формат типа RTF или MIF. Однако, в данной спецификации авторам предлагается возможность выбора из ряда широко использумых классов или типов границы. Атрибут frame управляет внешним видом рамки вокруг таблицы, в то время как атрибут rules определяет выбор rulings в таблице. Более богатый уровень управления будет поддерживаться с помощью аннотаций по представлению. Атрибут style может использоваться для определения информации о представлении отдельных элементов. Дальнейшая инфомрация о представлении может задаваться с помощью элемента STYLE в заголовке документа или с помощью связанных таблиц стилей.
В процессе разработки данной спецификации был изучен ряд вопросов по заданию шаблонов обрамления для таблиц. Один из вопросов относится к видам возможных выражений. Включение поддержки вычитания и сложения краев приводит к довольно сложным алгоритмам. Например, работа по обеспечению поддержки атрибутов frame и rules всеми элементами для представления таблиц привела к алгоритму определения того, отображается ли определенная часть рамки таблицы, или нет, из 24 шагов. Даже такая сложность не обеспечивает достаточного управления представлением, отвечающего всем нуждам предсатвления таблиц. Текущая спецификация умышленно придерживается простой интуитивной модели, достаточной в большинстве случаев. Для стандартизации более сложного подхода необходима дальнейшая экспериментальная работа.
в данной спецификации определяется надмножество более простой модели, представленной в более ранней работе по HTML+. Считается, что таблицы формируются из необязатеьлного заголовка и последовательности строк, которая, в свою очередь, состоит из последовательности ячеек. Затем эта модель различает ячейки заголовка и данных и позволяет ячейкам занимать несколько строк или столбцов.
Следуя модели таблиц CALS (см. [CALS]), данная спецификация позволяет группировать строки таблицы в разделы заголовка, тела и нижнего заголовка. Это упрощает представление информации об отображении и может использоваться для повторения заголовков таблицы при переносе таблиц или для обеспечения постоянных заголовков при прокручиваемой панели тела таблицы. В разметке раздел нижнего заголовка помещается перед разделом тела таблицы. Такая оптимизация используется в CALS для работы с длинными таблицами. Это позволяет генерировать нижний заголовок, не дожидаясь обработки всей таблицы.
Для людей с плохим зрением HTML предлагает упрощение использования графического интерфейса пользоваетля на базе окон. Модель таблиц HTML включает атрибуты отметки каждой ячейки для поддержки высококачественного преобразования текста в речь. Те же атрибуты могут использоваться для поддержки автоматизированного импорта и экспорта данных таблицы в базы данных и электронные таблицы.
Если в атрибуте cols элемента TABLE определяется число столбцов, таблица может представляться с использованием фиксирвоанного расположения, в противном случае должен использоваться описанный ниже алгоритм автоматической компоновки.
Если атрибут width не указан, визуальные агенты пользователей должны использовать при форматировании значение по умочланию - 100%.
Агентам пользователей рекомендуется расширять таблицы за пределы значения, указанного в атрибуте width, в случаях, когда содержимое ячейки не входит в нее. Агенты пользователей, изменяющие указанную ширину, должны делать это не без причины. Агенты пользователей могут разбивать слова на строки во избежание использования горизонтальной прокрутки.
Для компоновки агенты пользователей должны полагать, что заголовки таблиц (задавемые элементом CAPTION) подобны ячейкам. Каждый заголовок является ячейкой, занимающей все столбцы таблицы, если он располагается внизу или вверху таблицы, и захватывающей все строки таблицы, если он располагается слева или справа.
В этом алгоритме считается, что число столбцов известно. Ширина столбцов по умолчанию должна быть одинаковая. Авторы могут переопределять это путем указания относительной или абсолютной ширины столбцов с помощью элементов COLGROUP или COL. Ширина таблицы по умолчанию - все пространство между левым и правым полями, но ее можно переобпределить с помощью атрибута width элемента TABLE или определить из абсолютной ширины столбцов. При использовании как абсолютных, так и относительных ширин столбцов, первым шагом является распределение пространства под столбцы с фиксированной шириной. После этого оставшееся пространство делится для столбцов с относительной шириной.
Одного только синтакисиса таблицы недостаточно для гарантии соответствия значений атрибутов. Например, число столбцов, определяемое атрибутом cols, может не совпадать с числом столбцов, определяемым элементами COL. В свою очередь, это может не соответствовать числу столбцов, определяемому из ячеек таблицы. Затем проблемы возникают, если столбцы чересчур узкие, и содержимое не входит в ячейку. Ширина таблицы, указанная в элементе TABLE element или COL, может привести к переполнению ячейки. Агентам пользователей рекомендуется корректно выходить и таких ситуаций, например, путем переноса слов и пересортировки и разбивки слов, если места переноса неизвестны.
В случае, если переполнение ячейки вызывает неделимый элемент, агент пользователя может отрегулировать ширины столбцов и по-новому представить таблицу. В худшем случае, если настройка ширины стоолбца и прокрутка невозможны, можно обрезать содержимое. В любом случае, если содержимое ячейки образается или разбивается, об этом соответсвующим образом должно быть сообщено пользователю.
Если атрибут COLS а начальном теге таблицы отсутствует, агент пользователя должен использовать следующий алгоритм автоматической компоновки. В нем используется два прохода данных таблицы и линейное масштабирование размера таблицы.
На первом проходе перенос строк отключен, а агент пользователя контролирует минимальную и максимальную ширину каждой ячейки. Максимальная ширина определяется самой широкой строкой. Поскольку разбивка строк отключена, абзацы обрабатываются ка кдлинные строки, если только они не разбиты с помощью элементов BR. Минимальная ширина определяется самым широким элементом текста (словом, изображением и т.д.) с учетом начальных отсутпов, маркеров и т.д. Другими словами, необходимо определить минимальную ширину, которая понадобится ячейке в отдльеном окне без переполнения. Разрешение агентам пользователей разбивать слова уменьшит необходимость в горизонтальной прокрутке и обрезание содержимого ячейки.
Этот процесс также применяется к вложенным в ячейки таблицам. Минимальная и максимальная ширина ячеек во вложенных таблицах используются для определения минимальной и максимальной ширины этих таблиц и, следовательно, для внешней таблицы. Алгоритм линейный с совокупным содержимым ячейки, и, широко говоря, не зависит от уровня вложенности.
Для выравнивания символов содержимого ячейки этот алгоритм хранит три значения минимума/максимума для каждой ячейки: Left of align char, right of align char и unaligned. Минимальная ширина столбца: max(min_left + min_right, min_non-aligned).
Минимальная и максимальная ширина ячейки используются для определения соответствующей минимальной и максимальной ширины столбцов. В свою очередь, они используются для нахождения минимальной и максимальной ширины таблицы. Обратите внимание, что ячейки могут содержать вложенные таблицы, но это не усложняет код. Следующим шагом являетс яназначение ширины столбцов в соответствии со свободным пространством (т.е. пространством между левым и правым полями).
Для ячеек, занимающих несколько столбцов, простой подход состоит в распределении минимальной/максимальной ширины равномерно меду всеми столбцами. Чуть более сложный подход - использовать минимальную/максимальную ширину ячеек, не занимающих несколько строк или столбцов, для взвешивания того, как распределяются ширины ячеек, занимающих несколько строк или столбцов. По результатам экспериментов можно сказать, что наилучшие результаты для широкого спектра таблиц дает сочетание этих двух подходов.
Граничы таблицы и поля между ячейками должны включаться в назначенную ширину столбцов. Имеется три случая:
Для каждого столбца сделайте d равным разнице между максимальной и минимальнйо шириной этого столбца. Затем установите ширину столбца равной минимальной ширине плюс d раз по W свыше D. Это позволит сделать столбцы с большей разницей между минимальной и максимальной шириной шире колонок с мнеьшей разницей.
Затем этот шаг повторяется для вложенных таблиц с использованием минимальной и максимальной ширины, полученных для всех таких таблиц в первом проходе. В данном случае ширина ячейки родительской таблицы играет роль размера текущего кона в приведенном выше описании. Этот процесс повторяется рекурсивно для всех вложенных таблиц. Самая верхняя таблицы затем представляется с исопльзованием назначенных ширин. Вложенные таблицы последовательно представляются как часть содержимого ячейки родительской таблицы.
Если ширина таблицы указана с использованием атрибута width, агент пользователя пытается установить соответсвующую ширину столбцов. Атрибут width не является ограничением, если результаты в столбцах имеют ширину меньше минимальной (т.е. неделимые).
Если относительная ширина определяется с помощью элемента COL, алгоритм изменяется, и ширина столбцов увеличивается по сравнению с минимальной для соответствия ограничениеям относительной ширины. Элементы COL должны учитываться только как подсказки, поэтому ширина столбцов не должна устанавливаться меньше минимальной. Аналогично, ширина столбцов не должна быть такой, чтобы таблица растягивалась за пределы окна. Если элемент COL задает относительную ширину, равную нулю, столбец всегда должен иметь минимальную ширину.
При использовании двухпроходного алгоритма компоновки положение выравнивания по умолчанию в отсутствие явного или унаследованного атрибута charoff может определяться путем выбора позиции, которая была бы центром строки, для которой ширина до и после выравнивающего символа являлись бы максимальными значениями для любой из строк в столбце, для которого align="этот символ". Для последовательной компоновки таблиц по умолчанию используется charoff="50%". Если несколько ячеек в разных строках одного столбца используют выравнивание, такие ячейки должны выстраиваться по умолчанию, независимо от того, какой символ используется для выравнивания. Правила обработки объектов, слишком больших для столбца, применяются, если явное или наследуемое выравнивание приводит к ситуации, когда данные превышают назначенную ширину столбца.
Выбор имен атрибутов. Предпочтительным является выбор значений атрибута frame, соответствующих атрибуту rules и значениям, используемым для выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, в SGML необходимо, чтобы нумерованные значения атрибутов были уникальными для каждого элемента, независимо от имени атрибута. Это сразу же вызывает проблемы со значениями "none", "left", "right" и "all". Значения атрибута frame выбраны так, чтобы избежать конфликтов имен с атрибутами rules, align и valign-COLGROUP. Это обеспечивает будущую гарантию, поскольку ожидается, что атрибуты frame и rules будут добавлены в другие элементы таблицы в будущих версиях данной спецификации. Альтернативой является способ сделать атрибут frame CDATA. Решением Рабочей группы HTML W3C явилось то, что преимущества возможности использования средств проверки корректности SGML для првоерки атрибутов на базе нумерованных значений превосходит необходимость соответствия имен.
Последовательное отображение документов, полученных по сети, представляет некоторые проблемы с формами. Агенты пользователей должны не позволять передачу форм до получения всех элементов формы.
Последовательно отображение документов приводит к некоторым проблемам относительно перемещения по клавише Tab. Эвристика перехода фокуса на tabindex с самым низким значением в документе на первый взгляд кажетя весьма логичной. Однако это подразумевает необходимость ожидания получения текста всего документа, поскольку до этого tabindex с самым низким значением может измениться. Если пользоваетль нажимает клвишу tab до этого, агентам пользоателя имеет смысл переместить фокус на низший доступный tabindex.
Если формы связаны с клиентскими скриптами, могут возникнуть дополнительные проблемы. Например, обработчик скрипта для данного поля может обращаться к полю, которого еще не существует.
В данной спецификации определяется набор элементов и атрибутов, достаточно мощный для представления основных форм. Однако возможности улучшения еще имеются. Например, в будущем можно попытаться решить следующие проблемы:
Другим возможным расширением будет добавление атрибута usemap для элемента INPUT для использования в клиентских навигационных картах, если "type=image". Элемент AREA, соответствующий местоположению щелчка, определяет передаваемое на сервер значение. Во избежание необходимости изменения серверных скриптов он может использоваться для расширения элемента AREA и указания значений x и y для использования в элементе INPUT.
В данной спецификации резервируется синтаксис для поддержки мкросов скриптов в атрибутах HTML CDATA. Это предназначено для того, чтобы сделать возможной установку атрибутов в зависимости от свойств объектов, находящихся на странице выше. Синтаксис:
attribute = "... &{ тело макроса }; ... "
Тело макроса состоит из одного или нескольких выражений в языке скрипта по умолчанию (как в атрибутах для внутренних событий). Точка с запятой, следующая за правой скобкой, всегда обязательна, в противном случае символ скобки "}" считается частью тела макроса. Не нужно и говорить, что кавычки для атрибутов, содержащих макросы скриптов, обязательны.
Обработка атрибутов CDATA происходит следующим образом:
Обработка макросов происходит при загрузке документа (или при перезагрузке), но не происходит при изменении размера документа, перерисовке и т.д.
ПРИМЕР НЕЖЕЛАТЕЛЬНОГО ИСПОЛЬЗОВАНИЯ:
Вот несколько примеров использования JavaScript. Первый устанавливает в документе случайный цвет фона:
<BODY bgcolor='&{randomrbg};'>
Вы можете установить более светлый фон в вечернее время:
<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="баннер">
С помощью скрипта можно устанавливать 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">
Поскольку униальность имени целевого фрейма не гарантирована, оно подходит для описания текущей практики поиска фрейма с данным целевым именем:
Примечание. Следующий алгоритм для генерации альтернативного текста может заменяться по рекомендации Инициативной группы по доступности Web W3C (W3C Web Accessibility Initiative Group). Подробнее см. [WAIGUIDE].
Если автор не установил атрибут alt для элемента IMG или APPLET, агенты пользователя должны сами задавать альтернативный текст, вычисляемый в следующем порядке:
Если автор не установил атрибут alt для элемента INPUT, агенты пользователяей должны вычислять альтернативный текст в следующем порядке:
Якоря, внедренные изображения и все прочие элементы, содержащие URI в качестве параметров, могут привести к разыменовыванию URI в ответ на ввод пользователя. В данном случае следует рассмотреть вопросы, описанные в [RFC1738], раздел 6. Широко используемые методы отправки запросов формы -- HTTP и SMTP - обеспечивают невысокую степень конфиденциальности. Провайдеры информации, запрашивающие через формы важную информацию - особенно с помощью элементов INPUT, type="password" - должны предупреждать своих пользователей о невыосокй степени защиты.
Агент пользователя не должен отправлять файлы, отправку которых пользователь не запросил явно. Таким образом, агенты пользователей HTML должны подтверждать все имена файлов, используемые по умочланию, которые могут быть указаны в атрибуте value элемента INPUT. В скриытых управляющих элементах имена файлов указываться не должны.
В данной спецификации не содержится механизма шифрования данных; оно должно проводиться любыми другими механизмами защищенной передачи данных.
После загрузки файла обрабатывающий агент должен соответствующим образом обработать и сохранить файл.