In dit hoofdstuk (hoofdstuk 8 van het boek ‘Designing with Web Standards’, red.) maken we onze borst nat en gaan we wat we tot dusver hebben geleerd over XHTML toepassen in een echt project. De markup die we gaan schrijven zal gedeeltelijk “structureel” zijn, gedeeltelijk “transitional” en zal helemaal voldoen aan de standaarden.

In het volgende hoofdstuk, hoofdstuk 9, “CSS Basics”, zullen we de basisbeginselen van Cascading Style Sheets (CSS) behandelen voor beginners en iets meer ervaren gebruikers. In hoofdstuk 10, “CSS in Action: A Hybrid Layout (Part II)”, zullen we uiteindelijk nog meer leren over CSS terwijl we werken aan de laatste loodjes van ons project. Dit “leren door het te doen” gedoe lijkt nogal op leren zwemmen door in diep, koud water gegooid te worden, hoewel wij het liever vergelijken met Frans leren door op vakantie te gaan in Parijs. Als extraatje zullen we tijdens het bouwen van dit project ook beginnen met er achter komen hoe we toegankelijkheidseisen toepassen binnen onze markup (en dus onze sites toegankelijker maken).

Voordelen van de “transitional” of overgangsmethode zoals gebruikt in deze hoofdstukken

In dit hoofdstuk beginnen we met een hybride “transitional” of overgangslayout, die de gangbare (maar hier iets gestroomlijnde) techniek van layout met tabellen combineert met gestructureerde tekstuele opmaak en extra’s voor toegankelijkheid. De technieken die we in dit project gebruiken en die we zullen uitleggen in deze drie hoofdstukken zijn ideaal voor bibliotheken en andere openbare instellingen, maar ook voor kleine bedrijven en alle andere organisaties die het volgende voor ogen hebben:

• Een grote verscheidenheid van browsers en apparaten ondersteunen
• De bandbreedte van de bezoeker (en die van jezelf) zo min mogelijk belasten
• Beginnen met de overgang naar webstandaarden met publicatiemethoden die betrouwbaar, goedkoop en gemakkelijk te implementeren zijn.

Stylesheets in plaats van JavaScript

Aan het einde van deze drie hoofdstukken zullen we een template hebben gemaakt voor de site van i3Forum [8.1] die aan de standaarden voldoet. Het definitieve template zoals dat in deze hoofdstukken opgezet werd kun je zien op de staging server van Happy Cog, op http://i3.happycog.com/. De uiteindelijke site, die gemaakt werd met deze templates, zie je op http://i3forum.com/.

In dit hoofdstuk zetten we onze markup neer. In hoofdstuk 10 voegen we CSS toe om de kleur, grootte en relatieve positie van de elementen te bepalen. (In hoofdstuk 9 nemen we een korte pauze om de basisbeginselen van CSS te leren.) We zullen er met onze CSS onder andere voor zorgen dat het menu een rollover effect krijgt dat meestal met behulp van plaatjes en JavaScript wordt gerealiseerd. Niet dat er iets mis is met plaatjes of JavaScript, maar doordat we in plaats daarvan XHTML tekst en CSS gebruiken, besparen we op bandbreedte terwijl we tevens de site toegankelijk maken voor een groot aantal omgevingen, zoals spraakgeneratoren en tekstbrowsers, nondesktop-browsers (PDA’s en browsers op telefoons), en browsers die niet met CSS kunnen omgaan.

Werkwijze (Overzicht)

De layout van i3Forum is zó ontworpen dat er een fris, onderscheidend merk wordt neergezet met een minimum aan toeters en bellen, en de XHTML is net zo ongecompliceerd. Het bestaat uit twee tabellen, allebei gecentreerd, en allebei opgemaakt en bestuurd via CSS. De eerste tabel bevat het menu, de tweede de content. [8.2].

[8.1]Het template zoals het er uit ziet wanneer we het werk zoals beschreven in hoofdstuk 8 tot en met 10 hebben uitgevoerd.

[8.2] Het template zoals we dat in dit hoofdstuk gaan bouwen, met CSS uitgeschakeld en ‘borders’ aan. Let op de iets dikkere lijn tussen het menu en de content, waar de twee tabellen elkaar raken.

De XHTML voor de tabellen zullen we laten zien in de komende pagina’s. Maar misschien is er al een vraag bij je opgekomen. Gewoonlijk zou een dergelijke layout gebruik maken van slechts één tabel, met rowspan en colspan om de diverse rijen en kolommen goed te krijgen. Als we Adobe ImageReady zouden gebruiken om het Photoshop bestand waarin ontwerp gemaakt werd (ook gebruikt om het ontwerp te verkopen aan de klant) te snijden, zouden ImageReady de hele pagina in één tabel zetten. Dus waarom zouden we hier nou twee tabellen gebruiken?

Meer tabellen: voordelen voor CSS en toegankelijkheid

Als je het stuk in hoofdstuk 7 over div, id, en andere helpers nog niet hebt gelezen zou het handig zijn als je dat eerst bekijkt voordat je verder leest. Het opdelen van onze layout in twee tabellen geeft ons de mogelijkheid om gebruik te maken van de kracht van het id attribuut om het volgende te doen:

• Stroomlijnen van de CSS die we in hoofdstuk 10 zullen maken
• De toegankelijkheid op een aantal punten verbeteren
• Iedere tabel structureel benoemen met een naam die laat zien wat zijn functie is, zodat het gemakkelijker wordt om in de toekomst de layout verder aan te passen en de XHTML tabellen te verwisselen met divs die met CSS opgemaakt worden.

Het element “table summary”

Als we de layout onderverdelen in twee tabellen kunnen we ze ook elk een summary geven:

<table id="nav" summary="Navigation elements" etc. >
<table id="content" summary="Main content." etc. >

Deze is onzichtbaar voor doorsnee desktop browsers zoals Internet Explorer (IE) en Netscape. Maar de voorleessoftware die visueel gehandicapten gebruiken begrijpt dit attribuut en zal de beschrijving die je hier ingeeft ook voorlezen. In ons geval zal de screen reader “Navigation elements” en “Main content” voorlezen. En als de software goed in elkaar zit, zal het de gebruikers ook de mogelijkheid geven om de tabel over te slaan als ze het idee hebben dat de inhoud niet voor hen van belang is. Het opnemen van de summary is dus een goede toegankelijkheidsstrategie om bezoekers te helpen die misschien de “Skip Navigation” link niet tegenkomen die we twee paragrafen verderop zullen bespreken.

Paginastructuur en id

We hebben allebei de tabellen een id attribuut gegeven die vertelt welke functie hij heeft – navigatie of content. Als we dat op dit moment in het bouwproces doen geeft het ons de mogelijkheid om later een compacte CSS-regel te schrijven die voor de gehele tabel geldt, wat er voor zorgt dat we een overvloed aan class en div’s vermijden (besproken in hoofdstuk 7).

Deze methode geeft ons ook de mogelijkheid om een “Skip Navigation” link op te nemen aan het begin van onze markup.

Het hoe en waarom van “Skip Navigation”

Zoals de naam al verklapt geeft de “Skip Navigation” link de bezoekers de mogelijkheid om de navigatie over te slaan en direct door te gaan naar de tabel met de content, dankzij een ankertje. Het id attribuut “content” is het anker waar we naartoe linken:

<div class="hide"><a href="#content" title="Skip navigation." accesskey="2">Skip navigation</a>.</div>

De navigatie overslaan is voor de meeste bezoekers die over hun volledige gezichtsvermogen kunnen beschikken niet zo belangrijk, omdat ze eenvoudig hun blik kunnen richten op de dingen in een pagina die ze interessant vinden, en andere zaken gewoon kunnen negeren.

Maar bezoekers die wegens een visuele handicap gebruik moeten maken van voorleessoftware doorlopen een website lineair, één link tegelijk. Het is frustrerend voor deze gebruikers om elke keer als je een nieuwe pagina opent een lange stroom menulinks aan te horen. “Skip Navigation” geeft de bezoeker de mogelijkheid om dit probleem te omzeilen.

“Skip Navigation” kan ook van pas komen voor mensen zonder visuele handicap die een PDA gebruiken die geen ondersteuning biedt voor CSS of een webtelefoon. Zij hoeven dan ook niet door eindeloze lijsten met links te scrollen op iedere nieuwe pagina. Bovendien kunnen mensen die wel kunnen zien maar een motorische handicap ook profijt hebben van “Skip Navigation”, hoewel deze methode niet perfect is (zie ook verderop in het stukje “accesskey: goed nieuws en slecht nieuws”).

“Skip Navigation” en accesskey

Onze “Skip Navigation” link geeft bezoekers die gebruik maken van een niet-visuele of een niet-CSS browser de mogelijkheid om meteen naar de content in de tweede tabel te springen, waarvan het id attribuut (en dus ook de ankerlink) "content" is:

<table id="content" …> etc.

In deze niet-visuele of niet-CSS omgeving staat de link handig klaar aan het begin van de pagina [8.3, 8.4]. In hoofdstuk 10 zul je een regel maken die er voor zorgt dat de “Skip Navigation” link in browsers die wel CSS ondersteunen verborgen wordt. En voor het geval je van het ongeduldige type bent zullen we hem hier ook alvast laten zien.

.hide {
display: none;
}

[8.3] In een browser die geen CSS ondersteunt (of een browser die wel CSS ondersteunt, maar waarin CSS is uitgeschakeld), is de “Skip Navigation” link duidelijk zichtbaar bovenaan de pagina.

[8.4] De zichtbare “Skip Navigation” link in het echt – in onze layout met CSS uitgeschakeld.

Dankzij deze CSS-regel zullen bezoekers die een moderne browser gebruiken waarin CSS ingeschakeld staat de “Skip Navigation” link niet zien - maar de meeste van hen hebben deze link niet nodig wegens de redenen waar we het in "Het hoe en waarom van “Skip Navigation” al over gehad hebben. Schermlezers, die CSS negeren, lezen vrolijk de inhoud van de div, en informeren zo de bezoekers over het goede nieuws dat ze de saaie voorlezing van de andere links over kunnen slaan.

Er is natuurlijk altijd een uitzondering die de regel bevestigt. Mensen met een lichamelijke handicap die de site met een CSS-geschikte browser bezoeken willen misschien ook de navigatie over kunnen slaan en direct naar de content gaan. De meeste mensen met een verminderde mobiliteit kunnen de gehele pagina van een website in één keer zien (behalve dan mensen die een visuele en een lichamelijke handicap hebben). Maar om te navigeren door de pagina gebruiken deze mensen het toetsenbord of een alternatief hulpmiddel voor de interactie. Met behulp van de tab-functie door al deze ongewenste navigatielinks wandelen kan heel vervelend zijn.

Hoe kunnen we deze gebruikers helpen zodat ze de navigatie over kunnen slaan ook al zien ze onze mooie “Skip Navigation” link niet in hun browser? We gebruiken daarvoor het accesskey attribuut, dat ook werkt als de “Skip Navigation” link niet zichtbaar is in de browser. Helaas, deze methode werkt niet perfect, zoals we hierna zullen laten zien.

accesskey: goed nieuws en slecht nieuws

Het accesskey attribuut in HTML/XHTML geeft mensen de mogelijkheid om te navigeren in websites met het toetsenbord in plaats van met de muis. Om aan een element een accesskey te geven vermeld je het simpelweg in je code, zoals in het stukje XHTML dat we eerder bespraken en wat we hier nog even laten zien – met het relevante attribuut en zijn waarde vetgedrukt:

<a href="#content" title="Skip navigation." accesskey="2">Skip navigation</a>.

In onze markup hebben we de “Skip Navigation” link de accesskey 2 gegeven. Dat betekent dat de bezoeker op de 2 op haar toetsenbord kan drukken om de navigatie over te slaan. Net zoals met zo veel maatregelen die de toegankelijkheid van je website verbeteren is ook dit heel gemakkelijk in je opmaak te schrijven en heeft het geen invloed op het uiterlijk van de site. In dit geval is dat zowel goed nieuws als slecht nieuws.

Want hoe weet de bezoeker nou dat ze op die 2 op haar toetsenbord moet drukken? Er zijn geen algemeen aanvaarde browsers die laten zien welke accesskeys gebruikt worden. En de meeste obscure browsers doen dat ook niet.

accesskey en iCab

Terwijl ik dit schrijf laat alleen iCab [8.5], een Macintosh browser zien welke accesskeys gebruikt worden. De meeste gebruikers van het web hebben geen Macintosh, en de meeste Macintosh gebruikers beschikken niet over iCab. En wat nog erger is, is dat iCab de accesskeys niet kan laten zien als de “Skip Navigation” link verborgen is met CSS. Op het moment dat ik dit boek naar de drukker stuur ondersteunt iCab nogsteeds een groot gedeelte van CSS1 niet, de allereerste aanbevelingen van het W3C, nota bene gepubliceerd in 1996. Kortom: hoewel iCab een interessante browser is en het bewonderenswaardig is hoe ze zich inzetten om HTML 4 te ondersteunen (en nee, dat is niet rot bedoeld: de HTML 4 ondersteuning van iCab is echt heel goed), zullen zij niet het huidige accesskey probleem kunnen oplossen.

[8.5] Van alle browsers die er bestaan is iCab voor Macintosh de enige die onze accesskey 2 laat zien, waardoor de bezoeker weet dat ze de navigatie over kan slaan door "2" te drukken op haar toetsenbord. De iCab browser is te vinden op http://www.icab.de/.

Twee utopische mogelijkheden voor de accesskey

Het is duidelijk dat de meerderheid van de bezoekers die baat zouden kunnen hebben bij de accesskey geen mogelijkheid hebben om te zien welke accesskey nummers of letters ze in zouden moeten toetsen, en dat ze er dus ook geen gebruik van kunnen maken. Daarom is het enigszins idealistisch om ze toch op te nemen in je markup.

Als het W3C aanbevelingen zou publiceren voor een accesskey standaard voor universele functies zoals “Skip Navigation” (en als ontwerpers en bouwers zich vervolgens zouden houden aan die aanbevelingen), dan zouden gebruikers altijd weten welke toetsen ze moesten gebruiken. Dat zou mooi zijn.

Of de browsermakers zouden kunnen besluiten om de ondersteuning van de accesskey te verbeteren door de accesskey-waarden te laten zien op het moment dat de gebruiker een toegankelijkheidsoptie aanvinkt in zijn voorkeuren. IE voor Windows biedt een toegankelijkheidsoptie die gebruikers in staat stelt om alle fontgroottes in webpagina’s te negeren. Ze zouden ook een optie kunnen toevoegen als "Laat Altijd Accesskey-waarden Zien".

We geven toe dat het een behoorlijk utopisch idee is dat het W3C de accesskey-waarden binnenkort gaat standaardiseren, en het voelt nog veel utopischer om te denken dat een grote browsermaker (laat staan alle browsermakers) ontwikkeltijd en menskracht zullen steken in een altijd-zichtbare-accesskey optie. Desalniettemin, wij blijven de accesskey gebruiken. Misschien zijn er gebruikers die in de code kijken welke accesskeys gebruikt worden in een pagina en daarna gebruik maken van die toetsen om door de pagina te navigeren. We hopen maar dat het leven binnenkort gemakkelijker wordt voor deze mensen.

Nog meer id attributen

Naast de meest gebruikelijke, primaire id attributen (nav en content) die we al gebruikten toen we aan de slag gingen met de markup geven we nu ook unieke id namen aan elke cel van de navigatietabel. Twee cellen is wel genoeg om het principe duidelijk te maken:

<td width="100" height="25" id="events"><a href="events.html">Events</a></td>
<td width="100" height="25" id="schedule"><a href="schedule.html">Schedule</a></td>

We geven ook unieke id attributen aan elk van de twee belangrijkste verdelingen van de content tabel, namelijk de sidebar (id="sidebar") en de belangrijkste content (id="primarycontent"). Daarna komt de structuur van de contenttabel (met veel gegevens eruit gehaald voor de duidelijkheid van het voorbeeld); de id attributen en waarden zijn aangegeven in vet:

<table id="content" etc.>
<tr>
<td width="200" id="sidebar">
Sidebar content goes here.
</td>
<td width="400" id="primarycontent">
Primary content goes here.
</td>

Als extraatje gooien we er ook nog een id attribuut bij op de tweede rij van het menu. Die heeft de volgende id:

<tr id="nav2">

En, zoals je misschien al verwachtte, heeft de derde rij "knoppen" deze id:

<tr id="nav3">

Hoe veel is te veel?

De laatste twee id’s (nav2 en nav3) zijn niet persé nodig voor dit ontwerp, maar misschien komen ze op een dag van pas als er een ander ontwerp gemaakt mocht worden. Maar zouden we ze nu op dit moment op moeten nemen of niet? Als we ze nu opnemen betekent dat dat onze XHTML een paar bytes groter wordt, en we zouden er net zo goed voor kunnen kiezen om het niet te doen.

Als de navigatie zich op de definitieve site in een apart Server-Side Include bestand bevindt (of in PHP, ASP enzovoorts), kan de klant dat bestand eenvoudig aanpassen op een willekeurig moment in de toekomst. Op die manier kan zij de hele site veranderen door het aanpassen van slechts één bestand. Als de klant van plan is om gebruik te maken van server-side technologie is het een beetje nutteloos om nav2 en nav3 nu toe te voegen. Aan de andere kant, als er geen gebruik wordt gemaakt van server-side technologie en de codering van het menu handmatig herhaald wordt op elke pagina, zou het veiliger kunnen zijn om nav2 en nav3 wél toe te voegen om mogelijke fouten bij het zoek en vervangen te voorkomen wanneer er een nieuw ontwerp uitgevoerd wordt. En daarom hebben we het toch gedaan.

Eerste ronde markup: zelfde als laatste ronde markup

Op deze en de volgende pagina’s zie je onze eerste ronde door de markup van de site, van <body> tot </body>. Dat is tevens onze laatste ronde door de markup. Alle verdere verbeteringen aan het uiterlijk werden geheel met CSS gedaan. Dat is één van de voordelen van zo veel mogelijk visuele zaken overdragen aan je stylesheets, zelfs in een hybride layout zoals deze. Om ruimte besparen in dit boek hebben we de prachtige bodytekst die we gebruikten in het template vervangen door neptekst.

Let er ook op dat we relatieve links gebruikt hebben bij het linken naar de afbeeldingen (img src="images/logo.gif") in plaats van absolute links (img src="/images/logo.gif") omdat we nu vanaf onze desktop werken in plaats van op de server. Absolute URL’s zijn betrouwbaarder dan relatieve URL’s omdat ze het blijven doen, ook als de locatie van je bestanden verandert. Een voorbeeld: als /events.html verplaatst wordt naar /events/index.html zal de absolute verwijzing naar /images/logo.gif nog steeds resultaat opleveren. Het gebruik van absolute URL’s helpt je ook bij het vermijden van een CSS bug in sommige oudere browsers die relatieve verwijzingen naar files in stylesheets verkeerd begrijpen.

Technische gesproken verschilt de uiteindelijke markup van de ‘eerste ronde’ markup doordat we de relatieve verwijzingen veranderen in absolute verwijzingen. Niet dat dat de meesten van jullie zal interesseren, maar er is altijd die ene lezer die in de broncode van de pagina gaat kijken om te zien of de beweringen in het boek wel echt waar zijn.

Misschien vind je het makkelijker om de broncode ook echt bij de bron te bekijken. Zoals ik al eerder vermeldde is het project te vinden op http://i3.happycog.com/.

Navigatiemarkup: de eerste tabel

Hierna volgt het navigatiegedeelte van de pagina, vanaf de body. Om het spannend te houden vertellen we je alvast dat dit gedeelte van de markup (hoewel het valideert) een “zonde” bevat tegen de regels van de schone markup – die voorschrijven dat de markup geen dingen zou moeten bevatten die de visuele presentatie regelen. Kijk maar eens of je deze zonde kunt vinden.

<body bgcolor="#ffffff">
<div class="hide"><a href="#content" title="Skip navigation." accesskey="2">Skip navigation</a>.</div>
<table id="nav" summary="Navigation elements" width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td rowspan="3" id="home" width="400"><a href="/" title="i3Forum home page."><img src="images/logo.gif" width="400" height="75" border="0" alt="i3forum home" /></a></td>
<td width="100" height="25" id="events"><a href="events.html">Events</a></td>
<td width="100" height="25" id="schedule"><a href="schedule.html">Schedule</a></td>
</tr>
<tr id="nav2">
<td width="100" height="25" id="about"><a href="about.html">About</a></td>
<td width="100" height="25" id="details"><a href="details.html">Details</a></td>
</tr>
<tr id="nav3">
<td width="100" height="25" id="contact"><a href="contact.html">Contact</a></td>
<td width="100" height="25" id="guestbios"><a href="guestbios.html">Guest Bios</a></td>
</tr>
</table>

Opmaak, semantiek, orthodoxie en zonde

Hoe erg is het gesteld met jouw standaardenfanatisme? Zag je de ergste zonde in onze XHTML? De eerste overtreding vond plaats in de eerste regel – namelijk het gebruik van het achterhaalde attribuut bgcolor (background color) bij het body element om te specificeren, zelfs in niet-CSS browsers, dat de achtergrond van de pagina wit zou moeten zijn (#ffffff). Hier heb je het nogmaals:

<body bgcolor="#ffffff">

Het schrijven van dit soort ouderwetse markup zou ons razendsnel uit de Pure Standards Academy gegooid kunnen krijgen. CSS geeft ons namelijk de mogelijkheid om de achtergrondkleur van de body te bepalen, en het W3C adviseert dat CSS – en niet HTML of XHTML – gebruikt moet worden voor dit doel. In de ogen van vele fans van de standaarden is ons gebruik van bgcolor een zonde.

Een overgangsboek voor een overgangstijd

Voor de standaardenfanatiekeling die elke week uren spendeert aan het pleiten over de kwalijkheid van markup die het uiterlijk van pagina’s regelt op de mailinglijsten van het W3C is wat we hier gedaan hebben kwalijk en schadelijk. We hebben trouwens ook een zonde begaan door gebruik te maken van tabellen anders dan strikt en alleen als verzamelplaats van tabeldata, door hoogte en breedte in onze tabelcellen te specificeren en door de marge van onze afbeeldingen op nul te zetten in de markup. Eerlijk gezegd is dit hele hoofdstuk zondig in de ogen van sommigen. Enkele standaardenfanaten vinden waarschijnlijk dit hele boek maar niks. In hun ogen zouden wij je moeten vertellen hoe je semantisch correcte markup moet schrijven in plaats van dat we je het idee geven dat het soms prima is om tabellen te gebruiken voor je layout.

Maar weet je, het is ook prima om dat te doen. Misschien niet meer over een aantal jaren, op het moment dat er puur semantische toekomstige versies van XHTML en uitgebreide toekomstige versies van CSS en SVG zijn die ook nog eens gebruikt worden door ontwerpers en ondersteunt worden door de browsers. Maar dit is een overgangsboek voor een overgangstijd: we schrijven XHTML 1.0 Transitional. “Web standaarden” zijn niet een collectie absolute wetten, maar een pad vol mogelijkheden en beslissingen. In onze optiek zijn mensen die in de huidige stand van zaken wat betreft standaarden en browsers staan op absolute orthodoxie net zo schadelijk voor de algemene aanvaarding van standaarden als diegenen die nog nooit van gestructureerde markup en CSS hebben gehoord of er zelfs uitgesproken vijandig over denken.

Rekening houden met oude browsers

Waarom gebruikte we nou die zondige bgcolor ondanks zijn schandelijke slechtheid? De hybride site die we aan het maken zijn doet geen aannamen over de browsers die gebruikt worden door de bezoekers. Als de default ingestelde achtergrond iets anders dan wit zou zijn in een oude browser die CSS niet ondersteunt, zou de transparante GIF van het logo een onappetijtelijke halo krijgen van pixels die niet kloppen bij de achtergrondkleur. Er is geen klant die wil dat zijn logo er in welke browser dan ook rommelig uit ziet, zelfs als de rest van de site er maar middelmatig uit ziet in sommige oude browsers.

Eén veelgebruikte oude browser die geen CSS ondersteunde gebruikte een middelgrijs als standaard achtergrondkleur. Ons logo is niet ge-antialiased op middelgrijs, maar op wit. Als we de achtergrondkleur niet met bgcolor in de XHTML op wit hadden gezet, had ons logo er niet uit gezien in deze omgeving.

In het dagelijks gebruik kan het je misschien niets schelen hoe je site er uit ziet in een 2.0 of een 3.0 omgeving. Misschien kunnen de 4.0 browsers je niet eens wat schelen. Misschien kan het je baas of je klant ook niets schelen. De semantisch niet correcte technieken die we in dit hoofdstuk gebruiken zijn er niet op uit om in alle browsers dezelfde visuele ervaring te realiseren. In een browser die geen CSS ondersteunt zal onze layout er niet beter uitzien dan wat je ziet in figuur 8.3. En dat is prima.

We hebben tabellen en de bgcolor gebruikt in deze site om je te laten zien dat zulke compromissen mogelijk zijn in XHTML 1.0 Transitional, en dat de site dan nog steeds valideert. We hebben het ook gedaan om je er van te overtuigen dat elke moeite die je neemt om rekening te houden met standaarden in je werk – zelfs een realistische aanpak die gebruik maakt van enkele compromissen en een klein beetje markup gebruikt dat visuele aspecten regelt – de moeite waard is.

Content markup: de tweede tabel

De "content" tabel komt direct na de eerste tabel en zou voor zich moeten spreken voor iedereen die ooit HTML of XHTML heeft geschreven. De twee dingen die je even goed moet bekijken zijn de compactheid van de markup en het gebruik van id:

<table id="content" summary="Main content." width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td width="200" id="sidebar" valign="top">
<img src="images/astro.jpg" width="200" height="200" border="0" alt="i3Forum. Breeding leadership." title="i3Forum. Breeding leadership." />
<h2>Subhead</h2>
<p>Text</p>
</td>
<td width="400" id="primarycontent">
<h1>Headline</h1>
<p>Copy.</p>
<p>Copy.</p>
<p>Copy.</p>
<p>Copy.</p>
<div id="footer">
<p>Copyright &copy; 2003 <a href="/" title="i3forum home page.">i3Forum</a>, Inc.</p>
</div>
</td>
</tr>
</table>
</body>

In hoofdstuk 9 gaan we verder met de basis van CSS. Daarna zullen we in hoofdstuk 10 CSS gebruiken om stijl en elegantie toe te voegen.

Dit hoofdstuk is geplaatst met toestemming van de Jeffrey Zeldman en New Riders Publishing en is een gedeelte uit “Designing with Web Standards”. All rights reserved.

• Home
• Artikelen
• Colofon