Od ponad roku piszę strony wyłącznie 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ą niezrozumiałe, 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
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 ó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:
- 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.
- 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.
- Nie da się ustawić kodowania znaków w . Ustawienie w deklaracji XML nie musi zawsze działać. Walidator W3C tego nie sprawdza.
- Używanie komentarzy XML () wewnątrz i jest bez sensu. Przeglądarki mają prawo usunąć wszystkie komentarze z dokumentów XHTML. Walidator W3C tego nie sprawdza.
- 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. Jego obsługa XHTML jest luzacka, że potrafi nawet HTML 4.01 z DOCTYPE HTML 4.01 i typem text/html uznać za XHTML.
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 XHMTL nie są identyczne z HTML.
Powszechnie stosowana metoda (wśród tych, którzy w ogóle wiedzą o stosowaniu MIME type):
<?php if (strstr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml')) {…xml…} ?>
jest niezgodna ze specyfikacją HTTP, ponieważ wyśle XML nawet jak w nagłówku znajdzie się application/xhtml+xml;q=0, które tego zabrania (żeby poprawnie ustawić typ z poziomu PHP trzeba dodać pare linijek kodu, a dla statycznych pilków 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:
Jeśli ten tekst jest czerwony, to strona jest pełnym błędów HTML, a nie XHTML.
Jeśli ten tekst jest czerwony, to strona jest pełnym błędów HTML, a nie XHTML.
Ten kod wykorzystuje różnicę w interpretacji XHTML i HTMLowej sieczki. XHTML dopuszcza dowolne samozamykające się elementy, jak . Większy test
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 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?
- Bardziej semantyczny? Nie. Oba mają identyczny zestaw elementów i atrybutów, bo XHTML to nie jest osobny język, a jedynie alternatywny sposób przedstawienia HTML.
- Bardziej kompatybilny? Nie. Najpopularniejsza przeglądarka i wyszukiwarka nie obsługują XHTML (w najlepszym przypadku traktując go jak HTML)
- Szybciej się ładuje? Nie. Kulawa implementacja w Gecko nie obsługuje progresywnego wyświetlania, a sam czas parsowania dokumentów jest mikroskopijny w porównaniu z czasem ich ściągania przez Internet.
- Lepszy dla telefonów komórkowych? Nie. W teście kilkunastu mobilnych przeglądarek okazało się, że tylko jedna z nich (Opera) poprawnie obsługuje XHTML.
- Bardziej przyszłościowy? Niekoniecznie. XHTML/2 ma spore różnice w stosunku do XHTML/HTML i obecnie jest z nimi niekompatybilny (może się to jeszcze zmienić). Pełne wykorzystanie XHTML/2 na pewno będzie wymagało konwersji dokumentów.
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.
- XHTML może mieszać się z innymi XMLowymi językami. Można w XHTML osadzić bezpośrednio MathML, SVG, RDF. Można umieścić XHTML w Atom, XSLT, PHPTAL.
- Tworzyć umyślnie błędny XHTML, np. wbić listę w paragraf. W HTML paragraf zostałby automatycznie zamknięty. Dla osób chcących tworzyć prawidłowe dokumenty jest to bez znaczenia.
- Dokument XHTML w którym nie ma encji nazwanych może być wczytany (w celu obróbki lub wyciągania danych) każdym standardowym parserem XML. Jeśli w dokumencie są encje nazwane (zamiast numerycznych), to niezbędny jest parser przetwarzający DTD (o te bywa trudniej, niż o parsery HTML).
- W trybie XHTML przeglądarki nieco ściślej interpretują CSS (właściwości z nie są kopiowane do ) i ignorują najstarsze i najgłupsze elementy JavaScript.
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 ,
, <iframe>, itp.
Zatem używać HTML, czy XHTML?
Po pierwsze — 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.
Ja jeszcze używam XHTML, ponieważ:
- Używam narzędzi, które dokument generują za mnie (nie klepię dokumentów z palca — nie używam PHPowego echo, tylko XSLT i PHPTAL), więc nie muszę polegać na samodyscyplinie i regularnym wizytom u walidatora.
- W Atom wstawianie treści jako XHTML jest o wiele łatwiejsze (oczy mnie bolą od podwójnych encji w RSS).
- Po naoglądaniu się XML bez slasha wygląda głupio.
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 do — reszta działa identycznie).
Walidator W3C bazuje na prymitywnym DTD, który nie odzwierciedla specyfikacji (sprawdź ). Jest ciut lepszy XHTML Schema Validator i bardziej czepialski kwality, ale niestety żaden z nich nie sprawdza sposobu wysyłania dokumentu, więc wszystkie zaakceptują oslashowaną tagzupę.
Podobne artykuły
- Safari blog: Understanding HTML, XML and XHTML — All those Valid XHTML 1.0! links on the web are really saying Invalid HTML 4.01!
- Anne van Kesteren: Quick guide to XHTML — The reason why people are using XHTML is probably based upon an illusion."
- Mark Pilgrim: XHTML's Dirty Little Secret — completely standards compliant XHTML markup is being treated as if it were still HTML with a few weird slashes in places they don't belong
I jeszcze mała uwaga
Orange/ex-Idea w idiotyczny sposób doczepia swój skrypt (http://1.2.3.4/bmi-int-js/smi.js) do wszystkich stron, nawet XHTML wysłanego jako application/xhtml+xml, przez co psuje poprawność XML i strony XHTML nie działają poza czytającym byle syf Pocket IE :P
Licencja: copyleft
Źródło: porneL