Standing in the middle of yesterday
Where it all went wrong—where we made mistakes
I'm sorry for the things I forgot to say
But it won't be long until it will be okay
—Raine Maida

Stel je voor dat je enkele jaren en enkele miljoenen euro’s hebt geïnvesteerd in het ontwikkelen van een product dat snel de SISO nummers op de ruggen van boeken kan scannen en die nummers naar een centrale database kan sturen. Dit geeft bibliotheken de mogelijkheid om bij te houden wat er aanwezig is in de bibliotheek. Je verkoopt je product aan honderden bibliotheken door het hele land en krijgt geweldige beoordelingen van je klanten.

Dan besluit op zekere dag een groot aantal bibliotheken om niet meer met SISO te werken, maar een ander systeem te gaan gebruiken, een systeem dat meer ruimte heeft voor uitbreiding. Veel van je klanten zullen overstappen, maar ze willen nog wel jouw product blijven gebruiken. Ze zijn bereid om te betalen voor een upgrade, en jij kunt die upgrade leveren, maar wanneer je je product ombouwt zal het geen SISO-nummers meer kunnen lezen. Dat zou er voor zorgen dat je andere klanten, die nog wél met SISO werken de upgrade niet zullen kopen, en ook dat je sommige nieuwe klanten niet zult binnenhalen.

De eenvoudigste oplossing zou zijn om beide systemen in te bouwen in je product en een knop aan de zijkant te plaatsen waarmee de gebruikers kunnen kiezen welke manier van scannen ze willen gebruiken. Dit levert een meer flexibel apparaat op dat er voor zorgt dat je geen klanten verliest.

Maar wat heeft dat nou met CSS te maken? Om hier het antwoord op te geven gaan we eerste even terug in de tijd.

Korte Geschiedenis van de Incompatibility

Eén van de grootste tragedies in de ontwikkelingsgeschiedenis van het Web was de zogeheten ‘browser-oorlog’, die volgens de meeste digitale historici goed begon the woeden in 1997. De geleerden zijn het er niet helemaal over eens wanneer het conflict eindigde, hoewel velen menen dat de openlijke strijd ophield aan het einde van 1999 of begin 2000. Het belangrijkste slachtoffer van dit conflict was de interoperabiliteit die het fundament was van het Web. In hun ijver om de “killer app” te bouwen, vervaardigden de browser bedrijven de ene na de andere exclusieve feature.

Tijdens het hoogtepunt van het conflict (vooral in 1998 en 1999) waren de twee belangrijkste strijders Netscape Navigator 4 en Internet Explorer 4. Deze twee browsers hadden compleet verschillende document object models, verschilden in hoe ze HTML layout en witruimte behandelden en hadden een enorme berg bugs, tekortkomingen en fouten in hun ondersteuning van CSS. In hun wanhoop maakten veel bouwers maar verschillende stylesheets voor elk van de browsers, in plaats van dat ze hun weg zochten door het mijnenveld van incompatibilities dat onstaan was.

Als één van deze twee browsers volgens de standaarden gewerkt had, hadden ontwerpers nog een kans gehad, maar helaas was dat niet het geval. De energie die gestopt moest worden in het omzeilen van bugs in de browsers zorgde ervoor dat grote groepen ontwerpers verkeerde gewoontes aanleerden en dat men een manier van denken kreeg die afweek van de specificaties van het W3C. Erger nog: hun documenten werden een hutspot van trucjes die nooit zouden valideren en die (expres of niet expres) bedoeld waren om slechts te werken in de browsers die op dat moment bestonden.

Het slagveld was bezaaid met de overblijfselen van het goede humeur van de ontwerpers. Toen Internet Explorer 5.0 voor Windows uitgebracht werd, werd de situatie niet zonniger. IE 5.0 werd dan wel beter en bouwde voort op het model van IE4, maar Netscape was zich aan het bezinnen op de toekomst en bracht niets nieuws uit. De drastische beperkingen van Navigator 4 waren nog steeds een belangrijk obstakel en zorgden ervoor dat veel leuke nieuwe dingen niet gebruikt konden worden.

En dan nu de Toekomst van het Web

Met het uitkomen van Internet Explorer 5.0 voor Macintosh werd voor het eerst duidelijk welke weg we moesten nemen om uit het moeras dat ontstaan was door de browser-oorlog los te geraken. De programmeurs van IE5/Mac hadden door dat geen enkele browser het zich kon veroorloven om oudere pagina’s kapot te maken. Om een overgang naar op standaarden gebaseerde markup mogelijk te maken zouden echter de behaviors waarop de oude pagina’s gebaseerd waren verlaten moeten worden. De oplossing was om twéé rendering engines te maken: één die zich hield aan de standaarden en één die rekening hield met hoe oudere pagina’s opgezet waren. En om daarbij een mechanisme te leveren dat de auteur van het document de mogelijkheid gaf om aan te geven welke modus de browser moest kiezen bij het laten zien van het document.

Wat? Een Doctype?

De programmeurs bedachten verschillende oplossingen, maar de oplossing die ze kozen was de meest praktische: het maakte gebruik van het DOCTYPE dat alle documenten moeten bevatten. In theorie zou elk HTML document zo'n DOCTYPE moeten hebben bovenaan het document. Een voorbeeld:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
     "http://www.w3.org/TR/REC-html40/strict.dtd">

In dit voorbeeld wordt dit document aangemerkt als strict HTML 4.0. Er is een groot aantal DOCTYPEs, een aantal zie je in tabel 1.

URL of URI?

Zoals je kunt zien in Tabel 1 hebben sommige DOCTYPEs een URI en andere niet. Dit is geen in steen gebeitelde regel: elk DOCTYPE kan een URI hebben of hem weglaten. Daarom heb ik er op willekeurige wijze één vermeld of weggelaten in de voorbeelden in de tabel. Verderop in dit artikel zal ik je laten zien dat het wel of niet vermelden van een DOCTYPE URI beïnvloed welke rendering mode genomen wordt.

Het mechanisme van de DOCTYPE-wisseling is in wezen vrij duidelijk en helder:

• Documenten met oudere of Transitional DOCTYPEs (of helemaal geen DOCTYPE) worden vertoond met de ‘loose rendering’ of ‘quirks’ modus. Deze mode, die ook wel ‘bugward compatibility’ genoemd wordt, houdt rekening met historische bugs en eigenaardigheden van Versie 4 browsers.
• Documenten met Strict of XHTML DOCTYPEs worden vertoond in de ‘strict rendering’ of standaarden modus. Deze modus volgt de specificaties van het W3C voor HTML, CSS en andere layout talen zo goed mogelijk.

Hoewel het verschrikkelijk nuttig is voor auteurs zou de DOCTYPE-wisseling misschien wel een onbekende voetnoot in de geschiedenis zijn gebleven als het alleen geïmplementeerd was in IE5 voor de Mac. Gelukkig hebben Netscape 6 en Internet Explorer 6 voor Windows het inmiddels ook geïmplementeerd. De deur naar een standards-compliant Web staat hiermee nu wijd open.

DOCTYPE wisselen: hoe gaat dat nou

Als je door een deur wilt stappen is het meestal een goed idee om enig idee te hebben van wat zich aan de andere kant van die deur bevindt. Wat je ook moet weten is hoe je überhaupt door die deur moet komen. Om dat te laten zien heb ik in Tabel 2 een lijstje met DOCTYPEs opgenomen, samen met het effect dat ze zullen hebben in de verschillende browsers die de DOCTYPE-wisseling herkennen.

En de Andere Browsers Dan?

Verschillen in Rendering Modus

Als je van plan bent om je oude pagina’s te gaan upgraden naar een nieuwe markup en een nieuw DOCTYPE, is het prettig om te weten welke veranderingen je waarschijnlijk tegen zult gaan komen. Er zijn ingrijpende veranderingen, zoals een andere betekenis voor de properties width en height, en er zijn ook subtiele verschillen, zoals overerfbaarheid in tabellen, die een ramp kunnen betekenen binnen bestaande ontwerpen. Er zouden zelfs verschillen kunnen zijn in de manier waarop het CSS geschreven kan worden, afhankelijk van de browser.

De hieronder staande informatie is een poging om te laten zien welke gebieden waarschijnlijk de meeste problemen op gaan leveren voor een auteur, hoewel het geen uitputtende lijst is van alle verschillen tussen de quirks modus en de standaarden modus in de verschillende browsers.

Overerfbaarheid en Tabellen

Het gebied dat waarschijnlijk de meeste problemen op kan leveren heeft te maken met tabellen en het wel of juist niet overerven van opmaak. In oudere browsers, zoals Navigator 4.x en Internet Explorer 5.x (en ouder), werden opmaak-elementen zoals fonts en font-groottes niet overerfbaar in tabellen. Zie bijvoorbeeld dit eenvoudige voorbeeld:

<body style="font: large sans-serif; color: purple;">
<table>

<tr><td>Hee, dit is tekst in een tabel!</td></tr>
</table>

In oude browsers zou de tekst in de tabel niet groot en niet in een sans-serif font vertoond worden. In oudere versies van Explorer zou de tekst niet eens paars zijn; het zou de standaard ingestelde kleur van de gebruiker zijn (meestal zwart).

In de quirks modus blijft dit gebrek aan overerfbaarheid bewaard. In de standaarden modus worden alle stijlen geërfd door de tekst binnen tabellen. En dit kan een probleem opleveren, dankzij een andere antieke bug, die afkomstig is uit Navigator 4.x.

Laten we zeggen dat een auteur de tekst op de pagina in een kleiner formaat wilde hebben dan de standaardinstelling van de gebruiker. In de meeste browsers kun je dat voor elkaar krijgen door bijvoorbeeld het volgende te schrijven:

body {font-size: 0.8em;}

Maar omdat de font-size (onder andere) niet overerfbaar was in tabellen, werd het een veelgebruikte truc om dezelfde waarden toe te kennen aan de cellen van de tabel.

Het Font Verkleinen

body, td, th {font-size: 0.8em;}

Dit zorgde er voor dat de font-groottes zo goed als consistent bleven in het hele document, gebruik makend van de browsers van circa 1998. Maar helaas zorgt het er ook voor dat in hedendaagse browsers de tekst in de tabellen slechts 64% van de standaardinstelling van de gebruiker wordt, en mogelijk zelfs kleiner!

Dit gebeurt om de volgende reden: wanneer een browser het toestaat dat eigenschappen zoals font-size overerfbaar is (zoals het hoort) heb je een situatie waarin een cel in een tabel (een nakomeling van het body element) zijn tekst op 0.8em van 0.8em van de standaard instelling heeft staan, wat 0.64em oplevert. Als er een tabel in een andere tabel genest is, zal die tekst 0.64em keer 0.8em, oftewel 0.512em zijn. Dat is net iets meer dan de helft van de standaard instelling van de gebruiker!

Een gemakkelijke manier om dit effect in actie te zien is om een aantal geneste lijsten op te zetten, met minimaal drie niveaus.

<ul>
<li>list item
<ul>
      <li>sublist item
            <ul>
            <li>subsublist item</li>

            </ul>
      </li>
      </ul>
</li>
</ul>

Nu voeg je aan dit document de stijl toe: ul {font-size: 0.8em;}. Elk niveau van de geneste lijst zal kleiner en kleiner worden, net zoals de geneste tabellen doen wanneer de overerving goed werkt.

table {
font-size: [[default_user_font_size_setting]];
color: [[default_user_text_color_setting]];}

Hoofdlettergevoeligheid

In de HTML 4.01 specificaties worden class- en id-waarden aangemerkt als hoofdlettergevoelig; dat wil zeggen, ze moeten op de zelfde manier gebruik maken van hoofdletters. Met andere woorden, Hallo en HalLO zijn niet hetzelfde. Op deze manier kun je het volgende tegenkomen:

Het Speciale Geval van id

<html>
<head>
<title>Hoofdlettergevoeligheid</title>
<style type="text/css">
p.TestDezeClass {color: red;}

</style>
</head>
<body>
<p class="testdezeclass">Hee, deze tekst is niet rood!</p>
</body>
</html>

Browsers uit het versie 4-tijdperk behandelden class- en id-waarden als niet gevoelig voor hoofdletters, wat er voor zou zorgen dat de tekst in het bovenstaande codeblok rood werd. Moderne browsers, in de standaarden modus, maken de tekst niet rood.

Omdat er eigenlijk geen reden is waarom je in al je CSS regels en HTML-gebaseerde waarden niet exact dezelfde class en id zou gebruiken, zou je er altijd voor moeten zorgen dat het hooflettergebruik in beiden hetzelfde is.

class en id, Tweede Bedrijf

Er waren nog wat merkwaardige dingen die te maken hadden met class en id. Vreemd maar waar: het was niet toegestaan onder CSS1 om class- en id-waarden te beginnen met een cijfer (0-9), maar sommige browsers stonden het wel toe. Moderne browser in de strict modus zullen hoogstwaarschijnlijk elke class en id-waarde die met een cijfer begint negeren, dus als je een id hebt die 1ste heet, kun je hem beter een andere naam geven.

Vermijd de Underscore

Nog een gek geval dat je aandacht verdient, hoewel het niet echt met strict/quirks te maken heeft. CSS1 en CSS2 stonden allebei niet toe dat er underscores gebruikt werden in class- en id-waarden, zodat waarden als test_class illegaal waren. Explorer heeft het gebruik van underscores altijd toegestaan, maar Navigator 4.x niet. Na de publicatie van CSS2 werden enkele errata toegevoegd, en één daarvan was het toestaan van underscores. Hoewel dit betekent dat de meeste browsers zich nu aan deze standaard houden en underscores toestaan, zijn er sommige die dat niet doen.

Problemen met Waarden

Dit gedeeelte gaat helemaal over Internet Explorer. In IE4.x/Win en IE5.x/Win, kon je redelijk slordig omgaan met het vermelden van waarden. Een voorbeeld:

h1 {color: FF0000;}     /* hier mist de octothorpe! */
h2 {font-size: 18 px;}  /* een spatie te veel */
table {width: 500;}     /* wat is de eenheid? */

In de eerste regel mist de kleurwaarde de octothorpe (#) die verplicht is voorafgaand aan elke hexadecimale kleurwaarde. De tweede regel heeft een extra spatie tussen het getal 18 en de eenheid px, en dit zorgt er voor dat de betekenis van de waarde totaal verandert. Bij de derde regel is er zelfs helemaal geen eenheid aangegeven. Moet de tabel 500 voet breed zijn? 500 el? 500 angstroms?

Een Snelle Leerhulp

De correcte vorm van deze regels is de volgende:

h1 {color: #FF0000;}
h2 {font-size: 18px;}
table {width: 500px;}

Internet Explorer 6 in de standaarden modus zal waarschijnlijk de eerste versie van de regels negeren, omdat ze niet correct zijn. Als je de afgelopen drie jaar bezig bent geweest met het aanleren van verkeerde bouw-gewoontes die bleken te werken in Explorer, is het nu tijd om die gewoontes af te leren.

Width en Height Veranderen

Dit is veruit de meest verrassende verandering voor veel bouwers die overstappen van ‘ouderwets’ bouwen naar bouwen volgens de standaarden... vooral die bouwers die gebruik maakten van positioneren met CSS of pogingen deden tot pixel-precieze opmaak in Explorer 5.x.

Dit onderwerp kan het best worden uitgelegd met een plaatje. In Figuur 1 zie je het element ‘box’ zoals beschreven in CSS1 en CSS2.

Figuur 1

Het CSS element ‘box’.

Als het goed is, valt het je op dat de properties width en height de grootte van het gebied voor de content beschrijven. Als er paddings of borders zijn worden deze toegevoegd aan het content gebied. Een voorbeeld:

div.illus {
width: 200px; 
height: 150px;
padding: 20px; 
margin: 10px; 
border: 3px double black;
}

Zoals hier is gedefiniëerd is het content gebied 200 pixels breed en 150 pixels hoog. De afstand van de buitenkant van de linker rand tot de buitenkant van de rechter rand is 246 pixels (3 + 20 + 200 + 20 + 3). Van de linker buitenmarge tot de rechter is 266 pixels, nadat je 10 pixels marge aan elke kant toevoegt. Op de zelfde manier is de afstand van de buitenkant van de bovenste rand tot de onderkant 196 pixels en van de bovenmarge tot de ondermarge 216 pixels.

Kijk nu naar Figuur 2, dat het Internet Explorer 4.x- en 5.x-element box laat zien.

Figuur 2

Het Internet Explorer element ‘box’ (oud).

Let op de verschillen tussen de vermeldingen van height en width. In oude Explorer versies beschreven deze waarden de optelling van het content-gebied, de padding en de borders, in plaats van alleen het content-gebied.

Om die reden zou in ons bovenstaande voorbeeld het content-gebied 154 pixels breed en 104 pixels hoog worden. Het verschil tussen de buitenste randen van de border zou 200 pixels horizontaal en 150 pixels verticaal zijn, en de afstand tussen de buitenste randen van de marge zou 220 pixels bij 170 pixels zijn. Deze verschillen kun je zien in Figuur 3.

Figuur 3

De twee manieren om een box op te maken vergeleken: standards-compliant links, het oude Explorer-model rechts.

Het maakt niet uit welke manier je het meest logisch vindt: het correcte model is dat wat links staat, het CSS model, en dat is ook het model dat door IE6 wordt gebruikt in de standaarden modus. In de quirks modus gebruikt het het oude Explorer model. Dit betekent dat je met alleen een verandering van het DOCTYPE van de pagina die pagina er radicaal anders uit kunt laten zien, zonder een letter te veranderen in je CSS-opmaak.

Kies je Favoriete Model

Omdat deze twee modellen zo verschillend zijn, lijkt dit een onoplosbaar probleem voor iedere pagina die getoond moet kunnen worden door meerdere browsers. Dat hoeft niet persé het geval te zijn. Er zijn manieren om problemen met de opmaak te voorkomen door het zorgvuldig opzetten van je documentstructuur (zie bijvoorbeeld Project 11, “Positioning a Better Design” in mijn boek Eric Meyer on CSS) en door gebruik te maken van dingen die door oudere browsers niet ondersteunt worden en om voor die browser gemaakte CSS te vertonen zonder gebruik te maken van JavaScript (zie “Tricking Browsers and Hiding Styles” op de website die bij het boek hoort).

Verder Lezen

Als je meer wilt lezen over DOCTYPE-wisselingen en de verschillen tussen de rendering modes, of als je meer gedetailleerde tabellen zoekt van DOCTYPEs en welke modus ze aanzetten in welke browsers, dan vind je hieronder een aantal goede bronnen.

CSS Verbeteringen in Internet Explorer 6

http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp

Dit artikel geeft een inleiding in het concept achter DOCTYPE-wisseling, een tabel met een overzicht van hoe je de quirks modus of de standaarden modus in IE6 kunt activeren, en behoorlijk gedetailleerde uitleg over de verschillen tussen quirks modus en standaarden modus.

Quirks Modus in Mozilla

http://www.mozilla.org/docs/web-developer/quirks/

Deze bescheiden collectie artikelen legt het denkproces achter DOCTYPE-wisselen in Mozilla uit, geeft een uitgebreide lijst van welke DOCTYPEs welke modus aanzetten en geeft een lijst van de quirks. In veel gevallen zijn deze quirks gelinkt aan entries in Bugzilla, het systeem dat de bugs in Mozilla bijhoudt, wat een af en toe fascinerende blik levert op de discussies over deze quirks en of ze gerepareerd moeten worden of niet.

Wat? Een DOCTYPE?

Terwijl ik dit schrijf heeft de meerderheid van de documenten op het web nog helemaal geen DOCTYPE. terug

URL of URI?

Hoewel de meeste webbouwers goed bekend zijn met het acroniem URL (uniform resource locator), is de term URI niet zo wijdverbreid. URI staat voor ‘uniform resource identifier’. Het grootste verschil is dat waar een URL moet verwijzen naar een bron op het web, een URI deze restrictie niet hoeft te volgen. Eén belangrijke eis: URIs moeten uniek zijn. Een analogie: het woord ‘hemel’. Misschien heeft het en echte, fycieke locatie, maar misschien ook niet, maar hoe dan ook beschrijft het een uniek concept. terug

En de Andere Browsers dan?

Netscape Navigator 4.x bestond lang voordat DOCTYPE-wisseling zelfs maar bedacht werd, dus je zou aan moeten nemen dat het altijd in de quirks mode werkt (en een quirks mode vol fouten, ook nog). Opera 6 en eerdere versies doen niet aan DOCTYPE-wisseling en je zou er van uit moeten gaan dat ze altijd in standaarden modus werken. Wees je ervan bewust dat Opera hier en daar nog wel een bug kan hebben, maar dat het zich grotendeels gedraagt als de standaarden modus van andere browsers. terug

Het Font Verkleinen

Over het algemeen wordt het kleiner maken van de tekst op een pagina dan de standaardinstelling van de gebruiker gezien als een slechte gewoonte voor bouwers. Helaas is het ook zo dat de default-groottes in browsers vaak groter zijn dan ontwerpers zouden wensen. Er is geen antwoord dat voor iedereen geldt, maar denk er goed over na voordat je fonts verkleint, want het zou heel goed kunnen zijn dat je je de letters zo te klein maakt om prettig gelezen te kunnen worden door de bezoekers. terug

Het Speciale Geval van id

Hoewel de waarden van id gevoelig zijn voor het gebruik van hoofdletters, kun je binnen een HTML-document ook niet gebruik maken van namen die precies hetzelfde zijn behalve in hun hoofdlettergebruik. Met andere woorden, hoewel TestID en testid niet hetzelfde zijn, kun je maar één van de twee gebruiken in de source van een bepaald document. Dit geldt trouwens ook voor namen van waarden. terug

Vermijd de Underscores

Underscores hebben een mottige geschiedenis qua ondersteuning, dus ik zou je van harte aanraden om ze gewoon niet te gebruiken in class- en id-waarden. Verbindingsstreepjes zijn toegestaan en zijn een veelgebruikte uitwijkmogelijkheid (voorbeeld: test-class). terug

Een Snelle Leerhulp

Eén van de snelste manieren om fouten op te sporen in je CSS, en daarmee ook jezelf goede bouwgewoontes aan te leren, is om een CSS validator te gebruiken. Dat zijn programma's die je CSS controleren op grammaticale fouten en veelvoorkomende vergissingen. Het W3C heeft bijvoorbeeld een goede. Realiseer je wel dat de validators niet kunnen voorkomen dat jij allerlei vergissingen kan maken, maar ze kunnen je wel helpen bij het vermijden van basale fouten. terug

Kies je Favoriete Model

De discussie over welk model nou het ‘beste’ is woedt al jaren en het ziet er niet naar uit dat er een definitieve beslissing komt. Desalniettemin is er hoop voor beide kampen: er is een voorstel voor de toevoeging van een property in CSS3 die de bouwer de mogelijkheid geeft om te beslissen welk model hij of zij wil volgen bij het opmaken van een element. Terwijl ik dit schrijf heet deze box-sizing, maar hou er rekeing mee dat deze naam kan veranderen voordat het CSS3 box model haar definitieve vorm krijgt. terug

Dit artikel is afkomstig van de website die hoort bij het boek Eric Meyer on CSS: Mastering the Language of Web Design. Al het materiaal is copyright Eric A. Meyer en New Riders Publishing. Reproduced by permission of New Riders Publishing. All Rights Reserved.

• Home
• Artikelen
• Colofon