Table of contents

  1. Irracjonalne uwielbienie dla XHTML
    1. X nie jest lekarstwem
    2. Mało kto robi poprawny XHTML
      1. Odróżnianie XHTML od zupy z tagów
      2. Kodowanie
    3. XHTML nie jest Ci potrzebny
      1. Co ma XHTML, czego HTML nie?
    4. Zatem używać HTML, czy XHTML?
    5. Posłowie
      1. Podobne artykuły

XHTMLEX TURBO

Napisałem sporo stron w XHTML, dlatego irracjonalne uwielbienie dla XHTML także i mnie dotyczy.

Webmasterzy chcący przerobić swoje strony na coś lepszego rzucają się na XHTML, wierząc, że to poprawi ich stronę. Najczęściej nie poprawia. Koncepcje XHTML są niezrozumiane, a jego zalety mocno przereklamowane.

X nie jest lekarstwem

Jeśli zmieniasz zaramkowany otabelkowany po<b>a<br>any HTML Transitional na XHTML Transitional nic nie zyskujesz — ramki i tabelki HTML są tak samo kiepskie w XHTML, a dodatkowy slash na <br /> tego nie zmieni.

XHTML nie jest następcą HTML. XHTML i HTML to ten sam język przedstawiony na dwa sposoby — jako XML i SGML. Ich semantyka nie różni się nic a nic, bo krótka specyfikacja XHTML 1 zawiera tylko opis różnic związanych ze składnią, a we wszystkich pozostałych kwestiach odsyła do HTML 4.

Dużo większą różnicę robi trzymanie się wersji Strict, która nie pozwala na używanie śmietnika z <font>ów, a także otwierania linków w nowym oknie (z czym musisz się pogodzić). Wersję Strict ma zarówno HTML i XHTML, ale i tak nawet walidowanie się kodu jako HTML/XHTML Strict nie jest gwarancją jego jakości (tak jak poprawna gramatyka i ortografia nie czyni książki doskonałą).

Mało kto robi poprawny XHTML

Wysyłanie niepoprawnego XHTML jest gorsze niż wysyłanie niepoprawnego HTML. Przeglądarki muszą odrzucić błędne dokumenty XHTML, a okazji do popełnienia błędu jest dużo więcej, niż się wydaje.

Nieświadomi, nieoduczeni autorzy najczęściej nie mają zielonego pojęcia, że:

  1. XHTML słany jako text/html (domyślne na wszystkich serwerach WWW) nie jest interpretowany jako XHTML, a jako HTML, który zawiera błędy składniowe. Walidator W3C tego nie sprawdza.
  2. Typ pliku określają tylko nagłówki serwera i absolutnie żaden kod w pliku nie jest w stanie wymusić jego interpretacji jako XHTML. W szczególności DOCTYPE i deklaracja XML są bez znaczenia. Walidator W3C tego nie sprawdza.
  3. Nie da się ustawić kodowania znaków w <meta>. Ustawienie w deklaracji XML nie musi zawsze działać. Walidator W3C tego nie sprawdza.
  4. Używanie komentarzy XML (<!-- -->) wewnątrz <script> i <style> jest bez sensu. Przeglądarki mają prawo usunąć wszystkie komentarze z dokumentów XHTML. Walidator W3C tego nie sprawdza.
  5. Nie należy używać document.write, element.innerHTML, ani podobnych. Sposób działania parserów XML wyklucza pierwsze i komplikuje drugie. Walidator W3C tego nie sprawdza.

Jak widać motyw przewodni tej listy — przy tworzeniu XHTML nie można polegać na Walidatorze W3C z powodu jego licznych poważnych błędów, niedoróbek i braków. Walidator wyszukuje XHTML w treści dokumentu, choć żadna przeglądarka tego nie robi.

Odróżnianie XHTML od zupy z tagów

XHTML powinien być wysyłany jako application/xhtml+xml, ale tego typu nie rozumie ani Internet Explorer, ani bot Google. Dla nich trzeba serwować text/html, wyłączając tym samym wszystkie rzeczy, które w XHTML nie są identyczne z HTML.

Żeby poprawnie ustawić typ z poziomu PHP trzeba dodać pare linijek kodu, a dla statycznych pilków użyć mod_rewrite.

Popularna opinia głosi, że XHTML/1.1 nie może być wysyłany jako text/html. Potwierdza to nawet XHTML FAQ opublikowane przez W3C, jednak w obliczu specyfikacji konsorcjum to jest nieprawda. Choć wysyłanie XHTML jako HTML jest generalnie bez sensu, to Nota dot. XHTML MIME Types to tylko odradza (SHOULD NOT), ale nie zabrania (było by wtedy MUST NOT).

Przy właściwym MIME Type przeglądarki nigdy nie użyją quirks mode. Ignorują DOCTYPE i rozpoznają elementy XHTML wg ich przestrzeni nazw (namespace).

Prosty test

Wstaw na swoją “XHTMLową” stronę i zobacz (test u mnie: 1 vs 2):

<p style="color:green"><span style="color:red" />Jeśli ten tekst jest czerwony, to strona jest pełnym błędów HTML, a nie XHTML.</p>

Ten kod wykorzystuje różnicę w interpretacji XHTML i HTMLowej sieczki. XHTML dopuszcza dowolne “samozamykające się” elementy, jak <span/>. Większy test.

Spróbuj też otworzyć swoją stronę przez XMLizujące proxy, które wymusi interpretację jako XHTML.

Kodowanie

Kodowanie powinno być ustawione w nagłówkach HTTP. W przypadku braku deklaracji dla text/* (text/xml) domyślne jest ISO-8859-1 i ma to wyższy priorytet niż deklaracja XML (XML on the Web Has Failed). Dla XMLowych application/* kodowanie jest zależne od BOM i deklaracji XML, z którymi niektóre przeglądarki sobie nie radzą.

Element <meta> nie działa, ponieważ parser XML musi znać kodowanie zanim odczyta jakikolwiek element.

XHTML nie jest Ci potrzebny

Jakie są zalety XHTML/1.0 Strict nad HTML4 Strict? Hm?

Jeśli nie chcesz, żeby byle drobny błąd w składni powodował całkowite niewyświetlanie się strony albo ważne jest dla ciebie poprawne działanie strony pod IE, to wszystko, co oferuje XHTML, będzie dla ciebie tylko utrudnieniem.

Co ma XHTML, czego HTML nie?

Żeby zrozumieć istotę różnic, wypada wiedzieć, co to jest XML.

Wiele pozytywnych rzeczy, które upowszechniły się razem z XHTML (UTF-8, budowa układu bez pomocy tabel, dostoswanie do różnych mediów, itp.) jest przypisywane wyłącznie jemu, choć są one tak samo dostępne w HTML. W XHTML/1.0, poza składnią też wiele się nie zmieniło – XHTML/1.0 Transitional, tak samo jak stary HTML dopuszcza używanie <font>, <center>, <iframe>, itp.

Zatem używać HTML, czy XHTML?

Jeśli nie jesteś w stanie zagwarantować, że Twój kod będzie zawsze poprawny, to nie używaj XHTML w ogóle. Półśrodki jak wysyłanie “XHTML” jako HTML tylko zaśmiecają sieć.

Poprawność gwarantuje używanie narzędzi, które nie traktują XHTML jako tekst. XHTML to nie jest po prostu jakiś tekst, tylko drzewo elementów, które zawsze musi być poprawnie zapisane. Proste PHPowe echowanie i większość systemów szablonów (ze Smarty na czele) nie gwarantuje poprawności XHTML, więc prędzej czy później jakaś niezakodowana encja albo niezamknięty tag wywali całą stronę. Generowanie dokumentu przez serializer DOM→XML, sensowny system szablonów jak PHPTAL lub doczepienie HTML Tidy “na wylocie” daje pewność poprawnego składniowo dokumentu i jednocześnie chroni przed większością ataków XSS.

Problemem będą także skrypty pisane przez autorów, którzy nigdy nie zetknęli się z XHTML działającym w trybie XML. Nawali wszystko, co produkuje Google. Nawalą “łebdwazerowe” frameworki od DHTML-przezywanym-AJAX (np. script.aculo.us, mootools).

Strona pornel.net jest generowana z kodu Wiki do XHTML, a następnie przetwarzana przez XSLT do HTML4.01. Bynajmniej nie dlatego, że to jest dobre rozwiązanie, tylko to był najszybszy sposób odświeżenia mojego starego kiepskiego Wiki.

Ja sporadycznie używam XHTML, ponieważ:

Posłowie

Możesz chcieć użyć HTML Tidy, aby skonwertować XHTML na HTML… lub odwrotnie.

Ta superzaleta XHTML, która nie jest jego zaletą, to oddzielenie treści od prezentacji. Chodzi o CSS, który działa tak samo dobrze z HTML i XHTML (jedyne różnice w CSS to rozróżnianie wielkości liter w selektorach elementów oraz brak wstecznego “dziedziczenia” tła z <body> do <html> — reszta działa identycznie).

Walidator W3C bazuje na prymitywnym DTD, który nie odzwierciedla specyfikacji (sprawdź <a><em><a /></em></a>). Jest lepszy validator.nu i XHTML Schema Validator (szkoda, że kwality padło). Niestety żaden z nich nie sprawdza sposobu wysyłania dokumentu, więc wszystkie zaakceptują “oslashowaną tagzupę”.

Podobne artykuły