Jak sprawdzić poprawność xhtml?

Jak walidować XHTML? Oznacza to sprawdzenie, czy dokument jest zgodny z dwiema warstwami reguł: składnią XML oraz zadeklarowanym DTD lub schematem. XHTML 1.0 jest przeformułowaniem HTML 4.01 w XML, więc dokument może być dobrze sformułowany (well-formed), ale jednocześnie nieprawidłowy (invalid), na przykład gdy w XHTML 1.0 Strict pojawia się <a target="_blank">.

Walidacja XHTML polega na sprawdzeniu, czy dokument jest jednocześnie zgodny z dwiema warstwami reguł:

1. Zasady składni XML: poprawnie zagnieżdżone znaczniki, atrybuty w cudzysłowie, obowiązkowe zamykanie wszystkich elementów (w tym pustych, takich jak <br />), pojedynczy element główny, spójne zadeklarowane kodowanie itp.
2. Reguły DTD lub zadeklarowany schemat: jakie elementy i atrybuty istnieją, w jakim kontekście mogą się pojawić i jakie wartości są dozwolone. Oto klasyczne DTD dla XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic oraz XHTML Modularization.

Dokument może być poprawnie sformułowany w XML, a mimo to być nieprawidłowy: na przykład, jeśli użyjesz <a target="_blank"> w XHTML 1.0 Strict, składnia będzie nienaganna, ale atrybut target nie istnieje w tym DTD. To rozróżnienie między dobrze sformułowanym (well-formed) a prawidłowym (valid) jest główną przyczyną nieporozumień, gdy ktoś widzi błąd i nie rozumie dlaczego.

Warto także pamiętać, że XHTML 1.0 jest przeformułowaniem HTML 4.01 w XML, zdefiniowanym przez W3C. Dziś jego praktyczna wartość jest dwojaka: służy do starszych projektów, które nadal są serwowane jako application/xhtml+xml lub text/html, oraz służy jako dyscyplina intelektualna do pisania czystego kodu znaczników. Jeśli potrzebujesz pełnego kontekstu normatywnego dotyczącego walidacji XHTML, głównym źródłem jest especificación de XHTML 1.0 del W3C.

Walidatory, które są warte uwagi (i kiedy którego użyć)

Nie ma jednego „poprawnego” walidatora. Wybór zależy od tego, czy walidujesz fragment, stronę produkcyjną, całą witrynę, czy dokument, który jest już w standardzie XHTML5.

Narzędzie	Co waliduje	Idealne dla	Główne ograniczenie
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Punktowa walidacja przez URL, plik lub wklejenie treści	Nowoczesny „Nu Html Checker” priorytetyzuje HTML5; stare DTD wymagają ręcznego wyboru
Nu Html Checker (vnu)	HTML5 i XHTML5	Nowe projekty, walidacja lokalna i w CI	Nie waliduje klasycznych DTD dla XHTML 1.x
Lokalne walidatory (vnu.jar, tidy)	Zależnie od konfiguracji	Automatyzacja, pre-commit, pipeline’y	Wymaga instalacji Javy lub binariów; konfiguracja początkowa
xmllint	Poprawność XML (well-formedness) i walidacja względem DTD/XSD	Sprawdzanie czystej warstwy XML	Nie zna specyficznych reguł HTML poza schematem
Rozszerzenia przeglądarki / IDE	Znaczniki na żywo	Natychmiastowy feedback podczas pisania	Często używają nieaktualnych lub niekompletnych silników

W3C Markup Validation Service

Pozostaje punktem wyjścia dla osób zastanawiających się, jak walidować XHTML. Obsługuje trzy tryby: Validate by URI, Validate by File Upload oraz Validate by Direct Input. W przypadku klasycznego XHTML-a kluczem jest rozwijane menu Document Type: jeśli Twój dokument deklaruje własne DTD poprzez DOCTYPE, walidator go respektuje; jeśli nie, musisz wymusić go ręcznie.

Powiązane: accessiBe — Superposición de IA que promete cumplimiento WCAG w 48 godzinach.

Szczegół, o którym wielu nie wie: nowoczesny walidator W3C opiera się na Nu Html Checker, który rozumie HTML5 i XHTML5, ale traktuje stare DTD z mniejszym priorytetem. W przypadku XHTML 1.0 Strict nadal działa, ale zaleca się sprawdzenie, czy wynik odzwierciedla oczekiwane DTD, a nie luźną interpretację.

Nu Html Checker (vnu)

Jest to walidator, którego samo W3C używa wewnętrznie. Istnieje jako usługa internetowa, plik wykonywalny JAR oraz obraz Dockera. Jego wielką zaletą jest to, że można go uruchamiać lokalnie i w ciągłej integracji (CI), co jest niezbędne przy utrzymywaniu dużej witryny. Dla XHTML serwowanego jako application/xhtml+xml, vnu wykrywa błędy zagnieżdżania i atrybutów, które tolerancyjny walidator HTML przepuściłby.

xmllint

Jeśli Twoją obawą jest czysta warstwa XML — na przykład dlatego, że generujesz XHTML z szablonów XSLT — wówczas xmllint jest niezastąpiony. Za pomocą --noout --valid dokument.xhtml sprawdza poprawność sformułowania i ważność względem referencyjnego DTD. Jest szybki, skryptowalny i nie zależy od sieci.

Warto zobaczyć: AudioEye — Accesibilidad gestionada: automatización cobinada con revisión humana.

Walidacja w edytorze

Rozszerzenia do VS Code, wtyczki IDE i narzędzia wiersza poleceń oferują natychmiastowy feedback. Są wygodne, ale mają tendencję do zostawania w tyle za standardami. Używaj ich jako pierwszej linii obrony, nigdy jako jedynej weryfikacji.

Jak walidować XHTML krok po kroku

1. Poprawnie zadeklaruj DOCTYPE i kodowanie

DOCTYPE określa, według jakich reguł dokument jest walidowany. Dla XHTML 1.0 Strict:

<!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>Przykład poprawny</title>
</head>

Dwa klasyczne błędy: zapomnienie atrybutu xmlns (obowiązkowego w XHTML) oraz zadeklarowanie w meta kodowania, które nie zgadza się z rzeczywistym plikiem. Walidator wykryje oba, ale ten drugi czasami objawia się jedynie jako uszkodzone znaki.

2. Sprawdź poprawność sformułowania (well-formedness) przed ważnością

Zanim zaczniesz walczyć z DTD, upewnij się, że XML jest dobrze sformułowany. xmllint --noout plik.xhtml powie Ci to w kilka sekund. Jeśli tutaj wystąpi błąd, żaden walidator DTD nie pomoże: najpierw zamknij znaczniki, popraw zagnieżdżenia i zakoduj encje (&, <, >).

3. Waliduj względem DTD

Mając dobrze sformułowany dokument, przepuść go przez walidator W3C lub vnu. Przeanalizuj nie tylko ile jest błędów, ale jakiego są typu. Pojedynczy błąd zagnieżdżenia może wygenerować kaskadę błędów wtórnych, które znikną po poprawieniu pierwszego.

4. Waliduj całą witrynę, nie tylko stronę główną

Częstym błędem jest walidacja strony głównej i założenie, że reszta jest w porządku. Szablony, komponenty i strony generowane dynamicznie często wprowadzają nieprawidłowe znaczniki. Automatyzuj: przejdź przez główne adresy URL za pomocą skryptu i uruchom vnu dla każdej odpowiedzi.

Powiązane: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

5. Zintegruj walidację w swoim przepływie pracy

Ręczna walidacja nie skaluje się. Dodaj krok walidacji do swojego pipeline’u (pre-commit hook, zadanie builda lub job CI), który przerwie proces, jeśli pojawi się nowy błąd. W ten sposób nieprawidłowe znaczniki nigdy nie trafią na produkcję.

Interpretacja błędów: te, które będziesz widzieć w kółko

• “end tag for X omitted, but OMITTED end tags are not allowed”: typowe dla <li>, <p> lub <td> bez zamknięcia. W XHTML wszystko musi być zamknięte.
• “there is no attribute X”: atrybut nie istnieje w Twoim DTD. Typowe przypadki: target, name w niektórych elementach, atrybuty data-* w XHTML 1.0 (nie ma ich w klasycznym DTD).
• “element X undefined”: użycie elementu, którego Twoje DTD nie uznaje, często wynikające z kopiowania znaczników HTML5 do dokumentu XHTML 1.0.
• “character data is not allowed here”: treść tekstowa tam, gdzie DTD oczekuje tylko elementów, lub znak & bez zakodowania.
• “reference to entity X for which no system identifier could be generated”: nazwane encje HTML, które nie są zdefiniowane w XML (na przykład   bez deklaracji). W czystym XHTML użyj   lub zadeklaruj encję.

Złota zasada walidacji XHTML: poprawiaj od góry do dołu. Pierwszy błąd jest zazwyczaj przyczyną; kolejne są jego konsekwencją.

XHTML5: niuans, który zmienia zasady

Jeśli serwujesz XHTML5 — XHTML zserializowany zgodnie ze składnią HTML5 — zasady się zmieniają. Nie ma już DTD: zgodność jest zdefiniowana w specyfikacji HTML WHATWG oraz specyfikacjach W3C dotyczących HTML. Właściwym walidatorem jest Nu Html Checker, a nie klasyczny walidator DTD.

Warto zobaczyć: UserWay — Widżet umożliwiający dostęp do planu za darmo dla każdego użytkownika.

Praktyczne różnice dotyczące walidacji XHTML, o których należy pamiętać:

• Atrybuty data-* są poprawne w XHTML5, ale nie w XHTML 1.0.
• DOCTYPE jest uproszczony do <!DOCTYPE html>.
• Walidacja odbywa się względem conformance checker HTML5, który w niektórych punktach jest bardziej liberalny, a w innych bardziej rygorystyczny (np. w kwestii użycia niektórych przestarzałych elementów).

Wybór między XHTML 1.0 a XHTML5 nie jest tylko techniczny: jeśli Twój projekt jest nowy, rozsądną drogą jest XHTML5 z walidacją vnu. Jeśli utrzymujesz system legacy z DTD, pozostań przy XHTML 1.0 i waliduj względem jego DTD.

Walidacja a dostępność: dwie różne warstwy

Częstym błędem jest przekonanie, że poprawny (valid) dokument jest automatycznie dostępny. Nie jest. Walidacja sprawdza składnię i zgodność ze schematem; dostępność ocenia się względem WCAG W3C, który obejmuje postrzeganie, obsługiwalność i kompatybilność z technologiami wspomagającymi.

Niemniej jednak istnieje realne powiązanie: nieprawidłowe znaczniki zazwyczaj oznaczają wadliwą strukturę (źle zagnieżdżone nagłówki, uszkodzone listy, formularze bez poprawnych etykiet), a to wpływa na dostępność. Rozsądna strategia walidacji XHTML i innych dokumentów to najpierw walidacja (eliminacja szumu strukturalnego), a następnie audyt dostępności za pomocą narzędzi takich jak axe, Lighthouse lub przeglądów ręcznych. Walidacja jest warunkiem koniecznym, ale niewystarczającym.

Częste błędy przy walidacji XHTML

Ucząc się, jak walidować XHTML, unikaj tych typowych błędów:

• Walidowanie tylko strony głównej. Problematyczne znaczniki zazwyczaj znajdują się w szablonach wewnętrznych.
• Ignorowanie kodowania. Źle zadeklarowany charset generuje błędy widma.
• Mylenie poprawności sformułowania (well-formed) z ważnością (valid). To odrębne warstwy; rozwiązuj je po kolei.
• Używanie niewłaściwego walidatora. vnu dla XHTML5, DTD dla XHTML 1.x.
• Naprawianie błędów kaskadowych bez przeczytania pierwszego. Marnujesz czas i leczysz objawy.
• Brak automatyzacji. Ręczna walidacja nie przetrwa drugiego sprintu.
• Zakładanie, że poprawność = dostępność. To różne standardy o różnych celach.

Kluczowe wnioski

• Walidacja XHTML obejmuje dwie warstwy: poprawność sformułowania XML (well-formedness) oraz zgodność z zadeklarowanym DTD lub schematem.
• W3C Markup Validation Service oraz Nu Html Checker (vnu) to referencyjne narzędzia do walidacji XHTML; xmllint obsługuje czystą warstwę XML.
• Dla XHTML 1.0/1.1 stosuj walidację względem DTD; dla XHTML5 używaj vnu i zapomnij o klasycznych DTD.
• Poprawiaj błędy od góry do dołu: pierwszy zazwyczaj powoduje kolejne.
• Zautomatyzuj walidację w swoim pipeline’ie; przegląd ręczny nie skaluje się.
• Poprawność (valid) nie jest synonimem dostępności: to standardy komplementarne, a nie równoważne.

Źródła i dalsza lektura

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic is an XML-based markup language designed for simple user agents with limited computing power, such as early mobile phones, PDAs, pagers, and set-top…

Często zadawane pytania

Jaka jest różnica między XHTML dobrze sformułowanym a XHTML prawidłowym?

Dokument dobrze sformułowany (well-formed) przestrzega syntaktycznych reguł XML: zamknięte znaczniki, poprawne zagnieżdżanie i atrybuty w cudzysłowie. Dokument prawidłowy (valid) dodatkowo respektuje DTD lub schemat, który deklaruje: używa tylko elementów i atrybutów dozwolonych w danym kontekście. Możesz mieć dokument dobrze sformułowany, ale nieprawidłowy, na przykład jeśli użyjesz atrybutu, który nie istnieje w XHTML 1.0 Strict.

Czy walidacja XHTML ma nadal sens w 2024 roku?

Tak, z dwóch powodów. Po pierwsze, wiele projektów legacy nadal serwuje XHTML i musi pozostać prawidłowy, aby nie psuć się w trybie XML. Po drugie, walidacja to dyscyplina, która wykrywa błędy strukturalne wpływające na dostępność i utrzymanie. Jeśli Twój projekt jest nowy, prawdopodobnie korzysta z HTML5 lub XHTML5, ale nawyk walidacji nadal pozostaje cenny.

Którego walidatora użyć dla XHTML5?

Nu Html Checker (vnu), dostępny jako usługa internetowa, plik wykonywalny JAR i obraz Dockera. To ten sam silnik, którego używa nowoczesna usługa W3C Markup Validation Service; rozumie on składnię HTML5 oraz jej serializację XHTML. Nie używaj klasycznych walidatorów DTD dla XHTML5: nie rozpoznają one atrybutów data-* ani innych funkcji HTML5.

Dlaczego walidator W3C wyświetla błędy, których nie rozumiem?

Ponieważ wiele błędów jest konsekwencją poprzedniego. Nieprawidłowe zagnieżdżenie może wygenerować dziesiątki komunikatów wtórnych. Prawidłową strategią jest poprawienie pierwszego błędu, ponowna walidacja i powtórzenie procesu. Zdarza się również, że walidator stosuje DTD zadeklarowane w DOCTYPE; jeśli to DTD nie jest tym, czego oczekiwałeś, błędy będą wydawać się arbitralne.

Czy mogę walidować XHTML z wiersza poleceń?

Tak. Jeśli zastanawiasz się, jak sprawdzić poprawność XHTML poprzez CLI, xmllint --noout --valid archivo.xhtml sprawdza poprawność i ważność XHTML pod kątem DTD. W przypadku HTML5/XHTML5 vnu.jar archivo.xhtml robi to samo. Obie opcje idealnie nadają się do integracji ze skryptami kompilacji, hookami pre-commit lub zadaniami ciągłej integracji, gdzie ręczna weryfikacja nie jest skalowalna.

Czy poprawny witryna XHTML jest automatycznie dostępna?

Nie. Walidacja sprawdza zgodność składni i schematu; dostępność ocenia się na podstawie WCAG, które obejmują takie aspekty, jak kontrast, nawigacja za pomocą klawiatury, tekst alternatywny lub struktura semantyczna. Dokument może być w pełni ważny, a mimo to pozostać niedostępny. Najpierw sprawdź poprawność, a następnie sprawdź dostępność: są to warstwy uzupełniające.