Inhoud

  1. Inleiding
  2. Geschiedenis
  3. web standaarden
  4. Structuur en presentatie
  5. (X)HTML
  6. CSS
  7. Toegankelijkheid
  8. URL's
  9. Referenties
  10. Verklarende woordenlijst
  11. Vertaling

1. Inleiding

Dit document legt uit hoe en waarom het gebruik van web standaarden er voor zorgt dat jij als developer geld en tijd bespaart én de bezoeker een betere ervaring levert. Ook worden er andere methodes, richtlijnen en raadgevingen besproken die helpen bij het maken van hoge kwaliteits websites. Sites die toegankelijk zijn voor zoveel mogelijk mensen.

2. Geschiedenis

Toen het internet en web bekender werden midden de jaren negentig, hadden de browsermakers CSS (Cascading Style Sheets) nog niet goed genoeg geïntegreerd om web ontwikkelaars de presentatie van een HTML document volledig door CSS te laten behandelen. Het gemis aan die integratie was te begrijpen, de specificatie voor CSS Level 1 werd gepubliceerd in 1996, die voor CSS Level 2 in 1998.

Het gebrek aan CSS ondersteuning in web browsers, in combinatie met de behoefte van grafische designers die gewend waren veel controle over hun drukwerk te hebben, zorgde er voor dat HTML misbruikt werd op iedere mogelijke manier om de presentatie te beïnvloeden. Een voorbeeld hiervan is het weglaten van de randen van een tabel door het attribuut border="0". Hierdoor kregen ontwikkelaars de mogelijkheid om een onzichtbaar rooster te maken waarmee een basislay-out gecreëerd werd. Een andere illustratie hiervan is het gebruik van transparante, en dus onzichtbare, spacer GIFs om de lay-out van een pagina te manipuleren.

Aangezien HTML nooit bedoeld was om de presentatie van een document te behandelen, werden hacks, ongeldige code en browser-specifieke elementen (tags) en attributen gebruikt. Validatie was een term waar weinigen van gehoord hadden, laat staan gebruikten. Aangezien de code hierdoor een soepje wordt, past de term “tag soup” perfect.

Telkens nieuwe versies gelanceerd werden van de web browsers, werd ook de CSS ondersteuning verbeterd en uitgebreid. Spijtig genoeg niet snel genoeg. Ondanks het feit dat browsermakers traag zijn in het implementeren van CSS, zijn we wel op een punt gekomen waarop bijna iedereen een browser gebruikt met relatief goede CSS ondersteuning zodat er geen enkele reden meer is HTML niet te gebruiken waarvoor het dient: de structuur van het document beschrijven, niet de presentatie. Daarvoor gebruiken we nu CSS dat specifiek daarvoor in het leven geroepen is.

3. web standaarden

Wat zijn web standaarden ?

web standaarden zijn technologieën, ontwikkeld door het W3C en andere instanties, om webinhoud te creëren en interpreteren. Deze technologieën zijn ontworpen om documenten in de toekomst bruikbaar te houden én toegankelijk te maken voor zoveel mogelijk mensen.

Structurele talen

Presentatie talen

Object Modellen

Scripting talen

Dit document focust op XHTML 1.0 Strict voor structuur, CSS Level 1 en 2 voor presentatie, en ECMAScript 262 voor scripting (hoewel er niet veel scripting voorbeelden zijn).

Als er gezegd wordt van een document dat het voldoet aan de web standaarden, dan betekent dit dat het document (behalve de bovenstaande technologieën):

Merk wel op dat “werkt in elke browser” niet betekent “in iedere browser gelijk uitziet”. Zorgen dat een document er identiek uitziet in verschillende browsers op verschillende platformen is zo goed als onmogelijk. Zelfs door enkel afbeeldingen te gebruiken, zal er niet voor zorgen dat een pagina er overal gelijk uitziet. Documenten op het internet worden opgehaald door een grote verscheidenheid aan browsers op verschillende besturingssystemen, met beeldschermen die verschillen in grote of kwaliteit – of zelfs zonder beeldscherm, door gebruikers die hun standaardinstellingen gewijzigd hebben, zoals de tekstgrootte. Door dit te aanvaarden, bespaar je jezelf veel frustratie. Iedereen die websites creëert moet begrijpen dat er beperkingen in acht genomen moeten worden, net zoals dat bij uitgevers van kranten of filmmakers zo is.

Waarom web standaarden gebruiken ?

Sommige web ontwikkelaars en designers hebben een onwil ten opzichte van het gebruik van web standaarden. Veel gehoorde argumenten zijn “het is te moeilijk”, “het werkt anders ook” of “de tools die ik gebruik schrijven ongeldige code”.

Het is gemakkelijk om emotioneel te reageren en weerstand te bieden om iets nieuws te leren, om vertrouwde – maar verouderde – technieken achter je te laten. Nochtans, als je logisch nadenkt zijn er genoeg voordelen bij het leren en gebruiken van web standaarden. Enkele voorbeelden:

web standaarden kunnen geld en tijd besparen voor website ontwikkelaars én een betere ervaring bieden aan de bezoekers van de site. Trouwens, web standaarden zijn de toekomst. Als je nog niet begonnen bent met het leren ervan, dan is’t nu hoog tijd om er mee te starten of je loopt het risico voorbij gelopen te worden.

Lees meer:

Validatie

Validatie is het controleproces om na te kijken of het document voldoet aan de regels van de taal gebruikt in het bestand. Je kan het vergelijken met het checken van de spelling en grammatica in een tekst.

Het is een belangrijk deel bij het ontwikkelen op het web. Veel fouten die moeilijk te vinden zijn, worden wel eens ontdekt tijdens het valideren. Zo’n fout kan even banaal zijn als een typfout, of even serieus als een element of attribuut dat op een ongeldige manier gebruikt wordt.

Spijtig genoeg zijn er nog veel mensen die hun bestanden niet valideren. Sommigen weten niet dat het bestaat, anderen vergeten het en dan zijn er nog diegenen die opzettelijk vermijden hun pagina’s te valideren. Deze situatie kan grotendeels toegeschreven worden aan browsermakers. De meeste browsers proberen de HTML zo goed als mogelijk te interpreteren door te gokken wat de auteurs bedoeling is, in plaats van een foutmelding te geven als de code niet correct is. Dit gedrag heeft er voor gezorgd dat slordige code zeer gewoon is vandaag. Het probleem bij zo’n code is dat het onvoorspelbare resultaten teweeg brengt en steunt op de foutverwerking van web browsers.

Er is geen enkele reden om je HTML en CSS niet te valideren. Integendeel, er zijn enkel voordelen.

Why we won’t help you is Mark Pilgrim’s goeie uitleg over de voordelen van validatie. Het artikel vertelt ook waarom het moeilijker kan zijn om hulp te krijgen van mensen op discussiefora en mailinglijsten als je je documenten nog niet hebt gevalideerd.

Heel wat HTML bewerkers zoals BBEdit en Homesite hebben ingebouwde validatie tools. Als je ontwikkelingssoftware deze niet heeft, dan kan je de online validatie services gebruiken van het W3C – die ook de best betrouwbare zijn:

Het begrijpen van de door de validators gegenereerde foutmeldingen kan soms lastig en netelig zijn. Een vroege fout kan resulteren in een resem bijkomende fouten. Door het fixen van de eerste fouten en het hervalideren kan je het foutenpercentage soms naar beneden halen. Enkele veelvoorkomende foutboodschappen worden uitgelegd in Common XHTML Validation Errors op Black Widow Web Design.

Het is altijd een goed idee er voor te zorgen dat je code volledig valid is, maar er zijn enkele gelegenheden waar validatie fouten onvermijdbaar zijn. Het beste voorbeeld hiervan is het inbedden van Flash, of andere inhoud die een plug-in nodig heeft, in een document. Meer over de problemen met Flash in Flash Satay: Embedding Flash While Supporting Standards, en Embedding flash without <embed>.

4. Structuur en presentatie

Iets wat veel vermeld wordt bij het bespreken van web standaarden, is het belang van het scheiden van structuur en presentatie. Het begrijpen van het verschil tussen structuur en presentatie kan moeilijk zijn in’t begin, vooral als je gewend bent niet te denken aan de semantische structuur van een document. Het is nochtans heel belangrijk om dit te begrijpen aangezien het behandelen van de presentatie van een document door middel van CSS veel gemakkelijker wordt als structuur en presentatie gescheiden zijn.

Structuur bestaat uit de verplichte delen van een document, plus de semantische en gestructureerde opmaak van de inhoud van het document.

Presentatie is de opmaak en stijl die je geeft aan de inhoud. In de meeste gevallen houdt dit in hoe het document er uitziet, maar het beinvloedt ook de manier waarop een document klinkt – niet iedereen gebruikt een grafische web browser.

Probeer zo veel mogelijk de presentatie van de structuur te scheiden. In ideale omstandigheden zou je een HTML document moeten hebben dat de structuur en de inhoud bevat, en een CSS document dat alle opmaak behandelt.

De scheiding van structuur en presentatie is jammer genoeg nog niet doorgedrongen tot het web van vandaag. Op de meeste websites mist de HTML zowel structuur als semantiek.

Tabellen voor lay-out

Als je structuur van presentatie wil scheiden, moet je CSS gebruiken in plaats van tabellen voor de opmaak van het document. Misschien ben je’t gewend om tabellen voor lay-out te gebruiken en schrikt dit wat af, maar het is niet zo moeilijk als je zou denken. Er is een overvloed aan informatie te vinden op het web en de voordelen zijn zo talrijk dat het zeker de moeite waard is wat tijd te investeren in een andere manier van denken.

Lees meer:

Semantische HTML

Een ander belangrijk onderdeel bij het scheiden van structuur en presentatie is het gebruik van semantische opmaak voor de inhoud van het document. Als er een XHTML element bestaat dat een structurele betekenis heeft voor het stuk inhoud dat opgemaakt wordt, dan is er geen reden om er iets anders voor te gebruiken. Anders gezegd, gebruik geen CSS om een HTML er te laten uitzien als een ander HTML element, bijvoorbeeld het gebruik van een <span> element in plaats van een <h1> voor een kop.

Door het gebruik van semantische HTML zorg je dat verschillende delen van een document een betekenis hebben voor gelijk welke web browser, van de nieuwste grafische web browser op een moderne PC, tot een oude browser die CSS niet weergeeft, of een text-gebaseerde browser op een Unix-machine.

Koppen

Om koppen op te maken gebruik je <h1>, <h2>, <h3>, <h4>, <h5> of <h6> naar gelang de graad van de kop. <h1> is de belangrijkste in de hiërarchie.

Voorbeelden:
<h1>Document heading</h1>
<h2>Sub heading</h2>

Document heading

Sub heading

Paragrafen

Voor paragrafen dient het <p> element. Gebruik geen <br /> element om ruimte tussen paragrafen te creëren. Marges worden behandeld door CSS en vragen om een correcte opmaak.

Voorbeeld:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

Lijsten

Een lijst van onderwerpen moet opgemaakt worden als ... een lijst. De XHTML definities bevatten drie soorten lijsten: ongeordende lijsten, geordende lijsten, en definitie lijsten.

Ongeordende lijsten, ook bekend als “bullet lists”, beginnen met <ul> en eindigen met </ul>. Iedere element in de lijst is een <li> element.

Geordende lijsten beginnen met <ol> en eindigen met </ol>.

Definitie lijsten zijn anders, deze worden gebruikt om een lijst met termen en beschrijvingen op te maken. Een definitie lijst begint met <dl> en eindigt met </dl>. Elke term die beschreven wordt, moet in een <dt> element. De beschrijving zelf in een <dd> element.

Voorbeelden:
<ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
</ul>
<ol>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
</ol>
  1. Item 1
  2. Item 2
  3. Item 3
<dl>
    <dt>website</dt>
    <dd>A collection of linked web pages that represent a company
    or an individual.</dd>
    <dt>web page</dt>
    <dd>The basic unit of information on the Web, containing text,
    graphics and other media.</dd>
</dl>
website
A collection of linked web pages that represent a company or an individual.
web page
The basic unit of information on the Web, containing text, graphics and other media.

CSS maakt het mogelijk om lijsten te gebruiken, zelfs al wil je niet dat ze er uitzien als traditionele lijstjes. Een navigatiebalk, die een lijst met links is, is hier een goed voorbeeld van. Het voordeel bij het gebruik van een lijst voor het menu, is dat het menu ook steek houdt in een browser die geen CSS ondersteunt.

Citaten

Het <q> element moet worden gebruikt voor korte, inline citaten. Web browsers worden verondersteld van automatisch aanhalingstekens voor en na het citaat te plaatsen. Jammer genoeg doet Internet Explorer dit niet, en in sommige gevallen kan het zelfs leiden tot toegankelijkheidsproblemen. Hierdoor raden sommigen het gebruik van het <q> element af en stellen voor om de aanhalingstekens manueel te zetten. Citaten in een <span> element met een CSS-klasse schrijven werkt wel, maar het heeft geen semantische betekenis. Voor een overzicht van de problemen die het <q> element met zich meebrengt, kan je Mark Pilgrim’s The Q Tag lezen.

Voor langere citaten die meer dan één paragraaf lang zijn, wordt het <blockquote> element gebruikt. Door middel van CSS kan het citaat perfect gestyled worden. Merk wel op dat tekst niet rechtstreeks in een <blockquote> element mag, het moet al in een ander element zitten, meestal is dat <p>.

Het cite attribuut kan gebruikt worden bij zowel <q> als <blockquote> om de bron-URL van het citaat te vermelden. Als je <span> gebruikt in plaats van <q> kan je het cite attribuut uiteraard niet gebruiken.

Voorbeelden:
<p>The W3C says that <q cite="http://www.w3.org/TR/REC-html40/
struct/text.html#h-9.2.1">The presentation of phrase elements
depends on the user agent.</q>.</p>

The W3C says that The presentation of phrase elements depends on the user agent..

<p>The W3C says that <span class="quote">&rdquo;The presentation of
phrase elements depends on the user agent.&rdquo;</span>.</p>

The W3C says that “The presentation of phrase elements depends on the user agent.”.

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">
    <p>&rdquo;The following sections discuss issues surrounding
    the structuring of text. Elements that present text (alignment
    elements, font elements, style sheets, etc.) are discussed
    elsewhere in the specification. For information about characters,
    please consult the section on the document character set.&rdquo;</p>
</blockquote>

“The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.”

Nadruk

<em> wordt gebruikt voor nadruk, <strong> voor sterke nadruk. De meeste browsers tonen benadrukte tekst in cursief, sterk benadrukte tekst in vet. Dit is nochtans niet verplicht dus kan je met CSS zelf bepalen hoe benadrukte tekst getoond wordt. Vermijd wel het gebruik van <em> en <strong> louter voor visuele effecten.

Voorbeeld:
<p><em>Emphasized</em> text is normally displayed in italics,
while <strong>strongly emphasized</strong> text is usually
displayed in bold.</p>

Benadrukte tekst wordt normaal getoond in cursief, sterk benadrukte tekst is vet.

Tabellen

XHTML tabellen mogen niet gebruikt worden voor layout. Voor data daarentegen wél. Om data tabellen zo toegankelijk mogelijk te maken, is het belangrijk om alle componenten te kennen die een tabel opmaken. Enkele voorbeelden zijn tabel koppen (<th>), samenvattingen (het summary attribuut) en bijschriften (het <caption> element).

Voorbeeld:
<table class="example" summary="This table shows the annual population
increase in Sweden during the years 1999 to 2003.">
    <caption>Annual population increase in Sweden, 1999 - 2003</caption>
    <thead>
        <tr>
            <td> </td>
            <th scope="col">1999</th>
            <th scope="col">2000</th>
            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th>Population</th>
            <td scope="row">8 861 426</td>
            <td scope="row">8 882 792</td>
            <td scope="row">8 909 128</td>
            <td scope="row">8 940 788</td>
            <td scope="row">8 975 670</td>
        </tr>
        <tr>
            <th>Increase</th>
            <td scope="row">7 104</td>
            <td scope="row">21 366</td>
            <td scope="row">26 368</td>
            <td scope="row">31 884</td>
            <td scope="row">34 882</td>
        </tr>
    </tbody>
</table>
Annual population increase in Sweden, 1999–2003
  1999 2000 2001 2002 2003
Population 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Increase 7 104 21 366 26 368 31 884 34 882

Voor een meer gedetailleerde beschrijving van tabellen en het gebruik er van, kijk je best naar Tables in HTML documents en HTML Techniques for Web Content Accessibility Guidelines 1.0.

Lees meer:

5. (X)HTML

Hoewel het mogelijk is om met HTML 4.01 moderne, gestructureerde en standards compliant (aan de standaarden voldoend) websites te maken, raad ik de overstap aan naar XHTML 1.0 Strict. Dit zorgt er voor meteen al nette, semantische code te schrijven en zo beter voorbereid te zijn op de overgang naar XML en andere toekomstige opmaaktalen. XHTML 1.0 Strict wordt gebruikt in de voorbeelden in dit document.

XHTML 1.0 is een herformulering van HTML 4 naar XML 1.0 en is ontwikkeld ter vervanging van HTML. XHTML 1.0 Strict, wat ik aanraad om te gebruiken, laat geen presentatie opmaak toe (net als HTML 4.01 Strict, maar hier focussen we op XHTML). Hierdoor dwingt XHTML 1.0 Strict ons tot een strikte scheiding van structuur en presentatie.

XHTML 1.1, de laatste versie van XHTML, is technisch gezien iets gecompliceerder om te gebruiken. De specificatie stelt dat XHTML 1.1 documenten moeten application/xhtml+xml als MIME type hebben en niet mogen gebracht worden als text/html. Het is niet strikt verboden om text/html te gebruiken, maar het is niet aangeraden. XHTML 1.0 daarentegen dat application/xhtml+xml zou moeten gebruiken, mag ook het MIME type text/html gebruiken, als het HTML compatibel is. De W3C Nota XHTML Media Types bevat een overzicht van MIME types die aangeraden worden door het W3C.

Jammer genoeg herkennen sommige oudere browsers, en Internet Explorer, het MIME type application/xhtml+xml niet en tonen daardoor de code van het document, of zelfs helemaal niets.

Als je per se application/xhtml+xml wil gebruiken, dat moet je de server laten checken of de vragende browser het MIME type kan behandelen, als de browser dat niet kan, schakelt de server over naar text/html.

Als je PHP gebruikt voor server side scripting, dan kan het volgende “content negotiation” script gebruikt worden om documenten met verschillende MIME types naar verschillende browsers te sturen:

<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
    header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
    header("Vary: Accept");
    echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
    }
else {
    header("Content-Type: text/html; charset=iso-8859-1");
    header("Vary: Accept");
    }
?>

Het script kijkt na of de user agent een “Accept http header” verstuurt die de waarde “application/xhtml/xml” bevat, of het de W3C HTML Validator is die geen echt “Accept http header” verstuurt maar nog application/xhtml+xml gebruikt. Als één van die twee voorwaarden waar is, dan wordt het document als application/xhtml+xml verstuurd. Deze browsers krijgen ook een XML declaratie meegestuurd. Aan andere browsers, waaronder alle versies van Internet Explorer, wordt het document getoond als text/html. Er wordt geen XML declaratie toegevoegd aan het document, want dat dwingt IE/Win in Quirks mode, dat willen we niet.

Na de Content-Type header wordt een “Vary header” verstuurd om tussenliggende caches, zoals Proxy servers, te zeggen dat het content type van het document varieert naar gelang de mogelijkheden van de client die het document opvraagt.

Voor een meer geavanceerd PHP content negotiation script kijk je best in de richting van Serving up XHTML with the correct MIME type. Dit script neemt de rating (hoe goed het claimt een bepaald MIME type te verwerken) van de vragende user agent en converteert XHTML naar HTML 4 vooraleer het document te versturen als text/html naar de user agents die application/xhtml+xml niet ondersteunen.

Hier is een gelijkaardig script voor wie ASP en VBScript gebruikt:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
    Response.ContentType = "application/xhtml+xml"
    Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
    Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Merk wel op dat als het MIME type application/xhtml+xml is, sommige browsers zoals Mozilla het document niet zullen tonen als het fouten bevat. Dit kan goed zijn tijdens het ontwikkelen van de site, maar problemen geven eens de site online gaat en wordt geüpdatet door niet-XHTML experten, tenzij je zelf kan garanderen dat de code geldig (valid) blijft.

Hier is een lijst van dingen die belangrijk zijn om weten bij het gebruik van XHTML 1.0 Strict in plaats van HTML:

Lees meer:

Doctype

Vandaag de dag hebben weinig HTML documenten een correct en volledig doctype of DTD (Document Type Declaration). Ooit was het decoratiever dan het functioneel was, maar sinds enkele jaren kan de aanwezigheid van een doctype de rendering van een document in een browser sterk beïnvloeden.

Alle HTML en XHTML documenten moeten een doctype declaratie hebben om geldig of valid te zijn. Het doctype vermeldt welke versie van HTML of XHTML gebruikt wordt in het document, en wordt ook gebruikt door de validator en de browsers om na te gaan in welke modes er gerenderd moet worden. Als een correct en volledig doctype aanwezig is in een document, dan schakelen veel browsers over naar “standards mode” wat betekent dat ze de CSS specificatie nadrukkelijker volgen. Het document wordt ook vlugger getoond omdat de browser geen foute HTML hoeft te interpreteren. Ook zorgt dit voor kleinere verschillen bij het renderen in diverse browers.

Het volgende doctype geeft aan dat het document XHTML 1.0 Strict is, en zorgt dat web browsers met “doctype switching” hun “standards mode” gebruiken.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Lees meer:

Character encoding

Alle XHTML documenten moeten hun “character encoding” specificeren.

De beste manier om “character encoding” in te stellen, is door de web server te configureren zodat die een http content-type header verstuurd met de “character encoding”. Voor gedetailleerde informatie hierover kijk je best de documentatie van je web server software na.

Als je Apache gebruikt, kan je de “character encoding” instellen door enkele regels toe te voegen aan je .htaccess bestand. Als al je bestanden bijvoorbeeld utf-8 zijn, dan kan je dit toevoegen:

AddDefaultCharset utf-8

Om een specifieke “character encoding” in te stellen voor bestanden met een bepaalde extensie, dan werkt dit:

AddCharset utf-8 .html

Als je server je toelaat om PHP scripts te draaien, dan kan je het volgende script gebruiken:

<?php
    header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

Om je pagina’s te laten behandelen als HTML, verander application/xhtml+xml naar text/html. Als je, om gelijk welke reden, je web server niet kan configureren om de “character encoding” in te stellen, dan gebruik je gewoon een <meta> element in de <head> van het document. Het is best van dit zo te doen, zelfs al is je server correct geconfigureerd.

Het volgende <meta> element zegt aan de browser dat het document een ISO-8859-1 character encoding gebruikt:

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />
Lees meer:

6. CSS

Terwijl CSS vroeger meestal enkel gebruikt werd om de eigenschappen van de lettertypes in te stellen, kan het nu gebruikt worden om de volledige lay-out van een document op te maken. Om dit efficiënt te doen is wel een andere aanpak nodig dan wanneer tabellen gebruikt worden voor lay-out.

Gestructureerde en semantische XHTML is nodig voor CSS om in staat te zijn de lay-out op een treffelijke manier te controleren.

Browser ondersteuning

Zoals al eerder gezegd is de ondersteuning voor CSS er sterk op vooruit gegaan in de laatste jaren. Spijtig genoeg zijn niet alle browser makers geïnteresseerd in de implementatie van open standaarden, de graad van ondersteuning is dus afhankelijk van browser tot browser. Daarbovenop komen nog eens software bugs die zorgen dat browsers soms anders reageren dan ze verondersteld zijn te doen.

Op moment van schrijven (2004) zijn de browsers met beste CSS ondersteuning Mozilla (en andere browsers gebaseerd op Gecko: Firefox, Camino, Netscape 6+), Opera en Safari (en andere browsers gebaseerd op WebCore: Omniweb 4.5 en later). Internet Explorer 6/Win zit niet op dezelfde hoogte qua CSS support, maar het laat je wel toe de meeste basis dingen te doen. Internet Explorer 5/Mac heeft zeer goeie ondersteuning voor CSS 1, maar het ondersteunt weinig van CSS 2. IE 5.* voor Windows ondersteunt redelijk veel, maar het heeft wat problemen waar je beter van op de hoogte bent. Eerdere versies van Internet Explorer hebben bijna geen ondersteuning. Hetzelfde geldt voor Netscape versies vóór versie 6.

Omdat de meerderheid van de surfers tegenwoordig Internet Explorer voor Windows gebruikt, moet je die browser vaak het laatste woord geven. Dit betekent niet dat je de mogelijkheden van browsers met betere CSS ondersteuning niet mag gebruiken om je design daar beter te maken.

Niet alle huidig gebruikte browsers hebben een adequate ondersteuning van CSS om een pagina, die volledig steunt op CSS voor een grafisch aantrekkelijke lay-out, netjes te renderen. Gelukkig is het aantal gebruikers van deze oude browsers heel laag.

Het is belangrijk te weten dat deze mensen niet uitgesloten worden. In de jaren negentig werden browser check scripts gebruikt die een populaire manier waren om iedereen met een “verkeerde” browser (meestal alles behalve Internet Explorer voor Windows) naar een andere pagina te sturen. Op die pagina bevond zich dan meestal een melding om up te graden naar een andere of nieuwere browser om de site te kunnen betreden.

Vandaag kan je beter omgaan met browsers met slechte ondersteuning. Een groot voordeel van het gebruik van logisch en semantische XHTML is dat het er voor zorgt dat documenten toegankelijk en bruikbaar zijn, ook zonder CSS. De presentatie — de manier waarop het document er uit ziet — is niet identiek aan die van een ondersteunde browser, maar de inhoud is er wel. In de meeste gevallen is de inhoud van een site belangrijkst voor een bezoeker, dan de manier waarop die weergegeven wordt. Daarom is het beter een ongestijlde pagina te tonen aan die browsers, dan de gebruikers helemaal uit te sluiten.

Er zijn verschillende manieren om dit te doen. Een van de meest voorkomende manieren is het gebruik van @import om het CSS bestand te linken. Netscape 4 en oudere browsers begrijpen de @import regel niet en zullen het CSS bestand niet tonen. Er zijn tal van manieren om CSS te verbergen van web browsers. Die methodes hebben meestal met elkaar gemeen dat ze misbruik maken van software bugs bij de browser’s interpretatie van de CSS code. Er is dus altijd een risico dat een browser update de bug repareert, maar het CSS probleem dat de reden voor het verbergen is, niet repareert. Het is dus beter van weinig CSS hacks te gebruiken.

Uiteraard kan via server side technologie een browser check gedaan worden om zo verschillende (of zelfs geen) CSS bestanden naar diverse browsers te sturen. Als je dit doet moet je wel opletten dat je het detectie script goed onderhoudt om zo te vermijden dat verkeerde CSS bestanden worden verstuurd eens een browser geüpdatet wordt of een nieuwe versie gelanceerd is.

Lees meer:

Verschillende manieren om CSS toe te passen

Er zijn verschillende manieren om CSS toe te passen op elementen in een HTML document.

Extern

CSS regels in één of meerdere afzonderlijke bestanden schrijven, heeft meerdere voordelen. De HTML documenten worden kleiner, CSS bestanden worden opgeslaan in de cache van de browser en moeten slechts één keer worden gedownload, en je hoeft slechts één bestand aan te passen om de presentatie van een volledige site aan te passen. Een extern CSS bestand kan er als volgt uitzien:

h1 {
    font-weight:bold;
}

Merk op dat er geen <style> element is in een extern CSS bestand.

Je kan ook een CSS bestand linken aan een HTML document door het gebruik van het <link> element:

<link rel="stylesheet" type="text/css" href="styles.css" />

Of door het gebruik van de @import regel in een <style> element:

<style type="text/css">
@import url("styles.css");
</style>

Inline

Met het attribuut style kan je CSS onmiddellijk toepassen op HTML elementen:

<h1 style="font-weight:bold;">Rubrik</h1>

Dit moet wel vermeden worden omdat het een mix oplevert van structuur en presentatie.

Internal

Interne CSS wordt geplaatst binnen <style> element dat op zich weer geplaatst wordt in de <head> van het document:

<style type="text/css">
h1 {
    font-weight:bold;
}
</style>

Dit wordt ook beter vermeden aangezien je best HTML en CSS in verschillende bestanden gescheiden houdt.

Lees meer:

CSS Syntax

Een CSS regel bestaat uit een selector en een of meerdere declaraties. De selector bepaalt op welk HTML element of elementen de regel van toepassing is. Iedere declaratie bestaat uit een eigenschap en een waarde. Het declaratie blok is omgeven door { } en iedere declaratie eindigt met een ; (puntkomma).

Een simpele CSS regel ziet er zo uit:

p {
    color:#0f0;
    font-weight:bold;
}

In dit geval is p de selector wat betekent dat de regel alle <p> elementen in het HTML document zal manipuleren. De regel heeft twee declaraties die er samen voor zorgen dat alle tekst die in <p> elementen staat, groen en vet getoond wordt.

Voor meer gedetailleerde beschrijvingen van CSS regels, zie CSS Beginner’s Guide, CSS from the Ground Up of een CSS boek.

Lees meer:

Overtollige elementen en klasses

Als je begint met CSS, maak je meestal de fout om veel onnodige XHTML elementen, overtollige klasses en extra <div> elementen te gebruiken. Dit betekent niet noodzakelijk dat je code ongeldig (invalid) is, maar het gaat in tegen de redenen van het scheiden van structuur en presentatie: simpelere en nettere code.

Een voorbeeld van gebruik van onnodige XHTML elementen:

<h3><em>Headline</em></h3>

Als je een kop cursief wil maken, dan gebruik je CSS om het <h3> element te herstylen:

h3 {
    font-style:italic;
}

Overdadig gebruik van klasses kan er zo uitzien:

<div id="main">
    <div class="maincontent">
        <p class="maincontenttext">
            Lorem ipsum dolor
        </p>
    </div>
</div>

Nochtans voldoet dit:

<div id="main">
    <div>
        <p>
            Lorem ipsum dolor
        </p>
    </div>
</div>

Om de elementen in div#main te controleren kan je gebruik maken van contextuele selectors in de CSS code:

div#main p {
    /* rules */
}

In de meeste gevallen kan CSS gebruikt worden om logische XHTML vorm te geven zoals je wil, zonder extra code te gebruiken. Dit betekent natuurlijk niet dat er geen gevallen zijn waar extra code de moeite waard is.

CSS tips

Eens je serieus begint met CSS, zal je natuurlijk vlug geconfronteerd worden met problemen van allerlei slag. Sommige problemen kunnen voortkomen uit misverstanden, andere dan weer uit onduidelijke specificaties of browsers vol bugs. De CSS Crib Sheet is een samenvatting met goed advies, samengesteld door Dave Shea. Hier zijn enkele van de belangrijkste tips, plus tips die niet in de Crib Sheet zijn vermeld:

CSS Layouts

Er zijn veel voorbeelden en stap-voor-stap handleidingen voor het gebruik van CSS bij het maken van een lay-out. Een goeie tip: begin met een simpele lay-out, leer hoe alles werkt en schuif zo door naar meer geavanceerde en complexere structuren.

Lees meer:

7. Toegankelijkheid

Toegankelijkheid is niet enkel mindervalide gebruikers helpen, zelfs al is dat één van de meest belangrijke redenen om een website toegankelijk te maken. Een toegankelijke site werkt beter voor iedereen, mindervalide of niet. Zo’n site kan bezocht worden door meer mensen met meer soorten browsers of browsing apparaten.

Een veelvoorkomende verkeerde opvatting is dat een website er minder aantrekkelijk zal uitzien als hij toegankelijk is, in vergelijking met een niet toegankelijke site. Dit is niet het geval. Toegankelijkheid hoeft geen invloed te hebben op de presentatie.

Even een voorbeeld hoe toegankelijkheid voor iedereen kan helpen: een website heeft een formulier waar bezoekers kunnen registreren voor een congres. In het formulier kan je kiezen waar je het congres wil bijwonen, er is keuze uit drie steden. Iedere stadsnaam staat naast een radio button. Als de maker van het formulier geen toegankelijkheid in gedachten had, dan zou iedereen op het bolletje van de radio button moeten klikken om een selectie te maken. Als de ontwikkelaar wel iets over toegankelijkheid weet en de labels naast de buttons had opgemaakt met een <label> element, dan kan de bezoeker ook gewoon op de stadsnaam klikken. Welke manier is simpeler voor iedereen die het formulier gebruikt?

Door het gebruiken van semantische en goed gestructureerde XHTML kom je gaandeweg uit op een toegankelijke website. Om een idee te krijgen hoe toegankelijk een document is, moet je eens proberen het te bekijken in een tekst-gebaseerde browser zoals Lynx om te zien of de inhoud er zinnig uitziet. Het is lang niet de enige stap die je moet ondernemen om een toegankelijke site te maken, maar ’t is een begin.

Frames

Veel “web designers” houden ervan frames te gebruiken om het browser venster in verschillende delen te verdelen, delen die elk een afzonderlijke HTML pagina bevatten. Dit kan handig zijn voor Intranet applicaties en dergelijke. Op een publieke website, daarentegen, zijn er heel wat bezwaren tegen het gebruik van frames:

Bovendien maak je het ook moeilijker voor jezelf, frames maken een website technisch gezien complexer.

Tabellen

Veel mensen interpreteren “gebruik geen tabellen voor layout” als “gebruik geen tabellen”, dit is natuurlijk niet zo. Als je tabellarische data hebt, dan moet die ook in een tabel. Het is wel belangrijk te weten dat er veel manieren zijn om tabellen logischer en toegankelijker te maken.

Lees meer:

Formulieren

Formulieren zijn vaak onnodig moeilijk te gebruiken, meestal omdat ze gemaakt zijn op een onlogische manier, deels omdat de onderliggende code niet de elementen gebruikt om ze toegankelijker en makkelijker te maken. De elementen <label>, <fieldset> en <legend> bestaan en zijn bedoeld gebruikt te worden.

Veelgestelde vraag is dan wat best gebruikt wordt om een formulier te lay-outen. De ene beweert dat een formulier tabellarische data is en dus in een tabel mag, anderen zeggen dan weer dat CSS moet gebruikt worden. Gebruik één van deze manieren, maar als je een tabel gebruikt, zorg dat ze steek houdt en toegankelijk is.

Lees meer:

JavaScript en cookies

Vermijd afhankelijk te zijn van JavaScript. Meer mensen dan je zou denken, zetten JavaScript uit in hun browser: uit veiligheidsoverwegingen of om pop-up vensters te vermijden. Bezoekers kunnen ook browsers gebruiken die simpelweg geen JavaScript ondersteunen. Volgens TheCounter.com heeft 6% van de web gebruikers geen JavaScript, W3Schools.com meldt 8%.

In de meeste gevallen waar JavaScript gebruikt wordt, levert het geen voordelen voor de bezoeker. Er zijn uiteraard voorbeelden waar het kan bijdragen tot een betere surf-ervaring, zoals bij het valideren van formulierinhoud.

Dit alles betekent niet dat je geen JavaScript meer moet gebruiken, maar er moet wel vermeden worden dat een site afhankelijk is van JavaScript om te werken.

Hetzelfde geldt voor cookies. Gebruik geen cookies op een wijze die ervoor zorgt dat een site niet meer werkt als de gebruiker de cookies niet accepteert.

8. URL's

Deze sectie gaat niet echt over web standaarden en toegankelijkheid, maar het wordt vermeld omdat de manier waarop een URL opgebouwd is, invloed kan hebben op hoe goed een site scoort in zoekmachines, en hoe gebruiksvriendelijk het is voor de bezoekers.

Sommige zoekmachines volgen geen links naar URL’s die eindigen met een query string. Dit soort URL is heel gewoon op websites die hun inhoud dynamisch uit databases halen, en kan er zo uitzien:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

De simpelste manier om een URL te vormen die beter is voor zowel zoekmachines als mensen, is door die te veranderen zodat het er uitziet alsof er verwezen wordt naar een map, een directory. Het bovenstaande voorbeeld ziet er dan zo uit:

http://yourdomain.com/products/item/34627393474632/id/4344/

De web server interpreteert de nieuwe URL en converteert die intern terug naar de originele URL, met query string dus. Op het einde van deze sectie zijn enkele links te vinden waar meer informatie kan gevonden worden over hoe dit werkt.

Een nog betere, soms wel wat gecompliceerde, manier om de URL’s te veranderen is door ze helemaal te herschrijven tot iets menselijks:

http://yourdomain.com/products/flowers/tulips/

De voordelen van dit soort URL’s zijn talrijk: zoekmachines zullen de site beter en hoger indexeren, het wordt mensen gemakkelijker gemaakt om de URL te lezen, en je vermijdt te onthullen welke server technologie je gebruikt. Omdat de URL’s ook geen serverspecifieke extensie hebben, zoals .asp, .cf, .cgi or .jsp, wordt het ook gemakkelijker om in de toekomst te veranderen van gebruikte technologie op de server, mocht dat ooit nodig zijn.

Als je query strings gebruikt in URL’s, is het belangrijk om de ampersands (&) te om te zetten tot hun HTML entiteit: &amp;. Als je dat niet doet, zullen sommigen browsers de ampersand zien als het begin van een HTML entiteit, en als de tekst volgend op de ampersand gelijk is aan een HTML entiteit, dan zal de browser de URL converteren en dus de link breken.

Tot slot de vermelding dat voor de meeste websites het gebruik van een www subdomein onnodig is. http://yourdomain.com/ zou moeten gebruikt worden in plaats van http://www.yourdomain.com/. Meer info hierover op no-www.org. Of je nu het www subdomein gebruikt of niet, het is een goed idee je web server zo te configureren dat alle verkeer op http://yourdomain.com/ en http://www.yourdomain.com/ op dezelfde URI terecht komen.

Lees meer:

9. Referenties

Een selectie van aangeraden boeken, websites en mailing lijsten.

Boeken

CSS

Web ontwikkeling

HTML

Toegankelijkheid

web standaarden

XHTML

10. Glossary

Accessibility/Toegankelijkheid
Een toegankelijke site is toegankelijk voor iedereen, wat ook de hardware of software is die de gebruiker heeft, en wat de gebruiker ook gebruikt om te navigeren op de site.
CSS (Cascading Style Sheets)
Regels die beschrijven hoe een document moet gepresenteerd worden.
HTML (HyperText Markup Language)
Gebruikt om de structuur van een document op te maken.
Presentation/Presentatie
Hoe een website er uitziet (of klinkt).
Structure/Structuur
De verplichte delen van een document plus de logische opmaak van de inhoud in het document.
Markup/Opmaak
On the web, HTML and XHTML is used for markup. Door een document op te maken geef je het structuur en betekenis. Op het web worden HTML en XHTML gebruikt voor opmaak/code.
Validatie
Validatie is het controleproces om na te kijken of het document voldoet aan de regels van de taal gebruikt in het bestand. Je kan het vergelijken met het checken van de spelling en grammatica in een tekst.
W3C (World Wide Web Consortium)
Officiële instantie die de specificaties en richtlijnen ontwikkelt voor het Web.
Web standards/web standaarden
web standaarden zijn technologieën, ontwikkeld door het W3C en andere instanties, om webinhoud te creëren en interpreteren. Deze technologieën zijn ontworpen om documenten in de toekomst bruikbaar te houden én toegankelijk te maken voor zoveel mogelijk mensen.
XHTML (Extensible HyperText Markup Language)
HTML herformulatie om de regels van XML te volgen.
XML (Extensible Markup Language)
Een opmaaktaal die op HTML lijkt, maar de auteur toelaat de data te beschrijven door zelf gepaste elementen te definiëren.

11. Vertaling

Vertaling
Fabian Deceuninck
Nagelezen door
Gerty Engrie, Pieter Hoste