Hvordan validere xhtml?

Hvordan validere XHTML betyr å kontrollere at et dokument overholder to lag med regler: XML-syntaks og dets erklærte DTD eller skjema. XHTML 1.0 er en omformulering av HTML 4.01 i XML, så et dokument kan være godt utformet, men likevel ugyldig, som når <a target="_blank"> vises i XHTML 1.0 Strict.

Validering av XHTML er å sjekke at et dokument samtidig overholder to lag med regler:

1. XML-syntaksregler: korrekt nestede tagger, attributter i anførselstegn, obligatorisk lukking av alle elementer (inkludert tomme som «
   »), et enkelt rotelement, en konsistent erklært koding, osv.
2. DTD-regler eller deklarert skjema: hvilke elementer og attributter som finnes, i hvilken kontekst de kan vises og hvilke verdier som er tillatt. Her er de klassiske DTDene til XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic og XHTML Modularization.

Et dokument kan være velutformet XML og fortsatt være ugyldig: hvis du for eksempel bruker <a target="_blank"> i XHTML 1.0 Strict, er syntaksen upåklagelig, men target-attributtet eksisterer ikke i den DTDen. Dette skillet mellom velformet og gyldig er hovedårsaken til forvirring når noen ser en feil og ikke forstår hvorfor.

Det er også praktisk å huske at XHTML 1.0 er en omformulering av HTML 4.01 i XML, definert av W3C. I dag er dens praktiske verdi todelt: den tjener til eldre prosjekter som fortsatt brukes som “applikasjon/xhtml+xml” eller “tekst/html”, og den fungerer som en mental disiplin å skrive ren markup. Hvis du vil ha den fullstendige normative konteksten for hvordan du validerer XHTML, er especificación de XHTML 1.0 del W3C den primære kilden.

Validatorer som er verdt å bruke (og når man skal bruke hvilken)

Det er ingen enkelt “riktig” validator. Valget avhenger av om du validerer et fragment, en produksjonsside, et helt nettsted eller et dokument som allerede er XHTML5.

Herramienta	Qué valida	Ideell para	Hovedbegrensning
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Punktvis validering via URL, fil eller direkte liming	Den moderne «Nu Html Checker» prioriterer HTML5; gamle DTD-er krever manuelt valg
Nu Html Checker (vnu)	HTML5 og XHTML5	Nye prosjekter, lokal validering og i CI	Validerer ikke klassiske DTD-er for XHTML 1.x
Lokale validatorer (vnu.jar, tidy)	Avhengig av konfigurasjon	Automatisering, pre-commit, pipelines	Krever installasjon av Java eller binærfiler; startkonfigurasjon
xmllint	Velformet XML og validering mot DTD/XSD	Sjekke det rene XML-laget	Kjenner ikke til spesifikke HTML-regler utover skjemaet
Nettleserutvidelser / IDE	Oppmerking i sanntid	Umiddelbar tilbakemelding mens du skriver	Bruker ofte utdaterte eller ufullstendige motorer

El W3C Markup Validation Service

Det er fortsatt utgangspunktet for de som lurer på hvordan de skal validere XHTML. Den støtter tre moduser: Valider med URI, Valider ved filopplasting og Valider med direkte inndata. For klassisk XHTML er trikset i rullegardinmenyen Dokumenttype: hvis dokumentet ditt erklærer sin egen DTD via DOCTYPE, respekterer validatoren det; hvis ikke, må du tvinge den manuelt.

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

En detalj som mange ikke er klar over: den moderne W3C-validatoren er avhengig av Nu Html Checker, som forstår HTML5 og XHTML5, men behandler gamle DTDer med mindre prioritet. For XHTML 1.0 Strict fungerer det fortsatt, men det er tilrådelig å verifisere at resultatet gjenspeiler DTDen du forventer og ikke en lemfeldig tolkning.

Nu Html Checker (vnu)

Dette er validatoren som W3C selv bruker internt. Den eksisterer som en webtjeneste, som en kjørbar JAR-fil og som et Docker-bilde. Den store fordelen er at du kan kjøre den lokalt og i kontinuerlig integrasjon, noe som er viktig hvis du har et stort nettsted. For XHTML tjent som application/xhtml+xml, oppdager vnu nesting- og attributtfeil som en tolerant HTML-validator ville la passere.

xmllint

Hvis din bekymring er det rene XML-laget - for eksempel fordi du genererer XHTML fra XSLT-maler - så er ‘xmllint’ uerstattelig. Med --noout --valid documento.xhtml sjekker den korrekt form og gyldighet mot den refererte DTDen. Det er raskt, skriptbart og er ikke avhengig av nettverket.

Verdt en titt: AudioEye — Tilgjengelighet: automatisert kombinasjon med menneskelig revisjon.

Validering i redaktøren

Utvidelser for VS-kode, IDE-plugins og kommandolinjeverktøy gir umiddelbar tilbakemelding. De er praktiske, men har en tendens til å falle bak når det gjelder standarder. Bruk dem som en første forsvarslinje, aldri som den eneste bekreftelsen.

Hvordan validere XHTML trinn for trinn

1. Declara correctamente el DOCTYPE y la codificación

DOCTYPE bestemmer mot hvilke regler den er validert. 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">
<hode>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Ejemplo valido</title>
</head>

To klassiske feil her: glemme xmlns-attributtet (obligatorisk i XHTML) og erklære en koding i meta som ikke sammenfaller med den faktiske filen. Validatoren oppdager begge, men den andre dukker noen ganger bare opp som ødelagte tegn.

2. Comprueba la well-formedness antes que la validez

Før du kjemper med DTD, sørg for at XML er godt utformet. xmllint --noout archivo.xhtml vil fortelle deg i løpet av sekunder. Hvis det mislykkes her, vil ingen DTD-validator hjelpe deg: først lukk tagger, korriger nesting- og escape-enheter (&, <, >).

3. Valida contra la DTD

Med det velutformede dokumentet, send det gjennom W3C Validator eller vnu. Gjennomgå ikke bare hvor mange feil det er, men av hvilken type. En enkelt nestfeil kan generere en kaskade av sekundære feil som forsvinner ved korrigering av den første.

4. Valida el sitio completo, ingen solo for hjemmet

En vanlig feil er å validere hovedsiden og anta at resten er bra. Maler, komponenter og dynamisk genererte sider introduserer ofte ugyldig oppmerking. Automatiser: gå gjennom hovednettadressene med et skript og kjør vnu på hvert svar.

Relatert: IAAP CPACC / WAS Certification — Den profesjonelle sertifiseringen er godkjenning for å oppleve og få tilgang.

5. Integra la validación en tu flujo

Manuell validering skaleres ikke. Legg til et valideringstrinn i pipelinen (pre-commit hook, byggeoppgave eller CI-jobb) som mislykkes hvis en ny feil vises. På denne måten når ugyldig markering aldri produksjon.

Tolk los feil: los que verás una y otra vez

• “sluttkode for X utelatt, men UDELT sluttkoder er ikke tillatt”: typisk for <li>, <p> eller <td> uten å lukkes. I XHTML må alt være lukket.
• “det er ingen attributt X”: attributtet finnes ikke i DTDen din. Vanlige tilfeller: target, name i noen elementer, data-*-attributter i XHTML 1.0 (ikke i den klassiske DTD).
• “element X undefined”: bruker et element som din DTD ikke tar i betraktning, ofte fra kopiering av HTML5-markering til et XHTML 1.0-dokument.
• “tegndata er ikke tillatt her”: tekstinnhold der DTD forventer bare elementer, eller et & uten å escape.
• “referanse til enhet X som ingen systemidentifikator kunne genereres for”: navngitte HTML-enheter som ikke er definert i XML (for eksempel   uten å deklarere). I ren XHTML bruker du   eller erklærer enheten.

Den gylne regelen for hvordan du validerer xhtml: korrekt fra topp til bunn. Den første feilen er vanligvis årsaken; følgende er konsekvensen.

XHTML5: el matiz que cambia las reglas

Hvis du viser XHTML5 —XHTML serialisert i henhold til HTML5-syntaks—, endres reglene. Det er ikke lenger en DTD: samsvar er definert i WHATWG HTML-spesifikasjonen og W3C-spesifikasjonene for HTML. Riktig validator er Nu Html Checker, ikke den klassiske DTD-validatoren.

Verdt en titt: UserWay — Tilgjengelighetswidget med gratis plan for empezar Hoy Mismo.

Praktiske forskjeller å være klar over når det gjelder hvordan du validerer xhtml:

• data-*-attributtene er gyldige i XHTML5, ikke i XHTML 1.0.
• DOCTYPE er forenklet til <!DOCTYPE html>.
• Validering gjøres mot HTML5s konformitetssjekker, som er mer tillatt på noen punkter og strengere på andre (for eksempel ved bruk av enkelte foreldede elementer).

Å velge mellom XHTML 1.0 og XHTML5 er ikke bare teknisk: Hvis prosjektet ditt er nytt, er XHTML5 med vnu-validering den fornuftige veien. Hvis du opprettholder et eldre system med DTD, hold deg i XHTML 1.0 og valider mot dets DTD.

Validering og tilgang: dos capas distintas

En vanlig feil er å tro at et gyldig dokument er automatisk tilgjengelig. Det er det ikke. Validering sjekker syntaks og skjemakonformitet; tilgjengelighet vurderes opp mot WCAG del W3C, som dekker oppfatninger, operabilitet og kompatibilitet med hjelpeteknologier.

Når det er sagt, er det reell overlapping: ugyldig oppmerking innebærer vanligvis en mangelfull struktur (dårlig nestede overskrifter, ødelagte lister, skjemaer uten korrekte etiketter), og dette påvirker tilgjengeligheten. Den fornuftige strategien for hvordan man validerer XHTML og andre dokumenter er å validere først (eliminere strukturell støy) og revidere tilgjengelighet etter med verktøy som øks, Lighthouse eller manuelle vurderinger. Validering er en nødvendig betingelse, men ikke tilstrekkelig.

Errores frecuentes al validar XHTML

Når du lærer hvordan du validerer XHTML, unngå disse vanlige feilene:

• Valider bare hjemmet. Den problematiske markeringen er vanligvis på interne maler.
• Ignorer koding. Et dårlig deklarert “tegnsett” produserer spøkelsesfeil.
• Forveksle velformet med gyldig. De er distinkte lag; løse dem i rekkefølge.
• Bruk feil validator. vnu for XHTML5, DTD for XHTML 1.x.
• Fiks kaskadefeil uten å lese den første. Du kaster bort tid og fikser symptomene.
• Ingen automatisering. Manuell validering overlever ikke den andre spurten.
• Forutsatt at gyldig = tilgjengelig. Det er forskjellige standarder med forskjellige formål.

Viktige takeaways

• Validering av XHTML involverer to lag: velformet XML og overholdelse av den deklarerte DTDen eller skjemaet.
• W3C Markup Validation Service og Nu Html Checker (vnu) er referanseverktøyene for hvordan du validerer xhtml; xmllint dekker det rene XML-laget.
• For XHTML 1.0/1.1, bruk validering mot DTD; for XHTML5, bruk vnu og glem de klassiske DTDene.
• Rett opp feilene fra topp til bunn: den første forårsaker vanligvis følgende.
• Automatiser valideringen i din pipeline; manuell gjennomgang skalerer ikke.
• Gyldig er ikke synonymt med tilgjengelig: de er komplementære standarder, ikke ekvivalenter.

Kilder og videre lesing

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) er en del av familien av XML-markeringsspråk som speiler eller utvider versjoner av den mye brukte HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic er et XML-basert merkespråk designet for enkle brukeragenter med begrenset datakraft, for eksempel tidlige mobiltelefoner, PDAer, personsøkere og set-top…

Vanlige spørsmål

¿Cuál es la diferencia entre XHTML bien formado y XHTML válido?

Et godt utformet dokument følger de syntaktiske reglene for XML: lukkede koder, korrekt nesting og attributter i anførselstegn. Et gyldig dokument respekterer dessuten DTDen eller skjemaet som det erklærer: kun ved å bruke elementer og attributter som er tillatt i konteksten. Du kan ha et godt utformet, men ugyldig dokument, for eksempel hvis du bruker et attributt som ikke finnes i XHTML 1.0 Strict.

¿Sigue teniendo sentido validar XHTML en 2024?

Ja, av to grunner. For det første fortsetter mange eldre prosjekter å betjene XHTML og må forbli gyldige for ikke å bryte i XML-modus. For det andre er validering en disiplin som oppdager strukturelle feil som påvirker tilgjengelighet og vedlikehold. Hvis prosjektet ditt er nytt, bruker det sannsynligvis HTML5 eller XHTML5, men vanen med å validere er fortsatt verdifull.

¿Qué validador debo usar for XHTML5?

Nu Html Checker (vnu), tilgjengelig som en webtjeneste, kjørbar JAR og Docker-bilde. Det er den samme motoren som den moderne W3C Markup Validation Service bruker og forstår HTML5-syntaksen og dens XHTML-serialisering. Ikke bruk klassiske DTD-validatorer for XHTML5: de vil ikke gjenkjenne data-*-attributter eller andre HTML5-funksjoner.

¿Vil du godkjenne W3C om jeg ikke har noen feil?

Fordi mange feil er konsekvensen av en tidligere. Feil hekking kan generere dusinvis av sekundære meldinger. Den riktige strategien er å rette opp den første feilen, validere igjen og gjenta. Det hender også at validatoren bruker DTDen som er deklarert i DOCTYPE; hvis den DTDen ikke er det du forventet, vil feilene virke vilkårlige.

¿Puedo validar XHTML desde la linea de commandos?

Ja. Hvis du lurer på hvordan du validerer XHTML via CLI, sjekker xmllint --noout --valid archivo.xhtml om dokumentet er velformet og gyldighet mot DTD. For HTML5/XHTML5 gjør vnu.jar archivo.xhtml det samme. Begge alternativene er ideelle for integrering i byggeskript, pre-commit hooks eller kontinuerlige integreringsjobber, der manuell validering ikke er skalerbart.

Er et gyldig XHTML-nettsted automatisk tilgjengelig?

Nei. Validering sjekker syntaktisk og skjemakonformitet; tilgjengelighet vurderes mot WCAG, som dekker aspekter som kontrast, tastaturnavigasjon, alternativ tekst eller semantisk struktur. Et dokument kan være helt gyldig og fortsatt være utilgjengelig. Valider først og revider tilgjengelighet etter: de er komplementære lag.