Kolejny draft artykułu z kursu na browsehappy.

Nie pamiętam już dokładnie kiedy zacząłem korzystać z XHTML. Pisząc już w HTML przestrzegałem wielu reguł, które stały się standardem w XHTML. Ot, po prostu wydawały mi się logiczne. Ale dopiero niedawno zacząłem używać XHTML poprawnie - serwując dokumenty jako application/xhtml+xml.

Wiedziałem wtedy, że na mojej drodze pojawią się problemy. Nie myślałem jednak, że będzie ich aż tyle. Jest po prostu cała masa drobnych spraw, które skutecznie potrafią utrudnić życie.

Niniejszy artykuł nie jest argumentem “za” bądź “przeciw” XHTML. Jest to właściwie tylko krótki spis problemów na jakie możesz natrafić zmierzając w stronę standardów. Czy zdecydujesz się na HTML 4.01, XHTML 1.0 serwowany jako text/html dla wszystkich przeglądarek czy XHTML 1.0 serwowany jako application/xhtml+xml dla tych, które potrafią to obsłużyć i text/html dla które nie potrafią - pozostawiam w Twojej gestii.

Jeszcze jedno - wymienione “haczyki” dotyczą tylko przeglądarek, które obsługują application/xhtml+xml, tym samym traktując XHTML jako XML. Prawdopodobnie jest to powód, dla którego tak rzadko mówiło się o tych problemach we wczesnych dniach XHTML - mało kto używał przeglądarek potrafiących obsłużyć taki mime-type, zatem wszyscy słali pliki jako text/html.

Obecnie wysyłanie XHTML jako XML jest coraz powszechniejsze. Głównie ze względu na fakt, że coraz więcej osób korzysta z przeglądarek takich jak Firefox, Mozilla, Opera, Safari czy innych, potrafiących w pełni obsłużyć XHTML/XML.

Także webdeveloperzy stają się coraz bardziej wyczuleni na to, czym w rzeczywistości jest XHTML (a nie jest tylko HTML’em ze zmienionym doctype, jakimś tam prologiem XML i slashami na końcu tagów).

Co jakiś czas wybuchały dyskusje na temat zastosowania i sposobu użycia XHTML. Niektóre były całkiem “gorące”. Ci, którzy brali w nich udział - wiedzą.

Jeśli zamierzasz umieścić na swojej stronie system negocjacji mime-type i wysyłać poprawnie XHTML, będziesz musiał wiedzieć co może się stać (i się stanie) z dokumentami, które zamierzasz opublikować, oraz jak uniknąć potencjalnych problemów.
Na początek polecam lekturę Content Negotiation i Serving up XHTML with the correct MIME type.

Inne, bardziej oczywiste, różnice między HTML a XHTML są wymieniane w każdym, dobrym, kursie XHTML: pisz tagi i ich atrybuty małymi literami, wartości atrybutów zawsze ubieraj w cudzysłów, sprawdź czy wszystkie tagi są pozamykane, itd.

Niemniej jest tego więcej gdy chcemy przesyłać XHTML jako XML.

Poprawna struktura jest wymagana

Przesyłane dokumenty muszą być poprawnie sformatowanym XML’em (co niekoniecznie znaczy, że są walidującym się XHTML). Nie ma kompromisów, nie ma miejsca na błąd. Jeśli dokument nie jest poprawny, wszystkie “zgodne” przeglądarki jak jeden mąż (z wyjątkiem IE, rzecz jasna) poinformują o błędzie i zaprzestaną renderowania strony.

Deklaracja kodowania znaków w prologu XML może byc wymagana

Jeśli w swoich dokumentach używasz kodowania innego niż UTF-8 czy UTF-16, deklaracja XML jest wymagana. Chyba, że informacja o kodowaniu wysyłana jest przez serwer.

Czy informacja o kodowaniu powinna być zawarta w nagłówkach wysyłanych przez serwer jest niesprecyzowana. Architecture of the World Wide Web, Volume One: Media Types for XML mówi:

In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing.

Z drugiej jednak strony, XHTML 1.0, Second Edition: Character Encoding mówi nam:

In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers.

Tak czy inaczej, nie zaszkodzi zdefiniować poprawnego kodowania w prologu XML:

<?xml version="1.0" encoding="iso-8859-2"?>