(Open web)standaarden zijn heilig en de validator ook

Deze maand een gastbijdrage van Ruud Steltenpool. Validator Fanboy noemt hij zichzelf. En niet onterecht. Hij wist ons te wijzen op het feit dat bij de laatste Dutch Bloggies het gros van de genomineerden flink wat HTML fouten in de code hebben staan. En dat terwijl toegankelijkheid juist een belangrijker onderdeel wordt op internet. Daarom deze maand een uiteenzetting van het hoe en waarom van webstandaarden en hoe je een validator kunt gebruiken. Ruud schrijft zelf op Twente Open Source & Standaarden, en is beheerder van svg.startpagina.nl

(Open web)standaarden zijn heilig en de validator ook

Vergelijk het met woordenboeken en automatische spellingscontrole. Een spellingscontrole werkt met een woordenboek, staat een woord er niet in, is het fout volgens de automatische spellingscontrole. Een mens is slim en kan op basis van ervaring, context en intuïtie heel vaak prima zelf bepalen om welke taal het gaat (Nederlands, Duits, Engels, etc.) Een computer kan alleen via exact voorgekauwde regeltjes werken, dus moet je precies aangeven om welke taal het gaat. (“Nederlands” is echter slechts een vage omschrijving, exact is bijvoorbeeld “Nederlands witte boekje 2005” of “Nederlands van Dale 2006”. Zelfs een mens kan niet verzinnen volgens welk woordenboek iets geschreven zou zijn, laat staan een computer, vandaar dat je dat precies moet aangeven.
Voor HTML (een opmaaktaal waarmee ongeveer iedere webpagina is opgebouwd) betekent dit dat je moet beginnen met een zogenaamd DOCTYPE, op basis waarvan de browser¹ bepaalt welke vertaalslag van code naar visuele representatie op je scherm hij gaat gebruiken. Als je in je HTML document het DOCTYPE vergeet, zou je browser eigenlijk alleen “DOCTYPE missing, can’t interpret” moeten melden (er zijn meerdere versies van HTML, 2.0, 3.2, 4.01 en ook nog XHTML versies) en die kant gaat het ook op, maar vooralsnog ‘gokken’ de meeste browsers een DOCTYPE.

Als je niet snapt dat dat een probleem is moet je maar eens een tekst uit een taal die je niet beheerst (Noors ofzo) proberen te lezen m.b.v. een woordenboek voor een andere taal die je niet beheerst (Russisch ofzo). Een ander probleem met webcontent en hoe browsers er (nu nog) mee omgaan is content die (zelfs als ze claimt van een bepaalde taal of DOCTYPE te zijn) niet correct van die taal is. Soms, en in de toekomst al vaker, zal je browser een foutmelding geven en daarna stoppen met verwerken. Nu meestal nog zal de browser echter iets ‘gokken’, deze gok is voor iedere browser anders, dus weet je niet wat je kunt verwachten. Naast het ‘kleine’ probleem dat het ‘afvangen’ van al deze fouten (de ‘gok’-methodes) een browser onnodig complex en langzaam maakt, heeft dit ook het grote probleem van verdraaide informatie. “Ken net” heeft bijvoorbeeld in het Fries een betekenis tegengesteld aan die in het Nederlands. Ook kan het ‘gokken’ van wat er eigenlijk bedoeld was ipv “stim” heel verschillend uitpakken (“stom”/“slim”). Zelfs in het hypothetische geval dat ieder stuk software dat nu en in de toekomst ooit op jouw content gaat werken “stim” magischer wijze vertaalt in het door jou bedoelde “slim” (in werkelijkheid zullen al meer tools terecht een foutmelding geven) dan nog heb je een probleem. Waar in de ene tekst “stim” wordt vertaald in “slim”, kan het in een andere tekst weer “stom” tot gevolg hebben (een poging tot het gebruiken van context wellicht), dus afhankelijk van de rest van de content. Dit betekent dus dat een correcte wijziging in de rest van de content ook een verandering in de interpretatie van het foute “stim” kan betekenen. Dat soort onzekerheid en verrassingen wil je niet.

Vind je dit nog steeds gezeur, en is het resultaat alleen voor jezelf bedoeld en verandert er nooit ook maar iets aan het systeem waar je het op draait, dan nog hebben standaarden een voordeel. De fouten die namelijk bij jou al een ongewenst resultaat hebben kun je makkelijk detecteren mbv dé validator. Als er verder nog allerlei fouten in je content zitten die je zelf niet belangrijk vindt zal dé validator de voor jou belangrijke fouten niet kunnen vinden, óf de melding erover “verstoppen”² tussen de meldingen over al die andere fouten. Vind je nu nog steeds dat je content niet foutloos door de validator hoeft te komen, dan kan ik nog een verhaal gaan houden over accessibility, mashups, het XMLweb, kostenbesparingen in onderhoud, het verlies van (potentiële) klanten, het mobiele web etc., etc., maar ook dat zal je dan waarschijnlijk niet overhalen van je “ze moeten maar begrijpen wat ik bedoel, ook al schrijf ik iets anders”-instelling af te stappen. Ben je wel overtuigd en voldoet je website nog niet echt aan een standaard, verander ‘m dan in geldige HTML 4.01 zo veel mogelijk voorbereid op XHTML. Zorg eerst dat je ‘m door de validator krijgt als ‘loose’ en als dat gelukt is vervolgens als ‘strict’.

1. Browser: vroeger vaak slechts bekend als “internet”,“die blauwe ‘E’,of Internet Explorer. De meeste programmeurs gebruiken al tijden iets anders (o.a. vanwege de vele fouten in Internet Explorer en de handige functies en ontwikkeltools in bijvoorbeeld Mozilla Firefox) en Jan en alleman zijn nu ook aan het overschakelen. Internet Explorer is, hoewel het nog steeds een groot marktaandeel heeft, z’n monopoliepositie kwijt en het gebruik blijft afnemen. Daarom is het devies voor de meeste webontwikkelaars nu “ontwikkel volgens de standaarden, pas het aan voor Internet Explorer”.
2. De validator is goed, maar niet perfect. Een hele enkele keer zal ie onterecht klagen (rapporteer de bug dan!), pas dan toch je code aan, zodanig dat ie nog steeds aan de standaard voldoet (het laatste woord is aan de W3C specificatie waarin de standaard is vastgelegd), maar tevens toch wordt goed gekeurd door de validator. Echte fouten kunnen dan niet verstopt raken tussen deze nepfouten.

KISS: Keep It Simple Stupid. Code lezen is 2x zo moeilijk als schrijven. Als je ingewikkelde code schrijft, begrijp je er later weinig meer van en een ander al helemaal niet. Je leest een stuk code veel vaker dan je ‘m schrijft. Gebruik verklarende (desnoods lange) variabele namen, commentaar kan zeker handig en soms zelfs nodig zijn, maar betekent meestal dat je code te ingewikkeld is. Wil je per se korte variabele name gebruiken (om minder te typen of minder schermoppervlak te gebruiken), zet dan boven aan je code in commentaar de alternatieve lange verklarende namen zodat een simpele search+replace de leesbaarheid snel kan verbeteren.

DRY: Don’t Repeat Yourself. Als je vaak (bijna) dezelfde code gebruikt, definieer die dan eenmaal om vaker aan te roepen. Hiermee wordt het aantal plaatsen verkleind waar zich een fout kan voordoen, of waar een wijziging dient te worden doorgevoerd. Bovendien is het gewoon overzichtelijker.

Houdt data, structuur, inhoud en stijl zoveel mogelijk gescheiden Dan hoef je je met minder aspecten tegelijk bezig te houden, waardoor je je op minder code hoeft te concentreren en makkelijker en sneller het gewenste resultaat kan verkrijgen. Ook kan je het ontwikkelwerk dan makkelijker opsplitsen over meerdere mensen en het draaien van het systeem over meerdere onderdelen. Denk goed na over wat in de database hoort, wat in de PHP/HTML en wat in CSS of Javascript (wat is tijdelijke data? wat is ‘permanente’? wat is opmaakcode? wat server-side algoritme? wat client-side algoritme? wat styling?) Als je in een functie of bestand een deel van de uiteindelijke HTML genereert, zorg dan zoveel mogelijk dat ieder deel an sich een geldig en volledig HTML element is. Dus bijvoorbeeld niet “<em>WorldWide</em><a “ en “href=‘http://my.com’>Web</a>“, maar “<em>WorldWide</em>“ en “<a href=‘http://my.com’>Web</a>“. Dit zal er voor zorgen dat het oplossen van een fout vaker slechts verandering op 1 plaats vereist i.p.v. op allerlei plaatsen (een voorbeeld van ‘spaghetti-code’, te veel en slecht gestructureerde afhankelijkheden). Vervolgens moet je ook nog bedenken wat in welk bestand gaat en waar dat bestand zich in de directory-structuur moet bevinden en welk onderdeel of persoon welke (lees-/schrijf-)rechten nodig heeft, of wat in welk datatype in welke tabel.

Gebruik de juiste tools: Tijdens het ontwikkelen kan je als (test)browser het beste Mozilla Firefox gebruiken, uitgebreid met de Web Developer en FireBug extensies. Af en toe ter vergelijk afgewisseld met Opera of Konqueror die nog beter aan de standaarden voldoen. Als editor kan je het beste eentje met syntax highlighting gebruiken, zodat je sneller type- en andere fouten zult opmerken. Een auto-complete functie kan tevens het aantal keren dat je moet terugvallen op documentatie verkleinen. Met auto-indenting houdt je je code leesbaarder en met js- en andere lint programma’s haal je makkelijker fouten uit je code en verlaag je tevens het risico ze later te introduceren. Om fouten op te sporen in je website, kan je automatisch informatie mbt voorgekomen PHP fouten opslaan in een logbestand en daarover een mail laten sturen naar de beheerder. Tevens kan je steeksproefsgewijs automatisch een pagina door validators en checkers sturen en een eventuele gevonden fout mailen

Ten overvloede. Al die technisch perfecte, makkelijker aan te passen code is natuurlijk weinig nuttig als het eindresultaat niet goed op de gebruiker en zijn/haar workflow past.

REACTIES