Увага!

Цей документ є перекладом, який може містити помилки та хибності.

Оригінал цієї сторінки доступний за адресою http://www.w3.org/TR/2002/REC-xhtml1-20020801/.

Всі авторські права належать W3C.

Переклад зробив Тарас Склепко (редактор українського порталу по продажу подержаних авто - rstcars.com)

W3C

XHTML™ 1.0 Extensible HyperText Markup Language (друге видання)

Переформулювання HTML 4 в XML 1.0

Рекомендація W3C від 26 січня 2000, перегляд від 1 серпня 2002

Ця версія:
http://www.w3.org/TR/2002/REC-xhtml1-20020801
Остання версія:
http://www.w3.org/TR/xhtml1
Попередня версія:
http://www.w3.org/TR/2000/REC-xhtml1-20000126
Версія з визначеннями змін:
http://www.w3.org/TR/2002/REC-xhtml1-20020801/xhtml1-diff.html
Автори:
Дивіться подяки.

Будь ласка, зверніться до списку помилок в цьому документ, який може включати в себе деякі нормативні виправлення. Також дивіться переклади.

Також цей документ буде доступний в таких ненормативних форматах як: XHTML файл з кількох частин, PostScript версія, PDF версія, ZIP архів та Gzip'd TAR архів.

Copyright © 2006 W3C® (MIT, ERCIM, Keio), всі права зарезервовані. W3C дотримується всіх вимог за зобов'язаннями, торгівельними марками та ліцензуванням програмного забезпечення.

Анотація

Ця специфікація визначає друге видання XHTML 1.0, переформулювання HTML 4 в XML 1.0 та три DTDвідповідні до визначених в HTML 4. Семантика елементів і їх атрибути визначаються в рекомендації W3C для HTML 4. Ця семантика закладає фундамент майбутньому розширенню XHTML. Сумісність з існуючими броузерами HTML можлива при дотриманні невеликого набору керівних принципів.

Стан цього документа

Цей розділ описує стан цього документа на момент його публікації. Інші документи можуть заміняти цей документ. Останній статус серій цього документа підтримується на W3C.

Даний документ є другим виданням спеціфікації XHTML 1.0 що включає виправлені помилки станом на 1 серпня 2002 року. Зміни між цією версією і попередньою рекомендацією проілюстровані у версії з переглядом визначень.

Це друге видання не є новою версією XHTML 1.0 (перша публікація від 26 січня 2000 року). Зміни в цьому документі, відображають корекції в результаті зауважень, представлених співтовариством, і в результаті проведеної роботи в рамках робочої групи HTML. У цьому документі нема жодних суттєвих змін - лише інтеграція різних виправлень.

Перелік помилок, виявлених у цій специфікації можна отримати за http://www.w3.org/2002/08/REC-xhtml1-20020801-errata.

Повідомляйте про помилки в цьому документі за адресою www-html-editor@w3.org (архів). Відкрита дискусія про можливості HTML проходить в списку розсилки www-html@w3.org (архів).

Цей документ був підготовлений у рамках діяльності W3C щодо HTML. Мета робочої групи HTML (тільки для членів) обговорюється в статусі робочої групи HTML.

На час публікації Робоча група вважає що кількість патентів, що мають відношення до даної специфікації, дорівнює нулю. Поточний список патентів, що мають відношення до даної специфікації, можна знайти на сторінці розкриття патентів.

Список поточних рекомендацій W3C і інших технічних документів можна знайти за посиланням http://www.w3.org/TR.

Скорочений зміст

Повний зміст

1. Що таке XHTML?

Даний розділ є інформативним.

XHTML це сім'я теперішніх та майбутніх типів документів і модулів що відтворюють, підмножину і продовження HTML4 [HTML4]. Сім'я типів документів XHTML базуються на XML, і повністтю призначені для роботив поєднанні з браузерами що базуються на XML. Подробиці цієї родини та її еволюції більш детально обговорюються в [XHTMLMOD].

XHTML 1.0 (ця специфікація) перший документ в сім'ї XHTML. Це зміна з трьох документів HTML4 як додаток XML 1.0 [XML]. Вона призначена для використання в якості мови для змісту, що відповідна до XML і, якщо йдеться про декілька простих принципів, відповідність до HTML4 браузерів. Розробники, які мігрують їх зміст в XHTML 1.0 будуть чинні реалізувати наступні переваги:

Cім'я XHTML це новий крок в еволюції Інтернету. Шляхом переходу на XHTML сьогодні, розробники контенту можуть увійти в світ XML з усіма супутніми перевагами, залишаючись впевненими в змісті з сумісністю у минулому і майбутньому.

1.1. Що таке HTML4?

HTML 4 [HTML4] це SGML (англ. Standard Generalized Markup Language - стандартна узагальнена мова розмітки) додаток відповіднає міжнародному стандарту ISO 8879 і широко розглядається в якості стандартної мови видання World Wide Web.

SGML це мова що існує для опису мов розмітки, особливо ті, що використовуються в електронному обміні документами, управління документообігом і публікації документів. HTML прикладом мови визначеної в SGML.

SGML існувала приблизно з середини 1980 року і залишається досить стабільною. Багато чого з цієї стабільності виникає з того факту, що ця мова є багатофункціональною та гнучкою. За таку гнучкість, однак, доводиться платити, і ціною є рівень складності, що перешкоджає його прийняттю у різноманітних середовищах, включаючи World Wide Web.

HTML, як спочатку планувалося, повинна була стати мовою для обміну науковою та інших технічних документів, придатних для використання, які не є фахівцями в цих документах. HTML звернувся до проблеми складності SGML шляхом визначення порівняно невеликого набору структурних і семантичних тегів, пристосованих для написання відносно простих документів. Крім спрощення структури документа, до HTML додана підтримка гіпертексту. Мультимедійні можливості були додані пізніше.

За досить короткий час, HTML став дуже популярним і швидко переріс своє первісне призначення. З моменту створення HTML, існують була швидко з'являтися нові елементи для використання в HTML (як стандарт) і для адаптації до HTML вертикальні, високо спеціалізованих ринках. Така величезна кількість нових елементів, привела до проблем з сумісністю документів на різних платформах.

1.2. Що таке XML?

XML™ це скорочена назва роширюваної мови розмітки (англ. Extensible Markup Language) [XML].

XML був задуманий як засіб відновлення потужності і гнучкості SGML без більшої частини того, що ускладностнює їого. Незважаючи на обмежену форму SGML, тим не меньше XML зберігає більшу частину сильних і збагачених частин SGML, і все ще зберігає всі найбільш часто використовувані функції SGML.

При збереженні таких корисних функцій, XML усуває багату частину з найбільш складних особливостей, які роблять SGML та роботу авторів відповідних програм важкими та дорогими.

1.3. Навіщо XHTML?

Переваги переходу на XHTML 1.0 були описані вище. Деякі з переваг переходу на XHTML в цілому:

2. Визначення

Даний розділ є нормативним.

2.1. Термінологія

Терміни, що використовувались в цій специфікації. Ці терміни є продовженням визначень в [RFC2119] у способах засновання на тих же визначень, що містяться в ISO/IEC 9945-1:1990 [POSIX.1]:

Може
Що стосується реалізації слово "може" слід тлумачити як додатковий компонент, який не потрібен в даній специфікації, але може бути наданий. Що стосується відповідності документа, слово "може" означає, що додаткова функція не повинна бути використана. Термін "необов'язково" має таке ж визначення, як "може".
Повинен
У цій специфікації, слово "повинен" слід тлумачити як обов'язкову вимогу про здійснення або на строгу відповідність XHTML документу, в залежності від контексту. Термін "буде повинен" має таке ж визначення, як "повинно".
Необов'язково
Дивіться "може".
Запасний
Значення або поведінка не визначені, але це не дозволило використовувати відповідні документи в підтримці браузерів що підтримують.
Буде повинен
Дивіться "повинен".
Був би повинен
Що стосується реалізації, словосполучення "був би повинен" слід тлумачити як здійснення рекомендацій, але це не є обов'язковою вимогою. Що стосується документів, словосполучення "був би повинен" слід ьлумачити як рекомендування практичниго програмування для документів і вимог для строї відповідність XHTML документів.
Підтримується
Деякі об'єкти в даній специфікації, є необов'язковими. Якщо уміння підтримується, віно веде себе, як зазначено в цій специфікації.
Не вказано
Коли значення або поведінка не визначені, специфікація не визначає вимоги до мобільності об'єкту на реалізацію навіть тоді, коли стикається з документом, який використовує об'єкт. Документ, який вимагає особливої поведінки в таких випадках, а не відсіч будь-яким поведінкою при використанні цього об'єкта, не є строго відповідним XHTML документом.

2.2. Загальні умови

Атрибут
Атрибут параметра елемента оголошені в DTD. Атрибут тип і діапазон значень, в тому числі можливі значення за замовчуванням, які визначені в DTD.
DTD
DTD, або визначення типу документа, являє собою набір декларацій розмітки XML, що, як збір, визначає правову структуру, елементи та атрибути, які доступні для використання в документі, який відповідає в DTD.
Документ
Документ являє собою потік даних, який, після того як у поєднанні з будь-якими іншими потоками на який він посилається, структурований таким, що воно утримує інформацію, що міститься в елементах, які організовані як це визначено у відповідному DTD. Дивіться Відповідність документів для отримання додаткової інформації.
Елемент
Елемент є документом, структурної одиниці оголошеної в DTD. Модель вмісту елементу визначається в DTD, а також додаткова семантика може бути визначена в описанні елементів.
Послуги
Об'єкти елементи, атрибути та семантику, пов'язану з цими елементами і атрибутами.
Здійснення
Дивіться браузер.
Розбір
Розбір є скануванням документа, а також отримання інформації, що міститься в документі та фільтрується в контексті елементів, в яких інформація структурована.
Подання
Подання це дія при якій представляється інформація, що міститься в документі. Ця презентація проводиться у найбільш зручному для навколишнього середовища формі (наприклад, на слух, візуально, у друці).
Браузер
Браузер це система, яка обробляє XHTML документи у відповідності з цією специфікацією. Дивіться відповідність браузеру для додаткової інформації.
Перевірка
Перевірка це процес, при якому документи перевіряються щодо пов'язаних зними DTD, гарантуючи, що структура, використання елементів і використанням атрибутів відповідають визначенням, що містяться в DTD.
Добра сформованість
Добре (правильно) сформований документ, коли він структурований у відповідності з правилами, визначеними в розділі 2.1 в рекомендації XML 1.0 [XML].

3. Нормативне визначення XHTML 1.0

Даний розділ є нормативним.

3.1. Відповідність документів

Ця версія надає визначення XHTML що строго відповідає до XHTML 1.0 документів, які обмежені у наборі елементів і атрибутів XML 1.0 і XHTML простору імен. Дивіться розділ 3.1.2 для інформації про використання XHTML з іншими просторами імен, наприклад, для включення метаданих, виражених в RDF в документи XHTML.

3.1.1. Строго відповідні документи

Строго відповідний XHTML документ являє собою XML документ, який вимагає лише можливості, описані в якості обов'язкових у даній специфікації. Такий документ повинен відповідати всім наступним критеріям:

  1. Воно повинно відповідати обмеженням в одному з трьох DTD, що містяться в DTD та додатку B.

  2. Кореневим елементом документа повинен бути html.

  3. Кореневий елемент документа повинен містити xmlns декларацію простору імен XHTML [XMLNS]. Простір імен для XHTML визначено як http://www.w3.org/1999/xhtml. Приклад кореневого елемента може виглядати так:

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

  4. Також в документі обов'язково повинна бути DOCTYPE декларація до кореневого елемента. Публічний ідентифікатор включений в декларацію DOCTYPE має посилатися на однин з трьох DTD, що міститься в DTD та використовує відповідні офіційні публічні ідентифікатори. Ідентифікатор системи, може бути змінений з урахуванням місцевих конвенцій системи.

    <!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

  5. Підмножина DTD не повинна використовуватися для перевизначення будь-яких параметрів особи в DTD.

Декларація XML не потрібна у всіх документах XML, однак авторам документа XHTML рішуче рекомендується використовувати XML у деклараціях всіх свої документів. Така заява є обов'язковою, якщо кодування символів документа відрізняється за замовчуванням від UTF-8 або UTF-16 і без кодування визначається протоколом більш високого рівня. Ось приклад документа XHTML. У цьому прикладі, включена декларація XML.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="uk" lang="uk">
  <head>
    <title>Віртуальна бібліотека</title>
  </head>
  <body>
    <p>Переміщено в <a href="http://example.org/">example.org</a>.</p>
  </body>
</html>

3.1.2. Використання XHTML з іншими просторами імен

Простір імен XHTML може використовуватися з іншими просторами імен XML відповідно до [XMLNS], хоча такі документи не є чітко відповідними до XHTML 1.0 документів, як визначено вище. Робота W3C розглядає способи надання відповідності для документів за участю декількох просторів імен. Для прикладу, дивіться [XHTML+MathML].

Наступний приклад показує, яким чином XHTML 1.0 може бути використаний в поєднанні з MathML Рекомендацією:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>A Math Example</title>
  </head>
  <body>
    <p>The following is MathML markup:</p>
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply> <log/>
        <logbase>
          <cn> 3 </cn>
        </logbase>
        <ci> x </ci>
      </apply>
    </math>
  </body>
</html>

Наступний приклад показує, яким чином розмітка XHTML 1.0 може бути включена в інший простір імен XML:

<?xml version="1.0" encoding="UTF-8"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
  <title>Cheaper by the Dozen</title>
  <isbn:number>1568491379</isbn:number>
  <notes>
    <!-- make HTML the default namespace for a hypertext commentary -->
    <p xmlns='http://www.w3.org/1999/xhtml'>
        This is also available <a href="http://www.w3.org/">online</a>.
    </p>
  </notes>
</book>

3.2. Відповідності Браузера

Відповідний браузер повинен відповідати всім наступним критеріям:

  1. Для того щоб бути у відповідності до рекомендацій XML 1.0 [XML], браузер повиннен аналізувати та оцінювати XHTML документ для доброго формування. Якщо браузер стверджує, що необхідна перевірка браузером, також необхідна і перевірка документів проти їх посиланнями DTD відповідно до [XML].
  2. Коли браузер стверджує, що підтримка об'єктів, визначених у цій специфікації, чи потрібні в цій специфікації через нормативне посилання, він повинен робити це таким чином, відповідно до визначення об'єктів.
  3. Якщо браузер роспізнає XHTML як загальний документ XML, він повинен тільки розпізнавати атрибути типу ID (наприклад, id це атрибут більшості елементів XHTML) як ідентифікаторів фрагментів.
  4. Якщо браузер виявляє елемент який він не підтримує, він повинен обробляти вміст елемента.
  5. Якщо браузер виявляє атрибут, який він не підтримує, він повинен проігнорувати всю специфікацію атрибута (тобто атрибут і його значення).
  6. Якщо браузер виявляє значення атрибуту, яке він не визнає (йому не є знайомим), він повинен використовувати значення атрибуту за замовчуванням.
  7. Якщо він стикається з особою повноважень (за винятком одного з суб'єктів, визначених у цій рекомендації або в рекомендаціях XML), для яких агент користувача не оброблені заяви (яке може статися, якщо оголошення знаходиться у зовнішньому підмножині, яке hasn User Agent ' T читання), посилання на сутність повинна оброблятися як символи (починаючи з амперсанда і закінчуючи крапкою з комою), які складають посилання на сутність.
  8. При обробці змісту, браузери, які стикаються з символами або посилань на символи, які зізнаються, але не відображаються, можуть заміняти один одного при відображенні, який дає той самий же зміст, або повинен показати документ таким чином, що це є помітним для звичайних користувачів, які не слідують до місця відображиння.

  9. Білий простір (англ. white space - пробіл) обробляється у відповідності з наступними правилами. Наступні символи визначені в [XML] як символи пробілів:

    XML процесор нормалізує різні системи кодів кінця рядку в одну характеристику - строка, яка передається вгору до застосування.

    Браузер повинен використовувати визначення у CSS для обробки пробільних символів [CSS2]. Зауважимо, що CSS2 рекомендація не розглядає конкретно питання про прогалини в обробці нелатинських наборів символів. Це питання буде розглянуто в майбутніх версіях CSS, на якому це посилання буде поновлене.

Зверніть увагу, що для того, щоб підготувати документ канонічний XHTML, повинні застосовуватися вищевказані правила і правила в [XMLC14N] повинні бути так само застосовані і до цього документа.

4. Відмінності від HTML4

Даний розділ є інформативним.

У зв'язку з тим, що XHTML є додатком XML, певні види практики, які були абсолютно законними в HTML4 що основується на SGML [HTML4] повинні бути змінені.

4.1. Документи повинні бути добре сформовані

Добре сформаваний це нове поняття, що з'явилось в [XML]. По суті це означає, що всі елементи повинні або мати закриваючий тег або бути записані в спеціальній формі (як описано нижче), і що всі елементи повинні встановлюватись правильно.

Хоча перекриття в SGML не є нормативним, браузери завжди закривають очі на на нього.

ПРАВИЛЬНО: вложені елементи.

<p>here is an emphasized <em>paragraph</em>.</p>

НЕПРАВИЛЬНО: перекритті елементи

<p>here is an emphasized <em>paragraph.</p></em>

4.2. Імена елементів і атрибутів повинні бути в нижньому регістрі

XHTML документи повинні використовувати нижній регістр для всіх елементів HTML і імена атрибутів. Це розходження необхідно, оскільки XML чутливий до регістру літер, наприклад, <li> і <LI> різні теги.

4.3. Для непустих елементів кінцеві теги необхідні

В HTML 4 що оснований на SGML, в деяких елементах могли бути опущені закриваючі теги; з елементами, маючи на увазі, що після закриття. XML не дозволяє віднустності кінцевих тегів. Всі елементи, крім тих, які оголошені в DTD як EMPTY повинні мати кінцевий тег. Елементи, які були оголошені в DTD як EMPTY можуть мати закриваючий тег чи можуть використовувати порожний скорочений елемент (дивыться Порожны елементи).

ПРАВИЛЬНО: звершені елементи

<p>here is a paragraph.</p><p>here is another paragraph.</p>

НЕПРАВИЛЬНО: незвершені елементи

<p>here is a paragraph.<p>here is another paragraph.

4.4. Значення атрибутів повинні завжди бути взяті в лапки

Всі значення атрибутів повинні бути взяті в лапки, навіть ті, які будуть виглядати як числові.

ПРАВИЛЬНО: значення атрибутів взяті в лапки

<td rowspan="3">

НЕПРАВИЛЬНО: значення атрибутів не взяті в лапки

<td rowspan=3>

4.5. Мінімізація атрибутів

XML не підтримує мінімізацію атрибутів. Пара атрибут-значення має бути написана в повному обсязі. Імена атрибутів, таких, як compact і checked не можуть використовуватись в елементах без певних значень.

ПРАВИЛЬНО: немінімізовані атрибути

<dl compact="compact">

НЕПРАВИЛЬНО: мінімізовані атрибути

<dl compact>

4.6. Порожні Елементи

Порожні елементи повинні мати або кінцевий тег, або початковий тег повинен закінчуватися />. Наприклад, <br/> або <br></br>. Дивіться Керівницво по сумісності з HTML для отримання інформації про способи забезпечення сумісність з HTML 4 браузерами.

ПРАВИЛЬНО: закриті (зачинені) порожні елементи

<br/><hr/>

НЕПРАВИЛЬНО: незакриті (незачинені) порожні елементи

<br><hr>

4.7. Білий простір (пробіл) в обробці значення атрибуту

Коли браузер обчислює атрибути, він робить це у відповідності до розділ 3.3.3 в [XML]:

4.8. Елементи скриптів і стилів

У XHTML, елементи скриптів і стилів мають бути оголошені через #PCDATA. В результаті < і & будуть розглядатися як початок розмітки, а також такі сполучення, як &lt; і &amp; будуть визнані в якості посилання на сутності XML процесором на < і & відповідно. Упаковка змісту елементу сценарію або стилю всередині CDATA, визначаючи розділ включення розширення цих структур.

<script type="text/javascript">
<![CDATA[
 ... unescaped script content ...
]]>
</script>

CDATA розділи розпізнаються процесором XML і з'являються у вигляді вузлів у об'єктної моделі документа (Document Object Model), дивіться розділ 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 атрибут при визначенні ідентифікаторів фрагментів на елементах, перерахованих вище. Дивіться керівництво по сумісності з HTML для інформації про забезпечення таких якорів та зворотну сумісність при обслуговуванні XHTML документів як тип text/html.

Відзначимо, що в XHTML 1.0 атрибут name в цих елементах є офіційно застарілим, і буде усунений в наступних версіях XHTML.

4.11. Атрибути із заздалегідь визначеним набором значень

HTML 4 і XHTML обидва мають деякі атрибути, які заздалегідь визначені і обмежені у наборі значень (наприклад, атрибут type елементу input). В SGML і XML вони називаються перерахованими атрибутами. Відповідно HTML 4, інтерпретація цих значень без урахування регістру, тому значення TEXT було еквівалентно значенням text. Відповідно XML, інтерпретація цих значень залежить від регістру і в XHTML 1 всі ці величини визначаються в нижньому регістрі.

4.12. Утворення посилань із шістнадцятирічними (hex) значеннями

SGML і XML обидва дозволяють посилання до символів через шістнадцятиричні значення. В SGML ці посиланняз використанням або &#Xnn;, або &#xnn; структур. В XML документах Ви маєте мождивістьвживати ті самі конструкції в нижньому регістрі (тобто &#xnn;)

5. Проблеми сумісності

Даний розділ є нормативним.

Хоча для документів XHTML 1.0 не потрібні браузери, що підтримують сумісність з ними. Керівництво для створення конкурентоспроможних документів можуть будти знайдені в додатку С.

5.1. Тип Інтернет Медіа

XHTML документи, які слідують принципам, викладеним у додатку C, "керівництво по сумісності з HTML" може будти позначене через тип Інтернет Медіа "text/html" [RFC2854], оскільки вони сумісні з більшістю браузерів HTML. Ці документи, а також будь-які інші документи, відповідні до цієї специфікації, також можуть бути позначені в типі Інтернет Медіа "application/xhtml+xml", як визначено в [RFC3236]. За додатковою інформацією про використання типу Інтернет Медіа з XHTML, дивіться інформаційну записку [XHTMLMIME].

A. DTD

Ця програма є нормативною.

Ці DTD і набори осіб форм утворюють нормативну частину цієї специфікації. Повний набір DTD файлів, разом з декларацією XML і SGML Open Catalog (відкритий каталог) входить в zip файл і gzip'd tar файл для цієї специфікації. Користувачі, які шукають місцеві копії DTD файлів для роботи з ними повинні скачати і використовувати архіви так само, як і специфічні DTD посилання нижче.

A.1. Визначення типу документа

These DTDs approximate the HTML 4 DTDs. W3C рекомендує використовувати авторитетні версій цих DTD на їх системних ідентифікаторів при перевірці вмісту. Якщо ви хочете використовувати ці DTD місцево необхідно завантажити один з архівів цієї версії. Для повноти роскриття питання, нормативні версії DTDs ключені нижче:

A.1.1. XHTML-1.0-Strict

Файл DTD/xhtml1-strict.dtd є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в цьому окремому розділі.

A.1.2. XHTML-1.0-Transitional

Файл DTD/xhtml1-transitional.dtd є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в цьому окремому розділі.

A.1.3. XHTML-1.0-Frameset

Файл DTD/xhtml1-frameset.dtd є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в цьому окремому розділі.

A.2. Набори сутностей

The XHTML сутностей такі ж самі, як і для HTML 4, але були змінені, щоб бути дійсними для декларації XML 1.0 сутностей. Зверніть увагу на обличчя для знака валюті євро (&euro; чи &#8364;, чи &#x20AC;) визначений у рамках спеціальних символів.

A.2.1. Latin-1 символи

Файл DTD/xhtml-lat1.ent є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в цьому окремому розділі.

A.2.2. Спеціальні символи

Файл DTD/xhtml-special.ent є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в окремому розділі.

A.2.3. Символи

Файл DTD/xhtml-symbol.ent є нормативною частиною цієї специфікації. Анотований вміст цього файлу, доступний в окремому розділі.

B. Заборони в елементах

Ця програма є нормативною.

Ці елементи мають в елементах заборони які вони можуть містити (дивіться SGML винятки). Ця заборона поширюється на всю глибину вкложеності, тобто він містить усі елементи, нащадка.

a
не повинні містити інші елементи.
pre
не повинні містити елементи img, object, big, small, sub чи sup.
button
не повинні містити елементи input, select, textarea, label, button, form, fieldset, iframe чи isindex.
label
не повинні містити іншого елемента label.
form
не повинні містити інші елементами form.

C. Керівні принципи сумісності HTML

Ця програма є інформативною.

Цей додаток сумує короткі технічні керівні принципи для авторів, які хочуть, щоб їх XHTML документи відображались на існуючих HTML браузерах. Зауважимо, що ця рекомендація не визначає, як HTML браузери користувачів повинні обробляти HTML документи. Він також не визначає зміст типу Інтернет Медіа text/html. За цими визначеннями, дивіться [HTML4] і [RFC2854] відповідно.

C.1. Інструкцій обробки і оголошення XML

Пам'ятайте, що інструкції з обробки надаються на деякі браузери. Крім того, деякі браузери інтерпретують XML декларації так, що документ є невизнаною формою XML замість HTML, і тому не може відобразити документ, як це очікувалося. Для сумісності з цими типами старих браузерах, ви можете уникнути використання інструкцій обробки XML і декларацій. Пам'ятайте про те, коли в документ не включено XML декларації, то можна використовувати тільки кодування символів за замовчуванням UTF-8 або UTF-16.

C.2. Порожні елементи

Включіть пробіл перед заднім / і > на порожних елементах, наприклад <br/>, <hr/> і <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

Не вмикайте більше одного isindex елементу в head документа. Елемент 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.3, випуску 5. На жаль, це обмеження не може бути виражено в XHTML 1.0 DTD. Через це зміни, необхідно подбати при перетворенні існуючих документів HTML. Значення цих атрибутів має бути унікальним в межах документа, термін дії, і будь-які посилання на ці ідентифікатори фрагмента (обидва як внутрішні, так і зовнішні) мають бути оновлені значення має бути змінена в ході перетворення.

Зверніть увагу, що збір правового значення в XML 1.0 розділу 2.3, випуску 5 набагато більше, ніж дозволено використовувати в ID і NAME типів, визначених в HTML 4. При визначенні ідентифікаторів фрагмента буде назад сумісний, тільки строк, відповідних шаблоном [A-Za-z][A-Za-z0-9:_.-]* повинен бути використаний. Дивіться розділ 6.2 з [HTML4] для отримання додаткової інформації.

Нарешті, відзначимо, що XHTML 1.0 має застарілий атрибут name для елементів a, applet, form, frame, iframe, img і map, і вона буде вилучена з XHTML у наступних версіях.

C.9. Кодування

Історично склалося, що кодування документа HTML або зазначеного веб-сервером за допомогою кодування параметром HTTP заголовка типу вмісту, або чере зелемент meta в самому документі. У документі XML, кодування документа вказується на декларації XML (наприклад, <?xml version="1.0" encoding="EUC-JP"?>). З метою портативного представлення документу з конкретним кодуваням найкращим підходом є забезпечення того, що веб-сервер надає правильні заголовки. Якщо це не можливо, документ, який хоче встановити свою кодування явним повинна включати в себе як декларація XML кодування декларації і meta http-екв заяви (наприклад, <meta http-equiv="Content-type" content="text/html; charset=EUC-JP"/>). Відповідно XHTML-браузерів, значення кодування декларацією декларації XML має пріоритет.

Примітка: пам'ятайте, що якщо документ має включати кодування декларації в META HTTP-екв заявою, що документ може завжди бути витлумачено сервери HTTP та/або агентів, як користувач інтернету тип засобів масової інформації визначено в цій заяві. Якщо документ буде послужили кілька типів носіїв, HTTP сервера повинна бути використана для встановлення кодування документа.

C.10. Булеві атрибути

Деякі HTML браузери не в змозі інтерпретувати булеві атрибути, коли вони присутні у їхній повній (несвернутій) формі, як це передбачено в XML 1.0. Ця проблема не зачіпає браузерів сумісних з HTML 4. У роботі беруть участь наступні атрибути: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11. Document Object Model і XHTML

Рекомендація Document Object Model рівня 1 [DOM] визначає об'єктну модель документа інтерфейсів для XML і HTML 4. HTML 4 об'єктна модель документа HTML вказує, що імена елементів і атрибутів повертаються у верхньому регістрі. Об'єкт XML Document модель вказує, що імена елементів і атрибутів повертаються у випадку вони вказані. У XHTML 1.0, елементи та атрибути, зазначені в нижньому регістрі. Це удаване розходження може розглядатися у двох аспектах:

  1. Браузери, які мають доступ до XHTML документів через тип Інтернет Медіа text/html через DOM може використовувати HTML DOM, і може спиратися на імена елементів і атрибутів повертаються у верхньому регістрі з цих інтерфейсів.
  2. Браузери, що мають доступ до XHTML документів через тип Інтернет Медіа text/xml, application/xml чи application/xhtml+xml так само може використовувати XML DOM. Елементи й атрибути будуть повертатися в нижньому регістрі. Крім того, деякі XHTML елементи можуть чи не можуть з'являтися в дереві об'єктів, оскільки вони є необов'язковими в моделі вмісту (наприклад, елемент tbody підмножина table). Це відбувається тому, що в HTML 4 Деякі елементи були дозволені до мінімуму такі, що їх початкові і кінцеві мітки опущені (функції SGML). Це неможливо в XML. Замість того, автори документа вимагають, щоб вставити сторонніми елементами, XHTML внесла елементи є обов'язковими. Браузерам необхідно адаптуватися до цього відповідним чином. За додатковою інформацією з даної теми, дивіться [DOM2]

C.12. Використання Амперсанда в значеннях атрибутів (та де інде)

В обох SGML і XML, амперсанд ("&") оголошує про початок посилання на сутність (наприклад, сполучення &reg; що використовується для визначення символу зареєстрованого товарного знаку "?). На жаль, багато HTML браузерів мовчки ігнорують неправильне використання амперсанда в HTML документах - лікування амперсанд, що не схожі на обличчя посилання як буквальне амперсанд. Браузери осовані на XML не будуть миритися з цим неправильним використанням, і будь-який документ, який використовує амперсанд неправильне не буде "дійсним", і, отже, не буде відповідати даному стандарту. З метою забезпечення того, щоб документи, сумісні з історичним броузерів HTML і XML-основаних користувацьких агентів, амперсанд, що використовуються в документі, які повинні розглядатися як літерних символів повинна бути виражена себе як суб'єкта (наприклад, "&amp;"). Наприклад, якщо атрибут href атрибута елемента посилається на скрипт CGI який приймає параметри, він повинен бути виражений як http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user а не як http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

C.13. Cascading Style Sheets (CSS) і XHTML

Рекомендація каскадних таблиць стилів рівня 2 [CSS2] визначаються властивості стилю, які застосовуються для дерева розбору в HTML або XML документів. Відмінності в розборі буде проводити різні візуальні або слухові результатів, в залежності від використовуваних селектор. Наступні поради будуть зменшити цей ефект для документів, які подаються без змін і як типи носіїв:

  1. Таблиць стилів CSS для XHTML повинні використовувати нижній регістр імен елементів і атрибутів.
  2. У таблицях TBODY елемента будуть встановлені парсерів агента користувача HTML, але не аналізатор агента користувача XML. Тому завжди треба явно додати TBODY елемента, якщо він згадується в селектор CSS.
  3. У просторі імен XHTML, браузери, як очікується, визнають "id" як атрибут атрибут типу ID. Таким чином, таблиці стилів повинні мати можливість продовжувати використання скороченого селектора "#" синтаксис, навіть якщо агент користувача не читав DTD.
  4. У просторі імен XHTML, браузери визначають атрибут "class". Таким чином, таблиці стилів повинні мати можливість продовжувати використання скороченого "." селектор синтаксису.
  5. CSS визначає різні правила відповідності для HTML і XML документів; Пам'ятайте, що в HTML правила застосовуються до документів XHTML поставлятися у вигляді HTML і XML, правила застосовуються до документів XHTML поставлятися у вигляді XML.

C.14. Звернення до елементів стилів при виступі в якості XML

В HTML 4 і XHTML, елемент style може бути використаний для визначення внутрішніх правил стилів документа. В XML, декларації XML шаблонів використовується для визначення стилю правил. Для того, щоб бути сумісним з цією Конвенцією, елемент style повиннен мати свій ідентифікатор фрагмента, який задається за допомогою атрибуту id, і визначення XML стилів повинні звобити посилання на цей фрагмент. Наприклад:

 
<?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An internal stylesheet example</title>
<style type="text/css" id="internalStyle">
  code {
    color: green;
    font-family: monospace;
    font-weight: bold;
  }
</style>
</head>
<body>
<p>
  This is text that uses our 
  <code>internal stylesheet</code>.
</p>
</body>
</html>

C.15. Різниці в символах пробілу в HTML та XML

Деякі символи, які є законними в документах HTML, є незаконними в документі XML. Наприклад, в HTML, FormFeed характеру (U+000C) розглядається як білий простір, в XHTML, у зв'язку з визначенням XML's символів, це незаконно.

C.16. Обізвані посилання до символів &apos;

Їменна характеристика &apos; (апостроф, U+0027) була введена в XML 1.0 але не відображається в HTML. Авторам слід використовувати сполучення &#39; замість &apos; для роботи, як очікувалося, в браузерах HTML 4.

D. Подяки

Ця програма є інформативною.

Ця специфікація була написана за участю членів робочої групи HTML W3C (англ. W3C HTML Working Group).

При публікації другого видання, до складу авторів входили:

Steven Pemberton, CWI/W3C (HTML Working Group Chair)
Daniel Austin, Grainger
Jonny Axelsson, Opera Software
Tantek ?lik, Microsoft
Doug Dominiak, Openwave Systems
Herman Elenbaas, Philips Electronics
Beth Epperson, Netscape/AOL
Masayasu Ishikawa, W3C (HTML Activity Lead)
Shin'ichi Matsui, Panasonic
Shane McCarron, Applied Testing and Technology
Ann Navarro, WebGeek, Inc.
Subramanian Peruvemba, Oracle
Rob Relyea, Microsoft
Sebastian Schnitzenbaumer, SAP
Peter Stark, Sony Ericsson

При публікації першого видання, до складу авторів входили:

Steven Pemberton, CWI (HTML Working Group Chair)
Murray Altheim, Sun Microsystems
Daniel Austin, AskJeeves (CNET: The Computer Network through July 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 visiting engineer through September 1999)
Shane McCarron, Applied Testing and Technology (The Open Group through August 1999)
Ann Navarro, HTML Writers Guild
Zach Nies, Quark
Dave Raggett, W3C/HP (HTML Activity Lead)
Patrick Schmitz, Microsoft
Sebastian Schnitzenbaumer, Stack Overflow
Peter Stark, Phone.com
Chris Wilson, Microsoft
Ted Wugofski, Gateway 2000
Dan Zigmond, WebTV Networks

E. Список літератури

Ця програма є інформативною.

[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
[DOM2]
"Document Object Model (DOM) Level 2 Core Specification", A. LeHors, et al., 13 листопада 2000 року
Остання версія доступна за адресою: http://www.w3.org/TR/DOM-Level-2-Core
[HTML]
"HTML 4.01 Specification", D. Raggett, A. LeHors, 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.
[RFC2045]
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed and N. Borenstein, листопад 1996 року. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.
[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 року
Цей документ застарів по [RFC3023].
доступна за адресою: 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
[RFC2854]
"RFC2854: The text/html Media Type", D. Conolly, L. Masinter, червень 2000 року
доступна за адресою: http://www.ietf.org/rfc/rfc2854.txt
[RFC3023]
"RFC3023: XML Media Types", M. Murata, S. St.Laurent, D. Kohn, січень 2001 року
Цей документ скасовує [RFC2376].
доступна за адресою: http://www.ietf.org/rfc/rfc3023.txt
[RFC3066]
"Tags for the Identification of Languages", H. Alvestrand, січень 2001 року
доступна за адресою: http://www.ietf.org/rfc/rfc3066.txt
[RFC3236]
"The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, січень 2002 року
доступна за адресою: http://www.ietf.org/rfc/rfc3236.txt
[XHTML+MathML]
"XHTML plus Math 1.1 DTD", "A.2 MathML as a DTD Module", Mathematical Markup Language (MathML) Version 2.0. доступна за адресою: http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd
[XHTMLMIME]
"XHTML Media Types", Masayasu Ishikawa, 1 серпня 2002 року
Остання версія доступна за адресою: http://www.w3.org/TR/xhtml-media-types
[XHTMLMOD]
"Modularization of XHTML", M. Altheim et al., 10 квітня 2001 року.
Остання версія доступна за адресою: http://www.w3.org/TR/xhtml-modularization
[XML]
"Extensible Markup Language (XML) 1.0 Specification (Second Edition)", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 жовтня 2000 року.
Остання версія доступна за адресою: http://www.w3.org/TR/REC-xml
[XMLNS]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 січня 1999 року.
Простори імен XML надають простий спосіб для кваліфікації імен, що використовуються в документах XML, асоціюючи їх з просторами імен, визначених в URI XML.
Остання версія доступна за адресою: http://www.w3.org/TR/REC-xml-names
[XMLC14N]
"Canonical XML Version 1.0", J. Boyer, 15 березня 2001 року.
Цей документ описує метод генерації фізичних уявлень, канонічних форм, XML документу.
Остання версія доступна за адресою: http://www.w3.org/TR/xml-c14n

Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0