XHTML du vet - för webben! Funderingar kring XHTML och den närmaste framtiden Åke Järvklo Dagtid:Netia Data AB Fritid: xhtml.se

”X” and ”HTML” sitting in a tree… • ”HTML5” kommer att införas i någon form – HTML5 bygger inte nödvändigtvis på SGML • Motsättningarna är (eller borde vara?) väck SHORTTAG (SGML-arvet designas bort) Taggsoppa eller ej (MIME-typsaspekter) Framtidssäkerheten (ingen vann) En DOM – Inte Två (men vissa skillnader är kvar) Bakåtkompatibilitet är ett starkt ledord

Två steg bakåt och ett åt sidan? • 1997 – HTML4 • 1999 – HTML4.01 presenteras med syfte att bl.a. förbereda för XHTML 1 – Dave Ragget håller ett föredrag om framtiden Dave Ragget håller ett föredrag om framtiden • Övergången till XML • Modularitet • CC/PP (”Composite Capability/Preference Profiles”) • Och inte långt därefter kommer XHTML1 • … och resten känner vi till – Eller ?

CCCP? • Inte riktigt… CC/PP var det  • ”Composite Capability/Preference Profiles”Composite Capability/Preference Profiles • A CC/PP profile is a description of device capabilities and user preferences. This is often referred to as a device's delivery context and can be used to guide the adaptation of content presented to that device. • “Browser sniffing” och saker som t.ex. “the WURFL” skulle inte behöva förekommathe WURFL • “Mobile Web Initiative” någon?Mobile Web Initiative

Fler steg åt sidan alltså… • I begynnelsen (typ ’98 eller så) var ”WAP-sidor” lika med WML-kodad text. – XML-baserat – Kompilerades till ett binärt transportformat – Inget samarbete med HTML/XHTML – Decks, Cards etc. men också, och – Fel i koden gav ”General server error” från din vänliga WAP-Gateway (”Draconian error handling” redan då) • … Men ”WAP 1” funkade  – Och vissa principer kommer igen i Opera Mini och Microsofts DeepFish (men det är en annan historia) Microsofts DeepFish

Fast forward några år • XHTML 1.0 (26 Januari 2000) • XHTML Modularization (10 April 2001) – XHTML Basic (19 december 2000) !!!  – XHTML 1.1 (31 maj 2001) •.. Och i WAP-världen – XHTML Mobile Profile (29 oktober 2001)

… och sedan var det mobil oenighet • W3C:: XHTML Basic   OMA:: XHTML MP • Bägge baseras på XHTML Modularization, men MP innehöll ”egna” moduler från början Men inte längre Men inte längre !!!  W3C standard expected in Q • Already very stable - reached final stage before becoming official Recommendation • Waiting for XHTML Basic/MP convergence

Så… • XHTML är lösningen på mobilsidan • Med stora nallefontillverkare bakom ryggen •.mobi • Och nu med en enighet mellan W3C och OMA • … och den mobila webben växer • … med krav på application/xhtml+xml och allt • … och det mobila modeordet för dagen är ”Adaptation” • Så kan man verkligen ”räkna ut” XHTML ? • Håll den tanken 

Hursomhelst… •... Så är vi inne i en övergångsperiod • HTML har en renässans – det vet vi  • XHTML har det också i praktiken – Market share (andelen OS-CMS som kör XHTML) – Reputation (varför inte ”rida på myterna”) – Maturity (jo faktiskt, om man tänker efter  ) • Men problemen då? – Fråga: Hur många har specialkodat för MSIE ? 

Personliga reflektioner • Content Negotiation är ett nätfundament • XHTML funkar – om man förhandlar – Fördelar: • ”Ren” syntax (inga valfria taggar för obligatoriska element) • Enkelt att validera mot DTD • Även DTD-delar • XML-parsning ger möjlighet att ”haka på” processing utan omtolkning eller genomsökning av textmassan – Nackdelar • ”the perils” är välkändathe perils • Men kanske framförallt ”Draconian error handling”

Taming the perils… • Content negotiation – Begär de application/xhtml+xml så ge dem det. – Föredrar de text/html eller låter bli att ange q- preferens för annat, ge dem ”XHTML enligt appendix C” som text/html • För det är ju i praktiken mest troligt ändå ”MSIE” • Och den specialkodar vi ju för oavsett – eller hur  – … och ”Appendix C” är ju inga problem att följa nu när HTML inte längre anses vara SGML och t.ex. SHORTTAG-problemet i praktiken är ur världen  – Och i HTML5 är XHTML-syntax som text/html helt OK

… och sedan var det det där med felhanteringen • HTML innehåller stabil felhantering… • Idé: text/html som ”fallback” • Alltså: – Content Negotiation + ”kod enligt Appendix C” – Om något blir fel – ”sänk” till text/html… – Hmm…. Validering… – Hmm… XML… – Hmm… Buffra, validera och ”sänk” om ogiltigt!

Men vänta – det är mer  • Cachea status från valideringen! – Senast uppdaterad + Senast kollad + URL + status – Ger i praktiken även grunden för en fel-logg för de icke- validerande sidor man har på webbplatsen ! • Men inte nog med det – Vi XML-tolkar ju under valideringen… – Med DOM eller SAX har vi ju då gjort tolkarbetet en gång… – Så att lägga till extra funktioner (som t.ex. logga alla länkar på sidan för separat länkvalidering eller att automatkolla rubriknivåer) ”kostar” i det läget mycket lite processtid. • Now try that with a ”Conformance checker” • … or width ”Tidy”

Fast det är klart… • Genomför man det där som ett ISAPI-filter eller som en apache-modul behöver man ju faktiskt ha med DTD:n i XHTML-dokumenten… • … eftersom man ju inte vill hålla på och rådda med andra filtyper än XHTML-filer • … och vara säker på att man validerar mot ”rätt” dialekt • … även om den inte spelar någon roll ute i browsern • … och den vänskapliga kängan till HTML5-gänget bjuder jag på som avslutning 

För när allt kommer omkring • Tycker inte jag att det spelar så stor roll om man kör HTML eller XHTML • Bara man väljer efter behov – … baserat på kunskap – … har klart för sig det där med separering av struktur, utseende och beteende • … och inte bara gör som alla andra utan att reflektera helt enkelt 

PEACE / Åke Järvklo