Du är här: keryx/artikel/32. Hoppa till huvudinnehållet (h) Sidans menysektion:
Keryx logotype

Olika slags (X)HTML

Om denna artikel

Denna fjärde del av webbteknikskolan för nybörjare handlar om skillnaderna mellan HTML och XHTML, deras tillkomsthistoria och om de olika undervarianterna av HTML och XHTML.

Publicerad: 2005-05-11

Uppdaterad: 2010-08-07

 

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.

Facebooks mobila webbplats har här skapat gulskärm pga. att & inte skrivits som &amp; (Skärmdump från Firefox Mobile på min Nokia n900.)
Gula XML-döden har drabbat Facebook's mobila version

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:

Ä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.

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 som kodningsstandard

De reella fördelarna med XHTML är framför allt två:

  1. 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.
  2. 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.

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.

(X)HTML5, med doctypes
HTML5 <!DOCTYPE html>
XHTML5 Ingen!
Utgående HTML-versioner, med doctypes
Version HTML 3.2 (utgången) HTML 4.01
strict En version endast <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
transitional <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
frameset <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
  "http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0, med doctypes
Version XHTML 1.0
strict <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
transitional <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
frameset <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Oanvända XHTML-versioner med doctypes
XHTML 1.1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
XHTML 2.0 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
  "http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
Artikelinfo
Publicerad:2005-05-11 05:38     Författare:itpastorn
Uppdaterad:2010-08-07 06:41     Ämne:Webbteknik
Uppdaterad: 2010-08-07 06:41    © Keryx