XHTML 1.0
представляются типографскими пробелами; в языках с арабским написанием типографские пробелы могут кодироваться с помощью символа пробела, а также с помощью символа пробела набора ZW для отделения 'внутренних' грамматических границ (то, что для русского человека выглядит в арабском языке, как одно слово, часто может быть несколькими словами, например, 'kitAbuhum' = 'kitAbu-hum' = 'книга их' == их книга); а в языках с китайским написанием традиционно не кодируются ни пробелы между словами, ни типографские пробелы.
Пробелы в значениях атрибутов обрабатываются в соответствии с [XML].
4. Различия по сравнению с HTML 4
Поскольку XHTML является приложением XML, некоторые приемы, допустимые в языке HTML 4 [HTML], основанном на SGML, должны быть изменены.
4.1 Документы должны быть правильно построены
Правильное построение - это новое понятие, введенное в [XML]. В основном это означает, что все элементы либо должны иметь закрывающие теги, либо записываться в специальной форме (как описано ниже), и все элементы должны вкладываться друг в друга.
Хотя в SGML перекрытие недопустимо, существующие браузеры обычно не считают это ошибкой.
ПРАВИЛЬНО: вложенные элементы.
<p>это выделенный <em>абзац</em>.</p>
НЕПРАВИЛЬНО: перекрывающиеся элементы
<p>это выделенный <em>абзац.</p></em>
4.2 Имена атрибутов и элементов должны быть в нижнем регистре
В документах XHTML для всех имен элементов и атрибутов HTML должен использоваться нижний регистр. Это различие обязательно, поскольку в XML регистр имеет значение - например, <li> и <LI> - различные теги.
4.3 Для непустых элементов конечные теги обязательны
В HTML 4 конечный тег некоторых элементов может опускаться; при этом закрытие элемента подразумевалось автоматически благодаря последующим тегам. Это не допускается в XHTML, построенном на основе XML. Все элементы, кроме объявленных в DTD как EMPTY, должны иметь конечный тег.
ПРАВИЛЬНО: закрытые элементы
<p>это абзац.</p><p>here is
another paragraph.</p>
НЕПРАВИЛЬНО: незакрытые элементы
<p>это абзац.<p>here is another
paragraph.
4.4 Значения атрибутов должны всегда заключаться в кавычки
Все значения атрибутов должны заключаться в кавычки, даже числовые.
ПРАВИЛЬНО: значения атрибутов в кавычках
<table rows="3">
НЕПРАВИЛЬНО: значения атрибутов без кавычек
<table rows=3>
4.5 Минимизация атрибутов
В XML не поддерживается минимизация атрибутов. Пары атрибут-значение должны быть записаны полностью. Такие имена атрибутов как
compact и checked не могут встречаться в элементах без указания их значения.
ПРАВИЛЬНО: неминимизированные атрибуты
<dl compact="compact">
НЕПРАВИЛЬНО: минимизированные атрибуты
<dl compact>
4.6 Пустые элементы
Пустые элементы должны иметь конечный тег или начальный тег должен заканчиваться угловой скобкой (/>). Например, <br/> или <hr></hr>. Информацию о том, как обеспечить обратную совместимость с пользовательскими агентами HTML 4 см. в HTML Compatibility Guidelines.
ПРАВИЛЬНО: закрытые пустые теги
<br/><hr/>
НЕПРАВИЛЬНО: незакрытые пустые теги
<br><hr>
4.7 Обработка пробелов в значениях атрибутов
В значениях атрибутов пользовательские агенты должны удалять начальные и конечные пробелы от значений атрибутов и отображать последовательности из одного или нескольких пробельных символов (включая перевод строки) в один пробел между словами (символ пробела кодировки ASCII для западного начертания). См. раздел 3.3.3 спецификации [XML].
4.8 Элементы скриптов и стилей
В XHTML элементы скриптов и стилей объявляются как элементы с содержимым #PCDATA. В результате < и & будут обрабатываться как начало разметки, а такие объекты как < и & будут распознаваться процессором XML как ссылки на объекты < и & соответственно. Разбиение на строки содержимого элементов скриптов и стилей в разделе CDATA позволит избежать развертывания этих объектов.
<script>
<![CDATA[
... незакодированное содержимое скрипта ...
]]>
</script>
Разделы CDATA распознаются процессором XML и представляются в в виде узлов в объектной модели документа, см. раздел 1.3 Рекомендации DOM уровня 1 [DOM].
В качестве альтернативы можно использовать внешний скрипт или документы стилей.
4.9 Исключения SGML
SGML дает авторам DTD возможность запрещения содержания некоторых элементов в каком-либо другом. Такие запреты (называемые "исключениями") в XML невозможны.
Например, HTML 4 Strict DTD (строгое определение типа документа) запрещает вложение элементов 'a' друг в друга. Такие запреты невозможны в XML. Несмотря на то, что такие запреты не могут быть определены в DTD, определенные элементы не должны вкладываться. Список таких элементов и элементов, которые не должны вкладываться в них, приведен в нормативном приложении Б.
4.10 Элементы с атрибутами 'id' и 'name'
В HTML 4 атрибут name определен для элементов a, applet, form, frame, iframe, img и map. Кроме того, в HTML 4 введен атрибут id. Оба эти атрибута разработаны как идентификаторы фрагментов.
В XML идентификаторы фрагментов имеют тип ID, и один элемент может иметь только один атрибут типа ID. Поэтому в XHTML 1.0 атрибут id определен как тип ID. Чтобы гарантировать, что документы XHTML 1.0 являются правильно структурированными документами XML, в документах XHTML 1.0 при определении идентификаторов фрагментов ДОЛЖЕН использоваться атрибут id, даже в элементах, которые исторически имеют атрибут name. Информацию об обеспечении обратной совместимости таких якорей при обслуживании документов XHTML с типом устройства text/html см. в HTML Compatibility Guidelines.
Обратите внимание, что в XHTML 1.0 атрибут name этих элементов формально считается нежелательным и будет удален из последующих версий XHTML.
5. Вопросы совместимости
Хотя к документам XHTML 1.0 не предъявляется требование совместимости с существующими пользовательскими агентами, на практике оно достаточно легко реализуемо. Основные принципы создания совместимых документов можно найти в приложении C.
5.1 Типы устройств Интернет
С момента публикации настоящей рекомендации общая рекомендованная отметка типа MIME для приложений на базе XML должна еще быть разрешена.
Однако документы XHTML, в которых соблюдаются принципы, изложенные в in приложении В, "Принципы совместимости с HTML", могут помечаться с помощью типа устройства Интернет "text/html", поскольку они совместимы с большей частью браузеров HTML. Настоящий документ не дает рекомендаций относительно пометки типа MIME других документов XHTML.
6. Направления развития
Спецификация XHTML 1.0 закладывает основу семейства типов документов, которые будут расширениями и подмножествами XHTML, для поддержания широкого диапазона новых устройств и приложений путем определения модулей и механизма объединения этих модулей. Такой механизм позволит унифицировать способы расширения XHTML 1.0 и использования его подмножеств путем определения новых модулей.
6.1 Модуляризация HTML
По мере перемещения XHTML с традиционных пользовательских агентов на рабочем столе на другие платформы становится ясно, что не все элементы XHTML будут необходимы на всех платформах. Например, в наладонниках или сотовых телефонах может поддерживаться только некоторое подмножество элементов XHTML.
Процесс модуляризации разбивает XHTML на ряд более мелких подмножеств элементов. Затем, если требования изменятся, эти элементы можно перекомбинировать иным образом.
Модули будут определены в другом документе W3C.
6.2 Подмножества и расширяемость
Модуляризация дает следующие преимущества:
Она предоставляет формальный механизм выделения подмножеств XHTML.
Она предоставляет формальный механизм расширения XHTML.
Она упрощает преобразование типов документов.
Она способствует повторному использованию модулей в новых типах документов.
6.3 Профили документов
В профиле документа определяется синтаксис и семантика набора документов. Соответствие профилю документа обеспечивает основу гарантии совместимости. В профиле документа определяются возможности, необходимые для обработки документа этого типа, например, какие могут использоваться форматы изображений, уровни скриптов, поддержка таблиц стилей и т.д.
Для разработчиков продуктов они обеспечивают возможность определения стандартных профилей различными группами по необходимости.
Для авторов профили устраняют необходимость написания нескольких различных версий документов для различных клиентов.
Для групп специальностей, например, химиков, врачей или математиков можно строить специальные профили со стандартными элементами HTML плюс группы элементов, необходимых для этих конкретных специальностей.
Приложение А. DTD
Данное приложение является нормативным.
Данные DTD и наборы объектов составляют нормативную часть настоящей спецификации. Полный набор файлов DTD с объявлением XML и открытым каталогом SGML можно найти в архиве zip настоящей спецификации.
A.1 Определения типов документов
Данные DTD приблизительно совпадают с DTD HTML 4. Весьма вероятно, что, когда DTD будут модуляризованы, будет применяться способ построения DTD, более близкий HTML 4.
XHTML-1.0-Strict
XHTML-1.0-Transitional
XHTML-1.0-Frameset
A.2 Наборы объектов
Наборы объектов XHTML совпадают с наборами для HTML 4, но изменены так, чтобы быть допустимыми объявлениями объектов XML 1.0. Обратите внимание, что объект для обозначения Евро (€ или € или €) определен как специальный символ.
Символы набора Latin-1
Специальные символы
Знаки
Приложение Б. Запрет на элементы
Данное приложение является нормативным.
На следующие элементы налагаются ограничения по включению в них других элементов (см. раздел 4.9). Эти запреты применяются на всех уровнях вложенности, т.е. распространяются и на все вложенные элементы.
a
не может содержать других элементов a.
pre
не может содержать элементы img, object, big, small, sub или sup.
button
не может содержать элементы input, select, textarea, label, button, form, fieldset, iframe или isindex.
label
не может содержать другие элементы label.
form
не может содержать другие элементы form.
Приложение В. Принципы совместимости с HTML
Данное приложение является информативным.
В данном приложении перечислены принципы дизайна для авторов, которые хотят, чтобы их документы XHTML генерировались и в существующих пользовательских агентах HTML.
C.1 Инструкции по обработке
Помните, что инструкции по обработке в некоторых пользовательских агентах генерируются. Однако обратите также внимание, что если объявление XML не включено в документ, в этом документе могут использоваться только стандартные кодировки символов UTF-8 или UTF-16.
C.2 Пустые элементы
Включайте пробел перед заключительным слешем (/) и > пустых элементов, например, <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Используйте также для пустых элементов синтаксис минимизированных тегов, например, <br />, поскольку альтернативный синтаксис <br></br>, допустимый в XML, во многих существующих пользовательских агентах приводит к непредсказуемым результатам.
C.3 Минимизация элементов и содержимое пустого элемента
В пустых экземплярах элементов, модель содержимого которых отличается от EMPTY (например, пустой заголовок или абзац) не используйте минимизированную форму (например, используйте <p> </p>, а не <p />).
C.4 Внедренные таблицы стилей и скрипты
Если в таблице стилей используется < или & или ]]> или --, используйте внешние таблицы стилей. Если в скрипте используются < или & или ]]> или --, используйте внешний скрипт. Обратите внимание, что синтаксические разборщики XML могут удалять содержимое комментариев. Поэтому как исторически сложилось, "прятать" скрипты и таблицы стилей в комментарии для обратной совместимости документов, скорее всего, не будет работать обычным образом в реализациях на базе XML.
C.5 Разрывы строк в значениях атрибутов
Избегайте помещения разрывов строк и нескольких пробельных символов в значения атрибутов. Они обрабатываются пользовательскими агентами по-разному.
C.6 Isindex
Не включайте в заголовок (head) документа несколько элементов isindex. Использование элемента isindex нежелательно, вместо него следует использовать элемент input.
C.7 Атрибуты lang и xml:lang
При указании чзыка элемента используйте оба элемента, lang и xml:lang. Приоритет имеет значение атрибута xml:lang.
C.8 Идентификаторы фрагментов
В XML URI [RFC2396], заканчивающиеся идентификаторами фрагментов в виде "#foo", не ссылаются на элементы с атрибутами name="foo"; вместо этого они ссылаются на элементы с атрибутом типа ID, например, атрибут id в HTML 4. Многие существующие клиенты HTML не поддерживают использование атрибутов типа ID таким образом, так что для обоих этих атрибутов для гарантии максимальной прямой и обратной совместимости могут задаваться идентичные значения (например, <a id="foo" name="foo">...</a>).
Далее, поскольку набор допустимых значений для атрибутов типа ID гораздо меньше, чем для атрибутов типа CDATA, атрибут типа name преобразован в NMTOKEN. Этот атрибут ограничен таким образом, что может иметь только те же значения, что и тип ID или продукция Name в XML 1.0, раздел 2.5, продукция 5. К сожалению, это ограничение не может быть выражено в XHTML 1.0 DTD. Поэтому при преобразовании существующих документов HTML нужно быть особенно осторожными. Значения этих атрибутов должны быть уникальными в пределах документа, допустимыми, а все ссылки на эти идентификаторы фрагментов (внутренние и внешние) должны быть обновлены, если при преобразовании изменялись значения.
И наконец, обратите внимание, что в XHTML 1.0 нежелательным является атрибут name элементов a, applet, form, frame, iframe, img и map, и он будет удален в последующих версиях XHTML.
C.9 Кодировка символов
Для указания кодировки символов в документе используйте как спецификацию атрибута кодировки в объявлении xml (например, <?xml version="1.0" encoding="EUC-JP"?>), так и выражение meta http-equiv (например, <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />). Значение атрибута encoding инструкции по обработке xml имеет приоритет.
C.10 Булевы атрибуты
Некоторые пользовательские агенты HTML неспособны интерпретировать булевы атрибуты в полной (ненормализованной) форме, как это требуется в XML 1.0. Обратите внимание, что эта проблема не затрагивает пользовательские агенты, совместимые с HTML 4. Это относится к следующим атрибутам: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.
C.11 Объектная модель документа и XHTML
В рекомендации Document Object Model level 1 (Объектная модель документов, уровень 1) [DOM] определяются интерфейсы объектной модели документов для XML и HTML 4. В объектной модели документов HTML 4 определяется, что элемент HTML и имена атрибутов возвращаются в верхний регистр. В объектной модели документов XML определяется, что имена элементов и атрибутов возвращаются в том регистре, в котором они указаны. В XHTML 1.0 элементы и атрибуты задаются в нижнем регистре. С этими различиями можно справиться двумя способами:
Приложения, которые обращаются к документам XHTML, обслуживаемым как тип устройств text/html через DOM, могут использовать HTML DOM и использовать имена элементов и атрибутов, возвращаемые этими интерфейсами в верхнем регистре.
Приложения, которые обращаются к документам XHTML, обслуживаемым как тип устройств text/xml или application/xml, могут также использовать XML DOM. Элементы и атрибуты будут возвращаться в нижнем регистре. Кроме того, некоторые элементы XHTML могут отображаться или не отображаться в дереве объектов, поскольку они являются необязательными в модели содержимого (например, элемент tbody в элементе table). Это происходит потому, что в HTML 4 была разрешена такая минимизация некоторых элементов, что их начальные и конечные теги опускались (возможность языка SGML). Это невозможно в XML. Вместо того, чтобы потребовать от авторов документов вставки посторонних элементов, в XHTML эти элементы сделаны дополнительными. Приложения должны использовать эту возможность соответствующим образом.
C.12 Использование амперсандов в значениях атрибутов
Если значение атрибута содержит амперсанд, он должен быть представлен в виде ссылки на символьный объект (например, "&"). Например, если атрибут href элемента a ссылается на CGI-скрипт, которому передаются параметры, он должен передавать их в виде http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user, а не http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.
C.13 Каскадные таблицы стилей (CSS) и XHTML
В рекомендации "Каскадные таблицы стилей уровня 2" [CSS2] определяются свойства стиля, которые применяются при разборе дерева документа HTML или XML. Различия в разборе приведут к различным визуальным или звуковым результатам, в зависимости от используемых селекторов. Следующие советы позволят ослабить этот эффект для документов, обслуживаемых без изменения как устройства обоих типов:
В таблицах стилей CSS для XHTML имена элементов и атрибутов должны быть в нижнем регистре.
В таблицах элемент tbody не будет учитываться синтаксическим анализатором пользовательского агента HTML, но не анализатором пользовательского агента XML. Поэтому следует всегда явным образом добавлять элемент tbody, если он ссылается на селектор CSS.
В пространстве имен XHTML ожидается, что пользовательские агенты будут распознавать атрибут "id" как атрибут типа ID. Поэтому таблицы стилей должны иметь возможность использования сокращенного синтаксиса селектора "#", если пользовательский агент не обращается к DTD.
В пространстве имен XHTML ожидается, что пользовательские агенты будут распознавать атрибут "class". Поэтому таблицы стилей должны иметь возможность использования сокращенного синтаксиса селектора ".".
В CSS определены разные правила конформности для документов HTML и XML; помните. Что правила HTML применяются к документам XHTML, представляемым как HTML, а правила XML применяются к документам XHTML, представляемым как XML.
Приложение Г. Благодарности
Данное приложение является информативным.
Настоящая спецификация была написана с участием следующих членов рабочей группы HTML W3C:
Стивен Пембертон (Steven Pemberton), CWI (Председатель рабочей группы HTML)
Мюррей Альтхайм (Murray Altheim), Sun Microsystems
Дэниел Остин (Daniel Austin), AskJeeves (CNET: The Computer Network до июля 1999 года)
Фрэнк Бамфри (Frank Boumphrey), HTML Writers Guild
Джон Бургер (John Burger), Mitre
Эндрю В. Донохо (Andrew W. Donoho), IBM
Сэм Дули (Sam Dooley), IBM
Клаус Хофрихтер (Klaus Hofrichter), GMD
Филипп Хошка (Philipp Hoschka), W3C
Масаясу Ишикава (Masayasu Ishikawa), W3C
Уорнер тен Кате (Warner ten Kate), Philips Electronics
Питер Кинг (Peter King), Phone.com
Паула Кланте (Paula Klante), JetForm
Шиничи Матсуи (Shin'ichi Matsui), Panasonic (частично занятый инженер W3C до сентября 1999 года)
Шейн МакКаррон (Shane McCarron), Applied Testing and Technology (The Open Group до августа 1999 года)
Анн Наварро (Ann Navarro), HTML Writers Guild
Зак Ниес (Zach Nies), Quark
Дэйв Рэггетт (Dave Raggett), W3C/HP (Руководитель по HTML W3C)
Патрик Шмитц (Patrick Schmitz), Microsoft
Себастиан Шнитценбаумер (Sebastian Schnitzenbaumer), Stack Overflow
Питер Старк (Peter Stark), Phone.com
Крис Уилсон (Chris Wilson), Microsoft
Тед Вугофски (Ted Wugofski), Gateway 2000
Дэн Зигмонд (Dan Zigmond), WebTV Networks
Приложение Д. Ссылки
Данное приложение является информативным.
[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B.
Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 мая 1998 г.
Последняя версия:
http://www.w3.org/TR/REC-CSS2
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren
Wood et al., 1 октября 1998.
Последняя версия:
http://www.w3.org/TR/REC-DOM-Level-1
[HTML]
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I.
Jacobs, 24 декабря 1999 г.
Последняя версия:
http://www.w3.org/TR/html401
[POSIX.1]
"ISO/IEC 9945-1:1990 Information Technology - Portable
Operating System Interface (POSIX) - Part 1: System Application
Program Interface (API) [C Language]", Institute of Electrical
and Electronics Engineers, Inc, 1990.
[RFC2046]
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types", N. Freed and N. Borenstein, ноябрь 1996 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2046.txt. Обратите внимание, что этот RFC заменяется RFC1521, RFC1522 и RFC1590.
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, март 1997 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2119.txt
[RFC2376]
"RFC2376: XML Media Types", E. Whitehead, M. Murata, июль 1998 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2376.txt
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic
Syntax", T. Berners-Lee, R. Fielding, L. Masinter, август 1998 г.
Данный документ дополняет RFC1738 и RFC1808.
Находится по адресу:
http://www.ietf.org/rfc/rfc2396.txt
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T.
Bray, J. Paoli, C. M. Sperberg-McQueen, 10 февраля 1998 г.
Последняя версия:
http://www.w3.org/TR/REC-xml
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14
January 1999.
Пространства имен XML предоставляют простой метод разрешения имен, используемых в документах XML путем связывания их с пространствами имен, определяемыми URI.
Последняя версия:
http://www.w3.org/TR/REC-xml-names
содержание
Пробелы в значениях атрибутов обрабатываются в соответствии с [XML].
4. Различия по сравнению с HTML 4
Поскольку XHTML является приложением XML, некоторые приемы, допустимые в языке HTML 4 [HTML], основанном на SGML, должны быть изменены.
4.1 Документы должны быть правильно построены
Правильное построение - это новое понятие, введенное в [XML]. В основном это означает, что все элементы либо должны иметь закрывающие теги, либо записываться в специальной форме (как описано ниже), и все элементы должны вкладываться друг в друга.
Хотя в SGML перекрытие недопустимо, существующие браузеры обычно не считают это ошибкой.
ПРАВИЛЬНО: вложенные элементы.
<p>это выделенный <em>абзац</em>.</p>
НЕПРАВИЛЬНО: перекрывающиеся элементы
<p>это выделенный <em>абзац.</p></em>
4.2 Имена атрибутов и элементов должны быть в нижнем регистре
В документах XHTML для всех имен элементов и атрибутов HTML должен использоваться нижний регистр. Это различие обязательно, поскольку в XML регистр имеет значение - например, <li> и <LI> - различные теги.
4.3 Для непустых элементов конечные теги обязательны
В HTML 4 конечный тег некоторых элементов может опускаться; при этом закрытие элемента подразумевалось автоматически благодаря последующим тегам. Это не допускается в XHTML, построенном на основе XML. Все элементы, кроме объявленных в DTD как EMPTY, должны иметь конечный тег.
ПРАВИЛЬНО: закрытые элементы
<p>это абзац.</p><p>here is
another paragraph.</p>
НЕПРАВИЛЬНО: незакрытые элементы
<p>это абзац.<p>here is another
paragraph.
4.4 Значения атрибутов должны всегда заключаться в кавычки
Все значения атрибутов должны заключаться в кавычки, даже числовые.
ПРАВИЛЬНО: значения атрибутов в кавычках
<table rows="3">
НЕПРАВИЛЬНО: значения атрибутов без кавычек
<table rows=3>
4.5 Минимизация атрибутов
В XML не поддерживается минимизация атрибутов. Пары атрибут-значение должны быть записаны полностью. Такие имена атрибутов как
compact и checked не могут встречаться в элементах без указания их значения.
ПРАВИЛЬНО: неминимизированные атрибуты
<dl compact="compact">
НЕПРАВИЛЬНО: минимизированные атрибуты
<dl compact>
4.6 Пустые элементы
Пустые элементы должны иметь конечный тег или начальный тег должен заканчиваться угловой скобкой (/>). Например, <br/> или <hr></hr>. Информацию о том, как обеспечить обратную совместимость с пользовательскими агентами HTML 4 см. в HTML Compatibility Guidelines.
ПРАВИЛЬНО: закрытые пустые теги
<br/><hr/>
НЕПРАВИЛЬНО: незакрытые пустые теги
<br><hr>
4.7 Обработка пробелов в значениях атрибутов
В значениях атрибутов пользовательские агенты должны удалять начальные и конечные пробелы от значений атрибутов и отображать последовательности из одного или нескольких пробельных символов (включая перевод строки) в один пробел между словами (символ пробела кодировки ASCII для западного начертания). См. раздел 3.3.3 спецификации [XML].
4.8 Элементы скриптов и стилей
В XHTML элементы скриптов и стилей объявляются как элементы с содержимым #PCDATA. В результате < и & будут обрабатываться как начало разметки, а такие объекты как < и & будут распознаваться процессором XML как ссылки на объекты < и & соответственно. Разбиение на строки содержимого элементов скриптов и стилей в разделе CDATA позволит избежать развертывания этих объектов.
<script>
<![CDATA[
... незакодированное содержимое скрипта ...
]]>
</script>
Разделы CDATA распознаются процессором XML и представляются в в виде узлов в объектной модели документа, см. раздел 1.3 Рекомендации DOM уровня 1 [DOM].
В качестве альтернативы можно использовать внешний скрипт или документы стилей.
4.9 Исключения SGML
SGML дает авторам DTD возможность запрещения содержания некоторых элементов в каком-либо другом. Такие запреты (называемые "исключениями") в XML невозможны.
Например, HTML 4 Strict DTD (строгое определение типа документа) запрещает вложение элементов 'a' друг в друга. Такие запреты невозможны в XML. Несмотря на то, что такие запреты не могут быть определены в DTD, определенные элементы не должны вкладываться. Список таких элементов и элементов, которые не должны вкладываться в них, приведен в нормативном приложении Б.
4.10 Элементы с атрибутами 'id' и 'name'
В HTML 4 атрибут name определен для элементов a, applet, form, frame, iframe, img и map. Кроме того, в HTML 4 введен атрибут id. Оба эти атрибута разработаны как идентификаторы фрагментов.
В XML идентификаторы фрагментов имеют тип ID, и один элемент может иметь только один атрибут типа ID. Поэтому в XHTML 1.0 атрибут id определен как тип ID. Чтобы гарантировать, что документы XHTML 1.0 являются правильно структурированными документами XML, в документах XHTML 1.0 при определении идентификаторов фрагментов ДОЛЖЕН использоваться атрибут id, даже в элементах, которые исторически имеют атрибут name. Информацию об обеспечении обратной совместимости таких якорей при обслуживании документов XHTML с типом устройства text/html см. в HTML Compatibility Guidelines.
Обратите внимание, что в XHTML 1.0 атрибут name этих элементов формально считается нежелательным и будет удален из последующих версий XHTML.
5. Вопросы совместимости
Хотя к документам XHTML 1.0 не предъявляется требование совместимости с существующими пользовательскими агентами, на практике оно достаточно легко реализуемо. Основные принципы создания совместимых документов можно найти в приложении C.
5.1 Типы устройств Интернет
С момента публикации настоящей рекомендации общая рекомендованная отметка типа MIME для приложений на базе XML должна еще быть разрешена.
Однако документы XHTML, в которых соблюдаются принципы, изложенные в in приложении В, "Принципы совместимости с HTML", могут помечаться с помощью типа устройства Интернет "text/html", поскольку они совместимы с большей частью браузеров HTML. Настоящий документ не дает рекомендаций относительно пометки типа MIME других документов XHTML.
6. Направления развития
Спецификация XHTML 1.0 закладывает основу семейства типов документов, которые будут расширениями и подмножествами XHTML, для поддержания широкого диапазона новых устройств и приложений путем определения модулей и механизма объединения этих модулей. Такой механизм позволит унифицировать способы расширения XHTML 1.0 и использования его подмножеств путем определения новых модулей.
6.1 Модуляризация HTML
По мере перемещения XHTML с традиционных пользовательских агентов на рабочем столе на другие платформы становится ясно, что не все элементы XHTML будут необходимы на всех платформах. Например, в наладонниках или сотовых телефонах может поддерживаться только некоторое подмножество элементов XHTML.
Процесс модуляризации разбивает XHTML на ряд более мелких подмножеств элементов. Затем, если требования изменятся, эти элементы можно перекомбинировать иным образом.
Модули будут определены в другом документе W3C.
6.2 Подмножества и расширяемость
Модуляризация дает следующие преимущества:
Она предоставляет формальный механизм выделения подмножеств XHTML.
Она предоставляет формальный механизм расширения XHTML.
Она упрощает преобразование типов документов.
Она способствует повторному использованию модулей в новых типах документов.
6.3 Профили документов
В профиле документа определяется синтаксис и семантика набора документов. Соответствие профилю документа обеспечивает основу гарантии совместимости. В профиле документа определяются возможности, необходимые для обработки документа этого типа, например, какие могут использоваться форматы изображений, уровни скриптов, поддержка таблиц стилей и т.д.
Для разработчиков продуктов они обеспечивают возможность определения стандартных профилей различными группами по необходимости.
Для авторов профили устраняют необходимость написания нескольких различных версий документов для различных клиентов.
Для групп специальностей, например, химиков, врачей или математиков можно строить специальные профили со стандартными элементами HTML плюс группы элементов, необходимых для этих конкретных специальностей.
Приложение А. DTD
Данное приложение является нормативным.
Данные DTD и наборы объектов составляют нормативную часть настоящей спецификации. Полный набор файлов DTD с объявлением XML и открытым каталогом SGML можно найти в архиве zip настоящей спецификации.
A.1 Определения типов документов
Данные DTD приблизительно совпадают с DTD HTML 4. Весьма вероятно, что, когда DTD будут модуляризованы, будет применяться способ построения DTD, более близкий HTML 4.
XHTML-1.0-Strict
XHTML-1.0-Transitional
XHTML-1.0-Frameset
A.2 Наборы объектов
Наборы объектов XHTML совпадают с наборами для HTML 4, но изменены так, чтобы быть допустимыми объявлениями объектов XML 1.0. Обратите внимание, что объект для обозначения Евро (€ или € или €) определен как специальный символ.
Символы набора Latin-1
Специальные символы
Знаки
Приложение Б. Запрет на элементы
Данное приложение является нормативным.
На следующие элементы налагаются ограничения по включению в них других элементов (см. раздел 4.9). Эти запреты применяются на всех уровнях вложенности, т.е. распространяются и на все вложенные элементы.
a
не может содержать других элементов a.
pre
не может содержать элементы img, object, big, small, sub или sup.
button
не может содержать элементы input, select, textarea, label, button, form, fieldset, iframe или isindex.
label
не может содержать другие элементы label.
form
не может содержать другие элементы form.
Приложение В. Принципы совместимости с HTML
Данное приложение является информативным.
В данном приложении перечислены принципы дизайна для авторов, которые хотят, чтобы их документы XHTML генерировались и в существующих пользовательских агентах HTML.
C.1 Инструкции по обработке
Помните, что инструкции по обработке в некоторых пользовательских агентах генерируются. Однако обратите также внимание, что если объявление XML не включено в документ, в этом документе могут использоваться только стандартные кодировки символов UTF-8 или UTF-16.
C.2 Пустые элементы
Включайте пробел перед заключительным слешем (/) и > пустых элементов, например, <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Используйте также для пустых элементов синтаксис минимизированных тегов, например, <br />, поскольку альтернативный синтаксис <br></br>, допустимый в XML, во многих существующих пользовательских агентах приводит к непредсказуемым результатам.
C.3 Минимизация элементов и содержимое пустого элемента
В пустых экземплярах элементов, модель содержимого которых отличается от EMPTY (например, пустой заголовок или абзац) не используйте минимизированную форму (например, используйте <p> </p>, а не <p />).
C.4 Внедренные таблицы стилей и скрипты
Если в таблице стилей используется < или & или ]]> или --, используйте внешние таблицы стилей. Если в скрипте используются < или & или ]]> или --, используйте внешний скрипт. Обратите внимание, что синтаксические разборщики XML могут удалять содержимое комментариев. Поэтому как исторически сложилось, "прятать" скрипты и таблицы стилей в комментарии для обратной совместимости документов, скорее всего, не будет работать обычным образом в реализациях на базе XML.
C.5 Разрывы строк в значениях атрибутов
Избегайте помещения разрывов строк и нескольких пробельных символов в значения атрибутов. Они обрабатываются пользовательскими агентами по-разному.
C.6 Isindex
Не включайте в заголовок (head) документа несколько элементов isindex. Использование элемента isindex нежелательно, вместо него следует использовать элемент input.
C.7 Атрибуты lang и xml:lang
При указании чзыка элемента используйте оба элемента, lang и xml:lang. Приоритет имеет значение атрибута xml:lang.
C.8 Идентификаторы фрагментов
В XML URI [RFC2396], заканчивающиеся идентификаторами фрагментов в виде "#foo", не ссылаются на элементы с атрибутами name="foo"; вместо этого они ссылаются на элементы с атрибутом типа ID, например, атрибут id в HTML 4. Многие существующие клиенты HTML не поддерживают использование атрибутов типа ID таким образом, так что для обоих этих атрибутов для гарантии максимальной прямой и обратной совместимости могут задаваться идентичные значения (например, <a id="foo" name="foo">...</a>).
Далее, поскольку набор допустимых значений для атрибутов типа ID гораздо меньше, чем для атрибутов типа CDATA, атрибут типа name преобразован в NMTOKEN. Этот атрибут ограничен таким образом, что может иметь только те же значения, что и тип ID или продукция Name в XML 1.0, раздел 2.5, продукция 5. К сожалению, это ограничение не может быть выражено в XHTML 1.0 DTD. Поэтому при преобразовании существующих документов HTML нужно быть особенно осторожными. Значения этих атрибутов должны быть уникальными в пределах документа, допустимыми, а все ссылки на эти идентификаторы фрагментов (внутренние и внешние) должны быть обновлены, если при преобразовании изменялись значения.
И наконец, обратите внимание, что в XHTML 1.0 нежелательным является атрибут name элементов a, applet, form, frame, iframe, img и map, и он будет удален в последующих версиях XHTML.
C.9 Кодировка символов
Для указания кодировки символов в документе используйте как спецификацию атрибута кодировки в объявлении xml (например, <?xml version="1.0" encoding="EUC-JP"?>), так и выражение meta http-equiv (например, <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />). Значение атрибута encoding инструкции по обработке xml имеет приоритет.
C.10 Булевы атрибуты
Некоторые пользовательские агенты HTML неспособны интерпретировать булевы атрибуты в полной (ненормализованной) форме, как это требуется в XML 1.0. Обратите внимание, что эта проблема не затрагивает пользовательские агенты, совместимые с HTML 4. Это относится к следующим атрибутам: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.
C.11 Объектная модель документа и XHTML
В рекомендации Document Object Model level 1 (Объектная модель документов, уровень 1) [DOM] определяются интерфейсы объектной модели документов для XML и HTML 4. В объектной модели документов HTML 4 определяется, что элемент HTML и имена атрибутов возвращаются в верхний регистр. В объектной модели документов XML определяется, что имена элементов и атрибутов возвращаются в том регистре, в котором они указаны. В XHTML 1.0 элементы и атрибуты задаются в нижнем регистре. С этими различиями можно справиться двумя способами:
Приложения, которые обращаются к документам XHTML, обслуживаемым как тип устройств text/html через DOM, могут использовать HTML DOM и использовать имена элементов и атрибутов, возвращаемые этими интерфейсами в верхнем регистре.
Приложения, которые обращаются к документам XHTML, обслуживаемым как тип устройств text/xml или application/xml, могут также использовать XML DOM. Элементы и атрибуты будут возвращаться в нижнем регистре. Кроме того, некоторые элементы XHTML могут отображаться или не отображаться в дереве объектов, поскольку они являются необязательными в модели содержимого (например, элемент tbody в элементе table). Это происходит потому, что в HTML 4 была разрешена такая минимизация некоторых элементов, что их начальные и конечные теги опускались (возможность языка SGML). Это невозможно в XML. Вместо того, чтобы потребовать от авторов документов вставки посторонних элементов, в XHTML эти элементы сделаны дополнительными. Приложения должны использовать эту возможность соответствующим образом.
C.12 Использование амперсандов в значениях атрибутов
Если значение атрибута содержит амперсанд, он должен быть представлен в виде ссылки на символьный объект (например, "&"). Например, если атрибут href элемента a ссылается на CGI-скрипт, которому передаются параметры, он должен передавать их в виде http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user, а не http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.
C.13 Каскадные таблицы стилей (CSS) и XHTML
В рекомендации "Каскадные таблицы стилей уровня 2" [CSS2] определяются свойства стиля, которые применяются при разборе дерева документа HTML или XML. Различия в разборе приведут к различным визуальным или звуковым результатам, в зависимости от используемых селекторов. Следующие советы позволят ослабить этот эффект для документов, обслуживаемых без изменения как устройства обоих типов:
В таблицах стилей CSS для XHTML имена элементов и атрибутов должны быть в нижнем регистре.
В таблицах элемент tbody не будет учитываться синтаксическим анализатором пользовательского агента HTML, но не анализатором пользовательского агента XML. Поэтому следует всегда явным образом добавлять элемент tbody, если он ссылается на селектор CSS.
В пространстве имен XHTML ожидается, что пользовательские агенты будут распознавать атрибут "id" как атрибут типа ID. Поэтому таблицы стилей должны иметь возможность использования сокращенного синтаксиса селектора "#", если пользовательский агент не обращается к DTD.
В пространстве имен XHTML ожидается, что пользовательские агенты будут распознавать атрибут "class". Поэтому таблицы стилей должны иметь возможность использования сокращенного синтаксиса селектора ".".
В CSS определены разные правила конформности для документов HTML и XML; помните. Что правила HTML применяются к документам XHTML, представляемым как HTML, а правила XML применяются к документам XHTML, представляемым как XML.
Приложение Г. Благодарности
Данное приложение является информативным.
Настоящая спецификация была написана с участием следующих членов рабочей группы HTML W3C:
Стивен Пембертон (Steven Pemberton), CWI (Председатель рабочей группы HTML)
Мюррей Альтхайм (Murray Altheim), Sun Microsystems
Дэниел Остин (Daniel Austin), AskJeeves (CNET: The Computer Network до июля 1999 года)
Фрэнк Бамфри (Frank Boumphrey), HTML Writers Guild
Джон Бургер (John Burger), Mitre
Эндрю В. Донохо (Andrew W. Donoho), IBM
Сэм Дули (Sam Dooley), IBM
Клаус Хофрихтер (Klaus Hofrichter), GMD
Филипп Хошка (Philipp Hoschka), W3C
Масаясу Ишикава (Masayasu Ishikawa), W3C
Уорнер тен Кате (Warner ten Kate), Philips Electronics
Питер Кинг (Peter King), Phone.com
Паула Кланте (Paula Klante), JetForm
Шиничи Матсуи (Shin'ichi Matsui), Panasonic (частично занятый инженер W3C до сентября 1999 года)
Шейн МакКаррон (Shane McCarron), Applied Testing and Technology (The Open Group до августа 1999 года)
Анн Наварро (Ann Navarro), HTML Writers Guild
Зак Ниес (Zach Nies), Quark
Дэйв Рэггетт (Dave Raggett), W3C/HP (Руководитель по HTML W3C)
Патрик Шмитц (Patrick Schmitz), Microsoft
Себастиан Шнитценбаумер (Sebastian Schnitzenbaumer), Stack Overflow
Питер Старк (Peter Stark), Phone.com
Крис Уилсон (Chris Wilson), Microsoft
Тед Вугофски (Ted Wugofski), Gateway 2000
Дэн Зигмонд (Dan Zigmond), WebTV Networks
Приложение Д. Ссылки
Данное приложение является информативным.
[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B.
Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 мая 1998 г.
Последняя версия:
http://www.w3.org/TR/REC-CSS2
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren
Wood et al., 1 октября 1998.
Последняя версия:
http://www.w3.org/TR/REC-DOM-Level-1
[HTML]
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I.
Jacobs, 24 декабря 1999 г.
Последняя версия:
http://www.w3.org/TR/html401
[POSIX.1]
"ISO/IEC 9945-1:1990 Information Technology - Portable
Operating System Interface (POSIX) - Part 1: System Application
Program Interface (API) [C Language]", Institute of Electrical
and Electronics Engineers, Inc, 1990.
[RFC2046]
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types", N. Freed and N. Borenstein, ноябрь 1996 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2046.txt. Обратите внимание, что этот RFC заменяется RFC1521, RFC1522 и RFC1590.
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, март 1997 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2119.txt
[RFC2376]
"RFC2376: XML Media Types", E. Whitehead, M. Murata, июль 1998 г.
Находится по адресу:
http://www.ietf.org/rfc/rfc2376.txt
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic
Syntax", T. Berners-Lee, R. Fielding, L. Masinter, август 1998 г.
Данный документ дополняет RFC1738 и RFC1808.
Находится по адресу:
http://www.ietf.org/rfc/rfc2396.txt
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T.
Bray, J. Paoli, C. M. Sperberg-McQueen, 10 февраля 1998 г.
Последняя версия:
http://www.w3.org/TR/REC-xml
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14
January 1999.
Пространства имен XML предоставляют простой метод разрешения имен, используемых в документах XML путем связывания их с пространствами имен, определяемыми URI.
Последняя версия:
http://www.w3.org/TR/REC-xml-names
содержание
