Hoe xhtml valideren?

Het valideren van XHTML betekent controleren of een document voldoet aan twee lagen regels: de XML-syntaxis en de gedeclareerde DTD of het schema. XHTML 1.0 is een herformulering van HTML 4.01 in XML, dus een document kan goed opgemaakt maar toch ongeldig zijn, zoals wanneer <a target="_blank"> verschijnt in XHTML 1.0 Strict.

Het valideren van XHTML is het controleren of een document tegelijkertijd voldoet aan twee lagen regels:

1. XML-syntaxisregels: correct geneste tags, attributen tussen aanhalingstekens, verplichte sluiting van alle elementen (inclusief lege elementen zoals <br />), een enkel hoofdelement, een consistent gedeclareerde codering, enz.
2. DTD-regels of gedeclareerd schema: welke elementen en attributen bestaan, in welke context ze kunnen verschijnen en welke waarden zijn toegestaan. Hier zijn de klassieke DTD’s van XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic en XHTML Modularization.

Een document kan goed opgemaakte XML zijn en toch ongeldig zijn: als u bijvoorbeeld <a target="_blank"> gebruikt in XHTML 1.0 Strict, is de syntaxis onberispelijk, maar bestaat het kenmerk target niet in die DTD. Dit onderscheid tussen goed opgemaakt en geldig is oorzaak nummer één van verwarring wanneer iemand een fout ziet en niet begrijpt waarom.

Het is ook handig om te onthouden dat XHTML 1.0 een herformulering is van HTML 4.01 in XML, gedefinieerd door het W3C. Tegenwoordig is de praktische waarde ervan tweeledig: het dient voor oudere projecten die nog steeds worden aangeboden als application/xhtml+xml of text/html, en het dient als een mentale discipline om schone markup te schrijven. Als je de volledige normatieve context wilt over hoe je XHTML valideert, is de XHTML-specificatie 1.0 van W3C de primaire bron.

Validators die de moeite waard zijn (en wanneer u deze gebruikt)

Er is niet één ‘juiste’ validator. De keuze hangt af van of u een fragment, een productiepagina, een volledige site of een document valideert dat al XHTML5 is.

Tool	Wat het valideert	Ideaal voor	Belangrijkste beperking
W3C Markup Validatieservice (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Validatie via URL, bestand of directe invoer	De “Nu Html Checker” moderniseert HTML5; oude DTD’s vereisen handmatige selectie
Nu HTML-checker (vnu)	HTML5 en XHTML5	Nieuwe projecten, lokale validatie en CI	Valideert geen klassieke DTD’s van XHTML 1.x
Lokale validators (vnu.jar, tidy)	Afhankelijk van configuratie	Automatisering, pre-commit, pijpleidingen	Vereist installatie van Java of binaire bestanden; initiële configuratie
xmllint	Welgevormdheid XML en validatie tegen DTD/XSD	Controleren van de pure XML-laag	Kent geen specifieke HTML-regels buiten het schema
Navigatorextensies / IDE	Live markup	Directe feedback tijdens het schrijven	Gebruiken vaak verouderde of onvolledige engines

De W3C Markup Validation Service

Het blijft het startpunt voor degenen die zich afvragen hoe ze XHTML kunnen valideren. Het ondersteunt drie modi: Valideren via URI, Valideren via bestandsupload en Valideren via directe invoer. Voor klassieke XHTML zit de truc in de vervolgkeuzelijst Documenttype: als uw document zijn eigen DTD declareert via het DOCTYPE, respecteert de validator dit; Als dit niet het geval is, moet u dit handmatig forceren.

Gerelateerd: UserWay — Widget voor toegang met een gratis plan voor uw bedrijf.

Een detail waar velen zich niet van bewust zijn: de moderne W3C-validator vertrouwt op de Nu Html Checker, die HTML5 en XHTML5 begrijpt, maar oude DTD’s met minder prioriteit behandelt. Voor XHTML 1.0 Strict werkt het nog steeds, maar het is raadzaam om te verifiëren dat het resultaat de DTD weerspiegelt die u verwacht en geen lakse interpretatie is.

Nu HTML-controle (vnu)

Dit is de validator die het W3C zelf intern gebruikt. Het bestaat als een webservice, als een JAR-uitvoerbaar bestand en als een Docker-image. Het grote voordeel is dat je het lokaal en in continue integratie kunt uitvoeren, iets wat essentieel is als je een grote site onderhoudt. Voor XHTML dat wordt gebruikt als application/xhtml+xml, detecteert vnu nest- en attribuutfouten die een tolerante HTML-validator zou doorlaten.

xmllint

Als u zich zorgen maakt over de pure XML-laag (bijvoorbeeld omdat u XHTML genereert op basis van XSLT-sjablonen), dan is xmllint onvervangbaar. Met --noout --valid documento.xhtml controleert het de opmaak en geldigheid ten opzichte van de DTD waarnaar wordt verwezen. Het is snel, scriptbaar en niet afhankelijk van het netwerk.

Een kijkje waard: AudioEye — Toegankelijkheidsbeheer: automatiseringscombinatie met menselijke herziening.

Validatie in de editor

Extensies voor VS Code, IDE-plug-ins en opdrachtregelprogramma’s bieden directe feedback. Ze zijn handig, maar lopen vaak achter op het gebied van normen. Gebruik ze als eerste verdedigingslinie, nooit als enige verificatie.

Hoe je XHTML stap voor stap valideert

1. Verklaar het DOCTYPE en de codificatie correct

Het DOCTYPE bepaalt tegen welke regels het wordt gevalideerd. Voor XHTML 1.0 strikt:

<!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">
<hoofd>
  <meta http-equiv="Inhoudstype"
        content="applicatie/xhtml+xml; charset=UTF-8" />
  <title>Ejemplo valido</title>
</kop>

Twee klassieke fouten hier: het vergeten van het xmlns attribuut (verplicht in XHTML) en het declareren van een codering in de meta die niet samenvalt met het eigenlijke bestand. De validator detecteert beide, maar de tweede verschijnt soms alleen als beschadigde tekens.

2. Comprueba the well-formedness antes que la validez

Voordat u met de DTD gaat vechten, moet u ervoor zorgen dat de XML goed is opgemaakt. xmllint --noout archivo.xhtml vertelt het u binnen enkele seconden. Als het hier niet lukt, zal geen enkele DTD-validator je helpen: sluit eerst tags, corrigeer nesting en ontsnap aan entiteiten (&, <, >).

3. Geldig tegen de DTD

Met het goed opgemaakte document geeft u het door aan de W3C Validator of vnu. Bekijk niet alleen hoeveel fouten er zijn, maar van welk type. Eén enkele nestfout kan een cascade van secundaire fouten genereren die verdwijnen bij het corrigeren van de eerste.

4. Valida el sitio completo, no solo la home

Een veelgemaakte fout is om de hoofdpagina te valideren en ervan uit te gaan dat de rest goed is. Sjablonen, componenten en dynamisch gegenereerde pagina’s introduceren vaak ongeldige markeringen. Automatiseren: doorloop de hoofd-URL’s met een script en voer vnu uit bij elk antwoord.

Gerelateerd: IAAP CPACC / WAS Certification — Het professionele certificaat dat u ervaring en toegankelijkheid geeft.

5. Integreer de validatie in uw flujo

Handmatige validatie schaalt niet. Voeg een validatiestap toe aan uw pijplijn (hook vooraf vastgelegd, build-taak of CI-taak) die mislukt als er een nieuwe fout optreedt. Op deze manier bereikt ongeldige markup nooit de productie.

Interpreteer de fouten: u kunt een ander probleem tegenkomen

• “eindtag voor X weggelaten, maar OMITTED eindtags zijn niet toegestaan”: typisch voor <li>, <p> of <td> zonder afsluiting. In XHTML moet alles gesloten zijn.
• “er is geen attribuut X”: het attribuut bestaat niet in uw DTD. Gebruikelijke gevallen: target, name in sommige elementen, data-* attributen in XHTML 1.0 (niet in de klassieke DTD).
• “element X ongedefinieerd”: gebruikt een element waar uw DTD geen rekening mee houdt, vaak door het kopiëren van HTML5-opmaak naar een XHTML 1.0-document.
• “karaktergegevens zijn hier niet toegestaan”: tekstinhoud waarbij de DTD alleen elementen verwacht, of een & zonder te ontsnappen.
• “referentie naar entiteit X waarvoor geen systeem-ID kan worden gegenereerd”: benoemde HTML-entiteiten die niet in XML zijn gedefinieerd (bijvoorbeeld   zonder te declareren). Gebruik in pure XHTML   of declareer de entiteit.

De gouden regel voor het valideren van xhtml: correct van boven naar beneden. Meestal is de eerste fout de oorzaak; de volgende zijn de gevolgen ervan.

XHTML5: de mat is dat de reglas

Als u XHTML5 (XHTML geserialiseerd volgens de HTML5-syntaxis) aanbiedt, veranderen de regels. Er is niet langer een DTD: conformiteit wordt gedefinieerd in de WHATWG HTML-specificatie en de W3C-specificaties over HTML. De juiste validator is Nu Html Checker, niet de klassieke DTD-validator.

Als u aan het winkelen bent: accessiBe — Superpositie van IA die de cumplimiento WCAG in 48 uur stimuleert.

Praktische verschillen waar u rekening mee moet houden met betrekking tot het valideren van xhtml:

• De data-* attributen zijn geldig in XHTML5, niet in XHTML 1.0.
• Het DOCTYPE is vereenvoudigd tot <!DOCTYPE html>.
• Validatie vindt plaats tegen de conformance checker van HTML5, die op sommige punten beter is toegestaan ​​en op andere strenger (bijvoorbeeld bij het gebruik van bepaalde verouderde elementen).

Kiezen tussen XHTML 1.0 en XHTML5 is niet alleen technisch: als uw project nieuw is, is XHTML5 met vnu-validatie het verstandige pad. Als u een verouderd systeem met DTD onderhoudt, blijf dan bij XHTML 1.0 en valideer tegen de DTD ervan.

Validatie en toegankelijkheid: er zijn verschillende mogelijkheden

Een veel voorkomende fout is dat men denkt dat een geldig document automatisch toegankelijk is. Dat is het niet. Validatie controleert de syntaxis en de conformiteit van het schema; De toegankelijkheid wordt beoordeeld aan de hand van de WCAG del W3C, die percepties, bruikbaarheid en compatibiliteit met ondersteunende technologieën omvat.

Dat gezegd hebbende, is er sprake van een reële overlap: ongeldige opmaak impliceert meestal een gebrekkige structuur (slecht geneste koppen, gebroken lijsten, formulieren zonder correcte labels), en dit heeft gevolgen voor de toegankelijkheid. De verstandige strategie voor het valideren van XHTML en andere documenten is om eerst valideren (structurele ruis te elimineren) en de toegankelijkheid daarna te controleren met tools als Axe, Lighthouse of handmatige beoordelingen. Validatie is een noodzakelijke voorwaarde, maar niet voldoende.

Fouten komen vaak voor bij het valideren van XHTML

Wanneer u leert hoe u XHTML valideert, vermijd dan deze veelgemaakte fouten:

• Alleen het huis valideren. De problematische opmaak bevindt zich meestal op interne sjablonen.
• Negeer codering. Een slecht gedeclareerde charset produceert spookfouten.
• Verwar goedgevormd met geldig. Het zijn verschillende lagen; los ze op volgorde op.
• Gebruik de verkeerde validator. vnu voor XHTML5, DTD voor XHTML 1.x.
• Repareer opeenvolgende fouten zonder de eerste te lezen. U verspilt tijd en verhelpt de symptomen.
• Geen automatisering. Handmatige validatie overleeft de tweede sprint niet.
• Ervan uitgaande dat geldig = toegankelijk. Het zijn verschillende standaarden met verschillende doeleinden.

Belangrijkste afhaalrestaurants

• Het valideren van XHTML omvat twee lagen: goed gevormde XML en naleving van de aangegeven DTD of schema.
• De W3C Markup Validation Service en Nu Html Checker (vnu) zijn de referentiehulpmiddelen voor het valideren van xhtml; xmllint bedekt de pure XML-laag.
• Gebruik voor XHTML 1.0/1.1 validatie tegen DTD; voor XHTML5 gebruikt u vnu en vergeet de klassieke DTD’s.
• Corrigeer de fouten van boven naar beneden: de eerste veroorzaakt meestal het volgende.
• Automatiseer de validatie in uw pijplijn; handmatige beoordeling schaalt niet.
• Geldig is niet synoniem met toegankelijk: het zijn complementaire standaarden, geen equivalenten.

Bronnen en verder lezen

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) maakt deel uit van de familie van XML-opmaaktalen die versies van de veelgebruikte HyperText Markup spiegelen of uitbreiden…
• XHTML Basic — Wikipedia: XHTML Basic is een op XML gebaseerde opmaaktaal ontworpen voor eenvoudige user agents met beperkte rekenkracht, zoals vroege mobiele telefoons, PDA’s, pagers en set-top…

Veelgestelde vragen

Is het verschil tussen XHTML in de juiste vorm en XHTML-valido?

Een goed opgemaakt document volgt de syntactische regels van XML: gesloten tags, correcte nesting en attributen tussen aanhalingstekens. Een geldig document respecteert bovendien de DTD of het schema dat het declareert: het gebruikt alleen elementen en attributen die in de context ervan zijn toegestaan. Mogelijk hebt u een goed opgemaakt maar ongeldig document, bijvoorbeeld als u een attribuut gebruikt dat niet bestaat in XHTML 1.0 Strict.

Wil je XHTML valideren in 2024?

Ja, om twee redenen. Ten eerste blijven veel oudere projecten XHTML aanbieden en moeten ze geldig blijven om niet in de XML-modus te breken. Ten tweede is validatie een discipline die structurele fouten opspoort die de toegankelijkheid en het onderhoud beïnvloeden. Als uw project nieuw is, gebruikt het waarschijnlijk HTML5 of XHTML5, maar de gewoonte om te valideren blijft nog steeds waardevol.

Wilt u het gebruik van XHTML5 valideren?

Nu Html Checker (vnu), beschikbaar als webservice, uitvoerbare JAR- en Docker-image. Het is dezelfde engine die de moderne W3C Markup Validation Service gebruikt en begrijpt de HTML5-syntaxis en de XHTML-serialisatie ervan. Gebruik geen klassieke DTD-validators voor XHTML5: deze herkennen geen data-*-attributen of andere HTML5-functies.

Waarom zijn er fouten in W3C die geen fouten opleveren?

Omdat veel fouten het gevolg zijn van een vorige. Onjuist nesten kan tientallen secundaire berichten genereren. De juiste strategie is om de eerste fout te corrigeren, opnieuw te valideren en te herhalen. Het komt ook voor dat de validator de DTD toepast die is gedeclareerd in het DOCTYPE; als die DTD niet is wat je had verwacht, zullen de fouten willekeurig lijken.

XHTML valideren van de comandoslijn?

Ja. Als u zich afvraagt ​​hoe u XHTML via CLI kunt valideren, controleert xmllint --noout --valid archivo.xhtml de correctheid en geldigheid ten opzichte van de DTD. Voor HTML5/XHTML5 doet vnu.jar archivo.xhtml hetzelfde. Beide opties zijn ideaal voor integratie in buildscripts, pre-commit hooks of continue integratietaken, waarbij handmatige validatie niet schaalbaar is.

Is een geldige XHTML-site automatisch toegankelijk?

Nee. Validatie controleert syntactische en schemaconformiteit; toegankelijkheid wordt beoordeeld aan de hand van de WCAG, die aspecten als contrast, toetsenbordnavigatie, alternatieve tekst of semantische structuur omvat. Een document kan volkomen geldig zijn en toch ontoegankelijk blijven. Eerst valideren en daarna de toegankelijkheid controleren: het zijn complementaire lagen.