Republic / Artiklar /

Artikeln uppdaterad 2020-05-26.
Skriven av Christofer Sandin.

Observera att det­ta är en lite äldre artikel som skrevs när HTML5 var på väg att lanseras, den håller däre­mot ändå som sam­man­fat­tning än idag…

En intro­duk­tion till HTML

HTML är ett begrepp med mån­ga oli­ka tolkningar, vis­sa använ­der det som en sam­man­fat­tning på alla de tekniker som ingår och andra menar istäl­let själ­va HTML-stan­dar­d­en. Här tit­tar vi på det senare, och gör en genomgång av skill­nad­er och likheter mel­lan alla de oli­ka ver­sion­er­na av HTML och XHTML.

Här föl­jer en genomgång av de oli­ka HTML-ver­sion­er­na vi haft under åren och efter det en tar vi en titt på vad HTML5 innebär för nyheter.

His­to­rien om HTML och XHTML

HTML har utveck­lats under mån­ga år och W3C-stan­dar­d­en HTML 4.01 är sedan slutet på 1999. Som vi alla vet har det hänt en hel del sedan dess. HTML har alltid var­it bakåtkom­pat­i­belt, vilket är en stor fördel, och det är allt­så inga prob­lem att se en webb­si­da skriv­en i HTML 3 i dagens webbläsare.

Som en vidareutveck­ling av HTML lanser­ades XHTML 1.0, senast rev­ider­ad under 2002, där den störs­ta skill­naden är att man införde krav på att använ­da XML-syn­tax. Det­ta innebär bland annat att

  • alla tag­gar skrivs med små bokstäver,
  • alla tag­gar skall avslutas,
  • och att alla attrib­ut skall ha citationstecken.

I övrigt är det inte så sto­ra skill­nad­er mel­lan HTML 4.01 och XHTML 1.0.

XHTML utveck­lades sedan till XHTML 1.1 som i prin­cip är sam­ma sak som XHTML 1.0, men med kravet på att all data skall skickas med sam­ma MIME-typ som XML (application/xhtml+xml). Det­ta innebär att doku­menten tolkas som XML-doku­ment istäl­let för SGML-doku­ment som tidi­gare ver­sion­er av HTML.

För ett par år sedan var mån­ga säkra på att XHTML 1.1 var rätt väg att gå. Som van­ligt, så ställde däre­mot de oli­ka web­bläsarver­sion­er­na till det för oss utveck­lare och även den­na gån­gen var det Inter­net Explor­er som sat­te käp­par i hjulet efter­som Inter­net Explor­er inte tolka­de XHTML som XML utan som HTML.

Det­ta resul­ter­ade i att mån­ga utveck­lare, däri­b­land vi, bör­jade utveck­la och valid­era doku­menten efter XHTML 1.1 Strict men fort­farande skic­ka doku­menten till web­bläsaren som html/​text istäl­let för application/xhtml+xml som 1.1‑specifikationen egentli­gen krävde. 

Så här i efter­hand kunde man kanske skick­at dessa som XHTML 1.0 istäl­let, efter­som vi ändå inte använde XML-egen­skaper­na i och med det­ta. Föru­tom en något annor­lun­da DOCTYPE så ser koden likadan ut och i prak­tiken blir allt­så resul­tatet likadant.

I prak­tiken var däre­mot html/​text ett bät­tre val

Ovanstående tillvä­gagångssätt var i och för sig inte helt dumt i prak­tiken, efter­som XML på gott och ont är ett väldigt strikt språk. 

Så visst bidrar ett XML-baser­at doku­ment till strik­tare struk­tur­erade doku­ment, men det gör sam­tidigt webb­si­dor­na väldigt känsli­ga för fel. Ett enda litet fel i koden innebär att sidan inte visas alls för besökaren, utan denne endast ser XML-tolkens felmed­de­lande på skär­men istället.

Finns det ett pub­licer­ingssys­tem bakom kulis­ser­na, eller om man läs­er in data från någon extern käl­la, så risker­ar man alltid att den kod som gener­eras inte är helt strikt. Där­för är det allt­så väldigt risk­a­belt att låta små fel göra hela webb­si­dan otill­gäng­lig. Webben byg­ger på fel­tol­er­ans och alla web­bläsare gör sitt bäs­ta för att rät­ta till små felak­tigheter, så XML-tolkens fel­hanter­ing kanske inte är det bäs­ta för vare sig besökar­na, pub­li­cis­ter eller webben i sig.

HTML5 vs. XHTML2

De senaste åren har två oli­ka stan­dards utveck­lats par­al­lellt. Den ena är HTML5 som W3C utveck­lar till­sam­mans med WHATWG och den andra är XHTML2 – båda är så kallade Work­ing Drafts för tillfäl­let och är allt­så inte helt spikade standards.

HTML5 är en vidareutveck­ling av HTML 4.01 medan XHTML2 inte har något som helst att göra med XHTML 1.1, utan är en helt ny stan­dard som inte är bakåtkom­pat­i­bel med HTML. 

Förvir­rande? Ja, en aning. Nyli­gen så har däre­mot nu W3C tag­it beslutet att läg­ga ner det fort­sat­ta arbetet med XHTML2 och istäl­let fokusera på HTML5. Det­ta har ock­så gjort att HTM­L5-stödet fått ett uppsv­ing i web­bläsar­na och det ser ut som om det är HTML5 som gäller framöver.

Åter dags för HTML då allt­så, eller?

Ja, nu verkar det allt­så som om det är dags att bör­ja koda HTML igen och då tänk­te jag att det kunde vara nyt­tigt med en kort genomgång efter ovanstående historielektion.

I HTML5 kan man väl­ja att skri­va koden som klas­sisk HTML-kod eller som XHTML-kod (och då menar jag allt­så med XHTML-syn­tax) och valid­era den som HTML5. Så det finns alla möj­ligheter att fort­sät­ta skri­va bra kod, oavsett vilken syn­tax du gillar bäst. I de all­ra fles­ta fall är det allt­så ingen större skill­nad på att skri­va bra HTML och bra XHTML, bara du är kon­sekvent och håller dig till en av de två.

HTML5 kan för övrigt ha både MIME-typ html/​text så väl som MIME-typ application/xhtml+xml. I det senare fal­l­et kom­mer det troli­gen att kallas XHTML5 istäl­let för HTML5, vilket på ett sätt känns gan­s­ka logiskt men sam­tidigt blir ytterli­gare en XHTML-term som inte har något med XHTML2 att göra, trots ett högre ​”ver­sion­snum­mer”…

Skriv kod enligt HTML- eller XHTML-syntax

Oavsett om du väl­jer att skri­va HTML eller XHTML så skriv strikt kod. Det­ta gör du genom att använ­da en så kallad DOCTYPE längst upp i var­je doku­ment. På det­ta sätt talar du om vilken typ av doku­ment det är du skriv­er och trig­gar även så kallat Stan­dards Com­plient mode i web­bläsar­na. Det­ta läge gör att sidor­na ren­deras efter sam­ma regler i de oli­ka web­bläsar­na (i myck­et större utsträckning).

Så, använd allt­så HTML 4.01 Strict eller XHTML 1.0 Strict vad det gäller syntax.

HTML5

HTML5 kan allt­så skickas som både application/xhtml+xml och som text/​html. Det­ta innebär att det inte finns några hin­der för er som vill använ­da HTML5 med en XML-parser.

HTML5 använ­der ock­så en myck­et enkel DOC­TYPE, det räck­er med <!DOCTYPE html>.

Föru­tom det­ta så intro­duc­er­ar den nya stan­dar­d­en även en rad nya seman­tiska tag­gar för att kun­na struk­tur­era doku­menten ännu bät­tre än idag. Visst funger­ar <div id="navigation"> bra och är någor­lun­da både struk­turellt och seman­tiskt men efter­som lika mån­ga använ­der <div id="nav"> eller <ul id="menu"> så finns det ingen rik­tig stan­dard gäl­lande exem­pelvis hur nav­iger­ing skall märkas upp.

De nya tag­gar­na i HTML5 inklud­er­ar bland annat;

<nav>

”The nav ele­ment rep­re­sents a sec­tion of a page that links to oth­er pages or to parts with­in the page: a sec­tion with nav­i­ga­tion links”. 

Den­na tagg är allt­så avsedd för att mär­ka upp sidans huvud­sak­li­ga och primära navigation.

<section>

”The sec­tion ele­ment rep­re­sents a gener­ic doc­u­ment or appli­ca­tion sec­tion. A sec­tion, in this con­text, is a the­mat­ic group­ing of con­tent, typ­i­cal­ly with a head­er, pos­si­bly with a footer.” 

Används allt­så för att mär­ka upp speci­fi­ka delar av en sida som hör samman.

I en <section> kan infor­ma­tio­nen ytterli­gare märkas upp med hjälp av tag­gar­na nedan. Används dessa tag­gar utan­för en <section> så associeras de med <body> och gäller således hela doku­mentet istället.

<header>

”The head­er ele­ment rep­re­sents the head­er of a section.” 

Därmed inte sagt att den endast innehåller H1 eller H2 tag­gar utan kan även innehål­la infor­ma­tion så som för­fattare, pub­licer­ings­da­tum och annan metadata.

<footer>

”The foot­er ele­ment rep­re­sents a foot­er for the sec­tion it applies to. A foot­er typ­i­cal­ly con­tains infor­ma­tion about its sec­tion such as who wrote it, links to relat­ed doc­u­ments, copy­right data, and the like.”

Används allt­så för att definiera infor­ma­tion relat­er­ad till den <section> den ingår i. Som exem­pel på det­ta använ­der W3C allt­så länkar till relat­er­ade artik­lar och copyright-information. 

Värt att notera är att om en <footer>-tagg rep­re­sen­ter­ar hela sidan och innehåller kon­tak­tuppgifter så skall dessa märkas upp med <address>-taggen som det tidi­gare fun­nits mån­ga oli­ka åsik­ter om.

<article>

”The arti­cle ele­ment rep­re­sents a sec­tion of a page that con­sists of a com­po­si­tion that forms an inde­pen­dent part of a doc­u­ment, page, or site.” 

Tanken är allt­så att <article> är tänkt att använ­das för att mär­ka upp delar av ett doku­ment som klarar sig bra även på egen hand. W3C använ­der forumposter, artik­lar, blog­gin­lägg och kom­mentar­er som exem­pel i sin beskrivning.

<aside>

”The aside ele­ment rep­re­sents a sec­tion of a page that con­sists of con­tent that is tan­gen­tial­ly relat­ed to the con­tent around the aside ele­ment, and which could be con­sid­ered sep­a­rate from that content.”

Hur man märk­er upp sekundär infor­ma­tion när man skriv­er HTML finns det mån­ga åsik­ter om, och i och med HTML5 finns nu en tagg som är speci­fikt tänkt att utnyt­t­jas för att mär­ka upp relat­er­ad men inte primär information. 

Ett exem­pel på det­ta är den text som oftast fun­nits i en kol­umn till vän­ster eller höger om huvudin­nehål­let eller som utskju­tande text i län­gre artik­lar (så som citat och extra information).

Annat intres­sant

Andra intres­san­ta tag­gar att hål­la reda på är exempelvis;

  • <audio>
  • <video>
  • <canvas>

Nytt är ock­så att <input> ele­mentets type-attrib­ut kom­plet­teras med ett par nya vari­anter, exempelvis;

  • date
  • time
  • num­ber
  • email
  • url

För alla som använ­der UTF‑8 kod­ning (vilket i prin­cip alla bor­de göra idag) kan det­ta definieras genom att läg­ga till <meta charset="utf-8"> som förs­ta ele­mentet i <head>-taggen.

Att använ­da HTML5 redan idag

Det är fak­tiskt inte speciellt svårt att bör­ja använ­da HTML5 redan idag. Fire­fox i ver­sion 3.5+, Safari i ver­sion 4+ och Google Chrome klarar redan av det mes­ta utan några kon­stigheter, medan Inter­net Explor­er kan behö­va lite hjälp på vägen. 

Först och främst så tolkas inte de nya tag­gar­na som block-ele­ment, så du måste deklar­era dessa i CSS-doku­mentet som sådana:

nav, 
section, 
header, 
footer, 
article, 
aside { 
    display: block; 
}

För att applicera CSS i Inter­net Explor­er så måste även man reg­istr­era de object som använ­der tag­gar­na ovan i DOM:en. Det­ta görs enklas genom att ska­pa dem med hjälp av JavaScript i bör­jan av dokumentet:

<script>
document.createElement('section');
document.createElement('nav');
document.createElement('header');
document.createElement('footer');
document.createElement('article');
document.createElement('aside');
</script>

Alter­na­tivt kan du använ­da dig av html5shiv eller ett mer robust bib­liotek som Mod­ern­izr för att lösa båda prob­le­men ovan.

Som bland annat Steve Smith påpekar i sin artikel Struc­tur­al Tags in HTML5 så tolkar HTML5 <script>-taggen som JavaScript om inget annat anges, så där­för är det onödigt att deklar­era type=“text/javascript” explicit.

Nytt sätt att bäd­da in video på webben

Det är allt­så möjligt att bör­ja använ­da de nya struk­turel­la tag­gar­na ovan redan nu, men givetvis så kom­mer inte de nya ele­menten så som <video> eller <audio> att fungera i de web­bläsare som inte har inbyg­gt stöd för HTML5.

Idag har Fire­fox, Safari, Chrome och Opera gan­s­ka bra stöd för <video> medan de andra web­bläsar­na fort­farande kräver att man använ­der exem­pelvis SWFOb­ject.

En stor fördel med <video>-taggen idag är att så länge vide­o­for­matet stöds av Safari så funger­ar den även på en iPhone med iOS 3 eller senare. Hen­rik Sjökvist har skriv­it en bra intro­duk­tion som het­er ​”Using the HTML5 <video> tag with a Flash fall­back” som är både kort och bra.

Använ­der du Fire­fox 3.5+ eller Opera kan du kol­la in hur den nya <video>-taggen funger­ar på länkar­na nedan. Där visas en video i Ogg The­o­ra-for­mat (.ogm/.ogg) som går att spela utan några extra plu­g­ins, och endast upp­ko­dat med HTML5. 

Tyvärr så klarar inte Safari av .ogm-for­matet i dagsläget, trots att Safari har stöd för HTML5. I det fal­l­et är det dock ett aktivt val av Apple som är orsak till att videon i exem­plet ovan inte spelas upp i Safari och inte en brist i stödet för HTML5. Hade fil­men var­it i något for­mat som Safari stöder hade det funger­at. För tillfäl­let så stöder Safari sam­ma for­mat som Quick­Time (där troli­gen MPEG4 är det van­li­gaste och mest använ­da idag).

Avs­lut­ning

Hop­pas ni fått en gan­s­ka snabb överblick över hur HTML utveck­lats och en liten tju­vtitt på HTML5. Nedan finns länkar till fler intres­san­ta resurs­er om ni vill grä­va djupare.

Ref­er­enser och resurser