kaxigt.com

Det händer då och då att jag hamnar på hemsidor som vill lära ut HTML och XHTML. De flesta har fattat det här med XHTML och/eller webbstandard. Men så finns det andra som bara delvis har förstått. Ett kännetecken för XHTML är att strukturens utseende styrs av presentationen; man använder således alltid css till presentationen och html till att bygga strukturen.

För att därutöver få en websajt att kunna implementeras crossbrowser validerar vi den utifrån rätt doctype för att få den att följa en webbstandard.

En doctypedefinition underlättar webbläsarnas valideringsverktyg samt att dessa ska kunna utläsa i vilken form hemsidan är konstruerad. Det är den allra första informationen som ska ges till varje besökares dator som besöker sidan. Därefter omvandlas denna information så att besökarens webbläsare kan förstå hur sidan är uppbyggd.

I guiden från HTML till XHTML – ny märkning tar jag bland annat upp vad fulhtml är för något. Fulhtml är när man med html-koder försöker att skapa specifika cssvärden, men då css är ett eget språk ska det också behandlas som så och inte nästlas in i själva html-koden.

Här är två typiska exempel:

<table width="50%" border=”1" cellspacing=”0" cellpadding=”40" bordercolor=”#000000" background=”strip.jpg”></table>

<table width="50%" border="0" cellpadding="5" cellspacing="0"><td valign="top" bgcolor="#cccccc">tabellcell</td></table>

En semantisk korrekt markup använder html-element för dess givna syfte. En väl utformad HTML har en semantisk innebörd för ett brett fält av användaragenter (webbläsare utan stilmallar, textbaserade webbläsare, PDA:s, sökmotorer osv.)

En sida som är byggd i web standards skall ansluta sig till standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) och sträva efter bästa utformandet (valida koder, koder för tillgängligheten, semantiskt korrekta koder, användarvänliga URLs etc).

Använder du tabeller bör du även definiera tabellen genom att lägga till kodsnutten summary=”” i varje ny befintlig tabellkod som börjar med table, i synnerhet om du använder doctype XHTML Strict. Tabeller används endast för tabulardata och inte till layouter.

<table summary="datatabell"></table>

Exempelkoderna här ovanför innehåller ”fulhtml” och är därför knappast semantiskt korrekta. Bgcolor attributet background-color är enbart tillåtna i tabellceller och även om de nu är tillgängliga htmlkoder så finns det inga som heter background=”strip.jpg”.

I ett xhtmldokument är inte heller td valign=”top” speciellt semantiskt lyckat eller väl utformat.

Valign=”top” är en positionering som ska styras av CSS genom att ge elementet följande kod: vertical-align:top;. Cell-spacing är överhuvudtaget inte tillåtet.

En sida som är byggd för xhtml/web standards ska idealiskt vara enkel, ren, CSS-baserad, tillgänglig, användarvänlig och vara vänlig för sökmotorerna.

Ett mer lyckat alternativ hade naturligtvis varit att formatera tabellen med css. Valign är således ett html-attribut som används för att försöka skapa samma förutsättningar som csskoden vertical-align genom att med html positionera ett element eller innehåll.

Tabellens storlek anger du också med css istället för med html. Du kan till och med skapa specifika class-attribut för varje tabellcell, men en semantisk och mer utformad kod kan i all enkelhet se ut så här:

Css:

table {
width:50%;
border:0;
padding:0;
color:#333;
 }
td{
text-align:left;
vertical-align:top;
background-color:#ccc;
padding:5px;
 }
tr {}

Html:

<table summary="data"><tr>
<td>text</td>
<td>text</td>
</tr></table>

En av webbsajterna som bland annat lär ut HTML och XHTML menar även att följande kod är rätt:

<img src="bild.gif" />

Men var är alt-attributet? Tomma element måste förvisso stängas i xhtml men alt-attributet är lika viktigt!

I xhtml/webbstandard måste man ge bilden ett alternativt attribut, dessutom skriva ut bildförhållandet. Webbstandard handlar ju om att göra en hemsida användarvänlig. Om nu bilden inte skulle laddas upp kan aldrig en person med synnedsättning förstå att det ska finnas en bild där.

Många med synnedsättningar har speciella datorer som bokstavligen talar om vad som står/finns på hemsidan. För oss seende skulle det vara som om ett textavsnitt helt plötsligt försvann.

Rätt kod är således denna där alt-attributet även beskriver vad bilden visar:

<img src="bild.gif" alt="blomma" width="150" height="150" />

Semantik, XHTMLsyntax och parsing

XHTML är en utbyggnad av HTML (en kombination av HTML och XML) och styrs därför utifrån en principiell logisk semantik – det innebär att man systematiskt placerar sina koder i en reglerad ordning (vilket man även bör göra i HTML).

XHTML eller HTML?

Det största problemet är att man levererar sin XHTML i textformat – text/html.

Det här beror helt på okunskap om vad XHTML är och det skapar en grov kommunikationsmiss mellan dokumentet och webbläsaren.

Tanken med XHTML är ju att bygga ut HTML 4.01 med applicationen XML, och det innebär att märkkoden XHTML tillsammans med ett relevant doctype och namespace skickar en specificerad information till webbläsarens xml-tolk, eller parser som det också kallas, så att dokumentet kan tolkas som XHTML och inte HTML.

Så fort vi lägger till XML till HTML så förändrar vi förutsättningarna. Därför är det viktigt att kontrollera så att dokumentet också verkligen levereras som en xml-applikation. XML-deklarationen är följande och ska ligga högst upp i varje dokument.

<?xml version="1.0" encoding="ISO-8859-1"?>

Mimetyp för XHTML är application/xhtml+xml. Alla xhtml-dokument måste också ha en name space-deklaration eller namnrymd vilket en lista över giltiga märken och attribut som används i dokumentet.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"></html>

CSS och XHTML/XML

CSS defines different conformance rules for HTML and XML documents; be aware that the HTML rules apply to XHTML documents delivered as HTML and the XML rules apply to XHTML documents delivered as XML

CSS definierar inte reglerna på samma överensstämmande vis beroende på om det är ett HTML-dokument eller ett XML-dokument. XML-regler som appliceras på ett XHTML-dokument kommer att levereras som XML. Ett XHTML-dokument som kallar på en extern stilmallen har följande kod:

<?xml-stylesheet type="text/css" href="style.css"?>

Leverera XHTML som text/html?

Om du avser att leverera ett dokument i xhtml-format ska du använda mime-type application/xhtml+xml, i annat fall bör du använda HTML 4.

Skulle du mot förmodan använda XHTML och leverera denna som text/html kan det komma att skapa problem.

Det här är vad som händer om man skickar XHTML i text/html-format:

1. Man skriver xhtml och utgår från att det ska validera ”taggsoppor” eller webbläsare för HTML 4, inte webbläsare för xhtml, och skickar det därför som text/html.
2. Man upptäcker att det fungerar finfint.
3. Så går tiden…
4. Nu bestämmer man sig plötsligt för att skicka sitt dokument som application/xhtml+xml, det är ju trots allt xhtml.
5. Vilket leder till att man upptäcker att sidan kraschar ordentligt.
6. Man skyller detta på xhtml.

Det här beror ofta på att man inte vet skillnaderna mellan HTML och XHTML. Skripts som innehåller document.write() fungerar inte heller i xhtml, du måste använda DOM Core istället.

Varför att använda XHTML och skicka det som text/html är dåligt

Dokument som skickas som text/html hanteras faktiskt som ”taggsoppor” av de flesta webbläsare, och det är just själva kärnan i det hela. Om du skickar xhtml som text/html, på så vis webbläsarna tolkar detta, så kommer du i praktiken att skicka dem en ”taggsoppa”.

Det spelar faktiskt ingen roll att koderna validerar, de kommer ändå att hanteras som gammal html.

Många testkör dessutom bara sina hemsidor i en eller två webbläsare istället för att använda en validator. Det betyder att man inte testar validiteten utan och de flesta sidor som påstås vara valida xhtml är egentliga inte valida.

Om du av någon anledning byter dokument från de som påstås vara xhtmlvalida tillsammans med text/html till mime-type application/xhtml+xml så kommer detta med all säkerhet att generera en massa xml-fel.

Den enda egentliga fördelen med att använda XHTML och inte HTML 4 är att du ges möjlighet att använda xml:s redskap. Å andra sidan, om man använder dessa redskap, varför inte låta dem få producera HTML 4?

Varför webbläsare inte kan hantera skickat XHTML och text/html som XML

Man kan inte förlita sig på att leverera XHTML med text/html då det inte finns något som per automatik upptäcker att det handlar om XHTML. Därför kan ingen webbläsare hantera text/html-dokument som xml.

Man kan inte heller utgå från följande fem tecken <?xml> därför att koden <?xml ... ?> i header är frivillig enligt Appendix C, och rekommenderas faktiskt att inte inkluderas då den tvingar in IE6 i quirks mode.

Fördelar med XHTML

Använder du XHTML och levererar det som application/xhtml+xml kommer ditt innehåll att anpassas med andra välkända namespaces, ex MathML.

Webbläsarna kommer omedelbart att upptäcka om sidan inte är välformaterad, ”well-formed” – det vill säga om det finns syntax och/eller parsingfel. Redskap som däremot interagerar med XHTML-dokument är garanterat välformulerade dokument.

Om sidan är skriven i XHTML men skickas som text/html så kommer inget att detta kunna appliceras på dokumentet.

Mer att läsa:

• HTML eller XHTML? Robert Nymans funderingar
• Att skriva XHTML men leverera HTML
• The XHTML as text/html Mess
• Henri Sivonen asks:”what is the point of XHTML?”

Summering

XHTML är inte detsamma som webbstandard. Webbstandard är dokument som följer de specifika regler som relateras till dokumentets specifika doctype vad gäller kombinationen av såväl HTML och CSS (och namnrymd).

Det är en myt att tro att ett dokument som validerar XHTML också levererar XHTML.

Detta är något att fundera över nästa gång vi snubblar på sidor som lär ut XHTML/webbstandard.