Czym jest XHTML i dlaczego warto go poznać
XHTML, czyli Extensible HyperText Markup Language, to reformulacja HTML jako aplikacji XML. Innymi słowy: weź semantykę i elementy HTML, ale wymuś na nich rygor składni XML. Wszystkie tagi zamknięte, wszystkie atrybuty w cudzysłowach, wielkość liter ma znaczenie, i żaden błąd nie przejdzie niezauważony. XHTML to HTML, który chodził do szkoły z internatem i wrócił z perfekcyjnymi manierami.
Dlaczego warto znać XHTML dzisiaj? Bo choć jego popularność spadła na rzecz HTML5, XHTML zostawił trwały ślad w tym, jak piszemy kod. Wiele best practices, które dzisiaj traktujemy jako oczywiste — zamykanie tagów, cytowanie atrybutów, lowercase tagi — to dziedzictwo XHTML. Jeśli kiedykolwiek widziałeś kod HTML, który wygląda czysto i konsekwentnie, prawdopodobnie ktoś pisał go pod wpływem nawyków z XHTML.
Poza tym, XHTML nadal żyje w wielu miejscach. Część systemów CMS generuje XHTML, starsze aplikacje webowe są w nim napisane, a ePub (format e-booków) bazuje na XHTML jako fundamencie. Jeśli kiedykolwiek będziesz musiał parsować dokumenty XHTML programowo, zrozumienie różnic między XHTML a HTML może oszczędzić Ci godzin debugowania.
Krótka historia i ewolucja
XHTML narodził się w 2000 roku, kiedy W3C opublikowało XHTML 1.0 jako “Recommendation”. Kontekst był taki: pod koniec lat 90. web był dziki. Developerzy pisali HTML byle jak, przeglądarki tolerowały byle co, a W3C wierzyło, że przyszłość webu wymaga dyscypliny. XHTML miał być mostem między chaotycznym HTML a uporządkowanym światem XML — zachowując znane elementy HTML, ale wymuszając poprawną składnię.
XHTML 1.0 był w zasadzie HTML 4.01 przepisany w składni XML. Te same elementy, te same atrybuty, ale z rygorystycznymi regułami parsowania. Istniały trzy warianty DTD: Strict (bez elementów prezentacyjnych), Transitional (z deprecated elementami jak <font> i align="center") i Frameset (z ramkami). Większość developerów wybierała Transitional, bo Strict wymagał pełnej separacji treści od prezentacji przez CSS — a CSS w 2000 roku nie był jeszcze na to gotowy.
XHTML 2.0 miał być rewolucją — całkowite zerwanie z backward compatibility, nowe semantyczne elementy, lepsza obsługa formularzy (XForms), i hyperlinking (XLink). Ale W3C posunęło się za daleko. XHTML 2.0 nie był kompatybilny z istniejącym webem — strony napisane w HTML 4 lub XHTML 1.0 nie działałyby w przeglądarce XHTML 2.0. Developerzy zbuntowali się, założyli WHATWG w 2004 roku, i zaczęli pracować nad HTML5. W 2009 roku W3C oficjalnie porzuciło XHTML 2.0 i zaakceptowało HTML5. XHTML 1.0 i XHTML 1.1 pozostały jako ważne standardy, ale przyszłość należała do HTML5.
Kluczowe cechy i filozofia
Fundamentalna różnica między XHTML a HTML to parsowanie. HTML jest parsowany przez parser HTML, który jest tolerancyjny na błędy i stosuje skomplikowane algorytmy error recovery. XHTML jest parsowany przez parser XML, który jest bezlitosny — jeden błąd składni i cały dokument jest odrzucany. W praktyce oznacza to, że XHTML wymusza na developerze pisanie poprawnego kodu, bo inaczej strona po prostu się nie wyświetli (biały ekran z błędem parsowania).
XHTML wymaga kilku rzeczy, których HTML nie wymaga. Po pierwsze: wszystkie elementy muszą być poprawnie zamknięte. <br> musi być <br/> lub <br />. <img> musi mieć zamykający slash. Po drugie: wszystkie atrybuty muszą być w cudzysłowach (podwójnych lub pojedynczych). <td colspan=3> to błąd — musi być <td colspan="3">. Po trzecie: wszystkie tagi i atrybuty muszą być pisane małymi literami. <DIV> to błąd — musi być <div>. Po czwarte: atrybuty boolean muszą mieć wartość — <input disabled> musi być <input disabled="disabled"/>.
XHTML musi być serwowany z odpowiednim MIME type: application/xhtml+xml. To kluczowa różnica — jeśli serwowany jako text/html, przeglądarka parsuje go jako HTML (ignorując rygor XML), co jest powszechnym błędem i źródłem wielu nieporozumień. W praktyce większość stron “XHTML” w internecie było serwowanych jako text/html i parsowanych jako HTML, co czyniło cały rygor składni czysto kosmetycznym.
Filozofia XHTML to “well-formedness jako fundament”. W3C wierzyło, że web powinien ewoluować w kierunku czystych, walidowalnych dokumentów, które mogą być przetwarzane przez dowolne narzędzia XML — nie tylko przeglądarki. XHTML miał być webowym formatem, który jest jednocześnie poprawnym XML, co otwierało drzwi do XSLT transformacji, XPath queries i integracji z innymi standardami XML.
Gdzie XHTML sprawdza się najlepiej
XHTML znalazł swoje miejsce w kilku konkretnych niszach. Pierwsza to ePub — standard e-booków bazuje na XHTML (dokładnie XHTML 1.1 z pewnymi rozszerzeniami). Każdy e-book, który czytasz na Kindle, Kobo czy w Apple Books, to pod spodem dokument XHTML opakowany w archiwum ZIP z metadanymi. Jeśli chcesz tworzyć e-booki programowo albo budować tooling do ePub, musisz rozumieć XHTML.
Druga nisza to mobile web w erze pre-smartphone. Wczesne telefony z XHTML Basic i XHTML Mobile Profile (standardy od OMA — Open Mobile Alliance) używały XHTML jako formatu stron. Operatorzy komórkowi w Japonii (i-mode, EZweb) i Europie (WAP 2.0) wymagały XHTML. To była era, kiedy “mobile web” oznaczał okrojony XHTML renderowany na ekranie 120×160 pikseli.
Trzecia nisza to enterprise i government, gdzie wymagana jest ścisła walidacja dokumentów. Niektóre systemy zarządzania treścią (CMS) w sektorze publicznym generują XHTML, bo łatwiej go przetwarzać automatycznie i archiwizować. Systemy prawne i archiwalne cenią deterministyczne parsowanie, które XML gwarantuje.
Jak wygląda kod w XHTML
Poprawny dokument XHTML 1.0 Strict:
<?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>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<title>Artykuł o XHTML</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
<div id="container">
<h1>Dlaczego zamykam tagi</h1>
<p>
XHTML wymaga dyscypliny. Każdy element musi być zamknięty,
nawet te, które w HTML są <em>void elements</em>.
</p>
<p>
<img src="diagram.png" alt="Diagram porównawczy HTML vs XHTML" />
</p>
<ul>
<li>Tagi lowercase</li>
<li>Atrybuty w cudzysłowach</li>
<li>Elementy poprawnie zagnieżdżone</li>
<li>Self-closing dla void: <br /> <hr /> <img /></li>
</ul>
<form action="/submit" method="post">
<label for="email">Email:</label>
<input type="text" id="email" name="email" value="" />
<input type="submit" value="Wyślij" />
</form>
</div>
</body>
</html>
Zwróć uwagę na kilka detali: deklaracja XML na początku (<?xml version="1.0"?>), namespace xmlns na elemencie <html>, self-closing tagi (<br />, <img />), puste atrybuty z wartością (value=""), i type="text/css" w <link>. Każdy z tych detali jest wymagany przez specyfikację — w HTML większość z nich jest opcjonalna.
Porównaj z tym samym dokumentem w HTML5:
<!DOCTYPE html>
<html lang="pl">
<head>
<meta charset="UTF-8">
<title>Artykuł o XHTML</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div id="container">
<h1>Dlaczego zamykam tagi</h1>
<p>XHTML wymaga dyscypliny. Każdy element musi być zamknięty,
nawet te, które w HTML są <em>void elements</em>.</p>
<p><img src="diagram.png" alt="Diagram porównawczy HTML vs XHTML"></p>
<ul>
<li>Tagi lowercase</li>
<li>Atrybuty w cudzysłowach</li>
<li>Elementy poprawnie zagnieżdżone</li>
<li>Self-closing dla void: <br> <hr> <img></li>
</ul>
<form action="/submit" method="post">
<label for="email">Email:</label>
<input type="text" id="email" name="email">
<input type="submit" value="Wyślij">
</form>
</div>
</body>
</html>
Różnica jest subtelna, ale istotna. HTML5 jest mniej verbose — brak deklaracji XML, prostszy DOCTYPE, niezamykane void elements, brak wymogu type w <link> i <style>.
Ekosystem i narzędzia
Ekosystem XHTML to w dużej mierze ekosystem XML zaadaptowany do web. Walidacja XHTML odbywa się przez W3C Validator, który rozpoznaje DOCTYPE i waliduje dokument przeciwko odpowiedniemu DTD. Narzędzia XML — XPath, XSLT, DOM parsers — działają z XHTML natywnie, co było jednym z głównych argumentów W3C za jego adopcją.
W praktyce developerzy XHTML używali tych samych narzędzi co developerzy HTML: Dreamweaver (który miał tryb XHTML), vim/emacs z odpowiednimi snippets, i później VS Code. Kluczową różnicą było to, że XHTML wymagał walidacji jako części workflow — bez niej nie miałeś pewności, że dokument się wyświetli.
Dzisiaj ekosystem XHTML jest w dużej mierze dziedzictwem. Narzędzia do ePub (Calibre, Sigil, pandoc) generują i edytują XHTML. Biblioteki jak lxml w Pythonie czy jsdom w Node.js potrafią parsować XHTML poprawnie. Ale nowe frameworki webowe (React, Vue, Svelte) generują HTML5, nie XHTML — i to jest standard de facto.
Mocne i słabe strony
Mocne strony XHTML to dyscyplina, którą wymusza. Kod XHTML jest z natury czysty, konsekwentny i łatwy do parsowania. Ponieważ jest poprawnym XML, możesz używać całego ekosystemu XML do jego przetwarzania — XSLT transformacje, XPath queries, programowe generowanie przez DOM. Dla zespołów, które cenią standardy i interoperacyjność, XHTML był naturalnym wyborem.
Kolejna mocna strona: deterministyczne parsowanie. Parser XML daje dokładnie jedno drzewo DOM dla danego dokumentu — nie ma ambiguity, nie ma error recovery, nie ma “przeglądarka A parsuje to inaczej niż przeglądarka B”. W teorii to ogromna zaleta. W praktyce — jak zobaczymy za chwilę — ta zaleta okazała się mieczem obosiecznym.
Słabe strony XHTML to przede wszystkim kruchość. Jeden niezamknięty tag i strona znika — biały ekran z błędem parsowania XML. W świecie, gdzie developerzy kopiują kod ze Stack Overflow i składają strony z fragmentów, to jest nie do zaakceptowania. HTML5 z jego error recovery jest po prostu bardziej praktyczny. Drugi problem: MIME type. Wymóg serwowania jako application/xhtml+xml sprawiał, że wiele stron “XHTML” było w praktyce HTML-em (bo serwery i CDN-y domyślnie serwowały text/html), co czyniło cały rygor bezcelowym.
I wreszcie: XHTML 2.0 pokazał, że W3C straciło kontakt z rzeczywistością developerów. Próba narzucenia niekompatybilnego standardu na istniejący web była arogancka i skazana na porażkę. WHATWG i HTML5 wygrały, bo szanowały istniejący ekosystem i “pave the cowpaths” zamiast “burn the cowpaths”.
Podsumowanie
XHTML to ważna lekcja z historii webu. Powinieneś go znać, jeśli pracujesz z ePub, legacy web applications, albo po prostu chcesz zrozumieć, dlaczego HTML5 wygląda tak, jak wygląda. Nawyki z XHTML — zamykanie tagów, lowercase, cytowanie atrybutów — to dobre nawyki, które warto zachować nawet pisząc HTML5.
Przyszłość XHTML to nisza. ePub nie zniknie, legacy systemy nie znikną, ale nowe projekty webowe wybierają HTML5 (lub jego living standard od WHATWG). XHTML spełnił swoją rolę — podniósł standardy jakości kodu HTML i pokazał, że rygorystyczna składnia ma wartość. Ale web wybrał pragmatyzm nad perfekcjonizm, i to była słuszna decyzja.
