XHTML™ 1.0: Rozszerzalny hipertekstowy język znaczników (wydanie drugie)

Przeformułowanie HTML 4 w XML 1.0

Rekomendacja W3C z 26 stycznia 2000, zrewidowana 1 sierpnia 2002

Ta wersja:

http://www.w3.org/TR/2002/REC-xhtml1-20020801

Ostatnia wersja:

http://www.w3.org/TR/xhtml1

Poprzednia wersja:

http://www.w3.org/TR/2000/REC-xhtml1-20000126

Wersja z zaznaczonymi różnicami:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/xhtml1-diff.html

Autorzy:

Zobacz podziękowania.

Proszę korzystać także z poprawek do tego dokumentu, które mogą zawierać pewne zmiany normatywne. Zobacz również tłumaczenia.

Ten dokument jest także dostępny w następujących nienormatywnych formatach: wieloczęściowy plik XHTML, wersja PostScript, wersja PDF, archiwum ZIP i zgzipowane archiwum TAR.

Copyright ©2002 W3C^® (MIT, INRIA, Keio). Wszelkie prawa zastrzeżone. Zastosowanie mają zasady W3C dotyczące odpowiedzialności prawnej, znaku towarowego, używania dokumentu i licencjonowania oprogramowania.

---

Streszczenie

Ta specyfikacja definiuje drugie wydanie XHTML 1.0, przeformułowania HTML 4 jako aplikacji XML 1.0, oraz trzy DTD odpowiadające tym, które zostały zdefiniowane w HTML 4. Semantyka, czyli znaczenie poszczególnych elementów i ich atrybutów jest zdefiniowana w rekomendacji W3C dla HTML 4. Semantyka ta stanowi też podstawę dla przyszłych rozszerzeń XHTML. Pod warunkiem zastosowania się do kilku wskazówek możliwe jest zachowanie kompatybilności z istniejącymi programami użytkownika HTML.

Status tego dokumentu

Ten rozdział opisuje status tego dokumentu w momencie jego publikacji. Inne dokumenty mogą zastąpić ten dokument. Aktualny status dokumentów z tej serii jest dostępny na stronach W3C.

Ten dokument to drugie wydanie specyfikacji XHTML 1.0 zawierające poprawki z 1 sierpnia 2002 roku. Zmiany w stosunku do poprzedniej rekomendacji są uwidocznione w wersji z zaznaczonymi różnicami.

To drugie wydanie nie jest nową wersją XHTML 1.0 (opublikowanego po raz pierwszy 26 stycznia 2000 roku). Zmiany w tym dokumencie są odzwierciedleniem poprawek przyjętych jako rezultat komentarzy nadesłanych przez wspólnotę internetową oraz w rezultacie postępującej pracy w ramach Grupy Roboczej do spraw HTML (HTML Working Group). Dokument ten nie zawiera zasadniczych zmian — został tylko uzupełniony o różne poprawki.

Lista znanych błędów w tej specyfikacji jest dostępna pod adresem http://www.w3.org/2002/08/REC-xhtml1-20020801-errata.

Błędy w tym dokumencie proszę zgłaszać na adres www-html-editor@w3.org (archiwum). Publiczna debata na temat właściwości HTML odbywa się na liście dyskusyjnej www-html@w3.org (archiwum).

Ten dokument powstał jako część działalności W3C HTML Activity. Cele HTML Working Group (tylko dla członków) są opisane w statucie Grupy Roboczej do spraw HTML.

W momencie publikacji grupie roboczej nie było wiadome istnienie jakichkolwiek patentów odnoszących się do tej specyfikacji. Aktualny wykaz ujawnień patentowych odnoszących się do tej specyfikacji można znaleźć na stronie ujawnień patentowych Grupy Roboczej.

Wykaz aktualnych rekomendacji W3C oraz innych dokumentów technicznych można znaleźć pod adresem http://www.w3.org/TR.

Krótki spis treści

Pełny spis treści

1. Czym jest XHTML?

Ten rozdział ma charakter informacyjny.

XHTML to rodzina obecnych i przyszłych typów dokumentów i modułów, które kopiują i rozszerzają HTML 4 [HTML4]. Rodzina typów dokumentów XHTML bazuje na języku XML i docelowo jest stworzona do współpracy z programami użytkownika opartymi na XML. Szczegółowe informacje dotyczące tej rodziny i jej rozwoju są opisane w [XHTMLMOD].

XHTML 1.0 (ta specyfikacja) jest pierwszym typem dokumentu z rodziny XHTML. Jest to przeformułowanie trzech typów dokumentów HTML 4 jako aplikacji XML 1.0 [XML]. Jest przeznaczony do używania jako język dla zawartości zgodnej z XML, lecz także, po zastosowania się do prostych wskazówek, jest obsługiwany przez programy użytkownika zgodne z HTML 4. Autorzy, którzy przeniosą zawartość swoich stron do formatu XHTML 1.0 odniosą następujące korzyści:

• Dokumenty XHTML są zgodne z XML. Jako takie mogą być przeglądane, edytowane i walidowane przy pomocy standardowych narzędzi XML.
• Dokumenty XHTML mogą być napisane tak, by były obsługiwane tak samo lub nawet lepiej niż wcześniej, zarówno przez istniejące programy użytkownika zgodne z HTML 4, jak i przez nowe programy użytkownika zgodne z XHTML 1.0.
• Dokumenty XHTML mogą wykorzystywać aplikacje (np. skrypty i aplety) opierające się albo na obiektowym modelu dokumentu HTML, albo na obiektowym modelu dokumentu XML [DOM].
• W miarę rozwijania się rodziny XHTML, dokumenty zgodne z XHTML 1.0 będą z większym prawdopodobieństwem zdolne współpracować pośród różnych środowisk XHTML.

Rodzina XHTML to kolejny krok w rozwoju Internetu. Przechodząc na XHTML autorzy stron mogą czerpać korzyści z możliwości XML, mając jednocześnie pewność, że zostanie zachowana wsteczna, jak i przyszła kompatybilność ich stron.

1.1. Czym jest HTML 4?

HTML 4 [HTML4] to aplikacja SGML (standardowy uogólniony język znaczników) zgodna z międzynarodowym standardem ISO 8879. Jest powszechnie postrzegany jako standardowy język publikacji w sieci WWW.

SGML jest językiem służącym do definiowania języków znacznikowych, zwłaszcza tych używanych w elektronicznej wymianie dokumentów, zarządzaniu dokumentami i ich publikowaniu. HTML to przykład języka zdefiniowanego w SGML.

SGML był używany od połowy lat 80. XX wieku i pozostawał językiem dość stabilnym. Stabilność ta w dużej mierze brała się z faktu, że SGML posiada szeroki zasób możliwości i jednocześnie jest elastyczny. Jednakże ta elastyczność ma swą cenę — wysoki stopień złożoności, który zahamował jego wprowadzenie w różne środowiska, m.in. w sieć WWW.

HTML początkowo miał być językiem służącym do wymiany dokumentów naukowych i technicznych, odpowiednim do używania przez specjalistów. HTML rozwiązał problem złożoności SGML poprzez zdefiniowanie niewielkiego zestawu strukturalnych i semantycznych znaczników nadającego się do tworzenia względnie prostych dokumentów. By dodatkowo uprościć strukturę dokumentu, HTML wprowadził obsługę hipertekstu. Później dodano też możliwość obsługi multimediów.

W wyjątkowo krótkim czasie HTML stał się niesamowicie popularny i szybko wykroczył poza swój pierwotny cel. Od powstania HTML szybko zaczęły się pojawiać nowe elementy przeznaczone dla tego języka (jako standard) mające przystosować HTML do poziomych, wysoko wyspecjalizowanych rynków. Wielość tych nowych elementów doprowadziła do pojawiania się problemów ze wzajemnym współdziałaniem dokumentów na różnych platformach.

1.2. Czym jest XML?

XML™ to skrót od Extensible Markup Language [XML], co oznacza rozszerzalny język znaczników.

XML był pomyślany jako sposób na odzyskanie możliwości i elastyczności SGML bez jego dużej złożoności. Mimo że XML jest ograniczoną formą SGML, to zachowuje większość z jego bogatych możliwości i ciągle zawiera wszystkie najczęściej używane funkcje znane z SGML.

Zachowując te użyteczne cechy, XML jednocześnie usuwa wiele z bardziej złożonych właściwości SGML, które czyniły authoring i projektowanie odpowiedniego oprogramowania zarówno trudnym, jak i kosztownym zajęciem.

1.3. Dlaczego potrzebujemy XHTML?

Korzyści z przejścia na XHTML 1.0 są opisane powyżej. Ogólnie rzecz biorąc niektóre z tych korzyści to:

• Dzięki nowym znacznikom autorzy stron internetowych i twórcy programów użytkownika ciągle odkrywają nowe sposoby wyrażania swych pomysłów. W XML wprowadzanie nowych elementów czy dodatkowych atrybutów elementów jest stosunkowo proste. Rodzinę XHTML zaprojektowano, by przystosować te rozszerzenia poprzez moduły i techniki XHTML do rozwijania nowych, zgodnych z XHTML, modułów (opisanych w specyfikacji Modularyzacja XHTML). Moduły te pozwolą łączyć istniejące i nowe funkcje przy jednoczesnym rozszerzaniu zawartości i projektowaniu nowych programów użytkownika.
• Ciągle pojawiają się nowe, alternatywne sposoby dostępu do Internetu. Przy projektowaniu rodziny XHTML wzięto pod uwagę możliwości wzajemnego współdziałania z programami użytkownika. Dzięki nowym programom użytkownika i mechanizmom profilowania dokumentów, serwery, serwery proxy i programy użytkownika będą mogły wykonać najlepszą transformację zawartości. W końcu będzie możliwe rozwijanie zawartości w XHTML, którą będzie można używać z każdym programem użytkownika zgodnym z XHTML.

2. Definicje

Ten rozdział ma charakter normatywny.

2.1. Terminologia

Następujące terminy są używane w tej specyfikacji. Terminy te rozszerzają definicje zawarte w [RFC2119] bazując na podobnych definicjach zawartych w ISO/IEC 9945-1:1990 [POSIX.1]:

Nieokreślony w specyfikacji (ang. unspecified)

Kiedy wartość lub zachowanie jest nieokreślone w specyfikacji, oznacza to, że specyfikacja nie definiuje żadnych wymagań dotyczących przenośności cechy w implementacji nawet, gdy spotka się ona z dokumentem używającym tej cechy. Dokument wymagający w takim przypadku określonego zachowania, zamiast tolerowania dowolnego zachowania, gdy używana jest ta cecha, nie jest dokumentem ściśle zgodnym z XHTML.

Ma / będzie (w znaczeniu powinności; ang. shall)

Zobacz: „musi”.

Może (ang. may)

Biorąc pod uwagę implementacje, wyraz „może” będzie interpretowany jako opcjonalna cecha, która nie jest wymagana w tej specyfikacji, ale może być przez implementacje obsługiwana. Biorąc pod uwagę zgodność dokumentu ze standardem, wyraz „może” oznacza, że opcjonalna własność nie może być użyta. Termin „opcjonalny” posiada taką samą definicję jak „może”.

Musi (ang. must)

W niniejszej specyfikacji wyraz „musi” będzie interpretowany jako obowiązkowe wymaganie dla implementacji lub dla dokumentów ściśle zgodnych z XHTML, w zależności od kontekstu. Ta sama definicja odnosi się do wyrazów „ma” i „będzie”, jeśli są używane w znaczeniu powinności.

Obsługiwany (ang. supported)

Niektóre cechy określone w tej specyfikacji są opcjonalne. Jeśli dana cecha jest obsługiwana, zachowuje się w sposób zdefiniowany w tej specyfikacji.

Opcjonalny (ang. optional)

Zobacz: „może”.

Powinien (ang. should)

Biorąc pod uwagę implementacje, wyraz „powinien” będzie interpretowany jako zalecenie dla implementacji, ale nie jako wymaganie. Biorąc pod uwagę dokumenty, wyraz „powinien” będzie interpretowany jako zalecana praktyka programistyczna dla dokumentów i jako wymaganie dla dokumentów ściśle zgodnych z XHTML.

Zarezerwowany (ang. reserved)

Wartość lub zachowanie nie jest określone w specyfikacji, ale nie może być używane przez dokumenty zgodne ze standardem, ani obsługiwane przez zgodne ze standardem programy użytkownika.

2.2. Terminy ogólne

Atrybut (ang. attribute)

Atrybut to parametr posiadany przez element zadeklarowany w DTD. Typ atrybutu i zakres wartości jakie może przyjmować, łącznie z ewentualną wartością domyślną, są zdefiniowane w DTD.

Cechy (ang. facilities)

Cechy to elementy, atrybuty oraz semantyka skojarzona z tymi elementami i atrybutami.

Dokument (ang. document)

Dokument to strumień danych, który po połączeniu z innymi strumieniami do których się odwołuje, posiada taką strukturę, że przechowuje informacje zawarte wewnątrz elementów zorganizowanych w sposób zdefiniowany w odpowiednim DTD. Więcej informacji w rozdziale Zgodność dokumentu ze standardem.

DTD

DTD, czyli definicja typu dokumentu, to zestawienie deklaracji oznakowania XML definiujące deklaracje, które łącznie definiują dopuszczalną strukturę, elementy i atrybuty, których można używać w dokumencie stosującym się do tego DTD.

Element

Element to jednostka strukturalna dokumentu zadeklarowana w DTD. Model zawartości elementu jest zdefiniowany w DTD, a dodatkowa semantyka może być zdefiniowana w słownym opisie elementu.

Implementacja (ang. implementation)

Zobacz: „program użytkownika”.

Parsowanie (ang. parsing)

Parsowanie to proces podczas którego następuje skanowanie dokumentu, a informacja wewnątrz niego zawarta jest przefiltrowywana w kontekście elementów w których ta informacja jest składowana.

Poprawny składniowo (ang. well-formed)

Dokument jest poprawny składniowo, gdy posiada strukturę zgodną z zasadami zdefiniowanymi w Rozdziale 2.1 Rekomendacji XML 1.0 [XML].

Program użytkownika (ang. user agent)

Program użytkownika to system przetwarzający dokumenty XHTML zgodnie z niniejszą specyfikacją. Więcej informacji w rozdziale Zgodność programów użytkownika ze standardem.

Renderowanie (ang. rendering)

Renderowanie to czynność, podczas której prezentowane są informacje zawarte dokumencie. Prezentacja ta jest dokonywana w formie najbardziej właściwej dla danego środowiska (np. dźwiękowo, wizualnie, w druku).

Walidacja (ang. validation)

Walidacja to proces, podczas którego dokumenty są weryfikowane pod względem skojarzonych z nimi DTD, w celu zapewnienia zgodności struktury, użycia elementów i użycia atrybutów z definicjami zawartymi w DTD.

3. Normatywna definicja XHTML 1.0

Ten rozdział ma charakter normatywny.

3.1. Zgodność dokumentu ze standardem

Ta wersja XHTML zawiera definicję dokumentów ściśle zgodnych z XHTML 1.0, które są ograniczone do elementów i atrybutów znajdujących się w przestrzeniach nazw XML i XHTML 1.0. W rozdziale 3.1.2 dostępne są informacje dotyczące używania XHTML z innymi przestrzeniami nazw, na przykład w celu włączenia do dokumentów XHTML metadanych wyrażonych w formacie RDF.

3.1.1. Dokumenty ściśle zgodne ze standardem

Dokument ściśle zgodny ze standardem XHTML to dokument XML, który wymaga jedynie cech opisanych jako obowiązkowe w tej specyfikacji. Taki dokument musi spełniać wszystkie z następujących kryteriów:

1. Musi stosować się do ograniczeń zawartych w jednym z trzech DTD opisanych w rozdziale DTD i w dodatku B.

2. Elementem głównym dokumentu musi być html.

3. Element główny dokumentu musi zawierać deklarację xmlns dla przestrzeni nazw XHTML [XMLNS]. Przestrzeń nazw dla XHTML jest zdefiniowana jako http://www.w3.org/1999/xhtml. Przykładowy element główny może wyglądać następująco:

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

4. W dokumencie przed elementem głównym musi występować deklaracja DOCTYPE. Identyfikator publiczny zawarty w deklaracji DOCTYPE musi odnosić się do jednego z trzech DTD opisanych w rozdziale DTD poprzez użycie odpowiedniego formalnego identyfikatora publicznego (ang. Formal Public Identifier). Identyfikator systemowy może być zmieniony w celu uwzględnienia lokalnych konwencji systemu.

   <!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. Podzbiór DTD nie może być użyty w celu przesłonięcia jakichkolwiek encji parametrycznych w DTD.

Deklaracja XML nie jest wymagana we wszystkich dokumentach XML; jednakże zdecydowanie zaleca się, by autorzy dokumentów XHTML używali deklaracji XML we wszystkich swoich dokumentach. Deklaracja taka jest wymagana, gdy kodowanie znaków w dokumencie jest inne niż domyślne UTF-8 lub UTF-16 i żadne kodowanie nie zostało określone przez protokół wyższego rzędu. Oto przykład dokumentu XHTML zawierającego deklarację 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="pl" lang="pl">
   <head>
     <title>Wirtualna Biblioteka</title>
   </head>
   <body>
     <p>Nowy adres: <a href="http://example.org/">example.org</a>.</p> 
   </body>
</html>

3.1.2. Używanie XHTML z innymi przestrzeniami nazw

Przestrzeń nazw XHTML może być używana razem z innymi przestrzeniami nazw XML zgodnie z [XMLNS], jednak takie dokumenty nie są zdefiniowanymi powyżej dokumentami ściśle zgodnymi ze standardem XHTML 1.0. Jednym z zadań W3C jest określanie zgodności ze standardem dla dokumentów wymagających wielu przestrzeni nazw; zobacz na przykład [XHTML+MathML].

Następujący przykład ukazuje sposób, w jaki XHTML 1.0 może być użyty w połączeniu z Rekomendacją MathML:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl" lang="pl">
  <head>
    <title>Przykład matematyczny</title>
  </head>
  <body>
    <p>Znaczniki języka MathML:</p>
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply> <log/>
        <logbase>
          <cn> 3 </cn>
        </logbase>
        <ci> x </ci>
      </apply>
    </math>
  </body>
</html>

Następujący przykład ukazuje sposób, w jaki znaczniki XHTML 1.0 mogą być użyte w ramach innej przestrzeni nazw XML:

<?xml version="1.0" encoding="UTF-8"?>
<!-- na początku domyślna przestrzeń nazw to „books” -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="pl" lang="pl">
  <title>Fałszywa dwunastka</title>
  <isbn:number>1568491379</isbn:number>
  <notes>
    <!-- HTML staje się domyślną przestrzenią nazw
      dla hipertekstowych komentarzy -->
    <p xmlns='http://www.w3.org/1999/xhtml'>
        Dostępne także <a href="http://www.w3.org/">w Internecie</a>.
    </p>
  </notes>
</book>

3.2. Zgodność programów użytkownika ze standardem

Program użytkownika zgodny ze standardem musi spełniać wszystkie poniższe kryteria:

1. W celu zgodności z Rekomendacją XML 1.0 [XML] program użytkownika musi parsować i sprawdzać poprawność składniową dokumentu XHTML. Jeśli program użytkownika ma być walidujący, musi także sprawdzać poprawność strukturalną dokumentów biorąc pod uwagę odpowiednie DTD zgodnie z [XML].
2. Jeśli program użytkownika ma wspierać cechy zdefiniowane w tej specyfikacji lub wymagane przez tę specyfikację poprzez odnośniki normatywne, musi robić to w sposób zgodny z definicjami tych cech.
3. Gdy program użytkownika przetwarza dokument XHTML jako czysty XML, powinien rozpoznawać jedynie atrybuty typu ID (tj. atrybut id w większości elementów XHTML) jako identyfikatory cząstkowe.
4. Jeśli program użytkownika napotka na element, którego nie rozpoznaje, musi przetworzyć zawartość tego elementu.
5. Jeśli program użytkownika napotka na atrybut, którego nie rozpoznaje, musi zignorować całość specyfikacji atrybutu (tj. atrybut i jego wartość).
6. Jeśli program użytkownika napotka na wartość atrybutu, której nie rozpoznaje, musi zastosować wartość domyślną atrybutu.
7. Jeśli napotka na odwołanie do encji (innej niż encje zdefiniowane w tej rekomendacji lub w rekomendacji XML), której deklaracji program użytkownika nie przetworzył (co może się zdarzyć, jeśli deklaracja jest zawarta w zewnętrznym podzbiorze, którego program użytkownika nie wczytał), odwołanie do encji powinno być przetworzone jako znaki (zaczynając na znaku et i kończąc na średniku), które tworzą to odwołanie do encji.
8. Program użytkownika, który podczas przetwarzania zawartości napotka na znaki lub odwołania do encji znakowej, które są rozpoznane, lecz nie mogą być renderowane, może w zamian zastosować inne renderowanie mające to samo znaczenie, albo musi wyświetlić dokument w sposób dający do zrozumienia użytkownikowi, że nie zostało zastosowane normalne renderowanie.

9. Białe znaki są obsługiwane według poniższych reguł. Następujące znaki są zdefiniowanymi w [XML] białymi znakami:

   • SPACJA ( )
   • TABULATOR POZIOMY (	)
   • POWRÓT KARETKI (
)
   • WYSUW WIERSZA (
)

   Procesor XML normalizuje właściwe dla różnych systemów kody końca wiersza w pojedynczy znak WYSUWU WIERSZA, który jest przekazywany do aplikacji.

   Program użytkownika w celu przetworzenia białych znaków musi skorzystać z definicji zawartych w CSS [CSS2]. Zauważ, że rekomendacja CSS2 właściwie nie podejmuje problemu obsługi białych znaków w niełacińskich zestawach znaków. Tą kwestią zajmą się przyszłe wersje CSS; wtedy powyższy odnośnik będzie zaktualizowany.

Weź pod uwagę, że w celu stworzenia kanonicznego dokumentu XHTML muszą być zastosowane powyższe reguły, a także reguły zawarte w [XMLC14N].

4. Różnice w stosunku do HTML 4

Ten rozdział ma charakter informacyjny.

Ponieważ XHTML jest aplikacją XML, pewne praktyki będące całkowicie dopuszczalne w HTML 4 [HTML4] (opartym na języku SGML) muszą być zmienione.

4.1. Dokumenty muszą być poprawne składniowo

Poprawność składniowa to nowe pojęcie wprowadzone przez [XML]. Zasadniczo oznacza ono, że wszystkie elementy muszą albo mieć znaczniki zamykające, albo być napisane w specjalnej formie (opisanej poniżej), oraz, że wszystkie elementy muszą być prawidłowo zagnieżdżone.

Mimo że zachodzenie na siebie elementów jest niedopuszczalne w języku SGML, to jest ono dość powszechnie tolerowane w istniejących przeglądarkach.

PRAWIDŁOWO: elementy zagnieżdżone

NIEPRAWIDŁOWO: elementy zachodzące na siebie

4.2. Nazwy elementów i atrybutów muszą być pisane małymi literami

W dokumentach XHTML nazwy wszystkich elementów i atrybutów muszą być pisane małymi literami. Ta różnica jest konieczna, ponieważ XML rozróżnia wielkość liter, np. <li> i <LI> to dwa różne znaczniki.

4.3. Dla niepustych elementów wymagane są znaczniki końcowe

W opartym na SGML-u języku HTML 4 w niektórych elementach można było pominąć znaczniki końcowe. XML na to nie pozwala. Wszystkie elementy, z wyjątkiem tych zadeklarowanych w DTD jako puste (EMPTY), muszą posiadać znacznik końcowy. Elementy zadeklarowane w DTD jako puste (EMPTY) mogą posiadać znacznik końcowy lub mogą używać formy skróconej dla elementu pustego (zobacz: Puste elementy).

PRAWIDŁOWO: elementy zakończone

NIEPRAWIDŁOWO: elementy niezakończone

4.4. Wartości atrybutów zawsze muszą być ujęte w cudzysłów

Wszystkie wartości atrybutów zawsze muszą być ujęte w cudzysłów, nawet jeśli posiadają wartość numeryczną.

PRAWIDŁOWO: wartości atrybutów ujęte w cudzysłów

NIEPRAWIDŁOWO: wartości atrybutów nieujęte w cudzysłów

4.5. Minimalizacja atrybutów

XML nie wspiera minimalizacji atrybutów. Pary atrybut – wartość muszą być napisane w pełnej formie. Nazwy atrybutów takie, jak compact i checked nie mogą występować w elementach bez przypisanej określonej w specyfikacji wartości.

PRAWIDŁOWO: atrybuty niezminimalizowane

NIEPRAWIDŁOWO: atrybuty zminimalizowane

4.6. Puste elementy

Puste elementy muszą albo posiadać znacznik końcowy, albo znacznik początkowy musi kończyć się znakami />, na przykład <br/> lub <hr></hr>. Informacje dotyczące wstecznej kompatybilności tego sposobu z programami użytkownika wspierającymi HTML 4 znajdują się w rozdziale Wskazówki dotyczące kompatybilności z HTML.

PRAWIDŁOWO: zakończone puste elementy

NIEPRAWIDŁOWO: niezakończone puste elementy

4.7. Obsługa białych znaków w wartościach atrybutów

Programy użytkownika przetwarzają atrybuty zgodnie z rozdziałem 3.3.3 [XML]:

• Ucinają wiodące i końcowe białe znaki.
• Zamieniają sekwencje jednego lub więcej białych znaków (włączając znaki łamiące wiersz) na pojedynczą spację międzywyrazową.

4.8. Elementy skryptów i stylów

W języku XHTML elementy skryptów i stylów są zadeklarowane jako mające zawartość #PCDATA. W rezultacie < i & będą traktowane jako początek oznakowania, a encje takie jak < i & będą rozpoznane przez procesor XML jako odwołania do encji — odpowiednio < i &. Umieszczenie zawartości elementu skryptu czy stylu w obrębie sekcji CDATA pozwoli uniknąć rozwinięcia tych encji.

<script type="text/javascript">
<![CDATA[
... zawartość skryptu, może zawierać znaki & i < ...
]]>
</script>

Sekcje CDATA są rozpoznawane przez procesor XML i pojawiają się jako węzły w obiektowym modelu dokumentu, zobacz: rozdział 1.3 Rekomendacji DOM Level 1 [DOM].

Alternatywnym wyjściem jest użycie zewnętrznych dokumentów skryptów i stylów.

4.9. Wykluczenia SGML

Pisząc w języku SGML twórca DTD może wykluczyć możliwość zawierania się pewnych elementów wewnątrz innych elementów. Takie zakazy (zwane „wykluczeniami”) nie są możliwe w XML.

Na przykład DTD HTML 4 Strict zabrania zagnieżdżania się elementu a wewnątrz innego elementu a na jakiejkolwiek głębokości. W XML nie ma możliwości wyrażenia takich zakazów. Mimo że zakazy te nie mogą być zdefiniowane w DTD, to jednak pewne elementy nie powinny być zagnieżdżane. Wykaz takich elementów można znaleźć w normatywnym rozdziale Zakazy zawierania się elementów.

4.10. Elementy z atrybutami id i name

HTML 4 zdefiniował atrybut name dla elementów a, applet, form, frame, iframe, img i map. HTML 4 wprowadził także atrybut id. Oba te atrybuty stworzono do używania ich jako identyfikatory cząstkowe.

W XML identyfikatory cząstkowe są typu ID, a w jednym elemencie może występować tylko jeden atrybut tego typu. Zatem w XHTML 1.0 atrybut id zdefiniowano jako mający typ ID. By zapewnić to, że dokumenty XHTML 1.0 są poprawnie skonstruowanymi dokumentami XML, dokumenty XHTML 1.0 MUSZĄ używać atrybutu id podczas definiowania identyfikatora cząstkowego w elementach wymienionych powyżej. Informacje pozwalające upewnić się o wstecznej kompatybilności takich identyfikatorów w sytuacji, gdy dokument XHTML ma zadeklarowany typ mediów text/html znajdują się w rozdziale Wskazówki dotyczące kompatybilności z HTML.

Weź pod uwagę, że w XHTML 1.0 atrybut name w wymienionych powyżej elementach jest formalnie uznany za przestarzały (ang. deprecated) i będzie usunięty w przyszłych wersjach XHTML.

4.11. Atrybuty z predefiniowanymi zbiorami wartości

Zarówno w HTML 4, jak i w XHTML niektóre atrybuty mają predefiniowane i ograniczone zbiory wartości (np. atrybut type elementu input). W SGML i XML są one zwane atrybutami wyliczeniowymi. W HTML 4 podczas interpretacji tych wartości nie były rozróżniane wielkie i małe litery, więc wartość TEXT była równoznaczna z wartością text. W XML podczas interpretacji tych wartości wielkie i małe litery są rozróżniane, a w XHTML 1 wszystkie takie wartości zdefiniowano jako pisane małymi literami.

4.12. Odwołania do encji jako wartości szesnastkowe

Zarówno SGML, jak i XML zezwalają, by odwołania znakowe używały wartości szesnastkowych. W SGML takie odwołania mogą mieć formę &#Xnn; lub &#xnn;. W dokumentach XML musisz używać wersji z małą literą (tj. &#xnn;)

5. Problem kompatybilności

Ten rozdział ma charakter normatywny.

Wprawdzie nie ma obowiązku, by dokumenty XHTML 1.0 były kompatybilne z istniejącym programami użytkownika, jednak w praktyce łatwo taką kompatybilność osiągnąć. Wskazówki dotyczące tworzenia kompatybilnych dokumentów można znaleźć w dodatku C.

5.1. Internetowe typy mediów

Dokumenty XHTML, które podążają za wskazówkami zawartymi w dodatku C mogą używać internetowego typu mediów „text/html” [RFC2854], ponieważ są kompatybilne z większością przeglądarek HTML. Te i wszystkie inne dokumenty zgodne z niniejszą specyfikacją mogą używać internetowego typu mediów „application/xhtml+xml” zdefiniowanego w [RFC3236]. Więcej informacji na temat używania typów mediów z XHTML znajduje się w nocie informacyjnej [XHTMLMIME].

A. DTD

Ten dodatek ma charakter normatywny.

Poniższe DTD i zestawy encji stanowią normatywną cześć tej specyfikacji. Kompletny zestaw plików DTD wraz z deklaracją XML i SGML Open Catalog jest włączony do pliku ZIP i zgzipowanego pliku TAR dla tej specyfikacji. Użytkownicy chcący pracować z lokalnymi kopiami DTD powinni raczej ściągnąć jedno z archiwów, zamiast korzystać z poniższych odnośników do poszczególnych DTD.

A.1. Definicje typów dokumentu

Te definicje typów dokumentu są podobne do DTD z HTML 4. W3C jednak zaleca korzystanie z wiarygodnych wersji tych DTD ze zdefiniowanymi identyfikatorami systemowymi (SYSTEM) podczas walidacji zawartości. Jeśli musisz korzystać z tych DTD lokalnie powinieneś ściągnąć jedno z archiwów tej wersji. Dla uzupełnienia, normatywne wersje DTD załączono tutaj:

A.1.1. XHTML-1.0-Strict

Plik DTD/xhtml1-strict.dtd jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

A.1.2. XHTML-1.0-Transitional

Plik DTD/xhtml1-transitional.dtd jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

A.1.3. XHTML-1.0-Frameset

Plik DTD/xhtml1-frameset.dtd jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

A.2. Zestawy encji

Zestawy encji XHTML są takie same, jak te dla HTML 4, zostały tylko zmodyfikowane w taki sposób, by były poprawnymi strukturalnie deklaracjami encji XML 1.0. Zauważ, że encja dla znaku waluty euro (€ lub € lub €) jest zdefiniowana jako część znaków specjalnych.

A.2.1. Alfabet łaciński 1

Plik DTD/xhtml-lat1.ent jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

A.2.2. Znaki specjalne

Plik DTD/xhtml-special.ent jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

A.2.3. Symbole

Plik DTD/xhtml-symbol.ent jest normatywną częścią tej specyfikacji. Zawartość tego pliku wraz z przypisami jest dostępna w tym osobnym rozdziale.

B. Zakazy zawierania się elementów

Ten dodatek ma charakter normatywny.

Dla następujących elementów określono zakazy zawierania się w nich niektórych elementów (zobacz: Wykluczenia SGML). Te zakazy stosują się do wszystkich głębokości zagnieżdżania się, tj. dotyczą wszystkich elementów potomnych.

a

nie może zawierać innych elementów a.

pre

nie może zawierać elementów img, object, big, small, sub i sup.

button

nie może zawierać elementów input, select, textarea, label, button, form, fieldset, iframe i isindex.

label

nie może zawierać innych elementów label.

form

nie może zawierać innych elementów form.

C. Wskazówki dotyczące kompatybilności z HTML

Ten dodatek ma charakter informacyjny.

Ten dodatek zawiera podsumowanie wskazówek projektowych dla autorów chcących, by ich dokumenty XHTML były poprawnie renderowane przez istniejące programy użytkownika HTML. Zauważ, że ta rekomendacja nie definiuje sposobu, w jaki programy użytkownika zgodne ze standardem HTML powinny przetwarzać dokumenty HTML. Nie definiuje też znaczenia internetowego typu mediów text/html. Definicje te znajdują się odpowiednio: w [HTML4] i [RFC2854].

C.1. Instrukcje przetwarzania i deklaracja XML

Powinieneś wiedzieć, że w niektórych programach użytkownika instrukcje przetwarzania są renderowane. W dodatku niektóre programy użytkownika interpretują deklarację XML tak, że biorą dokument za nierozpoznany XML, zamiast za HTML. Przez to dokument może być renderowany w sposób inny, niż oczekiwano. Być może, w celu zachowania kompatybilności z takimi starszymi przeglądarkami, będziesz chciał uniknąć używania instrukcji przetwarzania i deklaracji XML. Pamiętaj jednak, że gdy w dokumencie brakuje deklaracji XML, może on używać tyko domyślnego kodowania znaków: UTF-8 lub UTF-16.

C.2. Puste elementy

W pustych elementach przed końcowymi znakami / i > dołącz spację, np. <br />, <hr /> i <img src="karen.jpg" alt="Karen" />. Używaj zminimalizowanej formy znacznika dla pustych elementów, np. <br />, podczas gdy alternatywna forma <br></br> dozwolona przez XML doprowadzi do nieoczekiwanych rezultatów w wielu istniejących programach użytkownika.

C.3. Minimalizacja elementów i zawartość pustych elementów

W przypadku pustych elementów, których model zawartości jest różny od EMPTY (na przykład pusty tytuł czy akapit) nie używaj formy zminimalizowanej (np. używaj <p> </p>, a nie <p />).

C.4. Zagnieżdżone arkusze stylów i skrypty

Jeśli w twoim arkuszu stylów występują znaki <, &, ]]> lub --, użyj zewnętrznego arkusza stylów. Jeżeli w twoim skrypcie występują znaki <, &, ]]> lub -- użyj zewnętrznego skryptu. Weź pod uwagę, że parsery XML mogą bez powiadomienia usuwać zawartość komentarzy. Zatem dawna praktyka ukrywania skryptów i arkuszy stylów wewnątrz „komentarzy” w celu zachowania wstecznej kompatybilności może nie przynieść oczekiwanych efektów w programach użytkownika opartych na XML-u.

C.5. Kody końca wiersza w wartościach atrybutów

Unikaj stosowania kodów końca wiersza i wielokrotnych spacji wewnątrz wartości atrybutu. Ich obsługa w różnych programach użytkownika jest niespójna.

C.6. Element isindex

Nie używaj więcej niż jednego elementu isindex wewnątrz elementu head. Element isindex jest uznany za przestarzały i zastąpiony przez element input.

C.7. Atrybuty lang i xml:lang

Podczas określania języka elementu używaj zarówno atrybutu lang, jak i xml:lang. Wartość atrybutu xml:lang ma pierwszeństwo.

C.8. Identyfikatory cząstkowe

W XML odwołania do URI [RFC2396] zakończone identyfikatorami cząstkowymi postaci "#foo" nie odnoszą się do elementów z atrybutem name="foo", tylko do elementów posiadających atrybut typu ID, np. atrybut id w HTML 4. Wiele z istniejących klientów HTML nie akceptuje używania atrybutów typu ID w ten sposób, dlatego by zapewnić maksymalną kompatybilność można określić tę samą wartość dla obydwu tych atrybutów (np. <a id="foo" name="foo">...</a>).

Ponieważ zbiór dopuszczalnych wartości, które mogą przyjmować atrybuty typu ID, jest znacznie mniejszy niż dla atrybutów typu CDATA, typ atrybutu name został zmieniony na NMTOKEN. Atrybut ten jest ograniczony w ten sposób, że może przyjmować tylko takie wartości jak typ ID albo jak produkcja Name w Rozdziale 2.3, produkcji 5 specyfikacji XML 1.0. Niestety ograniczenie to nie może być wyrażone w DTD XHTML 1.0. Z powodu tej zmiany trzeba zachować ostrożność podczas konwersji istniejących dokumentów HTML. Wartości tych atrybutów muszą być unikatowe w całym dokumencie, poprawne strukturalnie, a każde odwołanie do tych identyfikatorów cząstkowych (zarówno wewnętrzne, jak i zewnętrzne) musi być aktualizowane, jeśli wartości zostały zmienione podczas konwersji.

Zauważ, że zbiór dopuszczalnych wartości w Rozdziale 2.3, produkcji 5 XML 1.0 jest znacznie większy, niż zbiór wartości dozwolony dla typów ID i NAME zdefiniowanych w HTML 4. Podczas definiowania wstecznie kompatybilnych identyfikatorów cząstkowych powinny być używane tylko łańcuchy znaków odpowiadające wyrażeniu regularnemu [A-Za-z][A-Za-z0-9:_.-]*. Więcej informacji w Rozdziale 6.2 [HTML4].

Powinieneś też pamiętać, że w XHTML 1.0 atrybut name dla elementów a, applet, form, frame, iframe, img i map został uznany za przestarzały i będzie usunięty w przyszłych wersjach XHTML.

C.9. Kodowanie znaków

Kodowanie znaków dokumentu HTML było określane przez serwer internetowy poprzez poprzez parametr charset nagłówka HTTP Content-Type albo poprzez element meta w samym dokumencie. W XML kodowanie znaków dokumentu jest określane w deklaracji XML (np. <?xml version="1.0" encoding="EUC-JP"?>). Najlepszym wyjściem w celu zapewnienia prezentacji dokumentów z określonym kodowaniem znaków jest upewnienie się, że serwer internetowy dostarcza prawidłowe nagłówki. Jeżeli jest to niemożliwe, to jeśli dokument ma mieć wyraźnie określone kodowanie znaków, musi zawierać zarówno deklarację kodowania w ramach deklaracji XML, jak i instrukcję meta http-equiv (np. <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). W programach użytkownika zgodnych z XHTML wartość deklaracji kodowania w deklaracji XML ma pierwszeństwo.

Uwaga: jeśli dokument musi zawierać deklarację kodowania znaków w ramach instrukcji meta http-equiv, wtedy serwery HTTP i/lub programy użytkownika zawsze mogą go interpretować jako dokument posiadający internetowy typ mediów zdefiniowany w tej instrukcji. W przypadku dokumentu przesyłanego z więcej niż jednym typem mediów, do ustawienia kodowania dokumentu musi zostać użyty serwer HTTP.

C.10. Atrybuty logiczne

Niektóre programy użytkownika HTML nie potrafią interpretować atrybutów logicznych gdy występują one w pełnej (niezminimalizowanej) formie wymaganej przez XML 1.0. Nie dotyczy to jednak programów użytkownika zgodnych z HTML 4. Problem dotyczy następujących atrybutów: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11. Obiektowy model dokumentu i XHTML

Rekomendacja Document Object Model level 1 [DOM] definiuje interfejsy obiektowego modelu dokumentu dla XML i HTML 4. Obiektowy model dokumentu HTML 4 określa, że nazwy elementów i atrybutów HTML są zwracane w formie używającej wielkich liter. Obiektowy model dokumentu XML określa, że nazwy elementów i atrybutów są zwracane w formie używającej takich wielkości liter, w jakich są zdefiniowane. W XHTML 1.0 elementy i atrybuty są zdefiniowane przy użyciu małych liter. Do tej ewidentnej różnicy można podejść dwojako:

1. Programy użytkownika uzyskujące dostęp do dokumentów XHTML przesyłanych jako internetowy typ mediów text/html poprzez DOM mogą używać HTML-owego DOM i stosować nazwy elementów i atrybutów, które są zwracane przez te interfejsy w formie używającej wielkich liter.
2. Programy użytkownika uzyskujące dostęp do dokumentów XHTML przesyłanych jako internetowy typ mediów text/xml, application/xml lub application/xhtml+xml mogą także używać XML-owego DOM. Elementy i atrybuty będą zwracane w formie używającej małych liter. Również niektóre elementy XHTML mogą, lecz nie muszą pojawiać się w drzewie obiektowym, ponieważ są opcjonalne w modelu zawartości (np. element tbody wewnątrz table). Dzieje się tak, gdyż w HTML 4 niektóre elementy mogły być zminimalizowane tak, że zarówno znacznik początkowy, jak i końcowy były pominięte (jest to cechą SGML). Praktyka ta jest niemożliwa w XML. By autorzy dokumentów nie musieli wstawiać dodatkowych elementów, w XHTML elementy te są opcjonalne. Programy użytkownika muszą się do tego odpowiednio przystosować. Więcej informacji na ten temat w [DOM2]

C.12. Używanie znaków et w wartościach atrybutów (i gdzie indziej)

Zarówno w SGML, jak i w XML, znak et („&”, ang. ampersand) oznacza początek odwołania do encji (np. ® dla symbolu zarejestrowanego znaku towarowego „®”). Niestety wiele programów użytkownika HTML ignorowało nieprawidłowe użycie znaków et w dokumentach HTML — traktując znaki et niewyglądające na początek odwołania do encji, jako literalne znaki et. Programy użytkownika oparte na XML nie będą tolerowały takiego nieprawidłowego użycia — każdy dokument używający znaków et w taki sposób nie będzie uznany za poprawny strukturalnie i w rezultacie za niezgodny z niniejszą specyfikacją. Aby upewnić się, że dokumenty są kompatybilne ze starszymi programami użytkownika HTML i programami użytkownika opartymi na XML, znaki et używane w dokumencie mające być traktowane jako znaki literalne muszą być wyrażone przez odwołanie do encji (np. &). Na przykład gdy atrybut href elementu a odnosi się do skryptu CGI otrzymującego parametry, musi mieć postać http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user, a nie http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

C.13. Kaskadowe arkusze stylów (CSS) i XHTML

Rekomendacja Cascading Style Sheets level 2 [CSS2] definiuje właściwości stylów odnoszące się do drzewa parsowania dokumentów HTML lub XML. Różnice w parsowaniu będą skutkowały odmiennymi rezultatami wizualnymi czy dźwiękowymi, w zależności od użytych selektorów. Poniższe wskazówki zminimalizują ten efekt dla dokumentów przesyłanych bez modyfikacji jako oba typy mediów:

1. Nazwy elementów i atrybutów w arkuszach stylów CSS dla XHTML powinny być pisane małymi literami.
2. W tabelach istnienie elementu tbody będzie wywiedzione przez parser programu użytkowika HTML, ale nie przez parser programu użytkownika XML. Dlatego powinieneś zawsze wprost dodawać element tbody jeśli istnieje odwołanie do niego w selektorze CSS.
3. Wewnątrz przestrzeni nazw XHTML programy użytkownika powinny rozpoznawać atrybut id jako atrybut typu ID. Arkusze stylów powinny zatem posiadać zdolność do kontynuowania z użyciem składni selektora ze skrótem „#” nawet jeśli program użytkownika nie wczytuje DTD.
4. Wewnątrz przestrzeni nazw XHTML programy użytkownika powinny rozpoznawać atrybut class. Arkusze stylów powinny zatem posiadać zdolność do kontynuowania z użyciem składni selektora ze skrótem „.”.
5. CSS definiuje odmienne reguły zgodności ze standardem dla dokumentów HTML i XML. Weź pod uwagę, że reguły HTML mają zastosowanie do dokumentów XHTML przesyłanych jako HTML, a reguły XML — do dokumentów XHTML przesyłanych jako XML.

C.14. Odwoływanie się do elementów stylów w XML

W HTML 4 i XHTML do zdefiniowania wewnętrznych reguł stylów dokumentu może być użyty element style. W XML do tego celu służy deklaracja xml-stylesheet. By zachować kompatybilność z tą konwencją, elementy style powinny posiadać swój zbiór identyfikatorów cząstkowych określony poprzez atrybut id, a deklaracja xml-stylesheet powinna się do niego odwoływać. Na przykład:

<?xml-stylesheet href="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="pl" lang="pl">
<head>
<title>Przykład z wewnętrznym arkuszem stylów</title>
<style type="text/css" id="internalStyle">
   code {
     color: green;
     font-family: monospace;
     font-weight: bold;
   }
</style>
</head>
<body>
<p>
   Ten tekst korzysta z naszego
   <code>wewnętrznego arkusza stylów</code>.
</p>
</body>
</html>

C.15. Białe znaki w HTML i XML

Niektóre znaki będące dopuszczalnymi w dokumentach HTML, są niedopuszczalne w dokumentach XML. Na przykład w HTML znak wysuwu strony (U+000C) jest traktowany jako biały znak, zaś w XHTML, na skutek XML-owej definicji znaków, jest uznawany za niedopuszczalny.

C.16. Nazwane odwołanie znakowe '

Nazwane odwołanie znakowe ' (apostrof, U+0027) zostało wprowadzone w XML 1.0, nie występuje jednak w HTML. Tak więc aby uzyskać oczekiwany efekt w programach użytkownika HTML 4, autorzy powinni używać odwołania ' zamiast '.

D. Podziękowania

Ten dodatek ma charakter informacyjny.

Ta specyfikacja została napisana przy udziale członków HTML Working Group (Grupy Roboczej do spraw HTML) działającej w ramach W3C.

Jej skład w momencie publikacji drugiego wydania był następujący:

Steven Pemberton, CWI/W3C (przewodniczący HTML Working Group)
Daniel Austin, Grainger
Jonny Axelsson, Opera Software
Tantek Çelik, 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

W momencie publikacji pierwszego wydania skład ten przedstawiał się następująco:

Steven Pemberton, CWI (przewodniczący HTML Working Group)
Murray Altheim, Sun Microsystems
Daniel Austin, AskJeeves (CNET: The Computer Network do lipca 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 do września 1999)
Shane McCarron, Applied Testing and Technology (The Open Group do sierpnia 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. Bibliografia

Ten dodatek ma charakter informacyjny.

[CSS2]

Cascading Style Sheets, level 2 (CSS2) Specification, B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 maja 1998.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/REC-CSS2.

[DOM]

Document Object Model (DOM) Level 1 Specification, Lauren Wood i in., 1 października 1998.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/REC-DOM-Level-1.

[DOM2]

Document Object Model (DOM) Level 2 Core Specification, A. Le Hors i in., 13 listopada 2000.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/DOM-Level-2-Core.

[HTML]

HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs, 24 grudnia 1999.
Ostatnia wersja jest dostępna pod adresem 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 i N. Borenstein, listopad 1996.
Weź pod uwagę, że ten dokument dezaktualizuje dokumenty RFC1521, RFC1522 i RFC1590.

[RFC2046]

RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, N. Freed i N. Borenstein, listopad 1996.
Dokument jest dostępny pod adresem http://www.ietf.org/rfc/rfc2046.txt.
Weź pod uwagę, że ten dokument dezaktualizuje dokumenty RFC1521, RFC1522 i RFC1590.

[RFC2119]

RFC2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, marzec 1997.
Dokument jest dostępny pod adresem http://www.ietf.org/rfc/rfc2119.txt.

[RFC2376]

RFC2376: XML Media Types, E. Whitehead, M. Murata, lipiec 1998.
Ten dokument jest zdezaktualizowany przez [RFC3023].
Dostępny jest pod adresem http://www.ietf.org/rfc/rfc2376.txt.

[RFC2396]

RFC2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, sierpień 1998.
Ten dokument aktualizuje dokumenty RFC1738 i RFC1808.
Dostępny jest pod adresem http://www.ietf.org/rfc/rfc2396.txt.

[RFC2854]

RFC2854: The text/html Media Type, D. Conolly, L. Masinter, czerwiec 2000.
Dokument jest dostępny pod adresem http://www.ietf.org/rfc/rfc2854.txt.

[RFC3023]

RFC3023: XML Media Types, M. Murata, S. St.Laurent, D. Kohn, styczeń 2001.
Ten dokument dezaktualizuje [RFC2376].
Dostępny jest pod adresem http://www.ietf.org/rfc/rfc3023.txt.

[RFC3066]

Tags for the Identification of Languages, H. Alvestrand, styczeń 2001.
Dokument jest dostępny pod adresem http://www.ietf.org/rfc/rfc3066.txt.

[RFC3236]

The 'application/xhtml+xml' Media Type, M. Baker, P. Stark, styczeń 2002.
Dokument jest dostępny pod adresem 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.
Dokument jest dostępny pod adresem http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd.

[XHTMLMIME]

XHTML Media Types, Masayasu Ishikawa, 1 sierpnia 2002.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/xhtml-media-types.

[XHTMLMOD]

Modularization of XHTML, M. Altheim i in., 10 kwietnia 2001.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/xhtml-modularization.
Polski przekład dostępny pod adresem http://podziemie.net/w3c/xhtml‑mod/overview.

[XML]

Extensible Markup Language (XML) 1.0 Specification (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 października 2000.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/REC-xml.
Polski przekład dostępny pod adresem http://glenik.webpark.pl/xml/rec-xml.pl.html.

[XMLNS]

Namespaces in XML, T. Bray, D. Hollander, A. Layman, 14 stycznia 1999.
Przestrzenie nazw XML dostarczają prostego sposobu kwalifikowania nazw używanych w dokumentach XML poprzez skojarzenie ich z przestrzeniami nazw identyfikowanymi przez URI.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/REC-xml-names.

[XMLC14N]

Canonical XML Version 1.0, J. Boyer, 15 marca 2001.
Dokument opisuje metodę tworzenia fizycznej reprezentacji — kanonicznej formy — dokumentu XML.
Ostatnia wersja jest dostępna pod adresem http://www.w3.org/TR/xml-c14n.