I den förra artikeln så vi vad som kan vara en god HTML-kod. Där började vi titta lite på skillnaderna mellan HTML och XHTML, samt på nedvärderade taggar och attribut. Nu skall vi gå vidare och utforska detta närmare och se mer specifikt på olika slags HTML.
Hur SGML blev HTML
Obs! Denna artikel går in på ett relativt djup i frågor som jag sällan sett förklaras på svenska, och kan kännas lite avskräckande. Om det känns krångligt, lyft på hatten och gå vidare. Återkom sedan efter ett tag, när du behöver, för jag tror ändå att det som beskrivs här är värdefullt att kunna.
Från början
fanns Structured Graphics Markup Language (SGML),
ett märkspråk som bl.a. användes av det amerikanska försvaret för deras miljontals sidor manualer.
SGML var krångligt men kraftfullt. När Tim-Berners Lee ville göra sitt sidbeskrivningsspråk (HTML),
så utgick han från SGML, fast han förenklade det åtskilligt. Däri låg kraften. Enkelheten gjorde att i stort sett alla kunde göra egna hemsidor.
Många introduktioner till HTML har under årens lopp påstått att HTML är en delmängd av SGML, eller att det är en tillämpning av SGML.
Detta är inte med den praktiska sanningen överensstämmande. I praktiken har nämligen webbläsarna aldrig följt SGML-reglerna särskilt väl.
Det finns många regler i SGML som webbläsarna ignorerar och eftersom det finns en hel del dålig kod ute på webben, så har webbläsarna
tvärs emot SGML-reglerna blivit oerhört förlåtande
när de tolkar koden för webbsidor.
Man kan uttrycka det så här. De allra första versionen av HTML var inspirerad av SGML. Till den andra versionen så blev denna inspiration något som skrevs in i den formella standarden som en regel, men denna del av standarden fick aldrig genomslag i webbläsarna.
Exkurs: Saker som borde funka om HTML verkligen vore SGML
Låt mig ge två exempel på hur SGML och HTML skiljer sig åt. Jag får ofta frågor om detta, främst från lärare som fått lära sig
HTML enligt datavetenskapen
och som ibland till och med blir lite upprörda över att detta ifrågasätts. Följande två
stycken (p-elementet anger ett stycke i HTML) skall enligt SGML-reglerna tolkas exakt likadant:
<p>Lorem ipsum</p>
<p/Lorem ipsum/
Ytterst få har sett kod enligt det nedre exemplet. Denna kortform är korrekt SGML, men stöds inte av någon webbläsare.
Ett annat exempel rör kommentarer. (Mycket förenklat resonemang följer.) Enligt HTML skall en kommentar börja med <!--
och sluta med -->
men en kommentar kan också sluta med ett ensamt & som står efter --
i SGML.
Den enda webbläsare som stödjer både sätten att avsluta en kommentar är Firefox (till och med version 3.6,
men inte 4.0 och framåt). Detta skapar ibland problem, då det finns kod som ser ut så här på webben:
<!-- Kommentartext -- x > y -- Också tänkt att vara kommentar -->
Firefox (<= 3.6) i Standards Compliant Mode
(se nedan) kommer visa texten y -- Också tänkt att
vara kommentar -->
, eftersom det är korrekt enligt reglerna för SGML. Alla andra webbläsare kommer dölja detta.
Okunnighet gör att utvecklarna tror att kommentaren skall fortsätta som vanligt också efter strecken i mitten, och så funkar det alltså i alla webbläsare utom Firefox (<= 3.6). I och med HTML5 så har denna förväntan gjorts till regel och Firefox 4 har ändrat sitt beteende. (Den bugg som handlat om att fixa beteendet i Firefox har duplicerats in absurdum.)
Slutsats: Till dess att Firefox 3.6 och äldre har försvunnit från marknaden, använd aldrig två bindestreck inuti en HTML-kommentar. Och med hänsyn till andra HTML-tolkar som kan tänkas finnas, låt bli det helst sedan också. En gång i tiden var HTML tänkt att vara likt SGML och detta är en retsam rest av denna idé. Detaljerna kring SGML:s regler för kommentarer är så många och krångliga, så vi skall skatta oss lyckliga att de har övergivits i HTML.
Hur HTML blev XML dvs. XHTML
När webbläsartillverkarna började införa grafiska element och taggar så svarade det visserligen mot
ett av användarna uttryckt behov, men det kom att göra språket mycket svårare.
Många misstag begicks, men man insåg också värdet av sidmärkningsspråk också för annat än rena webbsidor
och i stället för att införa tusentals taggar i HTML,
så konstruerades eXtensible Markup Language
, XML. XML har blivit en framgång och finns
på mängder av ställen, vilket vanliga datoranvändare är lyckligt ovetande om. XML-standarden definierar inga element,
utan det är upp till varje utvecklare att själv välja lämpliga taggar.
Det kan se ut så här:
<?xml version="1.0">
<familjer>
<familj id="1">
<medlem id="550712-1112">
<namn>Sven Svensson</namn>
<mamma>321109-2223</mamma>
<pappa>301212-7777</pappa>
</medlem>
<familj id="1">
<medlem id="540712-8882">
<namn>Stina Svensson</namn>
<mamma>371109-4223</mamma>
<pappa>321212-7373</pappa>
</medlem>
</familj>
</familjer>
En dator kan naturligtvis inte förstå koncepten familj
, mamma
och pappa
.
Ur datorns perspektiv hade jag kunnat kalla mina element precis vad som helst.
Deras namn bör dock vara logiska för den som utvecklar och använder XML-filen.
XML definierar alltså inte några specifika element eller attribut, utan enbart en syntax, dvs. språkliga regler för hur XML skall skrivas. Jämfört med SGML innebar det en förenkling och jämfört med HTML innebar det en tydlig uppstramning. Dålig kod, som inte är välformad (se förra artikeln) tillåts över huvud taget inte. Så fort tolken stöter på sådan, så kräver standarden att inläsningen skall avbrytas. Webbläsare däremot anstränger sig till det yttersta för att skapa någon slags reda också i den mest gräsliga HTML-kod.
När XML inte är välformad, så visar webbläsarna oftast upp en gul felsida – The Yellow Screen of Death
,
namngiven efter Windows ökända blåa skärm som visas vid systemfel.
XHTML
XHTML är XML som använder sig av HTML:s välkända element och attribut. Dvs. semantiken hämtas från HTML, men syntaxen är XML. XHTML är alltså en tillämpning av XML.
XHTML måste alltså uppfylla alla formella regler för XML, såsom:
- Alla taggar måste nästlas i rätt följd, som jag skrev i förra artikeln.
-
Eftersom man i XML skiljer mellan elementnamn och attribut också beroende på om de skrivs med stora eller små bokstäver,
så måste dessa i XHTML skrivas med små bokstäver.
Följande var OK i HTML 4 och tidigare:
<BODY>, <BoDy> och <body>
. Nu måste man använda det sista alternativet. - Alla entiteter måste skrivas korrekt. Gula XML-döden inträffar oftast när man skrivit glömt skriva
&
som&
- Alla element måste avslutas explicit. HTML tillåter att avslutningstaggen utelämnas ibland. XHTML gör den obligatorisk.
-
Tomma element, som
<br>
(=ny rad (eng: break), skall man nu också avsluta explicit. Det kan enklast göras så här:<br/>
. Här avslutas alltså elementet inuti samma tagg som det påbörjades. Äldre webbläsare kan ha problem med detta, så ofta skriver man för deras skull in ett mellanslag före den avslutande slashen, så här:<br />
. Dessa gamla webbläsare är numera i stort sett utrotade, men jag fortsätter använda detta mellanslag i alla fall då jag tycker att det ökar kodens läsbarhet. Det finns också skäl att bevara detta mellanslag när man blandar HTML och SVG, vilket man kan göra i HTML5. - Alla attribut måste ha attributvärde och alla attributvärden måste stå inom citationstecken. Förkortade attribut tillåts alltså inte. Om det är någon punkt i XML-syntaxen jag skulle vilja ändra så är det just för att få använda förkortade attribut.
- Alla HTML-taggar och attribut måste stå med små bokstäver (gemener).
- Ovanstående regel gäller också för CSS-selektorer.
Äkta och falsk XHTML
När webbläsaren skall visa en webbsida, så är det flera saker som händer. Somliga av dessa sker i sekvens, andra parallellt och somliga delar kan komma att upprepas flera gånger.
-
Indata skall
parsas
– vilket är en försvenskning av engelskansparse
. Parsningen består av två delar:-
Tokenisering som innebär att koden bryts ned i kategoriserade delar – tokens.
Denna del av processen kan också kallas
lexing
. -
Konstruktion av att objekt-träd (
Tree Building
), en inre representation i datorns minne av dokumentets delar, deras relationer och egenskaper,the DOM
.
-
Tokenisering som innebär att koden bryts ned i kategoriserade delar – tokens.
Denna del av processen kan också kallas
- Extra resurser skall hämtas; bilder, stilmallar, skript, Flash-objekt, etc.
- Skript skall köras, och dessa kan i sin tur påverka DOM-trädet eller leda till att ytterligare resurser hämtas.
- Sidan skall renderas (ritas) – och ofta ritas om på nytt beroende på skript eller andra resurser som påverkar dess utformning.
Det som skiljer webbläsarens hantering åt när man använder HTML och XHTML är främst tokeniseringen
och i viss mån
också träd-byggandet
. Dessa moment utförs helt enkelt av två skilda delar av programmet, men hur vet det vilken
den skall använda?
Svaret är att det beror på dokumentets MIME-deklaration vilken deklareras
i HTTP-huvudet. Lägg noga märke till detta. Växelmekansmen som avgör vilken parsning
som skall användas är inte
alls beroende av dokumentets innehåll. Det spelar alltså ingen roll om man deklarerar en XHTML-doctype längst upp, eller
om man lägger till ett XML-huvud. Det spelar ingen roll heller om man anger en namnrymd (se nedan). Alla dessa åtgärder utförs
i dokumentet, men det avgörande är alltså HTTP-huvudet.
Når inget HTTP-huvud finns, som när man läser in dokument direkt från hårddisken, så avgörs det i stället med hjälp av
filändelsen. Är den html
eller htm
så används the tag soup parser
, dvs HTML-tolken. Om
filändelsen är xhtml
, så används XML-tolken.
Att på detta sätt skilja ut XHTML kallas ofta för äkta
XHTML. Det finns många – och jag är
en av dem – som använt eller använder XHTML:s syntax och som kontrollerar våra webbplatser så att de uppfyller
XHTML-reglerna, i vart fall de flesta, trots att vi sedan skickar sidorna som vanlig HTML. Vi använder XHTML som en
självpåtagen regeluppsättning för att skapa
mer lättläst och lättskött kod; vi använder det som ett lint-verktyg.
Jag är en stark anhängare av falsk
XHTML, och kräver att mina elever använder det också, med några undantag.
I framtiden hoppas jag att det skall
finnas ett mer nyanserat och specialanpassat lint-verktyg för HTML, gärna inbyggd
i validatorn.
Ett dokument som fungerar lika bra som både HTML och XHTML kallas polyglot. Äkta polyglot-dokument görs sällan, för rent tekniskt är det mycket svårt att hålla reda på alla detaljer. Men som väl är behöver man sällan den precisionen i sitt arbete. Låt bara inte någon besserwisser skrämma dig från att använda de goda delarna i XHTML av sådana skäl.
XHTML:s teoretiska fördelar och praktiska nackdelar
X:et i XML och XHTML står för eXtensible. Tanken är att man skall kunna utvidga sin applikation med
taggar och attribut från andra språk. I praktiken har detta inneburit att man vill blanda SVG och MathML med sin HTML-kod.
För att skilja de olika elementen åt, beroende på ursprung, så deklareras de som tillhöriga olika namnrymder.
Det här kan man göra för all XML och det skapar en på pappret stor potential. I praktiken har detta dock inte medfört
några egentliga landvinningar. Trots att XML finns i din dator, under skalet
på flera olika sätt, så har det inte
slagit igenom på webben. Anledningarna är flera:
- XHTML:s drakoniska felhantering. Skärmdumpen ovan är från Facebook. Trots att de anställer hundratals extremt duktiga utvecklare, så kunde jag stoppa in ett & tecken, och få sidan att krascha. Sådan felhantering blir i praktiken inte rimlig.
- Fartökningen som skulle komma sig av snabbare parsning uteblev. Eller rättare sagt, den enda delen som snabbas upp, tokeniseringen är en så obetydlig del av den totala tidsåtgången att en aning högre fart på denna del är försumbar i det stora hela. Det är operationerna i DOM och själva ritandet på skärmen som tar tid.
- Internet Explorer klarar inte av XHTML. (Förrän version 9.) Sidor som skickas som äkta XHTML triggar dialogrutan för nedladdning, som om man ville öppna dem i en annan läsare! Så länge som Internet Explorer version 8 eller lägre finns på marknaden, alltså minst till år 2015 (min gissning), så kommer detta vara ett problem.
- I princip alla JavaScript slutar att fungera under XHTML. Somliga metoder är inte tillåtna alls och andra är ändrade. I och med genombrottet för Ajax så skapades ett stort antal kodbibliotek, som JQuery, Prototype, Mootols, YUI och Dojo. Någon av dessa återfinns på snart sagt varje moden webbplats. Ingen av dem fungerar med äkta XHTML.
XHTML som kodningsstandard
De reella fördelarna med XHTML är framför allt två:
- Det finns en mängd olika verktyg och kodbibliotek för att hantera XML på servern. Det innebär att om man håller sig till XML syntax, så kan dessa utnyttjas, men det betyder inte att man sedan måste skicka resultatet som äkta XHTML till webbläsaren.
- Som nämnts ovan, så fungerar XHTML utmärkt som en kodstandard. Resultatet blir renare och mer lättläst, vilket i sin tur kortar ner utvecklingstiden och framför allt tidsåtgången för underhåll och vidareutveckling.
Underversioner av HTML 4.01 och XHTML 1.x
XHTML 1.0 är helt identisk med HTML 4.01 vad gäller semantik (element, attribut och entiteter). Någon praktisk skillnaden
mellan dem i kapacitet finns inte – så länge som vi talar om falsk
XHTML. När man vill beskriva HTML och
XHTML tillsammans, eller när det inte spelar någon roll vilken av de två som avses, så skriver man (X)HTML, alltså med X:et
inom parentes.
Strict, transitional och frameset
När man introducerade HTML 4, så ville man uppmuntra till att skilja ut design (CSS) från innehåll (HTML). Dock så fanns det ju redan enorma
mängder sidor gjorda utan sådan separation. Därför valde man att tillåta vissa element och vissa attribut, som dock markerades som nedvärderade.
Detta var alltså en åtgärd för att inte bryta bakåtkompabiliteten på nätet. Den som idag skapar en hemsida kan tvinga sig själv att undvika dessa
dåliga saker genom att välja att koda sin sida strikt
. Det som undanbedes i övergångsformen (eng: transitional)
av HTML 4 är förbjudet i den strikta versionen. En tredje, än mer tillåtande version, kallas frameset
, då den tillåter
användning av ramar (se nedan).
Denna åtskillnad mellan tre versioner ärvdes av XHTML 1.0. Lägg märke till att det som tvingar utvecklaren att separera innehåll från design inte är om man använder XHTML i stället för HTML, utan om man använder sig av strikt (X)HTML. Samtidigt som XHTML började användas, så slog också den CSS-baserade designen igenom. I många webbutvecklares medvetande så sammanlänkades dessa två delar. Pedagogiskt kanske det fyllde ett syfte. XHTML-syntaxen tvingade utvecklaren skriva syntaktiskt renare kod och CSS möjliggjorde att man skrev semantiskt renare kod. Men denna sammankoppling är alltså mental, inte teknisk.
På denna punkt är jag stenhård. Mina elever är förbjudna att använda någon annat än de strikta versionerna, eller den senaste versionen (HTML5). HTML5 har inga versioner, men ställer lika hårda krav på utvecklaren, så det tillåter jag också.
Tillåter HTML5 skräpig kod?
En av tvistepunkterna runt HTML5 är om det är en tillbakagång. Sant är att HTML, till skillnad från XHTML, inte tvingar dig att använda citationstecken runt attributvärden eller bara ha små bokstäver som elementnamn och attribut, men det finns heller inget som tvingar dig att låta bli. Du kan fortfarande göra detta (och skall som min elev göra detta) och så får du använda andra sätt att kontrollera resultatet än enkel validering.
En annan källa till tron att HTML5 är ett steg tillbaka är att man inte ser att standarden har två olika regeluppsättningar.
En mycket tillåtande regeluppsättning, som definierar hur webbläsare skall hantera också värsta tänkbara HTML-kod, och
en mycket striktare regeluppsättning som definierar vad utvecklare av webbplatser får göra. De tillåtande reglerna
tar ingen hänsyn till tillgänglighet, användbarhet, kodkvalitet eller något annat som förknippas med god praxis.
De strikta reglerna, som nu kallas conformance criteria
, tar stor hänsyn till detta.
En ytterligare källa bakom dessa tvister är att somliga av de som drivit på utvecklingen bakom HTML5 haft en viss besserwisser attityd, som knappast hjälpt dem vinna gehör för sina åsikter. Speciellt när de ifrågasätter vissa invanda sannaningar, som ibland visat sig vara osanna eller när de ifrågasätter i vilken utsträckning god praxis skall skrivas in i standarden som sådan.
Kort sagt: På sätt och vis kan man komma undan med skräpig kod om man använder HTML5, men inget tvingar dig att skapa skräpkod, så låt bli! Och är du min elev så tvingar jag dig att låta bli!
Hur XHTML blev HTML igen
Modulär XHTML
Rent kronologiskt har vi gått händelserna något i förväg. Innan (X)HTML5 kom nämligen XHTML 1.1. Vid den här tiden var tanken hos W3C att HTML skulle helt ersättas med XHTML. Första vidareutvecklingen blev XHTML 1.1.
I denna standard så finns det inte längre någon uppdelning mellan strict
och transitional
.
I stället har man delat upp element och attribut i en mängd moduler. Dessa moduler sätts sedan ihop i olika
profiler. De enda som nappade på idén var mobiltelefontillverkarna, som skapade en mobile profile
,
som var tänkt som en vidareutveckling av WAP.
Idag satsar alla på att skapa en så fullständig webbupplevelse som möjligt också i mobilen. XHTML 1.1 har därför dött.
En annan anledning till att XHTML 1.1 aldrig slog igenom, var att man formellt förbjöd möjligheten till att använda versionen
som falsk
HTML. Nu har det hjorts i alla fall, men sällan medvetet, utan främst genom att
ASP-utvecklare inte ändrat de felaktigt standardinställningarna
i Visual Studio.
XHTML 1.1 introducerade en modul med nya element: ruby. Detta
är till stor nytta inom CJK-språken (Chinese, Japanese, Korean
), speciellt japanska. Webbläsarna
har varit mycket sena att stödja ruby. Bara Internet Explorer har gjort det sedan 2001 – fast med buggar. 2010 släpps versioner av
Safari, Chrome och Firefox som stödjer den delmängd av ruby, som ingår i HTML5. (Resten behövs troligen inte.) Opera
förväntas också snart komma med en version som stödjer ruby. (Detta skrivs sommaren 2010.)
XHTML 2.0
Efter 1.1 så skulle framtidens XHTML kallas 2.0. Den innebar ett rejält brott mot tidigare semantik från (X)HTML. Kanske skulle man lärt av den misslyckade standarden HTML 3.0, som aldrig fick genomslag, då den inte motsvarade verkligheten, hur många goda idéer man än hade. XHTML 2.0 innebar nämligen att man skrev om nästan hela språket. Befintliga webbplatser kunde inte uppgraderas och webbläsarnas befintliga metoder för att tolka och rendera (=visa) resultatet skulle ha behövt skrivas om i grunden.
XHTML 2.0 är en genomtänkt och extremt ren standard för textdokument. Men det som utvecklare verkligen saknar i HTML 4/XHTML 1 är möjligheten att bygga applikationer. Standarden är alltså ett opraktiskt, men ädelt, svar på fel fråga!
(X)HTML5
Eftersom XHTML 2.0 utvecklades åt galet håll, så blev ett antal aktörer intresserade av att i stället vidareutveckla dagens HTML. Denna grupp, WHATWG, har fått sitt arbete erkänt av W3C, och inom dess ram utvecklingar en öppen arbetsgrupp av HTML5. Detta är en bakåtkompatibel utvidgning av dagens HTML, som kommer att finnas i två serialiseringar: HTML och XHTML. Firefox, Opera och Safari har redan börjat implementera stöd för denna standard. Internet Explorer version 9 kommer också stödja stora delar av standarden.
Just vad HTML5 innebär är en svår fråga. Ordet är nämligen inte bara ett versionsnamn för märkspråket HTML, utan också ett
buzzword
, och har som sådant ersatt Ajax eller Web 2.0
som dominerade under perioden 2004-2009.
När jag talar om HTML5, så avses bara standarden för märkspråket. Alla andra tekniker
som
samlas under mode-ordet HTML5
kallar jag mer korrekt
webbstacken.
En liten detalj. HTML5 skrivs utan mellanslag mellan sista bokstaven och femman, till skillnad från alla andra standarder. Varför? Det bara blev så…
Läs mer om HTML historia.
- Mark Pilgrim förklarar
hur vi kom hit (HTML5)
. - Ian Hickson punktar upp HTML:s förhistoria och första år.
- HTML5:s historia på W3C:s wiki.
Vad är ramar (frames)?
Eftersom jag nämnde ramar ovan, så låt mig kort förklara vad det är. De kan ses som en kvarleva från 90-talet. De möjliggjorde att somliga delar av sidan (vanligen navigation och sidhuvud) låg fast när andra skrollade. De gjorde också så att utvecklarna slapp duplicera dessa delars kod på alla sidor. De fyllde på så sätt en viss funktion när de infördes men är mest allmänt idiotiska idag.
Varför frames är dåliga
Idag är det vanligaste att man kommer till en hemsida från en länk på en annan sida, oftast Google, kanske Facebook, Twitter eller en blogg. Eller så vill en kompis mejla en länk till dig. Allt detta är svårt att få att fungera på ett vettigt sätt om man använder frames. Sidor i ett frameset kan nämligen inte djuplänkas. Det innebär att man inte kan lägga till någon annan sida än startsidan som bokmärke eller skicka sidans adress som ett länktips.
Frames är också ett elände för handikappade, speciellt för dem som inte tittar på en hemsida, utan lyssnar på den via talsyntes eller tar del av den som blindskrift via en braille-terminal.
Det som man kunde göra med frames, att slippa upprepa koden för somliga delar av sidan, det kan man idag lösa med andra metoder. Kort sagt: Glöm frames. Använd dem inte! Punkt.
Frames i HTML5
Det kan finnas situationer då en speciell variant av frames är användbar, nämligen iframes. Men detta är inget man skall börja göra som nybörjare, utan en avancerad teknik för erfarna utvecklare. Eftersom iframes finns som en avancerad möjlighet i HTML5, så kommer inte validatorn klaga om man använder dem. Validatorn kan dock aldrig kontrollera om du använder dem på rätt sätt, så det behövs en stor portion av kunskap innan man ger sig på detta.
Vad gör en doctype egentligen?
Den version av (X)HTML man använder skall anges med en doctype. Doctypen fyller tre funktioner.
- 1. Ursprunglig funktion
- När man validerar SGML, HTML 4.01, XHTML 1.x och (ofta också för) andra tillämpningar av XML, så finns det en regeluppsättning i form av en DTD. Om man följer reglerna, så vet man att man har en basnivå av korrekthet i sin kod.
- 2. Social funktion
- En doctype är en signal till sig själv och samarbetspartners om vilken version av (X)HTML man ämnar följa.
- 3. Praktisk funktion
-
När CSS skapades, så började standarden implementeras av främst Microsoft i Internet Explorer, redan innan den hade stabiliserats.
På den tiden användes inte prefix för att skilja ut
experimentella implementationer, så mycket blev fel. När man sedan ville skapa en rendering i webbläsaren, som följde
standard, så började man använda doctypen som en växel, mellan standard-läge
och
quirks
-läge.
Följdfrågor:
- Varför har HTML5 ingen DTD
-
Som beskrivits i förra artikeln, så finns det regler i HTML5 som inte kan beskrivas med en DTD.
Dessutom så är detta ett sätt att markera att HTML5 inte längre formellt är en tillämpning av SGML. Kartan får så
följa verkligheten. Därtill kommer det faktum att för webbläsarna så finns det bara en enda version av HTML. Även om du
har angivit en strikt doctype, så kommer element och attribut som för till andra versioner att fungera. Till och med
sådant som aldrig standardiserats, som
<marquee>
kommer fungera. Utöver att styra renderingsläge, så spelar doctypen alltså ingen som helst praktisk roll i webbläsaren. - Hur skiljer man mellan HTML5 och
äkta
XHTML5? - Genom MIME-deklarationen. XHTML renderas alltid i standard-läge, så doctype är därför onödig för XHTML5.
Sammanfattning och doctypes
Kortversionen av denna artikel som frågor och svar:
- Vilken slags (X)HTML skall jag välja?
- HTML5, möjligtvis HTML 4.01 eller XHTML 1.0 med strikt doctype.
- Hur skall jag undvika fulkod?
- En god start är att använda XHTML-syntax.
HTML5 | <!DOCTYPE html> |
---|---|
XHTML5 | Ingen! |
Version | HTML 3.2 (utgången) | HTML 4.01 |
---|---|---|
strict | En version endast | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
transitional | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" |
|
frameset | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" |
Version | XHTML 1.0 |
---|---|
strict | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" |
transitional | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
frameset | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" |
XHTML 1.1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
---|---|
XHTML 2.0 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" |