XHTML is de standaard markup taal voor webdocumenten en de opvolger van HTML 4. Deze taal is een mengsel van klassiek (HTML) en super-modern (XML). XHTML ziet er uit als HTML en werkt ook volgens hetzelfde principe, maar het is gebaseerd op XML, de “super” markup taal van het web. XHTML zorgt er voor dat veel van de voordelen van XML van toepassing worden op je webpagina's (zie de opsomming in de Online Style Guide van de Branch Libraries van de New York Public Library).

Een ongeautoriseerde aanvulling op de Online Style Guide van de Branch Libraries van de New York Public Library

Als je je site goed wilt laten functioneren in de browsers die nu gebruikt worden, plus niet-traditionele toepassingen (PDA's bijvoorbeeld) en er ook voor wilt zorgen dat hij het in de toekomst blijft doen, is het een goed idee om nieuwe sites in XHTML op te zetten en oude sites te converteren naar XHTML (op het moment dat je agenda dat toelaat).

En het W3C heeft het je gemakkelijk gemaakt. De regels van XHTML kun je sneller onder de knie hebben dan dat de pizzakoerier je favoriete pizza afgelevert. Deze simpele regeltjes laten de practische toepasbaarheid van het werk van het W3C zien: ze zorgen ervoor dat het web consistenter wordt en voldoet aan XML standaarden, zonder dat drukbezette ontwerpers en ontwikkelaars geheel nieuwe markup hoeven te leren.

Maar net zoals met elke overgang zul je betere en beter voorspelbare resultaten krijgen als je je goed voorbereidt. Dit artikel helpt je daarbij, door het laten zien van tools die je kunnen helpen bij het converteren naar XHTML en het controleren of je dat correct hebt gedaan. Dit artikel bespreekt ook een aantal veranderingen in de manier waarop sommige browsers XHTML pagina's laten zien, waar je misschien van zou schrikken als je er niet op voorbereid bent. Bovendien geven we je tips om deze problemen op te lossen.

BEZINT EER GE BEGINT

Als je dat nog niet gedaan hebt, is het nu tijd geworden om de Online Style Guide van de Branch Libraries van de New York Public Library te lezen voor je de rest van dit artikel leest.

De Style Guide geeft een goed beeld van XHTML zonder dat je verplicht bent om je door de vaak mistige literatuur van het W3C te worstelen; ze geeft je waardevolle informatie over CSS (compleet met Style Sheets die je kunt gebruiken op je eigen sites); legt je uit hoe je kunt werken met de W3C validators; en verstrekt actuele tips voor Dreamweaver gebruikers.

Ik heb de New York Public Library geholpen bij het opstellen van de Style Guide en bedank de Library en haar web coördinator (tevens mede-schrijver van de Style Guide) Carrie Bickner voor het besluit om de Style Guide beschikbaar te maken voor de hele web-gemeenschap. De Style Guide wordt regelmatig bijgewerkt om fouten te verbeteren en nieuwe informatie op te nemen.

TIJD VOOR TIDY

Veruit de makkelijkste manier om valide XHTML pagina's te maken is om ze vanaf niets te schrijven. Maar veel webdesign is eigenlijk redesign, en je zult dan ook vaak gevraagd worden om oude of bestaande pagina's te updaten. Redesign-opdrachten geven je de perfecte mogelijkheid om te migreren naar XHTML.

Het gratis programmaatje HTML Tidy kan je HTML snel converteren naar XHTML. Wij hebben het recentelijk gebruikt voor The Daily Report op zeldman.com. We hebben Tidy vorig jaar ook gebruikt voor de CSS/XHTML conversie van A List Apart, en het werd succesvol ingezet bij verschillende sites voor klanten.

Tidy is geschreven door de briljante 'standards geek' Dave Raggett en wordt nu als Open Source software onderhouden door de mensen bij Source Forge, hoewel er ook versies zijn die door andere mensen als liefdewerk-oud papier worden bijgehouden.

Bij onze conversie gebruikten we MacTidy 1.0b13, de meest recente versie van Tidy voor Mac OS, ontwikkeld door Terry Teague. Je hebt overigens kans dat Terry’s site tijdelijk niet beschikbaar is wanneer je deze links gebruikt, daar zijn gratis hosts hem slechts een beperkte hoeveelheid data transfer toestaan. Als het niet lukt, probeer het dan later nog eens.

Er zijn ook online versies van Tidy en downloadbare binaries voor Windows, Unix, diverse Linux versies, Mac OS X en andere platforms. Elke versie heeft andere mogelijkheden en daarom ook behoorlijk verschillende documentatie.

LEES DE HANDLEIDING

Net zoals veel drukbezette mensen zijn wij geneigd het lezen van handleidingen te vermijden, maar in dit geval raden we je dringend aan dat wél te doen, en grondig. Sommige versies van Tidy zien er eenvoudig uit en je denkt misschien dat je zo ook wel snapt wat ze doen, maar Tidy is een power tool. Je moet je echt verdiepen in de settings en de preferences om er verzekerd van te zijn dat het zal doen wat je wilt.

Voor de conversie van Daily Report fristen we ons geheugen op met een slechts vlugge blik op de documentatie van MacTidy en dat bleek absoluut een vergissing te zijn.

Bij de eerste doorloop, met settings die we nooit eerder gebruikten, converteerde Tidy onze encoded character entities naar niet-gecodeerde, platform-specifieke toetsenbord-karakters; veranderde Unicode entities die in alle browsers werken in named entities die het zouden moeten doen in alle browsers maar het niet doen; en veranderde commentaar brackets (de < in <!-- bijvoorbeeld) in gecodeerde karakters, waardoor er errors tevoorschijn kwamen in een embedded JavaScript functie.

De kracht kwam van Tidy, de sulligheid van ons. Verkeerd gebruik van Photoshop, Illustrator, of Flash kan net zulke funeste consequenties hebben en we kunnen Tidy niet de schuld geven van de fouten van haar gebruikers. Dus doe jezelf een plezier en hou je aan de volgende regels:

1. Lees de handleiding.
2. Bewaar een backup van je document.
3. Lees de handleiding.

Diegenen die net zoals wij moeilijkheden hebben met het daadwereklijk lezen van de handleiding willen nu vast graag weten welke instellingen dan de juiste waren. Helaas, er ís niet één juiste instelling. De correcte instelling hangt af van het soort encoding dat je gaat specificeren in je heading, het soort encoding dat je je HTML editor hebt opgedragen uit te spugen (meestal, maar niet altijd Latin1), en andere variabelen. We hebben wel een tip. Kies in ieder geval Convert HTML to XML als je XHTML wilt genereren. Onthou: XHTML is eigenlijk XML.

VALIDEER, DAT SMAAKT NAAR MEER

De Style Guide legt uit hoe je aan de slag kunt met de (X)HTML en CSS validators van het W3C. Valideren kost je nauwelijks tijd. Als je deze stap overslaat en je XHTML of CSS bevat per ongeluk toch fouten, dan kan het zo zijn dat je site niet goed functioneert. Hij kan er ook heel anders uitzien dan je bedoeling was.

Met valide markup en CSS heb je een goede kans dat browsers die zich aan de standaarden houden je site volgens de verwachtingen laten zien, waarbij er een aantal uitzonderingen zijn die we hieronder zullen bespreken. Met niet-valide XHTML of CSS kun je er helemaal niets van zeggen en kun je bovendien de browsers niet de schuld geven. (Nou ja, je kunt het wel doen, maar het is niet eerlijk en je bereikt er helemaal niks mee.)

Als je je markup zelf typt zul je absoluut af en toe vergissingen maken (tenzij je perfect bent). Als je Macromedia Dreamweaver of Adobe GoLive gebruikt, rechtstreeks uit de doos, zal je site zeker fouten bevatten. Met behulp van de validators kun je deze fouten opzoeken en verbeteren.

Wij zijn er van overtuigd dat toekomstige versies van Dreamweaver en GoLive je zullen helpen bij het produceren van valide materiaal, maar helaas zijn deze versies nog niet op de markt, en zelfs op het moment dat ze er wel zijn zul je waarschijnlijk met de hand nog wat veranderingen aan moeten brengen in je code. (Ondertussen zouden Dreamweaver-gebruikers de tips van de Style Guide moeten lezen.)

Hoe je je markup ook maakt, het is de moeite waard om de validators te gebruiken. Ze zijn een vriendelijk soort XHTML- en CSS consultants die je laten zien waar de problemen zitten zonder dat ze je dom vinden.

VALIDATORS VERSTAAN

Zelfs de beste consultants geven je soms slechte adviezen. Soms eten ze ook te veel knoflook bij de lunch, of ze gebruiken je fax meer dan je zou willen. De robot-consultants van validator.w3.org en jigsaw.w3.org/css-validator/ zullen je soms ook hoofdbrekens opleveren.

Dat ligt vooral aan de taal die de validators gebruiken bij het rapporteren van fouten. Ze zijn geschreven voor en door standards geeks, en daardoor bieden de validators soms “hulp” die gewone stervelingen verwart of zelfs misleidt. Het is niet de taak van het W3C om de web standards in hapklare brokken te serveren, maar soms zouden we wel willen dat de validators zoiets zouden zeggen als “Hé suffie, je bent vergeten de <p> tag te sluiten” in plaats van die cryptische toestanden die ze af en toe uitspugen.

WAAROM ZO CRYPTISCH?

Toegegeven: cryptische berichten van je validator zijn vaak het gevolg van beperkingen in de software. De validator is niet HAL uit de film 2001. Als jij vergeet om een tag te sluiten kan de validator nooit weten dat je wel van plan was om hem te sluiten en kan daarom een foutmelding geven voor iets wat lager op de pagina staat, in plaats van je aandacht te vestigen op het echte probleem. De validator wijst je misschien op een tag die volgens hem niet goed genest is, maar die in werkelijkheid toch echt goed is. Dat komt dan waarschijnlijk door die fout die je eerder in het document gemaakt hebt en die de validator in de war brengt.

Als auteur van de markup ben jíj verantwoordelijk voor je eigen fouten, of ze nou veroorzaakt zijn door een programma dat je (mogelijk niet helemaal goed) gebruikt of wat je handmatig geschreven hebt. Als je op de hoogte bent van de neiging van de XHTML validators om nesting-fouten te rapporteren onder het punt waar ze werkelijk optreden heb je een grotere kans dat je verwarrende foutmeldingen kunt vertalen naar wat er werkelijk fout is gegaan en zo verder kunt met het opruimproces.

ANDERE VEEL VOORKOMENDE PROBLEMEN

Veel HTML editors genereren doctypes met relatieve URIs, zoals...

<!DOCTYPE html 
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">

Deze URIs leveren altijd validatiefouten voor je CSS op, iets wat bijna onmogelijk te begrijpen is voor gewone stervelingen. Wij hebben zelf ons hoofd bloedig gebeukt uit frustratie over foutmeldingen als de volgende:

org.xml.sax.SAXException: Please, fix your system identifier (URI) in the DOCTYPE

De bij zeer weinigen bekende CSS Validator FAQ vertaalt deze supertechnische opmerking in gewoon Engels en vertelt je wat je er aan kunt doen om het probleem op te ruimen. In het voorbeeld hierboven is de oplossing om een doctype te gebruiken met een absolute URI, zoals deze:

<!DOCTYPE html 
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

We zullen je verderop in dit artikel nog meer waardevolle tips over doctypes geven.

Een ander vaak voorkomend probleem waar de validators geen last van hebben, maar wat een janboel aanricht in oudere browsers, en zelfs in sommige nieuwere zoals MSIE6— heeft te maken met de niet-verplichte xml prologue die voorafgaat aan het doctype en de namespace declarations. Wederom, zie de XHTML Guidelines van de NYPL Style Guide voor de details en de oplossingen.

Andere veel-voorkomende validatieproblemen (plus oplossingen) worden behandeld in het artikel Liberty! Equality! Validity! van Eric Meyer in Netscape DevEdge.

BUGS IN DE VALIDATOR

Ook validators zijn het product van menselijke arbeid, en bevatten daardoor, zoals alle software, enkele bugs. Als je er één tegenkomt zou je hem eigenlijk moeten rapporteren (hieronder zullen we je vertellen hoe). Misschien vind je dat eng om te doen, omdat je eerder denkt dat jouw markup niet in orde is dan dat je verdenking valt op een krachtig programma, gemaakt door de experts op het gebied van standaarden. Maar één keer in de zoveel tijd gebeurt het toch echt.

Toen wij recentelijk onze fijne ervaring met Tidy hadden (waarbij we die instellingen verkeerd hadden staan) kregen we een webpagina die niet helemaal goed was en besloten de fouten met de hand te herstellen. Zonder dat we het in de gaten hadden misten we een fout.

Luisterend naar onze slecht-doordachte instellingen had Tidy onze © copyright symbolen geconverteerd naar het Macintosh toetsenbord karakter voor het copyright symbool. Dat werkt prachtig voor het overbrengen van documenten van de ene Macintosh naar de andere, maar is niet aan te raden op het web. We haalden onze nieuwe pagina door de W3C validator en hij slaagde met vlag en wimpel.

Toen probeerden we om ons style sheet te valideren, maar de CSS validator van het W3C zei dat dat niet kon, omdat er een fout in onze XHTML zat: “An invalid XML character (Unicode: 0xa9) was found in the element content of the document.”

CATCH-22

Helaas konden we geen 'zoek en vervang' doen voor “0xa9,” aangezien 0xa9 niet in onze tekst voorkwam. (Dit blijkt het copyright symbool in Unicode te zijn, maar als je niet toevallig alle Unicode karakters uit je hoofd hebt geleerd is dit bericht van de validator niet erg begrijpelijk.)

De CSS validator gaf ons aan in welke regel de fout gevonden werd, en dat had handig kunnen zijn in het traceren van het probleem als we die plek terug zouden kunnen vinden. Maar de aanduiding sloeg nergens op terug, omdat de CSS validator je markup niet laat zien.

De W3C markup validator laat je XHTML markup wel zien, compleet met regelverwijzingen, maar alleen als hij denkt dat je markup een fout bevat. En zoals we al zeiden: deze W3C validator vond onze markup in orde.

Daar zaten we dan, in een Catch–22. De ene validator zei dat onze pagina OK was; de andere verslikte zich erin en gaf ons foutmeldingen waar we niets mee konden.

Wij wisten het nu ook niet meer en hebben de pagina toch maar online gezet. Binnen een uur kregen we respons van lezers van Daily Report, onder andere Mark Howells, Zeke Runyon en Dylan Foley die zich hadden ingespannen bij het lezen van onze source en het localiseren van de fout. We bedankten hen hartelijk, verbeterden de fout en konden weer aan de slag.

Als we dit waren tegengekomen tijdens het werken aan een site voor een klant, dan hadden we natuurlijk de pagina niet kunnen uploaden zonder dat we de fout gevonden en hersteld hadden. In de meeste gevallen is het dan aan te raden om je HTML-editor uit te zetten, een wandeling te maken en later terug te komen met een frisse neus en blik.

VALIDATOR BUGS RAPPORTEREN

Deze problemen zijn zeldzaam (en hadden in ons geval dus voorkomen kunnen worden als we de handleiding van Tidy goed gelezen hadden), maar af en toe kom je ze tegen. Een vriend van ons, die de “beste web designer van onze tijd” genoemd wordt, typt regelmatig Windows keyboard characters in zijn source. Markup fouten zijn overal; validator fouten bestaan ook.

Als je denkt dat de XHTML validator van het W3C het bij het verkeerde eind heeft, bezoek dan de feedback pagina. Om mogelijke fouten in de CSS validator te rapporteren schrijf je naar www-validator-css@w3.org. (Het email adres op de ReadMe pagina van de CSS validator doet het niet, omdat het adres niet compleet is.) Als de validator inderdaad iets verkeerd doet, of als je gerede twijfel hebt over iets wat hij doet, wees dan vriendelijk en beleefd wanneer je de fout rapporteert.

De W3C validators zijn gratis te gebruiken en worden onderhouden door deskundige personen die dit uit liefde voor het vak doen. Soms kan het verleidelijk zijn om een lange neus te maken als je een fout vindt, maar hiermee beledig je deze hardwerkende mensen, of ze vragen zich op z'n minst af waarom je je zo onbeschoft gedraagt en gooien je bericht in de prullenbak.

XHTML & BROWSERS

Zo, nu heb je een valide XHTML pagina. Ziet het er nu nog zo uit als voor deze activiteiten? In sommige nieuwe, standaard-vriendelijke browsers misschien niet—maar dat kun je snel verhelpen.

Na het converteren van onze Daily Report van HTML 4.01 Transitional naar XHTML 1.0 Transitional zag onze pagina er precies hetzelfde uit als de vorige versie, behalve de verandering in doctype en de markup regels die daarbij horen.

Maar IE6 en Mozilla/Netscape 6 besloten dat het er anders uit moest zien dan vroeger. Hier zie je wat IE6/Windows uitspookte met onze menubalk:

En hier zie je wat Netscape 6.2/Mac er mee deed:

Bezoek zeldman.com om te zien hoe het menu er uit hoort te zien.

DE GATEN STOPPEN

Om deze (naar onze mening) uitglijders van MSIE6 en Mozilla/Netscape 6 te repareren, voegden we twee regels toe aan een style sheet dat we in de pagina tussen de <head> tags plaatstenb:

img {display: block;}

.inline {display: inline;}

De eerste regel zorgde ervoor dat de menubalk er goed uitzag. De tweede regel repareerde problemen met de layout die elders ontstonden door de eerste toegevoegde regel. Op plaatsen waar we afbeeldingen inline wilden laten zien voegden we een class="inline" toe aan de <img> tag. Gefixt!

Als markup (structuur) en zichtbare weergave (ontwerp) twee verschillende diersoorten zijn volgens de gedachtengang van het W3C, waarom veranderden deze browsers dan het uiterlijk van onze pagina? En hoe bedachten we de CSS regels die het probleem overwonnen?

STRIKTE INTERPRETATIES & WILLEKEURIGE GRILLEN

Allereerst, zoals al aangehaald in the Daily Report (26 januari), zijn de experts het niet met elkaar eens over hoe standaarden zoals CSS geïnterpreteerd moeten worden. Ze kunnen het met name niet eens worden over welke stijlen als standaardinstelling moeten worden toegepast (en óf ze moeten worden toegepast) op afbeeldingen die geen stijl hebben meegekregen van de ontwerper van de pagina.

Het artikel Tables, Images, and Mysterious Gaps van Eric Meyer legt uit hoe de CSS experts van Mozilla image tags zonder toegevoegde stijl interpreteren in relatie tot het impliciete grid van iedere webpagina. Hij vertelt je tevens trucs voor als je niet wilt dat er extra ruimte wordt toegevoegd aan je layouts. Deze problemen treden vooral op bij “gecombineerde” layouts die gebruik maken van een mengelmoes van ouderwetse (tabellen) en moderne (CSS) layout technieken.

STRIKT en STRIKT

Het nuttige artikel van Meyer beweert dat Mozilla en zijn afstammeling Netscape 6 dit alleen doen met (X)HTML documenten die strict in hun doctypes hebben staan, maar dat kan onbedoeld misleidend zijn, daar dit lijkt te betekenen dat de extra ruimte alleen wordt toegevoegd aan afbeeldingen bij HTML Strict of XHTML Strict. Bij het lezen van velen van de mailiing lists over webdesign zal je opvallen dat dit de meest courante interpretatie van het woord “strict” is in deze context.

In werkelijkheid bedoelen Meyer en zijn collega's met “strict doctypes” “complete” (of valide) doctypes, dat wil zeggen ieder document—zelfs al is het HTML 4.01 Transitional—dat een volledige URI bevat. Meyer gebruikt het woord strict overigens niet verkeerd; het betekent alleen verschillende dingen in verschillende contexten.

In de praktijk hebben we gemerkt dat Netscape 6.x de strikte CSS interpretatie van zijn experts gebruikt bij sommige HTML 4.01 Transitional documenten met complete doctypes en niet bij anderen. Het kan zijn omdat Mozilla (tijdens het schrijven van dit artikel) nog een Beta versie was en Netscape 6.x daardoor nog niet gereed was; maar misschien is het ook een mechanisme dat wij gewoon niet begrijpen.

Maar om terug te keren bij het doel van dit artikel: Mozilla/NN6 gebruikt altijd deze CSS interpretatie—en dus ook altijd deze extra ruimte—in pagina's die in XHTML (Strict of Transitional) gemaakt zijn. Zodra je je pagina's naar XHTML converteert zullen plaatjes in tabellen extra ruimte in beslag nemen.

DOCTYPES EN HET UITERLIJK VAN JE PAGINA

De meeste browsers die CSS goed ondersteunen zijn gebruiken de aan- of afwezigheid van een compleet doctype om te besluiten in welke modus ze de pagina zullen laten zien. Wordt het de "standards–compliant" modus of de "backward–compatible" modus (“Quirks (Grillen) mode”). Deze manier van werken werd voor het eerst voorgesteld (voor zover wij weten) door Todd Fahrner in 1998, en voor het eerst geïmplementeerd door IE5/Mac in maart 2000.

Mozilla/NN6 volgt dit patroon, net zoals IE6/Win. IE6 gebruikt ook een DOM property die laat weten of de 'standards–compliant mode' aangezet wordt voor een bepaald document.

Als de browser in de “standaarden” modus staat, neemt de browser aan dat je weet wat je aan het doen bent en laat hij je pagina's zien volgens de regels van het W3C. In de “Quirks” modus neemt de browser aan dat je een ouderwetse, waarschijnlijk niet-valide pagina hebt gemaakt en laat hem daarom zien zoals een oudere browser dat zou doen. Jij hebt de controle over welke mogelijkheid de browser pakt, en wel door het toevoegen of weglaten van een compleet (X)HTML doctype.

Er is één uitzondering op deze regel: Mozilla/NN6, dat net zoals MSIE HTML 4.0 pagina's—zelfs met complete doctypes— in de "backward–compatible" “Quirks” modus behandelt. Dus als je nog niet helemaal klaar bent voor XHTML maar al wel valide HTML en CSS schrijft en graag wilt dat de browser je pagina correct laat zien, kies dan een HTML 4.01 doctype. Als je ons een plezier wilt doen kun je natuurlijk net zo goed XHTML gebruiken.

Als je je document hebt geconverteerd naar XHTML en je plaatjes zich opeens onfatsoenlijk veel terrein beginnen toe te eigenen, moet je een paar minuten de tijd nemen om regels op te nemen in je stylesheet die hiervoor compenseren. Elke layout is anders, dus er is niet een enkele CSS regel (of verzameling regels) aan te wijzen die alle problemen op zal lossen, maar het artikel van Eric Meyer en de stijlregels die we hebben gebruikt en hierboven hebben vermeld zouden een goed startpunt moeten zijn. Bovendien kost het extra werk je waarschijnlijk niet heel veel tijd.

WITRUIMTE EN DE BROWSER

Met het artikel van Eric Meyer heeft Mozilla/Netscape vastgelegd waarom het doet wat het doet. Wij weten niet zeker waarom IE6/Win de pagina anders liet zien toen we het doctype van onze pagina veranderde in XHTML. (Beide versies—de oude HTML 4.01 Transitional en de nieuwe XHTML 1.0 Transitional—gebruikten complete doctypes.)

Wij denken dat dat iets te maken kan hebben met de manier waarop sommige browsers omgaan met witruimte. Elk van de twee tags hieronder is functioneel hetzelfde, maar door hun verschillend gebruik (of niet-gebruik) van witruimte kan het zijn dat ze er anders uitzien in een browser die witruimte probeert te begrijpen als markup. Zodoende kan dit:

<td><img src="foo.gif" /></td>

... er anders uitzien dan dit:

<td>

 <img src="foo.gif" />
</td>

Het tweede voorbeeld—met de witruimte in de markup—kan er toe leiden dat er ongewenste gaten ontstaan in je pagina. Dat gebeurt ook in het voorbeeld hieronder. De eerste tag (zonder witruimte)...

<td><a href="#foo"><img src="foo.gif" /></a></td>

... kan er anders uitzien in jouw browser dan het functioneel identieke:

<td>
 <a href="#foo">
  <img src="foo.gif" />
 </a>
</td>

Waarom gebeurt dit? De zogenaamde “whitespace bug” was een bekend probleem in Netscape Navigator, al sinds Versie 3.0 (als het al niet eerder optrad). Toen Microsoft besloot om een concurrerende browser te bouwen, deden de ontwikkelaars van Microsoft zo goed mogelijk het gedrag van Netscape na, compleet met een aantal van de bugs. Wij denken dat MSIE6 nogsteeds bezig is met het imiteren van deze bug.

Het maakt overigens niet uit waarom IE6 dit deed: onze toegevoegde regel (display: block) loste het probleem ook in deze browser op. Misschien zijn de resultaten bij jouw pagina's net even anders, maar de één of andere versie van (display: block) helpt je waarschijnlijk bij het oplossen van deze problemen in zowel Mozilla/NN6 als IE6.

WORD GELUKKIG MET XHTML

Als ze goed worden toegepast verbeteren de standaarden van het W3C de toegankelijkheid van elk document dat gepubliceerd wordt op het web. Tevens zorgen ze ervoor dat deze documenten langer houdbaar worden (wat wij “forward compatibility” noemen). Als je graag zo lang mogelijk zo veel mogelijk publiek wilt trekken voor je werk, doe je er verstandig aan om met web standaarden te werken. En als je iets moet doen met de structuur van documenten is XHTML de aangewezen standaard.

Sommige standaarden van het W3C zijn bedoeld voor experts, om ze te helpen bij het volbrengen van ingewikkelde opdrachten. Maar hun standaarden voor markup (XHTML) en style sheets zijn er voor iedereen. Bovendien heeft het W3C heeft zijn best gedaan om de weg naar XHTML gemakkelijk te maken.

De regels van XHTML zijn in nog geen half uur tijd te leren en de voordelen van XHTML zijn groot. Het is niet moeilijk om XHTML te schrijven en net zo gemakkelijk om met de hand HTML naar XHTML te converteren. Hulpmiddelen als Tidy kunnen je helpen met het automatisch uitvoeren van dit proces, als je tenminste een paar minuten besteedt aan het lezen van de handleiding vóór je op de knop drukt.

Gratis online validators helpen je bij het zorgen dat je XHTML en CSS volgens de regels zijn, hoewel de foutmeldingen je af en toe in verwarring kunnen brengen en de validators zich in zeldzame gevallen niet goed gedragen.

Na het converteren naar XHTML moet je misschien je style sheet aanpassen om de standaardinstellingen voor afbeeldingen van sommige browsers te omzeilen, vooral wanneer ze in tabelcellen staan, maar als je deze activiteit onderdeel maakt van je werkwijze kan het een tweede natuur worden. En het marktaandeel van nieuwe browsers wordt steeds groter, wat betekent dat we steeds minder zullen werken met tabellen en steeds meer met CSS.

Met wat liefdevolle aandacht helpt XHTML je sites beter functioneren in meer browsers en toepassingen, zodat ze meer mensen bereiken, nu en in de komende jaren. Wat wil je nog meer?

• Home
• Artikelen
• Colofon