Приложение Б: Замечания о работе, реализации и разработке

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

B.1 Замечания о недопустимых документах

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

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

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

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

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

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

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

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

B.2.1 Символы, не входящие в набор ASCII, в значениях атрибутов URI

Хотя URI и не включают символы, не входящие в набор ASCII, (см. [URI], раздел 2.1) авторы иногда указывают их в значениях атрибутоах, в которых должны указываться URI (например, в атрибуты, определенные как %URI; в DTD). Например, следующее значение атрибута href недопустимо:

<A href="http://foo.org/Håkon">...</A>

Для обработки символов, не входящих в набор ASCII, в таких случаях агентам пользователей рекомендуется:

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

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

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

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

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

B.3 Замечания по реализации SGML

B.3.1 Разрывы строк

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

Следующие два примера кода HTML должны представляться одинаково:

<P>Паша смотрит телевизор.</P>

<P>
Паша смотрит телевизор.
</P>

Также одинаково должны представляться следующие два примера:

<A>Мой любимый сайт</A>

<A>
Мой любимый сайт
</A>

B.3.2 Указание данных не в формате HTML

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

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

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

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

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

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

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

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

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

• ’"’ должно записываться как "&quot;" или "&#34;"
• ’&’ должно записываться как "&amp;" или "&#38;"

 <INPUT name="num" value="0"
 onchange="if (compare(this.value, &quot;Справка&quot;)) {gethelp()}">

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

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

B.3.4 Логические атрибуты

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

<OPTION selected>

<OPTION selected="selected">

B.3.5 Отмеченные разделы

Отмеченные выбранные варианты играют роль, подобную конструкции #ifdef, распознаваемой препроцессором языка C.

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

<![IGNORE[
 <!-- это будет игнорироваться -->
]]>

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

<![CDATA[
 <an> пример разметки <sgml>, не вызывающий
 <проблем> при записи < и т.д.
]]>

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

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

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

<?инструкция >

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

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

B.3.7 Сокращенная разметка

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

конструкции SHORTTAG:

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="отпуск,Греция,солнце">
<META name="description" content="Идиллический отпуск в Европе">

Укажите начало набора

Наборы документов или представлений систем обработки текстов часто переводятся в наборы документов HTML. Для поисковых машин полезно указать ссылку на начало набора в дополнение к попаданию страницы в результаты поиска. Вы можете помочь поисковым машинам с помощью элемента LINK с атрибутом rel="begin" и TITLE, как показано в следующем примере:

 
<LINK rel="begin" 
         type="text/html"
         href="page1.html" 
         title="Общая теория относительности">

Предоставьте роботам инструкции по индексированию

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

B.4.1 Поисковые роботы

Файл robots.txt 

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

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

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

Робот просто найдет файл "/robots.txt" URI на Вашем сайте, где сайт - это сервер HTTP, работающий на определенной машине и порте. Вот некоторые примеры расположения файла 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 

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

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

B.5 Замечания о таблицах

B.5.1 Логическое обоснование дизайна

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

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

Если в атрибуте 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).

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

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

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

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

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

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

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

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

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

B.6 Замечания о формах

B.6.1 Последовательное отображение

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

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

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

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

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

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

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

B.7 Замечания о скриптах

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

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

   attribute = "... &{ тело макроса }; ... "

Практики макросов скриптов в настоящее время 

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

Обработка атрибутов CDATA происходит следующим образом:

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

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

    
<BODY bgcolor=’&{randomrbg};’>

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

    
<MAP NAME=foo>
   <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
 </MAP>

    
<img src="stat/html401/bar.gif" width=’&{document.banner.width/2};’ height=’50%’ alt="баннер">

 <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">

   
<img src="stat/html401/&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

B.8 Замечания о фреймах

Поскольку униальность имени целевого фрейма не гарантирована, оно подходит для описания текущей практики поиска фрейма с данным целевым именем:

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

B.9 Замечания о доступности

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

1. Если указан title, в качестве альтернативного текста должно использоваться значение этого атрибута.
2. В противном случае, если информация о заголовке дается в заголовках HTTP при загрузке включенного объекта, в качестве альтернативного текста должна использоваться эта информация.
3. В противном случае, если во включенном объекте имеются текстовые поля (например, изображения GIF имеют тектсовые поля), информация, извлеченная из текстовых полей, должна использоваться в качестве альтернативного текста. Поскольку агентам пользователей для извлечения текстовой инфомрации может понадобиться загрузка всего объекта, они могут использовать более экономичные подходы (например, обсуждение содержимого).
4. В противном случае, если отсутствует всякая другая информация, агент пользователя должен использовать в качестве альтернативного текста имя файла (без расширения).

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

1. Если указан title, в качестве альтернативного текста должно использоваться его значение.
2. В противном случае, если указан атрибут name, в качестве альтернативного текста должно использоваться его значение.
3. В противном случае (кнопки отправки и сброса) в качестве альтернативного текста должно использоваться значение атрибута type.

B.10 Замечания о защите

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

B.10.1 Вопросы защиты для форм

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

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

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