Hvordan validerer man xhtml?

At validere XHTML betyder at kontrollere, at et dokument overholder to lag af regler: XML-syntaks og dets erklærede DTD eller skema. XHTML 1.0 er en omformulering af HTML 4.01 i XML, så et dokument kan være velformet og alligevel ugyldigt, som når <a target="_blank"> vises i XHTML 1.0 Strict.

Validering af XHTML er at kontrollere, at et dokument samtidig overholder to lag af regler:

1. XML-syntaksregler: korrekt indlejrede tags, attributter i anførselstegn, obligatorisk lukning af alle elementer (inklusive tomme som "
   "), et enkelt rodelement, en konsistent erklæret kodning osv.
2. DTD-regler eller erklæret skema: hvilke elementer og attributter findes, i hvilken sammenhæng de kan optræde og hvilke værdier er tilladt. Her er de klassiske DTD’er fra XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic og XHTML Modularization.

Et dokument kan være velformet XML og stadig være ugyldigt: hvis du for eksempel bruger <a target="_blank"> i XHTML 1.0 Strict, er syntaksen upåklagelig, men target-attributten findes ikke i den DTD. Denne skelnen mellem velformet og gyldig er den største årsag til forvirring, når nogen ser en fejl og ikke forstår hvorfor.

Det er også praktisk at huske, at XHTML 1.0 er en omformulering af HTML 4.01 i XML, defineret af W3C. I dag er dens praktiske værdi dobbelt: den tjener til gamle projekter, der stadig bruges som application/xhtml+xml eller text/html, og den tjener som en mental disciplin at skrive ren opmærkning. Hvis du vil have den komplette normative kontekst for, hvordan man validerer XHTML, er W3C’s XHTML 1.0-specifikation den primære kilde.

Validatorer der er værd at bruge (og hvornår man skal bruge hvilken)

Der er ingen enkelt “korrekt” validator. Valget afhænger af, om du validerer et fragment, en produktionsside, et helt websted eller et dokument, der allerede er XHTML5.

Værktøj	Hvad den validerer	Ideel til	Hovedbegrænsning
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Punktvis validering via URL, fil eller direkte indsættelse	Den moderne “Nu Html Checker” prioriterer HTML5; gamle DTD’er kræver manuelt valg
Nu Html Checker (vnu)	HTML5 og XHTML5	Nye projekter, lokal validering og CI	Validerer ikke klassiske DTD’er fra XHTML 1.x
Lokale validatorer (vnu.jar, tidy)	Afhænger af konfiguration	Automatisering, pre-commit, pipelines	Kræver installation af Java eller binære filer; indledende konfiguration
xmllint	Velformet XML og validering kontra DTD/XSD	Kontrol af det rene XML-lag	Kender ikke specifikke HTML-regler ud over skemaet
Browser-udvidelser / IDE	Live-markup	Øjeblikkelig feedback mens du skriver	Bruger ofte forældede eller ufuldstændige motorer

W3C Markup Validation Service

Det er fortsat udgangspunktet for dem, der spekulerer på, hvordan man validerer XHTML. Den understøtter tre tilstande: Valider ved URI, Valider ved filupload og Valider ved direkte input. For klassisk XHTML er tricket i rullemenuen Dokumenttype: hvis dit dokument erklærer sin egen DTD via DOCTYPE, respekterer validatoren det; hvis ikke, skal du tvinge det manuelt.

Relateret: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 timer.

En detalje, som mange ikke er klar over: den moderne W3C-validator er afhængig af Nu Html Checker, som forstår HTML5 og XHTML5, men behandler gamle DTD’er med mindre prioritet. For XHTML 1.0 Strict virker det stadig, men det er tilrådeligt at verificere, at resultatet afspejler den DTD, du forventer, og ikke en slap fortolkning.

Nu Html Checker (vnu)

Dette er den validator, som W3C selv bruger internt. Det eksisterer som en webservice, som en JAR-eksekverbar fil og som et Docker-billede. Dens store fordel er, at du kan køre det lokalt og i kontinuerlig integration, noget væsentligt, hvis du vedligeholder et stort websted. For XHTML tjent som application/xhtml+xml, registrerer vnu indlejrings- og attributfejl, som en tolerant HTML-validator ville lade passere.

xmllint

Hvis din bekymring er det rene XML-lag - for eksempel fordi du genererer XHTML fra XSLT-skabeloner - så er xmllint uerstattelig. Med --noout --valid documento.xhtml kontrollerer den veludformethed og gyldighed mod den refererede DTD. Det er hurtigt, scriptbart og afhænger ikke af netværket.

Værd at se: AudioEye — Accesibilidad gestionada: automatisering combinada con revision humana.

Validering i editoren

Udvidelser til VS-kode, IDE-plugins og kommandolinjeværktøjer giver øjeblikkelig feedback. De er praktiske, men har en tendens til at falde bagud med hensyn til standarder. Brug dem som en første forsvarslinje, aldrig som den eneste verifikation.

Sådan validerer du XHTML trin for trin

1. Deklarer DOCTYPE og kodning korrekt

DOCTYPE bestemmer i forhold til hvilke regler den valideres. For 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="es" lang="es">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Gyldigt eksempel</title>
</head>

To klassiske fejl her: at glemme xmlns-attributten (obligatorisk i XHTML) og erklære en kodning i metaen, som ikke falder sammen med den faktiske fil. Validatoren registrerer begge, men den anden dukker nogle gange kun op som beskadigede tegn.

2. Kontroller velformethed før gyldighed

Før du kæmper med DTD’en, skal du sørge for, at XML er veludformet. xmllint --noout archivo.xhtml vil fortælle dig på få sekunder. Hvis det mislykkes her, vil ingen DTD-validator hjælpe dig: Luk først tags, ret indlejring og escape-entiteter (&, <, >).

3. Valider mod DTD’en

Med det velformede dokument skal du sende det gennem W3C Validator eller vnu. Gennemgå ikke kun hvor mange fejl der er, men af hvilken type. En enkelt indlejringsfejl kan generere en kaskade af sekundære fejl, der forsvinder ved at rette den første.

4. Valider hele siden, ikke kun forsiden

En almindelig fejl er at validere hovedsiden og antage, at resten er god. Skabeloner, komponenter og dynamisk genererede sider introducerer ofte ugyldig markup. Automatiser: kryds de vigtigste URL’er med et script og kør vnu på hvert svar.

Relateret: IAAP CPACC / WAS Certification — Den professionelle certificering que acredita tu experiencia and accessibilidad.

5. Integrer validering i dit workflow

Manuel validering skaleres ikke. Tilføj et valideringstrin i din pipeline (pre-commit hook, build-opgave eller CI-job), der mislykkes, hvis der vises en ny fejl. På denne måde når ugyldig markup aldrig produktion.

Fortolk fejl: dem du vil se igen og igen

• “sluttag for X udeladt, men UDELADTE sluttags er ikke tilladt”: typisk for <li>, <p> eller <td> uden at lukke. I XHTML skal alt være lukket.
• “der er ingen attribut X”: attributten findes ikke i din DTD. Sædvanlige tilfælde: target, name i nogle elementer, data-*-attributter i XHTML 1.0 (ikke i den klassiske DTD).
• “element X undefined”: bruger et element, som din DTD ikke overvejer, ofte fra kopiering af HTML5-markup til et XHTML 1.0-dokument.
• “tegndata er ikke tilladt her”: tekstindhold, hvor DTD’en kun forventer elementer, eller et & uden at escape.
• “reference til enhed X, for hvilken der ikke kunne genereres nogen system-id”: navngivne HTML-enheder, der ikke er defineret i XML (f.eks.   uden erklæring). I ren XHTML skal du bruge   eller erklære entiteten.

Den gyldne regel for, hvordan man validerer xhtml: korrekt fra top til bund. Den første fejl er normalt årsagen; følgende er dens konsekvens.

XHTML5: nuancen der ændrer reglerne

Hvis du serverer XHTML5 —XHTML serialiseret i henhold til HTML5-syntaks — ændres reglerne. Der er ikke længere en DTD: Overensstemmelse er defineret i WHATWG HTML-specifikationen og W3C-specifikationerne for HTML. Den korrekte validator er Nu Html Checker, ikke den klassiske DTD-validator.

Værd at se: UserWay — Accessibilidad widget med en gratis plan for empezar hoy mismo.

Praktiske forskelle at være opmærksom på med hensyn til, hvordan man validerer xhtml:

• data-*-attributterne er gyldige i XHTML5, ikke i XHTML 1.0.
• DOCTYPE er forenklet til <!DOCTYPE html>.
• Validering foretages mod HTML5’s conformance checker, som er mere tilladt på nogle punkter og strengere på andre (f.eks. ved brug af visse forældede elementer).

At vælge mellem XHTML 1.0 og XHTML5 er ikke kun teknisk: Hvis dit projekt er nyt, er XHTML5 med vnu-validering den fornuftige vej. Hvis du vedligeholder et ældre system med DTD, skal du blive i XHTML 1.0 og validere mod dets DTD.

Validering og tilgængelighed: to forskellige lag

En almindelig fejl er at tro, at et gyldigt dokument er automatisk tilgængeligt. Det er det ikke. Validering kontrollerer syntaks og skemaoverensstemmelse; tilgængelighed vurderes i forhold til W3C’s WCAG, som dækker opfattelser, funktionalitet og kompatibilitet med hjælpeteknologier.

Når det er sagt, er der reelt overlap: ugyldig markup indebærer normalt en mangelfuld struktur (dårligt indlejrede overskrifter, brudte lister, formularer uden korrekte etiketter), og dette påvirker tilgængeligheden. Den fornuftige strategi for, hvordan man validerer XHTML og andre dokumenter, er at validere først (eliminere strukturel støj) og auditér tilgængelighed bagefter med værktøjer som økse, Lighthouse eller manuelle anmeldelser. Validering er en nødvendig betingelse, men ikke tilstrækkelig.

Almindelige fejl ved validering af XHTML

Når du lærer at validere XHTML, skal du undgå disse almindelige fejl:

• Valider kun forsiden. Den problematiske markering er normalt på interne skabeloner.
• Ignorer kodning. Et dårligt angivet “charset” producerer spøgelsesfejl.
• Forveksle velformet med gyldig. De er forskellige lag; løse dem i rækkefølge.
• Brug den forkerte validator. vnu for XHTML5, DTD for XHTML 1.x.
• Ret kaskadefejl uden at læse den første. Du spilder tid og fikser symptomer.
• Ingen automatisering. Manuel validering overlever ikke den anden sprint.
• Forudsat at gyldig = tilgængelig. Det er forskellige standarder med forskellige formål.

Key Takeaways

• Validering af XHTML involverer to lag: velformet XML og overholdelse af den erklærede DTD eller skema.
• W3C Markup Validation Service og Nu Html Checker (vnu) er referenceværktøjerne til, hvordan man validerer xhtml; xmllint dækker det rene XML-lag.
• For XHTML 1.0/1.1, brug validering mod DTD; for XHTML5, brug vnu og glem de klassiske DTD’er.
• Ret fejlene fra top til bund: den første forårsager normalt følgende.
• Automatiser valideringen i din pipeline; manuel gennemgang skalerer ikke.
• Gyldig er ikke synonymt med tilgængelig: de er komplementære standarder, ikke ækvivalenter.

Kilder og yderligere læsning

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) er en del af familien af XML-markupsprog, som afspejler eller udvider versioner af den meget brugte HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic er et XML-baseret markup-sprog designet til simple brugeragenter med begrænset computerkraft, såsom tidlige mobiltelefoner, PDA’er, personsøgere og set-top…

Ofte stillede spørgsmål

Hvad er forskellen mellem velformet XHTML og gyldig XHTML?

Et veludformet dokument følger de syntaktiske regler for XML: lukkede tags, korrekt indlejring og attributter i anførselstegn. Et gyldigt dokument respekterer desuden den DTD eller det skema, som det erklærer: kun ved hjælp af elementer og attributter tilladt i dets kontekst. Du kan have et veludformet, men ugyldigt dokument, for eksempel hvis du bruger en attribut, der ikke findes i XHTML 1.0 Strict.

Giver det stadig mening at validere XHTML i 2024?

Ja, af to grunde. For det første fortsætter mange ældre projekter med at betjene XHTML og skal forblive gyldige for ikke at bryde i XML-tilstand. For det andet er validering en disciplin, der opdager strukturelle fejl, der påvirker tilgængelighed og vedligeholdelse. Hvis dit projekt er nyt, bruger det sandsynligvis HTML5 eller XHTML5, men vanen med at validere er stadig værdifuld.

Hvilken validator skal jeg bruge til XHTML5?

Nu Html Checker (vnu), tilgængelig som en webservice, eksekverbar JAR og Docker-billede. Det er den samme motor, som den moderne W3C Markup Validation Service bruger og forstår HTML5-syntaks og dens XHTML-serialisering. Brug ikke klassiske DTD-validatorer til XHTML5: de genkender ikke data-*-attributter eller andre HTML5-funktioner.

Hvorfor giver W3C-validatoren mig fejl, jeg ikke forstår?

Fordi mange fejl er konsekvensen af ​​en tidligere. Forkert indlejring kan generere snesevis af sekundære meddelelser. Den korrekte strategi er at rette den første fejl, validere igen og gentage. Det sker også, at validatoren anvender den DTD, der er erklæret i DOCTYPE; hvis den DTD ikke er, hvad du forventede, vil fejlene virke vilkårlige.

Kan jeg validere XHTML fra kommandolinjen?

Ja. Hvis du undrer dig over, hvordan du validerer XHTML via CLI, kontrollerer xmllint --noout --valid archivo.xhtml veludformethed og gyldighed mod DTD. For HTML5/XHTML5 gør vnu.jar archivo.xhtml det samme. Begge muligheder er ideelle til at integrere i build-scripts, pre-commit hooks eller kontinuerlige integrationsjob, hvor manuel validering ikke er skalerbar.

Er et gyldigt XHTML-site automatisk tilgængeligt?

Nej. Validering kontrollerer syntaktisk og skemaoverensstemmelse; tilgængelighed vurderes i forhold til WCAG, som dækker aspekter som kontrast, tastaturnavigation, alternativ tekst eller semantisk struktur. Et dokument kan være fuldkommen gyldigt og stadig være utilgængeligt. Valider først og kontroller tilgængelighed efter: de er komplementære lag.