Wångstedt nova

Att leverera en sida korrekt

Sedan vintern 2004 har jag arbetat med att använda xhtml och css när jag gjort webbsidor. En av de främsta fördelarna – som jag ser – är att man får en väldigt flexibel struktur på sajten. Att separera innehåll och form gör att det är väldigt enkelt att uppdatera formen om det skulle behövas. Samtidigt minskas kodmängden rätt radikalt, vilket gör sidorna mer snabbladdade. Men framför allt blir sidorna snabbare att rendera för webbläsaren. I slutändan är det besökaren som tjänar på att sajterna är välkodade och välstrukturerade.

Debatten på nätet

Den senaste tiden har jag sett några olika diskussioner och åsikter i ämnet för/emot xhtml. Bland de som motsätter sig användandet av xhtml är det starkaste argumentet att Internet Explorer inte har xml-stöd, och därför inte kan tolka koden riktigt. Lösningen är att använda en enklare dtd som är bakåtkompatibel med renderingsmotorn i webbläsarna. Många webbutvecklare hävdar att man då förlorar meningen med att använda xhtml, och att man då lika gärna kan köra med html 4. Framförallt för att man då är helt i fas med renderingsmotorns tolkningsläge. Stoppar man in xhtml-kod i en html 4-tolk kommer den att kunna läsa och tolka koden, men tycka att det är rörigt.

Några av de som inte gillar att lägga tag soup i renderingsmotorn är bland annat Ian Hickson, men hans argument känns väl tunna. Eller han kan inte uttrycka dem väl, tycker jag. Även Peter-Paul Koch tycker att det är meningslöst att använda något annat än traditionell html. Han argumenterar att det aldrig, på någon plattform, kommer att släppas en webbläsare utan html-tolk. Av den anledningen finns ingen orsak att byta sidbeskrivningsspråk heller.

En åsikt som jag sett återkomma är att man, om man kodar xhtml ska använda xhtml 1.1 och skicka dokumentet som application/xhtml-xml från webbservern. Gör man det så slår man om tolken i webbläsaren till xml-läge (om ett sådant finns), och får också en mer känslig tolkning och rendering av sidan. En xml-tolk är betydligt känsligare än en vanlig webbtolk, och kommer obönhörligen att generera felmeddelande om inte koden är helt korrekt. För webbmakaren blir det ett steg av validering och felsökning som man i andra lägen inte behöver vara så noggrann med, och för besökaren stiger risken av sajter som inte kommer att visas korrekt eller alls.

Jag kan därför förstå att man inte levererar dokument med den mime:en. Dels för att valideringen blir tuffare för webbutvecklaren, och – antagligen framförallt – för att inte Internet Explorer har stöd för xml.

Om man gör rätt…

För att försöka få en större förståelse för vad som egentligen är poängen med att inte skicka dokumentet som text/html satte jag upp en liten labb-sajt där jag levererade ett dokument som xhtml 1.1 med application/xhtml+xml, och samma dokument som xhtml 1.0 strict med text/html. Den mest uppenbara skillnaden – som jag nämnt tidigare – är att Explorer inte kan tolka dokumentet över huvud taget.

Bortsett från det stötte jag på några intressanta saker;

En xml-tolk använder själva dokumentet som bas vid renderingen. Till skillnad från en html-tolk som använder body som bas. Det man märker som webbutvecklare eller webbformgivare är att man måste sätta ett värde även på html-taggens marginaler. Det är också den som blir bas för positionering av övriga element.

Självklart stötte jag på några renderingsbuggar och skillnader mellan läsarna. Av någon anledning lider Safari av en renderingsbug som brukar benämnas Whitespace bug. Den ger sig till känna genom att mellanslag, radbrytningar och tabbar (tomrum alltså) i koden syns vid renderingen. Antingen genom att de tar plats på den visuella sidan mellan elementen, eller genom att andra renderingsfel uppstår. I mina tester var det tabbar i koden runt och i en osorterad lista – menyn i mitt fall – som renderades som ett icke-existerande tecken. Varken snyggt eller bra, men lätt att lösa.

En effekt som jag räknade med var att få en portabilitet mot wap-läsare i mobiltelefoner. De flesta moderna telefoner klarar chtml och då också att visa de flesta xhtml 1.0-sajter. Hyggligt i alla fall. Men med riktig xml levererad till telefonen så är det större chans att sidan verkligen kan renderas och visas. En klar vinst alltså.

Så vad ska man göra?

I och med att Explorer inte stödjer xml är det svårt att rekommendera användningen av application/xhtml+xml som mime-type. Även om det går att använda olika sidor beroende på ua.

Men jag tycker att man tjänar på att koda sidorna med xhtml 1.0 Strict just för att kunna porta dem till exempelvis mobiltelefoner i framtiden. Förhoppningsvis kan man så småningom gå över till application/xhtml+xml för hela sajten när Explorer antingen försvinner eller får stöd för det. På så vis får man en framtidssäker och lättkonverterad sajt.

Har du synpunkter eller idéer går det bra att e-posta.