Hur validerar man xhtml?
Att validera XHTML innebär att kontrollera att ett dokument följer två lager av regler: XML-syntax och dess deklarerade DTD eller schema. XHTML 1.0 är en omformulering av HTML 4.01 i XML, så ett dokument kan vara välformat men ändå ogiltigt, som när <a target="_blank"> visas i XHTML 1.0 Strict.
Att validera XHTML är att kontrollera att ett dokument samtidigt följer två lager av regler:
- XML-syntaxregler: korrekt kapslade taggar, attribut inom citattecken, obligatorisk stängning av alla element (inklusive tomma som "
"), ett enda rotelement, en konsekvent deklarerad kodning, etc. - DTD-regler eller deklarerat schema: vilka element och attribut som finns, i vilket sammanhang de kan förekomma och vilka värden som är tillåtna. Här är de klassiska DTD:erna för XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic och XHTML Modularization.
Ett dokument kan vara välformad XML och fortfarande vara ogiltigt: om du till exempel använder <a target="_blank"> i XHTML 1.0 Strict, är syntaxen oklanderlig men target-attributet finns inte i den DTD:n. Denna distinktion mellan välformad och giltig är den främsta orsaken till förvirring när någon ser ett fel och inte förstår varför.
Det är också bekvämt att komma ihåg att XHTML 1.0 är en omformulering av HTML 4.01 i XML, definierad av W3C. Idag är dess praktiska värde tvåfaldigt: det tjänar till äldre projekt som fortfarande används som “applikation/xhtml+xml” eller “text/html”, och det fungerar som en mental disciplin att skriva ren uppmärkning. Om du vill ha det fullständiga normativa sammanhanget för hur man validerar XHTML, är W3C:s specifikation för XHTML 1.0 den primära källan.
Validerare som är värda att använda (och när man ska använda vilken)
Det finns ingen enda “korrekt” validator. Valet beror på om du validerar ett fragment, en produktionssida, en hel webbplats eller ett dokument som redan är XHTML5.
| Verktyg | Vad som valideras | Ideal för | Huvudbegränsning |
|---|---|---|---|
| W3C Markup Validation Service (validator.w3.org) | XHTML 1.0/1.1, HTML4, HTML5 | Punktvis validering via URL, fil eller direktinmatning | Den moderna “Nu Html Checker” prioriterar HTML5; gamla DTD:er kräver manuellt val |
| Nu Html Checker (vnu) | HTML5 och XHTML5 | Nya projekt, lokal validering och i CI | Validerar inte klassiska DTD:er för XHTML 1.x |
| Lokala validerare (vnu.jar, tidy) | Beroende på konfiguration | Automatisering, pre-commit, pipelines | Kräver installation av Java eller binärer; initial konfiguration |
| xmllint | Välformad XML och validering mot DTD/XSD | Kontrollera det rena XML-lagret | Känner inte till specifika HTML-regler utöver schemat |
| Webbläsartillägg / IDE | Live-markering | Omedelbar feedback medan du skriver | Använder ofta utdaterade eller ofullständiga motorer |
W3C Markup Validation Service
Det förblir utgångspunkten för de som undrar hur man validerar XHTML. Den stöder tre lägen: Validera med URI, Validera genom filuppladdning och Validera med direktinmatning. För klassisk XHTML finns tricket i rullgardinsmenyn Dokumenttyp: om ditt dokument deklarerar sin egen DTD via DOCTYPE, respekterar valideraren det; om inte, måste du tvinga den manuellt.
Relaterat: — Superposición de IA que promete cumplimiento WCAG en 48 horas.
En detalj som många inte är medvetna om: den moderna W3C-valideraren förlitar sig på Nu Html Checker, som förstår HTML5 och XHTML5 men behandlar gamla DTD:er med mindre prioritet. För XHTML 1.0 Strict fungerar det fortfarande, men det är tillrådligt att verifiera att resultatet återspeglar den DTD du förväntar dig och inte en slapp tolkning.
Nu Html Checker (vnu)
Detta är validatorn som W3C själv använder internt. Den finns som en webbtjänst, som en JAR-körbar och som en Docker-bild. Dess stora fördel är att du kan köra den lokalt och i kontinuerlig integration, något viktigt om du har en stor webbplats. För XHTML tjänat som application/xhtml+xml, upptäcker vnu kapslings- och attributfel som en tolerant HTML-validator skulle låta passera.
xmllint
Om ditt problem är det rena XML-lagret - till exempel eftersom du genererar XHTML från XSLT-mallar - så är “xmllint” oersättlig. Med --noout --valid documento.xhtml kontrollerar den välformad och giltighet mot den refererade DTD. Det är snabbt, skriptbart och beror inte på nätverket.
Värt att titta på: — Accesibilidad gestionada: automatización combinada con revisión humana.
Validering i editorn
Tillägg för VS-kod, IDE-plugin-program och kommandoradsverktyg ger omedelbar feedback. De är bekväma, men tenderar att hamna efter när det gäller standarder. Använd dem som en första försvarslinje, aldrig som den enda verifieringen.
Hur man validerar XHTML steg för steg
1. Deklarera DOCTYPE och kodning korrekt
DOCTYPE bestämmer mot vilka regler den valideras. För 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>Giltigt exempel</title>
</head>Två klassiska fel här: att glömma xmlns-attributet (obligatoriskt i XHTML) och deklarera en kodning i meta som inte sammanfaller med den faktiska filen. Validatorn upptäcker båda, men den andra visas ibland bara som skadade tecken.
2. Kontrollera välformadhet före giltighet
Innan du slåss med DTD, se till att XML är välformaterad. xmllint --noout archivo.xhtml kommer att berätta på några sekunder. Om det misslyckas här kommer ingen DTD-validator att hjälpa dig: stäng först taggar, korrigera kapslings- och escape-enheter (&, <, >).
3. Validera mot DTD
Med det välformade dokumentet, skicka det genom W3C Validator eller vnu. Granska inte bara hur många fel det finns, utan av vilken typ. Ett enda kapslingsfel kan generera en kaskad av sekundära fel som försvinner när det första korrigeras.
4. Validera hela webbplatsen, inte bara startsidan
Ett vanligt misstag är att validera huvudsidan och anta att resten är bra. Mallar, komponenter och dynamiskt genererade sidor introducerar ofta ogiltig uppmärkning. Automatisera: gå igenom huvudadresserna med ett skript och kör vnu på varje svar.
Relaterat: — La certificación profesional que acredita tu experiencia and accesibilidad.
5. Integrera valideringen i ditt arbetsflöde
Manuell validering skalas inte. Lägg till ett valideringssteg i din pipeline (pre-commit hook, build-uppgift eller CI-jobb) som misslyckas om ett nytt fel dyker upp. På så sätt når ogiltig uppmärkning aldrig produktion.
Tolka felen: de du kommer se om och om igen
- “sluttaggar för X har utelämnats, men UTEGNADE sluttaggar är inte tillåtna”: typiskt för
<li>,<p>eller<td>utan att stängas. I XHTML måste allt vara stängt. - “det finns inget attribut X”: attributet finns inte i din DTD. Vanliga fall:
target,namei vissa element,data-*-attribut i XHTML 1.0 (inte i den klassiska DTD). - “element X undefined”: använder ett element som din DTD inte tar hänsyn till, ofta från att kopiera HTML5-uppmärkning till ett XHTML 1.0-dokument.
- “teckendata är inte tillåtet här”: textinnehåll där DTD endast förväntar sig element, eller ett
&utan att escape. - “referens till entitet X för vilken ingen systemidentifierare kunde genereras”: namngivna HTML-entiteter som inte är definierade i XML (till exempel
Den gyllene regeln för hur man validerar xhtml: rätta uppifrån och ned. Det första felet är vanligtvis orsaken; följande är dess konsekvens.
XHTML5: nyansen som ändrar reglerna
Om du visar XHTML5 —XHTML serialiserad enligt HTML5-syntax — ändras reglerna. Det finns inte längre en DTD: överensstämmelse definieras i WHATWG HTML-specifikationen och W3C-specifikationerna för HTML. Rätt validator är Nu Html Checker, inte den klassiska DTD-validatorn.
Praktiska skillnader att vara medveten om när det gäller hur man validerar xhtml:
- “data-*“-attributen är giltiga i XHTML5, inte i XHTML 1.0.
- DOCTYPE är förenklat till
<!DOCTYPE html>. - Validering görs mot HTML5:s överensstämmelsekontroll, som är mer tillåten på vissa punkter och strängare på andra (till exempel vid användning av vissa föråldrade element).
Att välja mellan XHTML 1.0 och XHTML5 är inte bara tekniskt: om ditt projekt är nytt är XHTML5 med vnu-validering den vettiga vägen. Om du har ett äldre system med DTD, stanna kvar i XHTML 1.0 och validera mot dess DTD.
Validering och tillgänglighet: två olika lager
Ett vanligt fel är att tro att ett giltigt dokument är automatiskt tillgängligt. Det är det inte. Validering kontrollerar syntax och schemaöverensstämmelse; tillgänglighet bedöms mot WCAG del W3C, som täcker uppfattningar, funktionsduglighet och kompatibilitet med hjälpmedelsteknik.
Som sagt, det finns en verklig överlappning: ogiltig uppmärkning innebär vanligtvis en bristfällig struktur (dåligt kapslade rubriker, trasiga listor, formulär utan korrekta etiketter), och detta påverkar tillgängligheten. Den förnuftiga strategin för hur man validerar XHTML och andra dokument är att validera först (eliminera strukturellt brus) och granska tillgängligheten efter med verktyg som axe, Lighthouse eller manuella granskningar. Validering är ett nödvändigt villkor, men inte tillräckligt.
Vanliga fel vid validering av XHTML
Undvik dessa vanliga misstag när du lär dig att validera XHTML:
- Validera endast hemmet. Den problematiska markeringen finns vanligtvis på interna mallar.
- Ignorera kodning. En dåligt deklarerad “teckenuppsättning” ger spökfel.
- Förväxla välformad med giltig. De är distinkta lager; lösa dem i ordning.
- Använd fel validator. vnu för XHTML5, DTD för XHTML 1.x.
- Åtgärda kaskadfel utan att läsa det första. Du slösar bort tid och fixar symtom.
- Ingen automatisering. Manuell validering överlever inte den andra spurten.
- Förutsatt att giltig = tillgänglig. Det är olika standarder med olika syften.
Viktiga slutsatser
- Validering av XHTML involverar två lager: välformad XML och överensstämmelse med den deklarerade DTD eller schema.
- W3C Markup Validation Service och Nu Html Checker (vnu) är referensverktygen för hur man validerar xhtml;
xmllinttäcker det rena XML-lagret. - För XHTML 1.0/1.1, använd validering mot DTD; för XHTML5, använd vnu och glöm de klassiska DTD:erna.
- Korrigera felen uppifrån och ned: det första orsakar vanligtvis följande.
- Automatisera valideringen i din pipeline; manuell granskning skalas inte.
- Giltigt är inte synonymt med tillgängligt: de är kompletterande standarder, inte motsvarigheter.
Källor & vidare läsning
- XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) är en del av familjen XML-markeringsspråk som speglar eller utökar versioner av den mycket använda HyperText Markup…
- XHTML Basic — Wikipedia: XHTML Basic är ett XML-baserat märkningsspråk designat för enkla användaragenter med begränsad datorkraft, som tidiga mobiltelefoner, handdatorer, personsökare och set-top…
Vanliga frågor
Vad är skillnaden mellan välformad XHTML och giltig XHTML?
Ett välformaterat dokument följer de syntaktiska reglerna för XML: stängda taggar, korrekt kapsling och attribut inom citattecken. Ett giltigt dokument respekterar dessutom DTD eller schema som det deklarerar: endast med hjälp av element och attribut som är tillåtna i dess sammanhang. Du kan ha ett välformat men ogiltigt dokument, till exempel om du använder ett attribut som inte finns i XHTML 1.0 Strict.
Är det fortfarande meningsfullt att validera XHTML 2024?
Ja, av två anledningar. För det första fortsätter många äldre projekt att tjäna XHTML och måste förbli giltiga för att inte gå sönder i XML-läge. För det andra är validering en disciplin som upptäcker strukturella fel som påverkar tillgänglighet och underhåll. Om ditt projekt är nytt använder det förmodligen HTML5 eller XHTML5, men vanan att validera är fortfarande värdefull.
Vilken validerare ska jag använda för XHTML5?
Nu Html Checker (vnu), tillgänglig som en webbtjänst, körbar JAR och Docker-bild. Det är samma motor som den moderna W3C Markup Validation Service använder och förstår HTML5-syntax och dess XHTML-serialisering. Använd inte klassiska DTD-validerare för XHTML5: de känner inte igen data-*-attribut eller andra HTML5-funktioner.
Varför ger W3C-valideraren mig fel som jag inte förstår?
Eftersom många fel är följden av ett tidigare. Felaktig kapsling kan generera dussintals sekundära meddelanden. Den korrekta strategin är att korrigera det första felet, validera igen och upprepa. Det händer också att valideraren tillämpar DTD som deklareras i DOCTYPE; om denna DTD inte är vad du förväntade dig, kommer felen att verka godtyckliga.
Kan jag validera XHTML från kommandoraden?
Ja. Om du undrar hur man validerar XHTML via CLI, kontrollerar xmllint --noout --valid archivo.xhtml välformadhet och giltighet mot DTD. För HTML5/XHTML5 gör vnu.jar archivo.xhtml samma sak. Båda alternativen är idealiska för att integrera i byggskript, pre-commit hooks eller kontinuerliga integrationsjobb, där manuell validering inte är skalbar.
Är en giltig XHTML-webbplats automatiskt tillgänglig?
Nej. Validering kontrollerar syntax och schemaöverensstämmelse; tillgänglighet bedöms mot WCAG, som täcker aspekter som kontrast, tangentbordsnavigering, alternativ text eller semantisk struktur. Ett dokument kan vara helt giltig och fortfarande vara otillgänglig. Validera först och granska tillgängligheten efter: de är kompletterande lager.
Añade accesibilidad på 5 minuter
Widget för accessibilidad med plan gratis för empezar Hoy Mismo