Элементы стиля шрифта: TT, I, B, BIG, SMALL, STRIKE, S и U
<!ENTITY % fontstyle "TT | I | B | BIG | SMALL"> <!ELEMENT (%fontstyle;|%phrase;) - - (%inline;)*> <!ATTLIST (%fontstyle;|%phrase;) %attrs; -- %coreattrs, %i18n, %events -- >
Начальный тег: необходим, Конечный тег: необходим
Атрибуты, определённые в другом месте
id, class (идентификаторы документа)
dir (направление текста)
title (название элемента)
style (инлайн-стиль)
onkeydown onkeyup (внутренние события)
Представление элементов стиля шрифта зависит от пользовательского агента (ПА). Следующее описание является лишь информативным.
TT: моноширинный текст, телетайп.
I: курсив.
B: полужирный.
BIG: "большой" шрифт.
SMALL: "малый" шрифт.
STRIKE и S: не рекомендуются, зачёркнутый текст.
U: не рекомендуется, подчёркнутый.
Вот несколько примеров определения шрифта:
<P><b>bold</b>, <i>italic</i>, <b><i>bold italic</i></b>, <tt>teletype text</tt>, and <big>big</big> and <small>small</small> text.
Это будет отображено так:
Можно применить более сложные варианты отображения шрифтов, используя таблицы стилей. Чтобы отобразить голубой курсив в параграфе с помощью таблицы стилей (CSS):
<HEAD> <STYLE type="text/css"> P#mypar {font-style: italic; color: blue} </STYLE> </HEAD> <P id="mypar">...голубой курсив...
Элементы стиля шрифта должны вкладываться соответствующим образом. Отображение вложенных элементов стиля шрифта зависит от ПА.
Элементы управления
Пользователь взаимодействует с формой посредством элементов управления.
Имя элемента управления (ЭУ), "control name", задаётся атрибутом
name. Областью видимости атрибута name
ЭУ внутри формы является элемент FORM.
Каждый ЭУ имеет начальное и текущее значение типа "символьная строка". См. определение каждого ЭУ для спецификации начальных значений и возможные ограничения значений, принимаемых ЭУ. В целом, "начальное значение\initial value" может быть установлено атрибутом
value ЭУ. Однако начальное значение ЭУ
TEXTAREA задаётся его содержимым, а начальное значение ЭУ OBJECT в форме определяется реализацией данного объекта (т.е. находится вне пределов данной спецификации).
"Текущее значение\current value"ЭУ вначале устанавливается в первоначальное значение. После этого текущее значение ЭУ можно изменять, взаимодействуя с пользователем, и с помощью скриптов (сценариев).
Начальное значение ЭУ не изменяется. Таким образом, при очистке формы текущее значение каждого ЭУ устанавливается в начальное значение.
Если ЭУ не имеет начального значения, воздействие очистки формы на данный ЭУ не определено.
При отправке формы на обработку, некоторые ЭУ образуют пары "имя/значение", которые затем пересылаются
с формой. ЭУ, чьи пары имя/значение высланы, называются "действующие ЭУ".
ЭУ " только для чтения"
Определение атрибута
readonly [CI] Если установлен, этот булев атрибут запрещает изменение ЭУ.
Атрибут readonly определяет, может ли ЭУ быть модифицирован пользователем.
Если установлен, атрибут readonly действует на элемент следующим образом:
ЭУ "только для чтения" может получить фокус, но не может быть модифицирован пользователем. ЭУ "только для чтения" включён в навигацию табуляцией. ЭУ "только для чтения" может быть "действующим".
Следующие ЭУ поддерживают атрибут readonly: INPUT
и TEXTAREA.
То, как ЭУ "только для чтения" отображаются, зависит от ПА.
Примечание. Единственная возможность изменить значение атрибута readonly динамически - использование скриптов.
Как читать Определение Типа Данных (ОТД) HTML
Каждое объявление элемента или атрибута в этой спецификации сопровождается соответствующим фрагментом определения типа документа. Мы решили включать фрагменты ОТД в спецификацию вместо того, чтобы использовать более подходящие, но и более длинные и менее точные способы описания свойств элемента.
Этот учебник должен помочь читателям, не знакомым с SGML, разобраться в ОТД и понять технические детали этой спецификации HTML.
Как установить альтернативный текст
Определение атрибута
alt = text [CS]
Для ПА, которые не могут выводить изображения, формы или аплеты, этот атрибут определяет альтернативный текст. Язык альтернативного текста определяется атрибутом lang.
Некоторые нетекстовые элементы (IMG, AREA,
APPLET и INPUT) позволяют авторам вводить альтернативный текст, служащий содержимым в тех случаях, когда элемент не может быть отображён нормально.
Установка альтернативного текста помогает пользователям без графических дисплеев, пользователям, чьи браузеры не поддерживают формы, пользователям с дефектами зрения, тем, кто использует голосовые синтезаторы, тем, кто настроил свои графические ПА так, чтобы не показывать изображения и т.д.
Атрибут alt должен быть определён для элементов IMG и AREA. Он не обязателен для элементов INPUT и APPLET.
Поскольку альтернативный текст может оказать существенную помощь, он должен быть определён очень тщательно. Авторы должны руководствоваться следующим:
Не определяйте не относящийся к делу альтернативный текст при включении изображений, предназначенных для форматирования
страницы, например, alt="red ball" не подойдёт для изображения, которое добавляет красные мячи для декорирования заголовка или параграфа. В этом случае альтернативный текст должен быть пустой строкой (""). В любом случае авторам не стоит использовать изображения для форматирования страниц. Вместо этого нужно использовать таблицы стилей.
Не указывайте бессмысленный альтернативный текст (напр., "пустой текст"). Это не только дезориентирует пользователей, но и замедляет работу ПА, которые должны конвертировать текст для речевого или брайль-вывода.
Разработчики должны просмотреть раздел о доступности для получения информации о том, как обрабатывать ситуации с отсутствием альтернативного текста.
Карты изображений
Карты изображений позволяют авторам специфицировать регионы/области изображения или объекта и назначать отдельное действие каждому региону (напр., запросить документ, запустить программу и т.п.). Если регион активируется пользователем, действие запускается на выполнение.
Карта изображений (image map) создаётся путём ассоциирования объекта со спецификацией сенситивного геометрического региона на объекте.
Существуют карты двух типов:
Клиентские\на стороне клиента (Client-side). Если пользователь активирует мышью регион клиентской карты, координаты щелчка (в пикселах) интерпретируются ПА. ПА выбирает ссылку, определённую для данного региона, и переходит по ней.
Серверные\На стороне сервера (Server-side). Если пользователь активирует мышью регион серверной карты, координаты щелчка (в пикселах) пересылаются на сервер агенту, определённому атрибутом href элемента A. Агент на сервере интерпретирует координаты и выполняет некоторое действие.
Клиентские карты изображений предпочтительнее,
нежели серверные по двум (как минимум) причинам: они доступны для людей, просматривающих документ в неграфических браузерах, и немедленно реагируют при перемещении указателя над активным регионом.
Каскадные таблицы стилей
Языки каскадных таблиц стилей, такие как CSS, разрешают объединять стилевую информацию из различных источников. Однако, не все языки таблиц стилей поддерживают каскадирование. Чтобы создать каскад, авторы определяют последовательность элементов LINK и/или STYLE. Стилевая информация каскадируется в том порядке, в котором элементы появляются в HEAD.
Примечание. Эта спецификация не определяет, как каскадируются таблицы стилей на другом языке таблиц стилей. Авторы должны исключить смешение языков таблиц стилей.
В следующем примере мы определяем две альтернативные таблицы стилей с названием "compact". Если пользователь выберет стиль "compact", ПА обязан применить обе внешние таблицы стилей, также как и постоянную таблицу стилей "common.css". Если пользователь выберет стиль "big print", только альтернативная таблица "bigprint.css" и постоянная "common.css" будут применены.
<LINK rel="alternate stylesheet" title="compact" href="small-base.css" type="text/css"> <LINK rel="alternate stylesheet" title="compact" href="small-extras.css" type="text/css"> <LINK rel="alternate stylesheet" title="big print" href="bigprint.css" type="text/css"> <LINK rel="stylesheet" href="common.css" type="text/css">
Пример каскада, который использует элементы
LINK и STYLE.
<LINK rel="stylesheet" href="corporate.css" type="text/css"> <LINK rel="stylesheet" href="techreport.css" type="text/css"> <STYLE type="text/css"> p.special { color: rgb(230, 100, 180) } </STYLE>
Каталог образцов SGML
Этот каталог содержит директиву override для того, чтобы удостовериться, что программа, такая как nsgmls, использует public-идентификаторы, а не системные. Это значит, что пользователи не должны быть соединены с Web при затребовании системных идентификаторов на базе URI.
OVERRIDE YES
PUBLIC "-//W3C//DTD HTML 4.01//EN" strict.dtd PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" loose.dtd PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" frameset.dtd PUBLIC "-//W3C//ENTITIES Latin1//EN//HTML" HTMLlat1.ent PUBLIC "-//W3C//ENTITIES Special//EN//HTML" HTMLspecial.ent PUBLIC "-//W3C//ENTITIES Symbols//EN//HTML" HTMLsymbol.ent
Категоризация ячеек
Пользователи, просматривающие таблицы с помощью речевого ПА, могут дополнительно пожелать услышать разъяснение о содержимом ячейки. Один из методов получить разъяснение состоит в прослушивании ассоциированной заголовочной информации перед прослушиванием содержимого ячеек данных (см. раздел ассоциирование заголовочной информации с ячейками данных).
Пользователей может также заинтересовать информация о более чем одной ячейке. В этом случае заголовочная информация, даваемая на уровне ячейки (атрибутами headers, scope и abbr), не может предоставить адекватный контекст. Рассмотрим таблицу, классифицирующую цены на еду, отели и транспорт в двух городах (Сан-Хосе и Сиэтл) за несколько дней:
Пользователю может понадобиться извлечь информацию из таблицы в форме запроса:
"What did I spend for all my meals?"
"What did I spend for meals on 25 August?"
"What did I spend for all expenses in San Jose?"
Каждый запрос вызывает вычисления ПА, в которых могут быть задействованы ноль или более ячеек. Чтобы определить, например, стоимость питания 25 августа, ПА должен знать, какая ячейка ссылается на "Meals" (все) и какая ссылается на "Dates" (конкретно, на 25 августа), и найти пересечение двух наборов (данных).
Чтобы приспособить этот тип запроса, табличная модель HTML 4 позволяет авторам разместить заголовки ячеек и данные по категориям. Например, по таблице цен на проезд автор мог бы сгруппировать заголовочные ячейки "San Jose" и "Seattle" в категорию "Location", заголовки "Meals", "Hotels" и "Transport" - в категорию "Expenses", а 4 дня в категорию "Date". Предыдущие три вопроса получат тогда следующие значения:
"What did I spend for all my meals?" означает "Каковы все ячейки данных в категории "Expenses=Meals"?
"What did I spend for meals on 25 August?" означает "Каковы все ячейки данных в категориях "Expenses=Meals" и "Date=Aug-25-1997"?
"What did I spend for all expenses in San Jose?" означает "Каковы все ячейки данных в категориях "Expenses=Meals, Hotels, Transport" и "Location=San Jose"?
Авторы категоризируют ячейки заголовков или данных установкой атрибута axis
для ячейки. К примеру, в таблице затрат на проезд, ячейка, содержащая информацию "San Jose" может быть помещена в категорию "Location" так:
<TH id="a6" axis="location">San Jose</TH>
любая ячейка, содержащая информацию со ссылкой на "San Jose", должна ссылаться на эту заголовочную ячейку через атрибуты headers или scope.
Таким образом, затраты на питание 25 августа должны быть помечены так, чтобы ссылаться на атрибут id
(значение которого - "a6") заголовочной ячейки "San Jose":
<TD headers="a6">37.74</TD>
Каждый атрибут headers предоставляет список ссылок на id. Авторы могут таким образом категоризировать данные ячейки любыми способами.
Ниже мы разметим таблицу затрат на путешествие с распределением информации по категориям:
<TABLE border="1" summary="This table summarizes travel expenses incurred during August trips to San Jose and Seattle"> <CAPTION> Travel Expense Report </CAPTION> <TR> <TH></TH> <TH id="a2" axis="expenses">Meals</TH> <TH id="a3" axis="expenses">Hotels</TH> <TH id="a4" axis="expenses">Transport</TH> <TD>subtotals</TD> </TR> <TR> <TH id="a6" axis="location">San Jose</TH> <TH></TH> <TH></TH> <TH></TH> <TD></TD> </TR> <TR> <TD id="a7" axis="date">25-Aug-97</TD> <TD headers="a6 a7 a2">37.74</TD> <TD headers="a6 a7 a3">112.00</TD> <TD headers="a6 a7 a4">45.00</TD> <TD></TD> </TR> <TR> <TD id="a8" axis="date">26-Aug-97</TD> <TD headers="a6 a8 a2">27.28</TD> <TD headers="a6 a8 a3">112.00</TD> <TD headers="a6 a8 a4">45.00</TD> <TD></TD> </TR> <TR> <TD>subtotals</TD> <TD>65.02</TD> <TD>224.00</TD> <TD>90.00</TD> <TD>379.02</TD> </TR> <TR> <TH id="a10" axis="location">Seattle</TH> <TH></TH> <TH></TH> <TH></TH> <TD></TD> </TR> <TR> <TD id="a11" axis="date">27-Aug-97</TD> <TD headers="a10 a11 a2">96.25</TD> <TD headers="a10 a11 a3">109.00</TD> <TD headers="a10 a11 a4">36.00</TD> <TD></TD> </TR> <TR> <TD id="a12" axis="date">28-Aug-97</TD> <TD headers="a10 a12 a2">35.00</TD> <TD headers="a10 a12 a3">109.00</TD> <TD headers="a10 a12 a4">36.00</TD> <TD></TD> </TR> <TR> <TD>subtotals</TD> <TD>131.25</TD> <TD>218.00</TD> <TD>72.00</TD> <TD>421.25</TD> </TR> <TR> <TH>Totals</TH> <TD>196.27</TD> <TD>442.00</TD> <TD>162.00</TD> <TD>800.27</TD> </TR> </TABLE>
Обратите внимание, что такая разметка таблицы позволяет также ПА исключить получение пользователем нежелательной информации. Например, если речевой синтезатор назвал бы все позиции в столбце "Meals" этой таблицы в ответ на запрос "What were all my meal expenses?", пользователь не смог бы отличить ежедневные затраты от общих. Внимательно категоризируя данные в ячейках, авторы позволяют ПА выполнить важное семантическое различение при выводе информации.
Конечно, нет никаких ограничений по категоризации информации таблицы. В таблице затрат на путешествие, например, мы могли бы добавить дополнительные категории "subtotals" и "totals".
Эта спецификация не требует от ПА обрабатывать информацию, предоставленную атрибутом axis, как и не даёт каких-либо рекомендаций, как ПА могут представлять пользователям информацию в axis
или как пользователи могут запрашивать ПА об этой информации.
Однако ПА, в особенности речевые синтезаторы, могут выносить за скобки информацию, обычную для некоторых ячеек, которые являются результатом выполнения запроса. Например, если пользователь спрашивает "What did I spend for meals in San Jose?", ПА мог бы сначала определить ячейки для вопроса (25-Aug-1997: 37.74, 26-Aug-1997:27.28), а затем отобразить эту информацию. Речевой ПА смог бы прочитать эту информацию:
Location: San Jose. Date: 25-Aug-1997. Expenses, Meals: 37.74 Location: San Jose. Date: 26-Aug-1997. Expenses, Meals: 27.28
или более компактно:
San Jose, 25-Aug-1997, Meals: 37.74 San Jose, 26-Aug-1997, Meals: 27.28
И даже более экономно - можно было бы убрать общую информацию и реорганизовать её:
San Jose, Meals, 25-Aug-1997: 37.74 26-Aug-1997: 27.28
ПА, поддерживающие такой тип представления, должны иметь способность настраивать представление (напр., с помощью таблиц стилей).
Кавычки: элементы BLOCKQUOTE и Q
<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- полная форма ("закавычивания") --> <!ATTLIST BLOCKQUOTE %attrs; -- %coreattrs, %i18n, %events -- cite %URI; #ПРЕДПОЛАГАЕТСЯ -- URI документа-источника или msg -- > <!ELEMENT Q - - (%inline;)* -- сокращённая инлайн-форма ("закавычивания") --> <!ATTLIST Q %attrs; -- %coreattrs, %i18n, %events -- cite %URI; #ПРЕДПОЛАГАЕТСЯ -- URI документа-источника или msg -- >
Начальный тег: необходим, Конечный тег: необходим
Определение атрибута
cite = uri [CT]
Значением этого атрибута является URI, обозначающий источник документа или сообщения. Этот атрибут предназначается для сообщения информации о источнике, из которого заимствованы кавычки.
Атрибуты, определённые в другом месте
id, class (идентификаторы документа)
lang (язык), dir (направление текста)
title (название элемента)
style (инлайн стиль )
onkeydown, onkeyup (внутренние события )
Эти два элемента обозначают текст в кавычках.
BLOCKQUOTE предназначен для полной формы (содержимое уровня блока), а Q - для краткой формы (инлайн содержимое), которая не требует разрывов параграфов.
Это пример форматирует отрывок из "The Two Towers", J.R.R. Tolkien, блок в кавычках.
<BLOCKQUOTE cite="http://www.mycom.com/tolkien/twotowers.html"> <P>They went in single file, running like hounds on a strong scent, and an eager light was in their eyes. Nearly due west the broad swath of the marching Orcs tramped its ugly slot; the sweet grass of Rohan had been bruised and blackened as they passed.</P> </BLOCKQUOTE>
Клавиши быстрого доступа
Определение атрибута
accesskey = символ/character [CN] Устанавливает клавишу быстрого доступа к элементу. Клавиша доступа - это одиночный символ из набора символов документа.
Примечание. Автор должен учитывать при определении клавиш доступа метод ввода, применяемый предполагаемым пользователем.
Нажатие клавиши доступа, назначенной элементу, передаёт фокус этому элементу. Действие после получения фокуса зависит от элемента. Например, если пользователь активизирует гиперссылку, определённую элементом A, ПА обычно переходит по ссылке. Если пользователь активизирует radio-кнопку, ПА изменяет значение radio-кнопки. Если пользователь активирует поле text, оно становится доступным для ввода и т.д.
Следующие элементы поддерживают атрибут accesskey: A, AREA, BUTTON, INPUT, LABEL, LEGEND
и TEXTAREA.
В следующем примере клавиша "U" устанавливается для лэйбла, ассоциированного с ЭУ INPUT. Нажатие клавиши доступа передаёт фокус лэйблу, который, в свою очередь, передаёт его ассоциированному ЭУ. Пользователь может вводить текст в поле INPUT.
<FORM action="..." method="post"> <P> <LABEL for="fuser" accesskey="U"> User Name </LABEL> <INPUT type="text" name="user" id="fuser"> </P> </FORM>
В следующем примере мы устанавливаем клавишу доступа гиперссылке, определённой элементом A. Нажатие клавиши переводит пользователя к другому документу, в данном случае - к оглавлению.
<P><A accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> Table of Contents</A>
Вызов быстрых клавиш зависит от операционной системы. Например, на машинах с MS Windows обычно нужно нажимать "alt" одновременно с клавишей доступа. В системе Apple - "cmd" одновременно с клавишей доступа.
Отображение клавиш доступа зависит от ПА. Мы рекомендуем, чтобы авторы включали клавиши доступа в лэйблы. ПА должны рассматривать значение клавиш доступа так, чтобы подчеркнуть их значение и выделить из окружающего текста (например, подчёркиванием).
Клиентские карты изображений: элементы MAP и AREA
<!ELEMENT MAP - - ((%block;) | AREA)+ -- клиентская карта изображений --> <!ATTLIST MAP %attrs; -- %coreattrs, %i18n, %events -- name CDATA #НЕОБХОДИМ -- для ссылок usemap -- >
Начальный тег: необходим, Конечный тег: необходим
<!ELEMENT AREA - O EMPTY -- регион клиентской карты --> <!ATTLIST AREA %attrs; -- %coreattrs, %i18n, %events -- shape %Shape; rect -- управляет интерпретацией coords -- coords %Coords; #ПРЕДПОЛАГАЕТСЯ -- список разделённых запятыми размеров -- href %URI; #ПРЕДПОЛАГАЕТСЯ -- URI связанного ресурса -- nohref (nohref) #ПРЕДПОЛАГАЕТСЯ -- этот регион не имеет action -- alt %Text; #НЕОБХОДИМ -- краткое описание -- tabindex NUMBER #ПРЕДПОЛАГАЕТСЯ -- позиция в порядке табуляции -- accesskey %Character; #ПРЕДПОЛАГАЕТСЯ -- символ быстрого доступа -- onfocus %Script; #ПРЕДПОЛАГАЕТСЯ -- элемент получил фокус -- onblur %Script; #ПРЕДПОЛАГАЕТСЯ -- элемент потерял фокус -- >
Начальный тег: необходим, Конечный тег: запрещён
Определения атрибутов элемента MAP
name = cdata [CI]
Назначает имя карте изображений, определённой элементом MAP.
Определения атрибутов элемента AREA
shape =
[CI]
Этот атрибут определяет границы региона. Возможные значения:
default: весь регион;
rect: прямоугольный регион;
circle: круглый регион;
poly: многоугольный регион.
coords =
coordinates [CN]
Определяет позицию на экране и очертания. Количество и порядок значений зависят от определяемой фигуры. Возможные сочетания:
rect: left-x, top-y, right-x, bottom-y.
circle: center-x, center-y, radius.
Примечание. Если значение radius - в процентах, ПА должны вычислять окончательное значение радиуса на базе ширины и высоты ассоциированного объекта. Значение радиуса должно быть меньше 2.
poly: x1, y1, x2, y2, ..., xN, yN. Первая пара координат x и y и последняя должны бить одинаковыми, чтобы "закрыть" многоугольник. Если эти значения не одинаковы, ПА должен вычислить дополнительную пару координат, чтобы закрыть многоугольник.
Координаты относительны к верхнему левому углу объекта. Все значения являются размерами. Все значения разделены запятыми.
nohref [CI]
Если установлен этот булев атрибут, то он указывает, что регион не имеет ассоциированной гиперссылки.
Атрибут для ассоциирования карты с элементом
usemap = uri [CT]
Ассоциирует карту с элементом. Карта изображений определяется элементом MAP. Значение usemap должно совпадать со значением атрибута name ассоциированного элемента MAP.
Атрибуты, определённые в другом месте
id, class (идентификаторы документа)
lang (язык), dir (направление текста)
title (заголовок элемента)
style (инлайн-стиль)
name (отправка объектов с формой)
alt (альтернативный текст)
href (ссылка-якорь)
target (целевой фрэйм)
tabindex (навигация табуляцией)
accesskey (символ быстрого доступа)
shape (карты изображений)
onclick, ondblclick,
onmousedown, onmouseup,
onmouseover, onmousemove,
onmouseout, onkeypress,
onkeydown, onkeyup,
onfocus, onblur (внутренние события)
Элемент
MAP определяет клиентскую карту (или другой механизм навигации), который может быть ассоциирован с другими элементами (IMG,
OBJECT или INPUT). Карта ассоциируется с элементом посредством атрибута
usemap. Элемент MAP
может использоваться без ассоциированного изображения для механизмов общей навигации.
Наличие атрибута usemap в элементе OBJECT
подразумевает, что включаемый объект - это изображение. Кроме того, если элемент OBJECT
имеет ассоциированную клиентскую карту, ПА могут выполнять взаимодействие с пользователем через OBJECT, только в понятиях клиентской карты. Это позволяет ПА (таким как аудиобраузер или робот) взаимодействовать с OBJECT без его выполнения (прогона); ПА может даже избрать вариант - не запрашивать (или не исполнять) объект. Если OBJECT
имеет ассоциированную карту изображений, авторы не могут рассчитывать, что объект будет запрошен или выполнен любым ПА.
Модель содержимого элемента
MAP позволяет авторам комбинировать:
Один или более элементов AREA. Эти элементы не имеют содержимого, но определяют геометрические регионы карты изображений и гиперссылки, ассоциированные с каждым регионом. Заметьте, что ПА обычно не отображают элементы AREA. Поэтому авторы должны предоставлять альтернативный текст для каждого AREA
в атрибуте alt (см. ниже как определить альтернативный текст).
Содержимое уровня блока. Это содержимое должно включать элементы A, которые специфицируют геометрические регионы карты и ссылки, ассоциированные с каждым регионом. Обратите внимание, что ПА должен отображать содержимое уровня блока элемента MAP. Авторы должны использовать этот метод для создания более доступных документов.
Если элемент MAP имеет смешанное содержимое (элементов AREA
и содержимое уровня блока), ПА должны игнорировать элементы AREA.
Авторы должны специфицировать геометрию карты изображений полностью элементами AREA, полностью элементами A или полностью теми и другими, если содержимое смешанное. Авторы могут смешивать содержимое так, чтобы старые ПА обрабатывали очертания карт, определённые элементами
AREA, а новые ПА использовали преимущества содержимого уровня блоков.
Если два или более регионов перекрываются, элемент, определяющий регион, который появился раньше в документе, имеет приоритет (напр., ответить на ввод пользователя).
ПА и авторы должны предоставлять текстовую альтернативу графической карте для тех случаев, когда графика недоступна или пользователь не может её получить. Например, ПА могут использовать текст из alt для создания текстовых ссылок вместо графической карты изображений. Такие ссылки могут быть активированы разными способами (с клавиатуры, голосом и т.д.).
Примечание.
MAP не имеет обратной совместимости с ПА HTML 2.0.
Кодировка
Атрибуты "charset" (%Charset в ОТД) ссылаются на кодировку символов, как описано в разделе кодировка символов. Значения должны быть строками (напр., "euc-jp") из регистра IANA (см. полный список в [CHARSETS]).
Наименования кодировки символов нечувствительны к регистру.
Пользовательские агенты (ПА) должны осуществлять серию шагов, предусмотренных в разделе определения кодировки символов, чтобы определить характер кодировки внешнего ресурса.
Кодовая страница документа
С целью улучшения взаимодействия, SGML требует, чтобы каждое приложение (приложение HTML - в том числе) специфицировало свой набор символов. Набор символов (кодовая страница) состоит из:
"Репертуара": набора абстрактных символов, таких как латинская буква "A", русская буква "И", китайские "водяные знаки" и т.д.Позиции символа: набора цифровых ссылок на символы в "репертуаре".
Каждый документ SGML (включая каждый документ HTML) - это последовательность символов из "репертуара". Операционная система компьютера идентифицирует каждый символ по его кодовой позиции. Например, в наборе символов ASCII кодовые позиции 65, 66 и 67 ссылаются на символы 'A', 'B' и 'C' соответственно.
Набор символов ASCII недостаточен для глобальных информационных систем, таких как Web, поэтому HTML использует более полный набор символов, называемый Universal Character Set (UCS)/Универсальный Набор символов,
определённый в документе [ISO10646]. Этот стандарт определяет репертуары тысяч наборов символов, используемых во всём мире.
Набор символов, определённый в [ISO10646], это символ-символ эквивалент Юникода ([UNICODE]). Оба этих стандарта время от времени дополняются новыми символами, и по этим поправкам нужно постоянно консультироваться на соответствующих Web-сайтах. В текущей спецификации ISO10646 использован для определения набора символов, в то время как UNICODEзарезервирован для ссылок на двунаправленный текстовый алгоритм.
Одного набора символов, однако, недостаточно для того, чтобы браузеры пользователя могли корректно интерпретировать документы HTML, так как они обычно кодируются как последовательность байтов в файле во время передачи по сети. Браузер пользователя должен также "знать" специфическую кодировку, используемую для трансформации документа в поток байтов.
Кодовые страницы
То, что в этой спецификации называется кодировкой символов, известно под различными названиями в других спецификациях (что может иногда смущать). Однако общее понимание - одно во всей сети Internet.
Заголовки протоколов (protocol headers), атрибуты и параметры, относящиеся к кодировке символов, используют один термин - "charset" и одни и те же значения из регистрации
[IANA] (смотри полный список в [CHARSETS]).
Параметр "charset" идентифицирует кодировку символов, которая представляет собой метод конвертации последовательности байтов в последовательность символов. Эта конвертация соответствует, по своей природе, схеме деятельности Web: серверы посылают документы HTML браузерам пользователей как поток байтов, браузеры пользователей интерпретируют его в последовательность символов.
Методы конвертации варьируются от простых один-за-другим до сложных схем переключения и алгоритмов.
Простая техника кодирования, один-байт-один-символ, недостаточна для использования символов, не входящих в "репертуар" [ISO10646]. Есть несколько различных кодировок, начиная с частичных кодировок с использованием [ISO10646], и до кодировок полного набора символов (как UCS-4).
Коды языка
Значением атрибута lang является код языка, идентифицирующий язык, используемый людьми для разговора, письма и других видов общения. Компьютерные языки исключены из кодов языка.
[RFC1766] определяет и разъясняет коды языка, которые должны использоваться в документах HTML.
Если говорить кратко, коды языка состоят из первичного кода и, возможно пустых, серий субкодов:
language-code = primary-code ( "-" subcode )*
Вот примеры кодов некоторых языков:
"en": английский,
"en-US": американский английский,
"en-cockney": Cockney-версия английского,
"i-navajo": навахо,
"x-klingon": тег "x" обозначает экспериментальный тег языка.
Двухсимвольные первичные коды зарезервированы для аббревиатур [ISO639].
Двухсимвольные коды включают fr (французский), de (немецкий), it (итальянский), nl (фламандский), el (греческий), es (испанский), pt (португальский), ar (арабский), he (еврейский), ru (русский), zh (китайский), ja (японский), hi (хинди), ur (урду) и sa (санскрит).
Любые двухбуквенный субкод понимается как код страны в [ISO3166].
Значение атрибута, чей тип - код языка (
%LanguageCode в ОТД), ссылается на код языка, специфицированный в [RFC1766], раздел 2.
О том, как специфицировать код языка в HTML, см. в разделе коды языка. Пробелы внутри кода языка недопустимы.
Коды языка нечувствительны к регистру.
Комментарии в ОТД
Комментарии в ОТД могут быть одно- или многострочными. Комментарии в ОТД это текст, ограниченный парами знаков "--", например:
<!ELEMENT PARAM - O EMPTY -- именованное значение свойства -->
Данный комментарий "именованное значение свойства" поясняет использование типа элемента PARAM. Комментарии в ОТД носят исключительно информативный характер.
Конструкции SGML, используемые в HTML
Следующие разделы посвящены конструкциям SGML, используемым в HTML.
В приложении описаны некоторые возможности SGML, которые не поддерживаются широко утилитами HTML и пользовательскими агентами (ПА), и использование которых должно быть исключено.
Краткая история HTML
HTML был первоначально разработан Tim Berners-Lee как CERN и популяризован браузером Mosaic, разработанным NCSA. В течение 90х гг. он буквально расцвёл в связи с бурным развитием Web. В это время HTML развивался разными путями. Web зависит от соглашений между создателями документов и провайдерами услуг. Это является причиной совместной работы над HTML.
HTML 2.0 (ноябрь 1995, см. [RFC1866]) был создан под эгидой Internet Engineering Task Force (IETF) для кодирования в конце 1994 г.. HTML+ (1993) и HTML 3.0 (1995, см. [HTML30]) представляли собой более "навороченные" версии HTML. Несмотря на то, что консенсус никогда не достижим в дискуссиях о стандартах, эти проекты вели к обобщению большого объёма новых возможностей. Усилия World Wide Web Consortium's HTML Working Group по кодификации практических наработок в 1996 г. выразились в появлении HTML 3.2 (январь 1997, см. [HTML32]). Изменения, сделанные в HTML 3.2 суммированы Приложении A.
Большинство было согласно с тем, что документы HTML должны хорошо работать на различных платформах и в различных браузерах. Достижение универсальности уменьшает затраты провайдеров, поскольку они должны создавать документы одной версии языка. Если это не будет сделано, увеличится риск того, что Web будет развиваться во множестве несовместимых форматов, уменьшая коммерческий потенциал Web для всех участников.
Каждая версия HTML пытается добиться большего согласия среди участников этой игры так, чтобы затраты, сделанные провайдерами информации, не оказались бесполезными и чтобы их документы не стали через короткое время "нечитабельными".
HTML был разработан в расчёте на то, что все виды устройств смогут получить информацию на Web: PC графическими дисплеями различного разрешения и глубины цвета, сотовыми телефонами, переносными устройствами, разговорными устройствами, компьютерами с высокой и низкой тактовой частотой и так далее.
Лэйблы
Некоторые ЭУ автоматически содержат лэйблы, ассоциированные с ними (кнопки), а другие - нет (поля ввода текста, переключатели, radio-кнопки и меню).
Для ЭУ, имеющих встроенные лэйблы, ПА должны использовать значения атрибута value как строку лэйбла.
Элемент LABEL используется для определения лэйблов в ЭУ, не имеющих встроенных лэйблов.
Локальное объявление языка скриптов
Атрибут type должен быть определён для каждого элемента SCRIPT в документе. Значение атрибута type элемента SCRIPT переопределяет язык скриптов по умолчанию для данного элемента.
В это примере мы объявляем язык скриптов по умолчанию "text/tcl". Мы включаем один SCRIPT в "шапку", чей скрипт находится во внешнем файле и написан на языке "text/vbscript". Мы также включили SCRIPT
в тело документа, который сам содержит собственный скрипт, написанный на "text/javascript".
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>A document with SCRIPT</TITLE> <META http-equiv="Content-Script-Type" content="text/tcl"> <SCRIPT type="text/vbscript" src="http://someplace.com/progs/vbcalc"> </SCRIPT> </HEAD> <BODY> <SCRIPT type="text/javascript"> ...сценарий JavaScript...
</SCRIPT> </BODY> </HTML>
Маркировка изменений документа: элементы INS и DEL
<!-- INS/DEL обрабатываются при включении в BODY --> <!ELEMENT (INS|DEL) - - (%flow;)* -- вставленный текст, удалённый текст --> <!ATTLIST (INS|DEL) %attrs; -- %coreattrs, %i18n, %events -- cite %URI; #ПРЕДПОЛАГАЕТСЯ -- информация о причинах изменений -- datetime %Datetime; #ПРЕДПОЛАГАЕТСЯ -- дата и время изменения -- >
Начальный тег: необходим, Конечный тег: необходим
Определения атрибутов
cite = uri [CT]
Значением данного атрибута является URI, указывающий на документ или сообщение-источник. Предполагается, что этот атрибут указывает на информацию, объясняющую, почему документ был изменён.
datetime = datetime [CS]
Определяет дату и время изменения документа.
Атрибуты, определённые в другом месте
id, class (идентификаторы документа)
lang (язык), dir (направление текста)
title (название элемента)
style (инлайн стиль )
onkeydown, onkeyup (внутренние события )
INS и DEL используются для маркировки разделов документа, которые были вставлены или удалены для сравнения с другими версиями документа (например, в проектах законов, где законодателям необходимо просматривать изменения).
Эти два элемента необычны для HTML тем, что могут обрабатывать элементы уровня блока или инлайн-элементы (но не те и другие вместе). Они могут содержать одно или более слов в параграфе или один или более элемент уровня блока, такой как параграфы, списки или таблицы.
Этот пример мог бы быть из билля, изменяющего закон о том, что округ Sheriff может теперь выбирать не 3, а 5 депутатов.
<P> A Sheriff can employ <DEL>3</DEL><INS>5</INS> deputies. </P>
INS и DEL не должны иметь содержимого уровня блока, если эти элементы действуют как инлайн-элементы.
НЕВЕРНОЕ ИСПОЛЬЗОВАНИЕ:
<P> <INS><DIV>...содержимое уровня блока...</DIV></INS> </P>
ПА должны отображать вставленный и удалённый текст так, чтобы это было заметно. К примеру, вставленный текст может быть выделен другим шрифтом, удалённый текст может вообще не выводиться или выводиться как перечёркнутый или со специальной маркировкой и т.д.
Оба следующих примера относятся к 5 ноября 1994 г., 8:15: 30 утра, US Eastern Standard Time.
1994-11-05T13:15:30Z 1994-11-05T08:15:30-05:00
С использованием INS
это выглядит так:
<INS datetime="1994-11-05T08:15:30-05:00" cite="http://www.foo.org/mydoc/comments.html"> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </INS>
Документ "http://www.foo.org/mydoc/comments.html" будет содержать комментарии о том, почему информация была вставлена в документ.
Авторы могут также вводить комментарии во вставленном и удалённом тексте и в значениях атрибута title элементов INS и DEL. ПА могут показывать эту информацию пользователю (как всплывающие подсказки). Например:
<INS datetime="1994-11-05T08:15:30-05:00" title="Changed as a result of Steve B's comments in meeting."> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </INS>
Media-зависимые каскады
Каскад может включать таблицы стилей, применяемые для разных типов носителя. И LINK, и STYLE могут использоваться с атрибутом media. ПА в этом случае отвечает за фильтрацию тех таблиц, которые не применяются для текущего носителя.
В следующем примере мы определяем каскад, где таблица "corporate" даётся в нескольких версиях: одна для печати, другая для экрана и третья для речевых браузеров (используемая, как говорят, при чтении email в автомобиле). Таблица "techreport" применима ко всем носителям. Правило цвета, определённое элементом
STYLE, используется для печати и экрана, но не для речевого представления.
<LINK rel="stylesheet" media="aural" href="corporate-aural.css" type="text/css"> <LINK rel="stylesheet" media="screen" href="corporate-screen.css" type="text/css"> <LINK rel="stylesheet" media="print" href="corporate-print.css" type="text/css"> <LINK rel="stylesheet" href="techreport.css" type="text/css"> <STYLE media="screen, print" type="text/css"> p.special { color: rgb(230, 100, 180) } </STYLE>
META и информация по умолчанию
META может использоваться для спецификации информации по умолчанию для следующих объектов документа:
язык скриптов по умолчанию;
язык таблиц стилей по умолчанию;
набор символов документа.
В следующем примере определён набор символов документа - ISO-8859-5:
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-5">
META и машины поиска
Обычно META специфицирует ключевые слова, которые используются поисковыми машинами для повышения качества и скорости поиска. Если несколько элементов META предоставляют информацию, связанную с языком документа, поисковые машины могут осуществлять фильтрацию на основе атрибута lang для отображения результата поиска с использованием языковых установок пользователя. Например,
<-- Для говорящих на американском английском --> <META name="keywords" lang="en-us" content="vacation, Greece, sunshine"> <-- Для говорящих на британском английском --> <META name="keywords" lang="en" content="holiday, Greece, sunshine"> <-- Для говорящих на французском --> <META name="keywords" lang="fr" content="vacances, Grèce, soleil">
Эффективность работы поисковой машины может также быть повышена за счёт использования элемента LINK
для установки ссылок на версии документа на других языках, ссылок на версии документа на других носителях (напр., PDF), и, если документ является частью коллекции, ссылок на подходящую стартовую точку для начала просмотра коллекции.
См. дополнительно раздел помощь машинам поиска в индексации Вашего Web-сайта.
META и PICS
Platform for Internet Content Selection/Платформа для Выбора Содержимого Internet (PICS, специфицированная в [PICS]) это инфраструктура для ассоциирования лэйблов (метаданных) с содержимым Internet. Созданная первоначально как помощь родителям и педагогам для контроля за тем, к чему дети могут получить доступ в Internet, она также даёт возможность использовать лэйблы для пометок кода, политики безопасности и обслуживания прав интеллектуальной собственности.
Этот пример иллюстрирует, как можно использовать объявление META для включения лэйбла PICS 1.1:
<HEAD> <META http-equiv="PICS-Label" content=' (PICS-1.1 "http://www.gcf.org/v2.5" labels on "1994.11.05T08:15-0500" until "1995.12.31T23:59-0000" for "http://w3.org/PICS/Overview.html" ratings (suds 0.5 density 0 color/hue 1)) '> <TITLE>... заголовок документа ...</TITLE> </HEAD>
META и "шапки" HTTP
Атрибут http-equiv может использоваться вместо атрибута name имеет специальное значение при возврате документов по протоколу Hypertext Transfer Protocol (HTTP). HTTP серверы могут использовать имя свойства, специфицированное атрибутом
http-equiv, для создания "шапки" в стиле [RFC822] для ответа HTTP. См. спецификацию HTTP ([RFC2616]) о правильных "шапках" HTTP.
Следующая выдержка из объявления META:
<META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">
даст в результате "шапку" HTTP:
Expires: Tue, 20 Aug 1996 14:25:27 GMT
Это может использоваться при кэшировании для определения того, когда вызывать свежую копию ассоциированного документа.
Примечание. Некоторые ПА поддерживают использование META для обновления текущей страницы по истечении определённого количества секунд с возможностью замены её другим URI. Авторы
не должны использовать этот метод перевода пользователя на другую страницу, поскольку это делает страницу недоступной для некоторых пользователей. Вместо этого, автоматическое перенаправление страницы должно осуществляться с использованием серверного перенаправления.
Метаданные
Примечание. The W3C Resource Description Framework (Структура Описания Ресурса) (см. [RDF10]) стал W3C Recommendation в феврале 1999 года. RDF даёт авторам возможность специфицировать читаемые машиной метаданные о документах HTML и других ресурсах, доступных в сети.
HTML позволяет авторам специфицировать метаданные - информацию о самом документе, а не о его содержимом - различными способами.
Например, чтобы специфицировать автора документа, можно использовать элемент META:
<META name="Author" content="Dave Raggett">
META определил свойство (здесь - "Author") и установил ему значение (здесь - "Dave Raggett").
Эта спецификация не определяет набор действительных свойств метаданных. Значение свойства и набор действительных значений для этого свойства должны быть определены в справочном словаре, называемом профиль. Например, профиль, созданный для помощи поисковым машинам при индексировании документов, может определять свойства, такие как "author", "copyright", "keywords" и т.д.
Метод отправки формы
Атрибут method элемента FORM определяет метод HTTP, используемый для отправки формы программе-обработчику. Этот атрибут может иметь два значения:
get: методом "get" HTTP набор данных формы
присоединяется к URI, определённому атрибутом action (со знаком "?" в качестве разделителя), и этот новый URI высылается программе-обработчику. post: методом "post" HTTP набор данных формы включается в тело формы и высылается программе-обработчику.
Метод "get" нужно использовать, если форма цельна (напр., не осуществляет побочных действий). Многие средства поиска в базах данных не имеют видимых побочных действий и являются идеальными приложениями для использования метода "get".
Если сервис, ассоциированный с обработчиком формы, имеет побочный эффект (например, если форма модифицирует базу данных или подписку на сервис), должен использоваться метод "post".
Примечание.
Метод "get" ограничивает набор данных формы символами ASCII. Только метод "post" (с enctype="multipart/form-data") специфицирован для использования с полным набором символов [ISO10646].
Мнемоники (символы по ссылке, по псевдониму)
Конкретная кодировка может не давать возможность отобразить все символы набора символов документа. Для таких кодировок, или если конфигурация "железа" или программного обеспечения не позволяют пользователю непосредственно вводить некоторые символы, авторы могут использовать SGML - ссылки на символы. Ссылки на символы - это механизм для ввода любых символов, не зависящий от кодового набора документа.
Ссылки на символ (мнемоники) могут быть двух видов:
Цифровые мнемоники (десятеричные или шестнадцатеричные).Мнемоники из символьных элементов.
Мнемоники внутри комментариев не имеют специального значения: это только лишь данные комментариев.
Примечание. HTML предоставляет другие возможности для представления символьных данных, в особенности - встроенные изображения\inline images.
Примечание. В SGML возможно отсутствие конечного символа ";" после ссылки-мнемоники в некоторых случаях (например, перед line break или непосредственно перед тегом). В других условиях это символ не может быть опущен (например, в середине слова). Мы настоятельно советуем использовать ";" во всех случаях, чтобы исключить проблемы с браузерами пользователей.
Multipart/form-data
Примечание. См. в [RFC2388] информацию о подгрузке файлов, включая проблемы обратной совместимости, взаимоотношения между "multipart/form-data" и другими типами содержимого, вопросы функционирования и т.д.
Пожалуйста прочтите дополнительно о проблемах безопасности в формах.
Типа содержимого "application/x-www-form-urlencoded" недостаточно для пересылки данных большого объёма данных бинарного типа или текста, содержащего не-ASCII символы. Тип содержимого "multipart/form-data" должен использоваться для отправки форм, содержащих файлы, не-ASCII данные и бинарные данные.
Содержимое "multipart/form-data" следует правилам всех составных MIME-данных, как описано в [RFC2045]. Определение "multipart/form-data" можно найти в регистре [IANA].
Сообщение "multipart/form-data" содержит несколько частей, каждая из которых представляет "действующий" ЭУ. Эти части пересылаются обработчику в том же порядке, в каком соответствующие ЭУ появляются в потоке документа. Границы частей не должны появляться внутри каких-либо данных; то, как это достигается, находится за рамками данной спецификации.
Как и все многочастные типы MIME, каждая часть может иметь заголовок "Content-Type", который по умолчанию содержит "text/plain". ПА должны предоставлять заголовок "Content-Type" вместе с параметром "charset".
Каждая часть должна содержать:
заголовок "Content-Disposition", значением которого является "form-data". атрибут имя, определяющий имя соответствующего ЭУ. Имена ЭУ, кодированные в оригинале в не-ASCII наборе символов, могут быть кодированы с использованием метода, описанного в [RFC2045].
Таким образом, для ЭУ с именем "mycontrol", соответствующая часть будет определена:
Content-Disposition: form-data; name="mycontrol"
Как и в других передачах MIME, "CR LF" (т.е., `%0D%0A') используется для разделения строк данных.
Каждая часть может кодироваться, и заголовок "Content-Transfer-Encoding" предоставляется, если значение этой части не соответствует кодировке по умолчанию(7BIT) (см. [RFC2045], раздел 6)
Если содержимое файла отправляется с формой, ввод файла должен идентифицироваться соответствующим типом содержимого (напр., "application/octet-stream"). Если несколько файлов возвращено как результат единого ввода формы, они должны быть возвращены как "multipart/mixed", внедрённые в "multipart/form-data".
ПА должен попытаться предоставить имя для каждого пересылаемого файла. Имя файла может быть определено параметром "filename" в заголовке 'Content-Disposition: form-data' или, в случае с нескольким файлами, заголовком 'Content-Disposition: file' подраздела. Если имя файла клиентской операционной системы не-US-ASCII, имя файла может быть приближено или кодировано с использованием метода [RFC2045]. Это подходит для всех тех случаев, когда, например, подгруженные файлы могут содержать ссылку друг на друга (напр., TeX файл и его ".sty" - дополнительное описание стиля).
Следующий пример иллюстрирует кодирование "multipart/form-data". Предположим, у нас есть такая форма:
<FORM action="http://server.com/cgi/handle" enctype="multipart/form-data" method="post"> <P> Как Вас зовут? <INPUT type="text" name="submit-name"><BR> Какие файлы Вы послали? <INPUT type="file" name="files"><BR> <INPUT type="submit" value="Send"> <INPUT type="reset"> </FORM>
Если пользователь вводит "Larry" в окне ввода текста и выделяет текстовый файл "file1.txt", ПА должен выслать обратно следующие данные:
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x Content-Disposition: form-data; name="submit-name"
Larry --AaB03x Content-Disposition: form-data; name="files"; filename="file1.txt" Content-Type: text/plain
... содержимое файла file1.txt ... --AaB03x--
Если пользователь выделит второй (image) файл "file2.gif", ПА может создать части так:
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x Content-Disposition: form-data; name="submit-name"
Larry --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y
--BbC04y Content-Disposition: file; filename="file1.txt" Content-Type: text/plain
... содержимое файла file1.txt ... --BbC04y Content-Disposition: file; filename="file2.gif" Content-Type: image/gif Content-Transfer-Encoding: binary
...содержимое файла file2.gif... --BbC04y-- --AaB03x--
предыдущий следующий содержание элементы атрибуты индекс
Направление в таблице
Направление в таблице или наследуется прямо (по умолчанию слева-направо), или определяется атрибутом dir элемента TABLE.
Для таблиц с направлением слева-направо нулевой столбец - самый левый, а нулевой ряд - самый верхний. Для таблиц с направлением справа-налево нулевой столбец - самый правый, а нулевой ряд - самый верхний.
Когда ПА добавляет дополнительные ячейки в ряд (см. раздел подсчёт количества столбцов таблицы), новые ячейки в ряду добавляются справа для таблиц с направлением слева-направо и слева - для таблиц с направлением справа-налево.
Обратите внимание, что TABLE это единственный элемент, в котором dir
резервирует визуальный порядок столбцов; отдельный ряд (TR)ил группа столбцов (COLGROUP) не могут быть независимо зарезервированы.
При установке для элемента TABLE, атрибут dir также влияет на направление текста внутри ячеек таблицы (поскольку атрибут dir наследуется элементами уровня блока).
Для определения таблицы с направлением справа-налево, установите атрибут dir так:
<TABLE dir="RTL"> ...таблица...
</TABLE>
Направление текста в конкретной ячейке может быть изменено установкой атрибута dir
в том элементе, который определяет ячейку. См. раздел двунаправленный текст.
Наследование и каскадирование
Если ПА хочет отобразить документ, ему нужно найти значения для свойств стиля, например, семейство шрифтов, стиль шрифта, размер, высота строки, цвет текста и так далее. Точный механизм зависит от языка таблиц стилей, но следующее описание в целом применимо:
Механизм каскадирования применяется, если несколько правил стиля применяются непосредственно к элементу. Этот механизм позволяет ПА сортировать правила по специфике, чтобы определить, какое правило применить. Если не найдено ни одного правила, следующий шаг зависит от того, может или нет наследоваться это свойство стиля. Не все свойства могут наследоваться. Для этих свойств язык таблиц стиля предоставляет значения по умолчанию для того, чтобы использовать их при отсутствии явных правил для конкретного элемента.
Если свойство может наследоваться, ПА проверяет непосредственно включаемые элементы, чтобы убедиться, применимо ли к ним правило. Этот процесс продолжается до тех пор, пока ПА находит применимые правила. Этот механизм позволяет компактно специфицировать таблицы стилей. К примеру, авторы могут определить семейство шрифтов для всех элементов внутри
BODY одним правилом, которое применяется к элементу
BODY.
Наследование информации о направлении текста
Двунаправленный алгоритм Unicode требует наличия базового направления для текстовых блоков. Чтобы определить базовое направление элементов на уровне блока, установите атрибут
dir в элементе. Значение атрибута dir
по умолчанию - "ltr" (left-to-right/слева-направо).
Если атрибут dir установлен для элементов уровня блока, он действует на период существования самого элемента и всех вложенных элементов уровня блока. Установка атрибута dir во вложенном элементе переопределяет наследованное значение.
Чтобы установить базовое направление текста для всего документа, установите атрибут dir
элемента HTML.
Например:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...заглавие справа-налево...</TITLE> </HEAD> ...текст справа-налево...
<P dir="ltr">...текст слева-направо...</P> <P>...снова текст справа-налево...</P> </HTML>
В то же время, инлайн-элементы не наследуют атрибут dir. Это значит, что инлайн-элемент без атрибута dir
не открывает дополнительный уровень в установке двунаправленного алгоритма. (Элемент рассматривается здесь как уровня инлайн или блока на основе его представления по умолчанию. Обратите внимание, что элементы INS и DEL
могут быть уровня блока или инлайн в зависимости от контекста.)
Наследование кодов языка
Элемент наследует информацию кода языка в следующем порядке (приоритет от высшего к низшему):
установлен атрибут lang
в самом элементе;
установлен атрибут lang ближайшего элемента-предка (т.е. атрибут lang наследован);
заголовок HTTP "Content-Language" (который может быть сконфигурирован на сервере). Например:
Content-Language: en-cockney
значения ПА по умолчанию и установки пользователя.
В этом примере основной язык документа - французский ("fr"). Один параграф объявлен как испанский ("es"), после которого возвращается основной язык (французский). Следующий параграф содержит фразу на внедрённом японском ("ja"), после чего возвращается основной язык (французский).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML lang="fr"> <HEAD> <TITLE>Un document multilingue</TITLE> </HEAD> <BODY> ...интерпретируется как французский...
<P lang="es">...интерпретируется как испанский...
<P>...снова интерпретируется как французский...
<P>...французский текст прерывается японским... <EM lang="ja">что-нибудь на японском</EM>здесь снова продолжается французский...
</BODY> </HTML>
Примечание. Если ячейка занимает область из нескольких ячеек (span), то она может наследовать значение lang
не из своего предка, а из первой ячейки в span . См. детали в разделе наследование выравнивания.
Наследование установок выравнивания
Выравнивание содержимого ячеек может быть определено на базе ячейка-за-ячейкой или наследоваться от включённых элементов, таких как ряд, столбец или сама таблица.
Приоритет (от высшего к низшему) атрибутов align, char и charoff:
Атрибут выравнивания, установленный для элемента внутри данных ячейки (например, P).
Атрибут выравнивания, установленный для ячейки (TH и TD).
Атрибут выравнивания, установленный для элемента группировки столбцов (COL и COLGROUP). Если ячейка является частью блока, охватывающего несколько столбцов, то свойство выравнивания наследуется из определения ячейки в начале этого блока.
Атрибут выравнивания, установленный в ряду или группе рядов (элементы TR,
THEAD, TFOOT и TBODY). Если ячейка является частью блока, охватывающего несколько рядов, то свойство выравнивания наследуется из определения ячейки в начале этого блока.
Атрибут выравнивания, установленный в таблице (TABLE).
Значение (выравнивания) по умолчанию.
Приоритет (от высшего к низшему) для атрибута valign
(как и для других наследуемых атрибутов lang, dir, и style):
Атрибут, установленный в элементе внутри данных ячейки (напр., P).
Атрибут, установленный в ячейке (TH и TD).
Атрибут, установленный в элементе ряда или группы рядов (TR,
TBODY). Если ячейка является частью блока, охватывающего несколько рядов, то свойство выравнивания наследуется из определения ячейки в начале этого блока.
Атрибут, установленный в элементе группировки столбцов (COL и COLGROUP). Если ячейка является частью блока, охватывающего несколько столбцов, то свойство выравнивания наследуется из определения ячейки в начале этого блока.
Атрибут, установленный в таблице (TABLE).
Значение (атрибута) по умолчанию.
Таким образом, при выводе ячеек горизонтальное выравнивание определяется столбцами (имеющими преимущество перед рядами), а при вертикальном выравнивании - ряды имеют преимущество перед столбцами.
Значение выравнивания по умолчанию в ячейках зависит от ПА. Однако ПА должны замещать атрибуты по умолчанию для текущего направления (т.е. не просто "left" во всех случаях).
ПА, не поддерживающие значение "justify" атрибута
align, должны вместо этого использовать наследуемое направление.
Примечание. Обратите внимание, что ячейка может наследовать атрибут не от своего предка, а от первой ячейки в охваченном блоке (span). Это является исключением из общих правил наследования.
Навигация с помощью табуляции
Определение атрибута
tabindex = number [CN] Определяет позицию элемента в порядке табуляции в текущем документе. Это должно быть цифровое значение в диапазоне от 0 до 32767. ПА должны игнорировать ведущие нули.
Порядок табуляции определяет последовательность, в которой элементы будут получать фокус при навигации с помощью клавиатуры. Порядок табуляции может включать вложенные элементы.
Элементы, которые могут получать фокус, "перебираются" пользовательским элементом в соответствии со следующими правилами:
Элементы, поддерживающие атрибут tabindex, и имеющие для него положительное значение, перебираются в первую очередь. Навигация проходит от элемента с наименьшим значением tabindex к элементу с наибольшим значением. Значения могут не быть непрерывной последовательностью или начинаться каким то определённым значением. Элементы, имеющие одинаковые значения tabindex, должны перебираться в том порядке, в котором они появляются в потоке символов. Элементы, не поддерживающие атрибут tabindex или поддерживающие его и устанавливающие значение "0", считаются текстом. Эти элементы перебираются в порядке, в котором они следуют в потоке символов. Недоступные элементы не перебираются при табуляции.
Следующие элементы поддерживают атрибут tabindex: A, AREA, BUTTON, INPUT, OBJECT, SELECT
и TEXTAREA.
В этом примере порядок табуляции: BUTTON, элементы INPUT по порядку (заметьте, что "field1" и кнопка разделяют один индекс табуляции, но "field1" появляется позже в потоке символов), и наконец - гиперссылка, созданная элементом A.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>A document with FORM</TITLE> </HEAD> <BODY> ...ещё текст...
<P>Go to the <A tabindex="10" href="http://www.w3.org/">W3C Web site.</A> ...ещё...
<BUTTON type="button" name="get-database" tabindex="1" onclick="get-database"> Get the current database. </BUTTON> ...ещё...
<FORM action="..." method="post"> <P> <INPUT tabindex="1" type="text" name="field1"> <INPUT tabindex="2" type="text" name="field2"> <INPUT tabindex="3" type="submit" name="submit"> </P> </FORM> </BODY> </HTML>
Клавиши табуляции. Реальная последовательность клавиш, вызывающая навигацию при помощи табуляции или активацию элементов, зависит от конфигурации ПА (напр., клавиша "tab" используется для навигации, а клавиша "enter" - для активации выбранного элемента).
ПА должны также определять последовательность клавиш для навигации в обратную сторону. Если достигнут конец (или начало) ряда табуляции, ПА должен "зацикливаться" на начало (или конец).
Не рекомендуемые элементы
Следующие элементы не рекомендуются:
STRIKE и U.
Недоступные и неидентифицируемые ресурсы
Ссылка не недоступный или неидентифицируемый ресурс является ошибкой. Хотя ПА могут по разному обрабатывать такие ошибки, мы рекомендуем следующее поведение ПА:
Если ПА не может обнаружить связанный ресурс, он должен предупредить пользователя.
Если ПА не может идентифицировать тип связанного ресурса, он должен попытаться обработать его. Он должен предупредить пользователя и может дать ему (пользователю) возможность доступа для идентификации типа документа.
Недоступные ЭУ
Определение атрибута
disabled [CI] Если установлен для ЭУ формы, этот булев атрибут делает ЭУ недоступным для пользователя.
Установленный атрибут disabled действует на ЭУ следующим образом:
Недоступный ЭУ не может получить фокус. Недоступный ЭУ скрыт от навигации табуляцией. Недоступный ЭУ не может быть "действующим".
Следующие ЭУ поддерживают атрибут disabled: BUTTON, INPUT, OPTGROUP, OPTION, SELECT
и TEXTAREA.
Этот атрибут наследуется, но локальное объявление переопределяет наследуемое значение.
То, как недоступные ЭУ отображаются, зависит от ПА. Например, некоторые ПА выделяют серым цветом недоступные элементы меню, лэйблы кнопок и т.п.
В данном примере элемент INPUT недоступен. Таким образом, он не может принимать ввод пользователя, и его значение не будет отправлено вместе с формой.
<INPUT disabled name="fred" value="stone">
Примечание. Единственная возможность изменить значение атрибута disabled динамически - использование скриптов.
Недоступные ЭУ и ЭУ "только для чтения"
В тех случаях, когда ввод данных пользователем не нужен или не желателен, важно иметь возможность делать ЭУ недоступными или "только для чтения". Например, кнопка submit может быть недоступной, пока пользователь не введёт нужные данные. Также автор может включить отрывок текста "только для чтения", который должен быть отправлен вместе с формой. Следующий раздел описывает Недоступные и "Только для чтения" ЭУ.
Неотображаемые символы
Браузер может не отображать корректно все символы в документе. Например, если у пользователя нет соответствующего шрифта, символ имеет значение, которое отсутствует во внутренней кодировке браузера, и т.д.
Поэтому вид документа во многих случаях становится непредсказуемым. В зависимости от реализации, неотображаемые символы также могут обрабатываться системой дисплея, а не самой программой. В связи с этим, мы рекомендуем следующие действия в отношении браузеров пользователей:
Создать ясный, но ненавязчивый механизм сообщения пользователю об отсутствующем ресурсе.Если отсутствующие символы представлены цифрами, используйте 16-ные (не десятеричные) формы, пока эти формы есть в стандартах.
Несоответствующие документы
Эта спецификация не определяет, как соответствующие ПА обрабатывают общие ошибки, в том числе - как ПА ведут себя при обнаружении элементов, атрибутов, значений атрибутов или объектов, не специфицированных в этом документе.
Однако, чтобы облегчить экспериментирование и взаимодействие между выполнениями различных версий HTML, мы рекомендуем следующую стратегию:
Если ПА обнаруживает элемент, который он не может распознать, он должен попытаться просмотреть содержимое элемента.
Если ПА обнаруживает атрибут, который он не может распознать, он должен игнорировать всю спецификацию атрибута (т.е. атрибут и его значение).Если ПА обнаруживает значение атрибута, который он не может распознать, он должен использовать значение атрибута по умолчанию.Если он обнаруживает необъявленный объект, объект должен рассматриваться как символьные данные.
Мы также рекомендуем, чтобы ПА поддерживали оповещение пользователя о таких ошибках.
Поскольку ПА могут отличаться в том, как они обрабатывают ошибки, авторы и пользователи не должны полагаться на конкретное поведение ПА при обнаружении ошибки.
Спецификация HTML 2.0 ([RFC1866]) наблюдала, как различные пользовательские агенты HTML 2.0 устанавливали, что документ, не начинающийся объявлением типа документа, относится к спецификации HTML 2.0. Как показывает опыт, это неверное поведение, и данная спецификация не рекомендует этого делать.
Из соображений совместимости, авторы не должны "расширять" HTML за рамки существующего механизма SGML (напр., расширяя ОТД, добавляя новый набор определения объектов и т.д.).
Неупорядоченные списки (UL), упорядоченные списки (OL) и элементы списка (LI)
<!ELEMENT UL - - (LI)+ -- неупорядоченный список --> <!ATTLIST UL %attrs; -- %coreattrs, %i18n, %events -- > <!ELEMENT OL - - (LI)+ -- упорядоченный список --> <!ATTLIST OL %attrs; -- %coreattrs, %i18n, %events -- >
Начальный тег: необходим, Конечный тег: необходим
<!ELEMENT LI - O (%flow;)* -- элемент списка --> <!ATTLIST LI %attrs; -- %coreattrs, %i18n, %events -- >
Начальный тег: необходим, Конечный тег: не обязателен
Определения атрибутов
type = информация о стиле [CI]
Не рекомендуется.
Этот атрибут устанавливает стиль элемента списка. Доступные в настоящее время значения касаются визуальных ПА. Возможные значения описаны ниже (вместе с информацией о регистре).
start = number [CN]
Не рекомендуется.
Только для OL. Этот атрибут устанавливает номер первого элемента упорядоченного списка. По умолчанию это "1". Заметьте, что, хотя значением этого атрибута является целое число, соответствующие лэйблы могут быть нечисловыми.
Так, если стиль элемента списка это латинские буквы в верхнем регистре (A, B, C, ...),
start=3 означает "C".
Если стиль - это римские цифры в нижнем регистре,
start=3 означает "iii" и т.д.
value = number [CN]
Не рекомендуется.
Только для LI. Этот атрибут устанавливает номер текущего элемента списка. Заметьте, что, хотя значением этого атрибута является целое число, соответствующие лэйблы могут быть нечисловым (см. атрибут start).
compact [CI]
Не рекомендуется.
Если установлен, этот булев атрибут подсказывает визуальному ПА, что список нужно отображать более компактно. Интерпретация этого атрибута зависит от ПА.
Атрибуты, определённые в другом месте
id, class (идентификаторы документа)
lang (язык), dir (направление текста)
title (заголовок элемента)
style (инлайн-стиль)
onkeydown, onkeyup (внутренние события)
Упорядоченные и неупорядоченные списки отображаются идентичными способами, за исключением того, что визуальные ПА нумеруют элементы упорядоченных списков. ПА могут представлять нумерацию разными способами. Элементы неупорядоченных списков не нумеруются.
Списки обоих типов состоят из последовательности элементов списка, определённых элементом LI (с отсутствующим конечным тегом).
Этот пример иллюстрирует базовую структуры списков:
<UL> <LI> ...первый элемент списка...
<LI> ...второй элемент списка...
... </UL>
Списки также могут быть вложенными:
НЕ РЕКОМЕНДУЕТСЯ:
<UL> <LI> ... Уровень 1, номер 1 ...
<OL> <LI> ... Уровень 2, номер 1 ...
<LI> ... Уровень 2, номер 2 ...
<OL start="10"> <LI> ... Уровень 3, номер 1 ...
</OL> <LI> ... Уровень 2, номер 3 ...
</OL> <LI> ... Уровень 1, номер 2 ...
</UL>
Детали. В упорядоченных списках невозможно продолжить автоматически нумерацию списка после предыдущего списка или скрыть нумерацию некоторых элементов списка. Однако, авторы могут сбросить номер элемента списка установкой его атрибута value. Нумерация начинается с нового для списка элементов значения. Например:
<ol> <li value="30"> устанавливает номер элемента 30. <li value="40"> устанавливает номер элемента 40. <li> установлен номер элемента 41. </ol>
Нормативные ссылки
"Cascading Style Sheets/Каскадные таблицы стилей, уровень 1", H.W.Lie и B. Bos, 17 декабря 1996. Пересмотрено 11 января 1999. Это документ http://www.w3.org/TR/1999/REC-CSS1-19990111
"Date and Time Formats/Формат даты и времени", заметки W3C, M.Wolf и C.Wicksteed, 15 сентября 1997. Пересмотрено 27 августа 1998. Это документ http://www.w3.org/TR/1998/NOTE-datetime-19980827
"Спецификация HTML 4.0", D. Raggett, A.Le Hors, I.Jacobs. Версия от 24 апреля 1998 - http://www.w3.org/TR/1998/REC-html40-19980424. Версия от 24 апреля включила редакционные изменения, по сравнению с оригиналом от 18 декабря 1997[IANA]
"Assigned Numbers/Передаваемые значения" STD 2, RFC 1700, USC/ISI, J.Reynolds and J.Postel, октябрь 1994.
[ISO639]"Codes for the representation of names of languages/Коды для представления названия языка", ISO 639:1988. Дополнительная информация - http://www.iso.ch/cate/d4766.html. См. также - http://www.oasis-open.org/cover/iso639a.html
[ISO3166]"Codes for the representation of names of countries/Коды для представления названия страны", ISO 3166:1993.[ISO8601]
"Data elements and interchange formats/Элементы даты и формат обмена -- Information interchange/Информационный обмен -- Representation of dates and times/Представление даты и времени", ISO 8601:1988.
"Information Processing/Информационный процессинг -- Text and Office Systems/Текстовые и офисные системы -- Standard Generalized Markup Language (SGML)", ISO 8879:1986. Смотрите информацию о стандарте в http://www.iso.ch/cate/d16387.html
"Information Technology/Информационные технологии -- Universal Multiple-Octet Coded Character Set (UCS)/Универсальный восьмерично кодированный набор символов -- Часть 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-1:1993. Это ссылка на список кодовых точек, которые могут "разворачиваться" при назначении им новых символов.
В то же время, этот справочник включает будущие исправления, пока они ещё не
вступили в силу, включая первые пять дополнений к ISO/IEC 10646-1:1993.
Также этот справочник суммирует, что набор символов, определённый ISO 10646 и Unicode, сохраняет вид "символ-символ".
Этот справочник включает также будущие публикации других источников 10646, определяющих символы в проектах 1-16.
[ISO88591]
"Information Processing/Информационный процессинг -- 8-bit single-byte coded graphic character sets/8-битовый однобайтовый набор графических кодов -- Часть 1: Latin alphabet No.1, Латинский алфавит №1", ISO 8859-1:1987.
[MIMETYPES]
Список зарегистрированных типов (MIME-типы). Загрузите список MIME-типов с ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
[RFC1555]
"Hebrew Character Encoding for Internet Messages/Набор символов иврита для Internet-сообщений", H.Nussbacher и Y.Bourvine, декабрь 1993.[RFC1556]
"Handling of Bi-directional Texts in MIME/Обработка двунаправленных текстов в MIME", H.Nussbacher, декабрь 1993.[RFC1738]
"Uniform Resource Locators/Универсальные локаторы ресурсов", T.Berners-Lee, L.Masinter и M.McCahill, декабрь 1994.[RFC1766]
"Tags for the Identification of Languages/Теги для идентификации языка", H.Alvestrand, март 1995. RFC1766, должен быть обновлён http://www.ietf.org/internet-drafts/draft-alvestrand-lang-tags-v2-00.txt, работа ещё продолжается.[RFC1808]
"Relative Uniform Resource Locators/Относительные URL", R.Fielding, июнь 1995.
[RFC2045]
"Multipurpose Internet Mail Extensions (MIME)/Многоцелевые расширения Internet Mail,
Часть первая: Format of Internet Message Bodies/Формат тела сообщений Internet", N.Freed и N.Borenstein, ноябрь 1996. Обратите внимание, что этот RFC отменяет RFC1521, RFC1522 и RFC1590.[RFC2046]
"Multipurpose Internet Mail Extensions (MIME)/Многоцелевые расширения Internet Mail,
Часть вторая: Media Types/Типы носителя", N.Freed и N.Borenstein, ноябрь 1996. Обратите внимание, что этот RFC отменяет RFC1521, RFC1522 и RFC1590.[RFC2119]
" Key words for use in RFCs to Indicate Requirement Levels", S.Bradner, март 1997.
[RFC2141]
"URN Syntax", R.Moats, май 1997.[RFC2279]
"UTF-8, a transformation format of ISO 10646", F.Yergeau, январь 1998. Этот RFC отменяет RFC 2044.
[RFC2616]
"Hypertext Transfer Protocol -- HTTP/1.1", R.Fielding, J.Gettys, J.Mogul, H.Frystyk Nielsen, L.Masinter, P.Leach и T.Berners-Lee; июнь 1999. Этот RFC отменяет RFC 2068.
[SRGB]"A Standard Default color Space for the Internet", версия 1.10, M.Stokes, M. Anderson, S.Chandrasekar и R.Motta, 5 ноября 1996. Это документ http://www.w3.org/Graphics/Color/sRGB
[UNICODE]
The Unicode Consortium. "The Unicode Standard, Version 3.0", Reading, MA, Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5. См. также http://www.unicode.org/unicode/standard/versions/
[URI]
"Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R.Fielding, L.Masinter, август 1998. Обратите внимание, что этот RFC 2396 обновляет [RFC1738] и [RFC1808].[WEBSGML]
"Final text of revised TC2 to ISO 8879:1986", C.F.Goldfarb, ред., 6 декабря 1998.
Новые элементы
Новые элементы HTML 4.0: ABBR,
THEAD и Q.
О SGML и HTML
Содержание
Введение в SGML
Конструкции SGML, используемые в HTML
Элементы
Атрибуты
Ссылки-мнемоники
Комментарии
Как читать Определение Типа Данных (ОТД) HTML
Комментарии в ОТД
Определение объектов-параметров
Объявление элементов Определение модели содержимого
Объявление атрибутов Объекты ОТД в определении атрибутов
Булевы атрибуты
Этот раздел посвящён SGML и его взаимосвязям с HTML. Полное обсуждение SGML находится в стандарте (см. [ISO8879]).
О спецификации HTML
Содержание
Структура спецификации
Соглашения
Элементы и атрибуты
Замечания и примеры
Благодарности
Благодарность за этот документ
Авторские права
Объекты, Изображения и Аплеты
13.2 Элемент IMG: дополнен атрибутом name для обеспечения обратной совместимости.13.2 Элемент IMG: добавлено примечание, что ПА обязаны предоставлять различные механизмы для доступа к "longdesc" URI (изображения/IMG) и "src" URI (якоря/A), если IMG является частью содержимого элемента A.
13.3 Элемент OBJECT:
добавлено примечание, что, если значения "type" для OBJECT и для заголовка Content-Type HTTP различны, то последнее имеет преимущество.13.3 Элемент OBJECT: добавлено указание использовать PARAM вместо совместного употребления атрибутов "data" и "classid" для OBJECT.
13.4 Элемент APPLET: добавлено примечание, что, из соображений безопасности, только субдиректории просматриваются для атрибута "codebase" в APPLET.
13.6.1 Клиентские карты изображений: определение атрибута "poly" дополнительно разъяснено, что, если многоугольник для атрибута "coords" в AREA не закрыт авторами, это должен сделать ПА..13.6.1 Клиентские карты изображений:модель содержимого элемента MAP теперь позволяет авторам смешивать содержимое AREA и содержимое уровня блока;ПА "должны" воспроизводить содержимое уровня блока (ранее "могли").элемент MAP может быть использован без изображения для общего использования в утилитах навигации;
ПА обязан игнорировать элементы AREA,
если содержимое является смешанным (AREA и уровня блока).авторы должны полностью специфицировать очертания элементами AREA
или A в содержимом блока или обоими.13.7.2 и 13.7.3 : определение атрибутов vspace и hspace выглядит теперь так же, как и определения других атрибутов.13.7.2 и 13.7.3 : тип значений атрибутов vspace, hspace и border изменён с "length" на "pixels".13.8 Альтернативный текст: последнее указание раздела теперь обращено к разработчикам ПА и касается обработки пустого атрибута текста "alt".
Содержание
Введение
Вставка изображения: элемент IMG
Общая вставка: элемент OBJECT
Правила представления объектов
Инициализация объекта: элемент PARAM
Глобальные схемы именования объектов
Объявление и размещение объектов
Вставка аплета: элемент APPLET
Замечания о внедрённых документах
Карты изображений
Клиентские (на стороне клиента) карты изображений: элементы MAP и AREA Примеры клиентских карт
Серверные (на стороне сервера) карты изображений
Визуальное представление изображений, объектов и аплетов
Ширина и высота
Свободное пространство вокруг изображений и объектов
РамкиВыравнивание
Как установить альтернативный текст
Объекты ОТД в определениях атрибутов
Определения атрибутов могут также содержать ссылки на объекты-параметры.
В этом примере мы видим, что список определения атрибута элемента
LINK начинается объектом-параметром "%attrs;":
<!ELEMENT LINK - O EMPTY -- независимая от типа носителя ссылка --> <!ATTLIST LINK %attrs; -- %coreattrs, %i18n, %events -- charset %Charset; #ПРЕДПОЛАГАЕТСЯ -- набор символов связанного ресурса -- href %URI; #ПРЕДПОЛАГАЕТСЯ -- URI связанного ресурса -- hreflang %LanguageCode; #ПРЕДПОЛАГАЕТСЯ -- код языка -- type %ContentType; #ПРЕДПОЛАГАЕТСЯ -- информативный тип содержимого -- rel %LinkTypes; #ПРЕДПОЛАГАЕТСЯ -- типы ссылки вперёд -- rev %LinkTypes; #ПРЕДПОЛАГАЕТСЯ -- типы ссылки назад -- media %MediaDesc; #ПРЕДПОЛАГАЕТСЯ -- для представления данным носителем -- >
Начальный тег: необходим, Конечный тег: запрещён
Объект-параметр "%attrs;" определён так:
<!ENTITY % attrs "%coreattrs; %i18n; %events;">
Объект-параметр "%coreattrs;" в определении "%attrs;" расширяется так:
<!ENTITY % coreattrs "id ID #ПРЕДПОЛАГАЕТСЯ -- уникальный идентификатор документа id -- class CDATA #ПРЕДПОЛАГАЕТСЯ -- список разделённых пробелами классов -- style %StyleSheet; #ПРЕДПОЛАГАЕТСЯ -- ассоциированная информация о стиле -- title %Text; #ПРЕДПОЛАГАЕТСЯ -- информативное название --" >
Объект-параметр "%attrs;" определён по соглашению, поскольку эти атрибуты определены для большинства типов элементов HTML.
Таким же образом ОТД определяет объект-параметр "%URI;" и расширяет его в строку "CDATA".
<!ENTITY % URI "CDATA" -- Uniform Resource Identifier, см. [URI]
-->
Как показано в этом примере, объект-параметр "%URI;" даёт читателю больше информации как об ОТД, так и о типе данных, ожидаемых для данного атрибута. Так же определяются объекты-параметры "%Color;", "%Charset;", "%Length;", "%Pixels;" и т.д.
