kaxigt.com

Den här artikeln publicerade jag 2010 som ett gästinlägg på annan sajt.
Sedan HTML introducerades i slutet av 1991 har den genomgått många förändringar.

Den första versionen av HTML som var tänkt att användas för att bygga enkla webbsidor saknade en fastställd definition. 1993 började dock the Internet Engineering Task Force (IETF) att standardisera språket och senare under 1995 så släpptes den första riktiga standarden för HTML i form av HTML 2.0.

Här handlade det mest om en klassisk HTML-dialekt som stöddes av webbläsare typ Mosaic. Denna form av HTML stöder endast kärnelementen och förekomsten av tabeller och formulär, men tar ingen som helst hänsyn till webbläsarnas utveckling vare sig i tolkning och stöd av stilmallar, script, eller av ramar.

HTML 4.0 tillhandahåller också en grundläggande övergång till CSS (Cascading Style Sheets) samt en samling av element och attribut med stöd för multipla språk, tillgänglighet och script. Problematiken som senare kom var det växande motståndet för XML:s omformulering av HTML (XHTML).

I skuggan av detta började the WHATWG3 group att utarbeta en standardmodell för HTML5, vilken framöver även skulle komma att involvera W3C. Här ville man anstränga sig för återuppväcka acceptansen och intresset för traditionell HTML och utveckla denna som en webbapplikation, men också för multimedia, och att hitta eventuella otydligheter i webbläsarnas parsingsystem.

Kännetecknet för detta är att sedan 2005 har delar av HTML-specifikationen HTML5 börjat synas i webbläsarna och det gör därför framtiden för XHTML något dunkel.

HTML och XHTML – specifikationerna i fokus

Till skillnad från den mark up som vissa webbutvecklare tycks producera har både HTML och XHTML en väldefinierad syntax. Alla (X)HTML-dokument bör följa den formella strukturen som fastställts av World Wide Web Consortium (W3C är den främsta organisationen som definerar web standards).

Traditionellt har W3C preciserat HTML som en applikation på Standard Generalized Markup Language (SGML). SGML är en teknologi (metaspråk) som används för att bestämma vilket typ av märkspråk som används genom att man specificerar dokumentets struktur med DTD (Doctype Type Definition).

1999 omformulerades emellertid HTML till att bli en applikation av XML och man kallade det därför XHTML. XML fick nu samma syfte som SGML, nämligen att vara ett regelverk för det språk som angavs.

Både XML och SGML kan användas till att skriva godtycklig mark up, inte bara HTML och XHTML. De senare brukar dock kallas för applikationer, eller mer korrekt; applikationsspråk. Det finns ett flertal olika märkspråk som definieras med SGML och XML, man kan till och med definiera sitt eget språk om man vill. Hur relationen mellan de olika märkspråkens teknologier ser ut visar nedanstående bild.

Ordentligt konstruerade (X)HTML-dokument ska referera till ett doctype eller något liknande av samma slag. Det är därför också viktigt att veta vad detta innebär för webbläsarna och för webbens kvalitetssäkrande redskap när de ska ta hänsyn till de direktiv som doctype anger.

Intressant nog så använder inte HTML5 varken SGML eller XML-definitioner utan förlitar sig istället på engelska prosaspecifikationer som är kombinerade med en viss formalia. Trots det skriver många fortfarande kodstandarden XHTML och lägger till en namnrymnd som refererar till XML fastän det nu är HTML5. Sedan anges doctype för HTML5 och XHTML validerar felfritt som – HTML5!

Kan detta verkligen vara sant?

När man applicerar XML på HTML5 börjar vi att röra oss mot XHTML5. XHTML5 är XML:s specialisering av HTML5 och har alla strikta parsingregler man kan förvänta sig och är van vid om man tidigare har arbetat med XHTML.

XHTML5 måste levereras med XML MIME type application/xml eller application/xhtml+xml (IE klarar ännu inte detta).

Alla vanliga XML-regler gäller; alltså inga document.write tillåts, inget doctype behövs, viss skillnad i syntax och script finns, samt att man kan använda namespace. Med andra ord tillåter HTML5 oss att fortsättningsvis applicera XHTML.

Inga regler för (X)HTML?

(X)HTML i sig har inga regler. Givetvis – i vissa versioner är reglerna något “lösa”. Men dessa ”regler” tycks inte alltid vara samma regler, och det beror mycket på webbläsarna för att de i princip låter vad som helst passera.

Visst – vi vet att vi ska lägga till slutslashar i XHTML men inte i HTML.

Vissa htmlelement förekommer i XHTML Transitional men inte i Strict trots att båda är kodstandard XHTML. Strict HTML och Strict XHTML bygger på samma princip, skillnaden är att den ena har en xml-baserad mark up och inte den andra.

SGML är en textbaserad mark up och XML är en förenkling av denna, vilket innebär att XML också är textbaserat på samma gång som språket är utbyggbart mot HTML (som enbart hanterar textbaserad mark up).

Man bör i alla händelser följa de ”regler”, eller rekommendationer, som finns för varje version därför att ett felaktigt dokument har många signifikanta baksidor, i synnerhet om de ska visas i kombination med exempelvis CSS eller javascript, eller en mix av dem båda och märkspråket.

I verkligheten är det så att XHTML används i allmänhet som något mellan ett strict utförande eller inget utförande alls mot specifikationen.

Specificera content type, character set, och mer

En <meta>-tagg kan användas i ett antal olika variationer. Till exempel kan man använda det för att specificera värden som är likvärdiga till HTTP response headers. Eftersom meta är ett tomt element används alltid en trailing-slash – en slutslash i koden.

Observera att man inte lägger till det i doctype eller i namnrymden (namespace). Nedanstående två koder är ingen ovanlig kombination på hemsidor.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

<!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">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Att bestämma sig för vilken MIME type man ska använda är inte alltid lätt. Skriver man standard HTML är MIME type alltid text/html. Å andra sidan, när man börjar att blanda in XHTML uppstår ofta funderingar kring vilka problem det kan bli när webbläsarna ska följa specifikationen.

Faktum är att de flesta levererar XHTML som text/html i tron att det är XHTML. HTML och XHTML är universella märkspråk och att xml ”bygger” ut HTML till XHTML vet vi nu eftersom HTML annars är begränsad till att leverera dokument i textformat (text/html).

För XHTML ges då särskilda riktlinjer då det är ett xmlbaserat märkspråk, vilket följdaktligen ställer större krav på dokumentets utformning.

Syftet med xml är ju att kunna skapa interaktioner mot andra webbplatser med vilka data sedan kan användas för olika applikationer och plattformar.

To send XHTML markup to a browser with a MIME type that says that it is XML, you need to use one of the following MIME types: application/xhtml+xml, application/xml or text/xml. The W3C recommends that you serve XHTML as XML using only the first of these MIME types – ie. application/xhtml+xml. When a browser reads XML it uses an XML parser, not an HTML parser.

(http://www.w3.org/International/articles/serving-xhtml/Overview.en.php)

Låt oss säga att Du vill säkerställa att din MIME type och teckenuppsättning är inställd för engelskbaserad XHTML i ditt dokument, men du vill också leverera det som ett gränssnitt till användaragenterna – då ska du alltid skriva XHTML Strict och använda följande:

<?xml version="1.0" encoding="UTF-8"?>
<!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">
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8">

Vill man att användargränssnittet XHTML (strict) ska levereras som just XHTML så är det alltså viktigt att både använda rätt mime type (application/xhtml+xml) som rätt doctype inklusive namnrymd (namespace).

För att också tydliggöra för webbläsarna att webbplatsen kan innehålla tecken från det Latinska språket (å ä och ö) kan man infoga en meta tagg för just svenska om man inte skriver om tecknen.

xml-deklarationen, tätt åtföljt av doctype, ska ligga absolut överst i dokumentet (före roten html).

Tillsammans bildar de xml-prologen, det vill säga doctype och själva xml-deklarationen, vilka innehåller relevant information som webbläsarens parser behöver för att kunna tolka xhtmldokumentet.

Det är då extra viktigt att använda rätt mime typ är för att kunna leverera XHTML. Med rätt mime typ är XHTML bakåtkompatibelt som just XHTML. Tyvärr så har IE problem med att tolka application/xhtml+xml och läser därför in denna som text/html.

Dock finns en ”fix”:

I html-dokumentet

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!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">

copy.xsl

<stylesheet version="1.0"
     xmlns="http://www.w3.org/1999/XSL/Transform">
    <template match="/">
        <copy-of select="."/>
    </template>
</stylesheet>

Webbläsare och XHTML

Webbläsaren bygger ett parsingträd för att kunna tolka strukturen i ett webbdokument.

Parsingträdet, som ofta kallas för DOM (Document Object Model), är detsamma som webbläsarnas tolkningar av den mark up som finns i dokumentet samtidigt som de fastställer hur sidan ska visas – både i default XHTML-läge som kopplat till CSS-läge.

Parsingträdet kan man säga vara en webbsidas ”skelett”, därför är det så otroligt viktigt att dokumentet är väl utformat, har rätt doctype och specifikationer, vilket tyvärr allt för ofta inte är fallet.

Det är beklagligt att webbläsarna stöder en sådan stor mångfald av inkorrekta saker och att utvecklarna oftast bara utgår från en, max två, populära webbläsare och sedan struntar hur sidan visas i andra.

Under ett kortare tidsperspektiv kan det möjligen vara acceptabelt, men i längden kommer det inte att fungera, i synnerhet om nya teknologier utvecklas och ska implementeras på sidan.

Här tänker jag bland annat på CSS, Javascript och nyare webbläsare. Tyvärr så är det så att utgår man bara från en eller två givna webbläsare så får man också räkna med att sidan inte alltid kommer att visas i standard compliance mode.

Vad följderna blir är lätt att räkna ut.

Standards mot praktiskt utförande

Bara för att det finns standarder så betyder det inte per automatik att alla följer det, eller ens tycker om det. Det finns många webbutvecklare som inte känner till vad web standards egentligen innebär.

De tror sig veta så länge deras webbsidor ser ”tillräckligt bra” ut i favoritwebbläsaren, då fortsätter de med felaktig använd mark up och otaliga kontroversiella lösningar för htmlelementen. Dock är inte ”tillräckligt bra” tillräckligt bra.

Utan några standardiseringar skulle nätet braka samman. Web standards kräver också erfarenhet men framförallt att man lär sig ta för vana att validera sin mark up.

Om en webbläsare känner att den ”går in” i XML så kommer den också att inta parsingreglerna för XML och tvinga fram ett ”väl format”. En strikt XHTML-inordnad webbläsare borde egentligen inte visa en enda felaktig sida ifall de inte följde standards.

Nu är ju det högst osannolikt att detta skulle ske eftersom webbläsarnas absolut sista utväg är att gå in i bakåtkompatibelt läge – quirks mode.

Doctype Switch “Doctype Sniffing” och browser rendering modes

Moderna webbläsare har i allmänhet två visningslägen: quirks mode och standards compliance mode. Precis som namnen anger är quirks mode mer tillåtande medan standards compliance mode är striktare.

Webbläsaren väljer vilket visningsläge denna ska inta beroende på vilket doctype som har angivits, om det överhuvudtaget finns något.

Om vi degraderar ett xhtmldokument till HTML med mime type text/html så skapas en taggsoppa, vars koder förvisso kan vara valida och hålla kodstandarden XHTML, men som ändock resulterar i att webbläsarna hanterar dokumentet som ett htmldokumet oavsett hur mycket det än är skrivet i kodstandarden XHTML.

Konsekvensen blir att det doctype som används i dokumentet egentligen inte är helt kompatibelt med XHTML, istället uppstår något som kallas för ”Doctype Sniffing”.

Det betyder att webbläsarna inte riktigt kan hantera de css-regler som relaterar till doctype XHTML (Strict), så antingen byter de (degraderar) till HTML eller går in i quirks mode än att följa CSS2 specifikationerna för XHTML.

Webbläsarna löser detta genom att kalla det för ”Almost Standard Mode”, och det säger ju faktiskt ganska mycket!

Därför menar jag att det inte finns några skäl till att leverera XHTML som text/html, då har man nog missat själva idén om XHTML är jag rädd, och kan likväl använda traditionell HTML.