In zijn artikel The Meaning of Web Standards geeft Derek Featherstone aan dat sommige mensen een verkeerd beeld hebben van het begrip “webstandaarden”. Veel mensen, zowel projectleiders als ontwikkelaars, verwachten bij de term web standaarden meetbare regels (measurable rules or qualities that can be held up as a comparison). Derek definieert webstandaarden daarentegen als een strategie (een overall strategy for development).

Het is dus lastig te bepalen wanneer een website werkelijk aan webstandaarden voldoet. Natuurlijk kun je de HTML van een pagina valideren. Maar helaas kun je heel goed een validerende pagina bouwen die niet toegankelijk of semantisch is. Nog regelmatig kom ik HTML tegen die heel stoer “XHTML” of “tableless” genoemd wordt, maar bij nadere inspectie uit louter DIV’s en SPAN’s bestaat. Valideert de pagina? Ja, hij valideert. Voldoet hij aan webstandaarden? Nee, absoluut niet.

Maar kun je HTML dan valideren op semantiek? Hoe kun je bepalen of iets betekenis heeft of niet? Waarom zou een bepaalde regel tekst niet in een SPAN, maar in een H2-element geplaatst moeten worden? En waarom in een H2 en niet in een H3?

Op dit soort vragen is natuurlijk geen eenduidig antwoord te geven. Veel hangt of van de context van de HTML en van het grafisch ontwerp dat je moet implementeren. Toch denk ik dat het mogelijk is om een aantal richtlijnen op te stellen aan de hand waarvan je kunt bepalen of jouw HTML semantisch is of niet.

Richtlijnen voor validatie van semantische HTML

1. Gebruik tabellen alleen voor data en niet voor opmaak.
2. Gebruik voor een titel een header-element (H1 tot en met H6).
3. Een zin op één regel is vaak een (verkapte) titel. Gebruik hiervoor geen STRONG of SPAN gevolgd door een BR, maar een header-element.
4. Gebruik het H1-element maar één keer.
5. Gebruik altijd eerst een lager header-element (bijvoorbeeld H3), voordat je een hoger header-element (bijvoorbeeld H4) inzet.
6. Denk na voordat je een BR gebruikt. Wanneer je een aantal keer achter elkaar een tekstje hebt, gevolgd door een BR, praat je waarschijnlijk over een list en kun je beter een UL gebruiken. Dit geldt ook voor linklijsten.
7. Denk na voordat je een DIV inzet. Bij geneste DIV’s moeten alarmbellen gaan rinkelen. Het riekt naar div-itis.
8. Images die niets toevoegen aan de inhoud, maar gebruikt worden voor de opmaak, kunnen beter in een CSS-file geplaatst worden.
9. Plaats een citaat in een Q, CITE of een BLOCKQUOTE.
10. Gebruik in een FORM-element geen P of DIV om de pagina te laten valideren, maar FIELDSET om samenhangende onderdelen van een formulier te groeperen.
11. Voor adressen, handtekeningen en dergelijke bestaat het ADDRESS-element.

Opmerkingen:

• Voor de hand liggende regels als “Plaats een paragraaf in een P” heb ik buiten beschouwing gelaten. Shirley Kaiser somt ze op in haar verhelderende artikel Semantics, HTML, XHTML, and Structure.
• In de bovenstaande richtlijnen heb ik de HTML-elementen voor de duidelijkheid in hoofdletters opgenomen. XHTML vereist echter dat de HTML-elementen lowercase zijn.
• Het is lang niet altijd mogelijk om DIV’s niet te nesten (punt 7.). In een ontwerp als het volgende ontkom je er waarschijnlijk niet aan:
  

Enkele interessante links:

• The Meaning of Semantics
• The Meaning of Web Standards
• Developing With Web Standards - Recommendations and best practices
• What is a “web standard”?
• Semantics, HTML, XHTML, and Structure
• Simplequiz - een archief aan discussies over kleine HTML-vraagstukken

Ik benieuwd naar andere tips en ervaringen!

Dit bericht was geplaatst door Tom op Thursday 15 September 2005 om 15:00 uur en is gearchiveerd onder webstandaarden. Je kan de reacties hierop volgen via de RSS 2.0 feed. Je kan een bericht achterlaten, maar pingen en trackback is niet mogelijk.