Hey! Bezoek

De Marktplaats.nl - Groot geworden in Emmeloord campagne waar je bijna niet omheen kunt als je met de auto over de snelweg A6 rijdt fascineert me. Met het doel meer ondernemers naar de Noordoostpolder in het algemeen en Emmeloord in het bijzonder te trekken is de campagne in januari van 2007 van start gegaan. Het in 2004 voor 220 miljoen euro door ebay overgenomen marktplaats.nl is het boegbeeld van de promotie.

Misschien is het niet zozeer de groot geworden in Emmeloord component die me hieraan bezighoudt, maar het succes van marktplaats.nl. Als ik aan de website van Marktplaats denk, moet ik onwillekeurig aan Craig's List denken. Dat is een nog onooglijker geheel van tekstlinks. Ziet er nog meer dan Marktplaats uit alsof er sinds 1997 geen updates meer zijn geweest. Is visueel net zo aantrekkelijk als de Atlantikwall. Onder de motorkop ziet het er allemaal trouwens nog droeviger uit. Antieke technieken als iframes, niet afgesloten paragraaf tags en inline stijlen zijn regel en geen uitzondering. Eigenlijk worden alle ** wetten van goed webontwerp ** met voeten getreden. Maar desalniettemin zijn bovengenoemde websites ongekend populair en (ook niet geheel onbelangrijk) zakelijk bijzonder succesvol.

Mag uit het bovenstaande (technisch kreupele websites met een oubollig uiterlijk die toch buitengewoon succesvol zijn) worden geconcludeerd worden dat het belang van een technisch solide / visueel aantrekkelijke website behoorlijk wordt overschat. Dat het in de praktijk niemand ene fok interesseert of www.mijn-website-is-technisch-top.nl vakkundig is gecodeerd. Of niet. Dat Zeldman dus lekker kan kletsen ... over webstandaards ... toegankelijkheid ... semantische markup ... Maar dat het allemaal niet zoveel uitmaakt. Dat uiteindelijk het concept de mate van succes van een website succes bepaalt ...

Of zit ik fout? En moet ik het omgekeerd bekijken? Met andere woorden, zouden de genoemde websites nog vele malen meer succesvol zijn als ze technisch fatsoenlijk in elkaar zaten?

Ik heb weleens getwijfeld aan mijn schone code evangelisme. Je weet wel: dat geitenwollen sokken geleuter over scheiding van inhoud, vormgeving en actie. Ja, ja Rochat. Da's een hoop blah, blah, blah. Allemaal leuk en aardig, maar snijdt het ook echt hout? Zit ik niet op een stokpaardje waar in de praktijk niemand iets aan heeft? Nou, mijn twijfel is geheel weggenomen. You fokking bet it does make sense to code clean!!!!

Op het moment ben ik bezig met wat kleine aanpassingen aan een website die gemaakt is met Microsoft Frontpage. En ik weet weer voor 300% zeker dat html code die technisch door de beugel kan (lees: xhtml validerend) en waarin opmaak geregeld wordt door een extern stijlblad de manier is om een fatsoenlijke pagina in elkaar te zetten. Eéntje die ook op een redelijke manier te onderhouden is.

Een oerwoud van tags
Veel inhoud staat er niet op de pagina's, maar de html code is een waar oerwoud van overbodige (proprietary) tags. Overhead in het kwadraat. Onnodig zwaar en onoverzichtelijk.

Tabellen voor layout
De layout van de website is gebaseerd op tabellen. Vlekken in m'n nek. Waarschijnlijk heeft het bloed, zweet en tranen gekost om alles in de huidige toestand toonbaar te krijgen. Maar aan het scenario dat er wel eens iets zou kunnen worden gewijzigd is niet gedacht. Derhalve is de onderhoudbaarheid een ware nachtmerrie. Als je in één van de tabelcellen iets teveel inhoud stopt, heeft dat direct zijn weerslag op een ander deel van de tabel waarin de navigatie staat. Die wordt dan vakkundig uit zijn voegen gerukt. Als je via WYSIWYG probeert sommige cellen samen te voegen reageert het geheel onvoorspelbaar. Een duik in de code is verplichte kost. Je durft amper iets aan te raken. Je weet maar nooit wanneer de fles met html-nytroglycerine instabiel zal worden!

Uitgerangeerde tags
De opmaak is een wirwar van uitgerangeerde tags (met name font tags) en inline stijlen (span wordt nogal eens misbruikt). Het is vrij moeilijk om te voorspellen hoe de opmaak van een pagina zich zal gedragen als je iets verandert in de achterliggende code.

Wakeup call
Eén kritische blik op de code en de tranen schieten me in de ogen. Xhtml is mijlenver buiten bereik. Ik ben het jongetje dat op onderbindschaatsjes achter een keukenstoel over het ijs krabbelt, maar eigenlijk met slagen van 5 meter breed rondjes hoort te draaien.

Vroeger weleens gedacht dat je liever in de fabriek ging werken in plaats van verder te leren? Ik wel. Een weekje vakantiewerk aan de productielijn was dan m'n wakeup call. Weleens getwijfeld aan het nut van een website met een fundament van enig technisch niveau? Soms is sleutelen aan een website zonder dat fundament voldoende om te worden wakker geschud!

Dit weekend ben ik bezig me een beeld te vormen van microformats. Microformats? Wat is een microformat? Waarvoor dient een microformat? Waarom zou ik een microformat op mijn website inzetten?


Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).


Niet helemaal helder
Hoewel ik dus al het halve weekeinde probeer te begrijpen wat microformats nu eigenlijk zijn ... helemaal scherp op het netvlies krijg ik het concept nog niet. De officiële microformats website is wat mij betreft ook niet echt behulpzaam. Er is weliswaar veel info op te vinden, maar hoe meer ik lees, hoe minder duidelijk het wordt.

In de praktijk
Om toch een poging te wagen ... ik begrijp dat microformats een manier is om specifieke blokjes informatie op een gestructureerde manier aan te bieden aan zowel mens als machine. Ter illustratie, onderstaand stukje code zou ik kunnen gebruiken om het verjaardagsfeest van mijn oudste dochter als microformat aan te kondigen.


November 9th 11am — 7pm 2006 — Verjaardagsfeest Lynnie
Gelrelaan 34 Emmeloord
Ter ere van de 11e verjaardag van Lynn is er deze dag volop gelegenheid voor het overbrengen van uw gelukwensen en het door middel van een gulle gift positief beïnvloeden van haar liquide middelen. Tevens wordt u van ganser hart aangemoedigd tot het consumeren van de aanwezige alcoholische versnaperingen.


Vraagtekens
Hmmmm. Waarom zou ik, als ik data op een dergelijke manier wil presenteren, een microformat gebruiken? Waarom zou ik zo'n stukje informatie, als ik het dan persé wil structureren, niet gewoon in xml verpakken? Net als een RSS feed? Met andere woorden, welke voordelen biedt een microformat ten opzichte van xml? De eenvoud van een microformat ten opzichte van xml wellicht?

W3C validator
In het door de hCalendar gegenereerde code wordt gebruik gemaakt van een tweetal div elementen. Omwille van de compatibiliteit met de xhtml webstandaard (een div element binnen een paragraaf maakt de W3C validator een beetje nerveus) heb ik deze hier vervangen door een als display: block gestyled span element. Voor zover ik heb begrepen zijn dit soort acties voor het hCalendar microformat toegestaan.

Elke dag zit ik een uurtje in mijn karretje om van Emmeloord in het Amersfoortse te geraken. Hey, in mijn Seat Leon op steroïden is dat niet echt een straf te noemen. Ik leef mijn leven in de snelle rijbaan, dus rij ik nogal eens een medeweggebruiker de vangrail in voorbij.

Ja, grinnik er maar om. Om Emmeloord bedoel ik. Maar bedenk wel dat je absoluut geen medelijden met me hoeft te hebben. Ik woon in een rustig dorp. Zeg maar groen in het kwadraat. Criminaliteit = weinig. File= minder, zelfs naar Amersfoort. Als één van mijn dochters per ongeluk crasht met haar fiets of step: een buurtbewoner begeleidt haar wel ff naar huis voor een pleister. Met andere woorden, Emmeloord is (voor mij in ieder geval) een toonbeeld voor lekker landelijk wonen, zonder de negatieve sociale controle van een echt klein dorp, maar wel met voldoende voorzieningen bij de hand. Want als ik toevallig een CDtje wil kopen ben ik binnen een paar minuten op de fiets bij de plaatselijke Free Record Shop aanbeland om een stukje muziek te scoren.

Ik dwaal af. Wat ik wilde zeggen: onderweg naar mijn werk en terug naar huis zie ik nogal eens een link op een auto gekalkt staan. En dan wil ik weten wat er achter die URL schuilgaat. Niet zozeer inhoudelijk. Maar vooral technisch.

Vaak valt het tegen: de technische invulling van de weblink op de wagen die ik onderweg noteerde. Overigens niet altijd geheel onverwacht. Als je een verroeste VolksWagen bus type GTI (Gordijnen - Trekhaak - Imperial) voorbij blaast verwacht je daar vanzelfsprekend vrij weinig van. Maar ook achter de URL op die fantastisch beletterde VW Transporter TDI met alle letters in het rood (voor de aanduidings-analfabeten onder u: hoe meer rode letters = meer PK's onder de billen. Jouw baas vindt het belangrijk dat je zo snel mogelijk op de plaats van bestemming bent) kan een ongelooflijke zudt website schuil gaan.

Mijn mening over de websites van de bedrijven die ik onderweg van Emmeloord naar de GGD in Amersfoort en visa versa ontmoet ga ik via nullbeta.net online zetten. Ik ga daarbij absoluut niet letten op wat ik mooi of lelijk vind (om maar eens een cliché van stal te halen: over smaak valt überhaupt niet te twisten), maar ik ga mijn waardeoordeel vellen op basis van technische zaken als het gebruik van frames, de inzet van stijlbladen (zo ja, inline of in een separaat bestand?), de aanwezigheid van een doctype declaratie (zo ja, valideert de website?) en toegankelijkheidsdingetjes zoals de aanwezigheid van alt tags bij de getoonde afbeelding en title tags bij links.

Met andere woorden: hoe ziet bijvoorbeeld een tekstbrowser als Lynx de website in kwestie?

Verder ga ik letten op de manier waarop optionele technologie benut wordt. Ik vind het bijvoorbeeld wel interessant om te zien hoe websites omgaan het gebruik van javascript en flash. Wordt er rekening gehouden met het feit dat de user agent van de betreffende bezoeker dit wellicht niet ondersteund?

Binnenkort op deze website ...

Krijg je jouw website niet goed? Ben je geboren als een Internet Exploder Only webbouwer? Nooit verder gekeken dan de WYSINWYG van FrontPage? Geen nood. Het is voorlopig niet nodig die 9 mm aan je slaap te zetten. Warren de Spammer neemt je zorgen uit handen als Wanna make sure your Web Site looks perfect in my computer je sole mission in life is.

Have you ever bumped into a crappy Web Site?
Well, guess what, thas very site might have looked perfect in its creator's Operating System and Browser.

Now, imagine that the same happens to 9 out of 10 web sites incIuding yours.
It is possibIe to take precautions and avoid such a miserable fate qiven you requIarIy check your web site appearance in different Operatinq Systems and Browsers.
You can easiIy do so with the new convenient service of screenshots.
Screenshots are digital pictures of your Web Recourse downIoaded from various pIatforms. Interested?

Spam. Jazeker. Maar er hangt in dit geval wel een echte website achter. Bij het eerste bezoek crasht mijn Firefox, maar dat zal wel aan die andere 90% van de websites liggen die klote zijn gecodeerd. Proest!

Ik ben verder toch wel enigszins teleurgesteld. Want Warren de Spammer belijdt zijn geloof grotendeels met zijn mond. Een minuutje broncode kijken leert dat Site Screenshot niet helemaal state of the art is wat betreft het kloppen van html.

Wat dacht je van:
(1) het gebruik van door het W3C afgeserveerde tags
(2) het inline gebruik van stijlen
(3) de nogal rommelige inzet van tabelletjes voor layout
(4) het negeren van xhtml syntax
(5) en last but not least het antieke gebruik van frames

Via ForgetFoO (note: FoO may or may not be SFW) kwam ik op de Mac Safari test. Voer de URL in van de pagina die je wilt checken en je komt te weten hoe jouw website eruit ziet als ie bekeken wordt met deze browser. In de vorm van een screenshot van de pagina in kwestie. Reuze handig voor de armlastige zieltjepootjes onder ons die zich de aanschaf van een G5 PowerMac niet kunnen permitteren. Zoals ik dus!

Ik heb een aantal pagina's bekeken. Jubel! Hoera! De vlag kan uit en ruk maar vast een extra krat Amstel aan! Want het resultaat is in het geheel niet ontmoedigend. Integendeel. Eigenlijk ziet het er gewoon hetzelfde uit als onder de Windows en Linux browsers waarmee ik doorgaans mijn code verifieer (IE5+, Opera, Firefox, Mozilla, Konqueror, Galeon).

** Schakelend naar gemoedstoestand (te) grote bek: wat wil je anders met een website die gecodeerd is volgens webstandaards? **

update:
Ook errug aardig - de mogelijkheid om via een VNC remote sessies voor het echie met Safari rond te klikken in de website.

Onlangs mocht ik een e-mailtje ontvangen van Ulco. Naar aanleiding van een schrijfseltje over doctyping. Behalve een sympathiek verhaal waarin het nut van de scheiding van inhoud, stijl en actie werd benadrukt eindigde Ulco zijn betoog met een vraag:


Overigens heb ik een nieuwe voor je om eens een keer over na te denken: Waarom gebruik je überhaupt *x*html en niet gewoon html, Internet Explorer interpreteert het toch allemaal hetzelfde, namelijk als text/html.


Ikke natuurlijk trouw beloven dat ik dit zeker zou doen. Terwijl ik het in de praktijk eigenlijk veel te druk heb met ademhalen en bier drinken. Uiteindelijk heb ik toch maar wat tijd vrijgemaakt (het ademhalen is er ff bij ingeschoten), want ** haalt cliché van stal ** : belofte maakt schuld. De vraag van vandaag is dus als volgt geformuleerd:

Waarom is het nodig om een webpagina te doctyperen als xhtml (terwijl het voor Internet Exploder momenteel helemaal nada uitmaakt of je nu declareert als html of xhtml)?

De in onzinnigheid aflopende reeks antwoorden die ik kon verzinnen lees je hieronder.

Antwoord 1a:
Erbij horen! Als wannabe webbouwert fungeer ik vanzelfsprekend graag als echoput van alle evangeliën die ooit door internetgoeroe's en webbouw-predikers als Zeldman verkondigd werden. Met andere woorden: alles wat er op AListApart wordt verteld neem ik tot mij als ware het God's Woord.

Antwoord 1b:
In de voedselketen van het web-evangelisme sta ik vrijwel onderaan. Zoals ieder schepsel wil ik echter liever eten dan gegeten worden. Middels mijn gestrengheid in de leer probeer ik karma te vergaren.

Antwoord 1c:
Om een verpletterende indruk te maken op die aantrekkelijke afdelingsecretaresse van After Sales. Als ik haar vertel dat mijn websites valideren als xhtml strict zal ze ongetwijfeld van opwinding van haar stoel glibberen.

Antwoord 2:
De niet-zo-heel-lollige maar onvermijdellijke constatering dat Internet Explorer de browsermarkt anno 2006 nog immer in zijn grip heeft wil niet zeggen dat het IE-development team van Microsoft de wijsheid in pacht heeft. In tegendeel. Internet Explorer en een succesvolle implementatie van webstandaards staan behoorlijk haaks op elkaar. Lekker eigenwijs de standaards volgen en waar nodig rond de quirks van IE heenfietsen dus. Zolang Microsoft's browser (expres?) de richtlijnen van het W3C met voeten treedt, is elke mate van tegengas gerechtvaardigd.

Antwoord 3:
De toekomst. Het is handig om ervoor klaar te zijn. Op het moment wordt xhtml dan wel geserveerd als html, maar wie weet hoe de vlag er morgen bijhangt? Bovendien zorgt xhtml er met zijn regeltjes (well-formed, lower case, attribute quotation) natuurlijk wel voor dat je min of meer gedwongen wordt om je code wat netter te schrijven. Alleen al het keurslijf van de W3C validator is voor mij voldoende pressie om syntactisch valide code te kloppen.

Afsluitend: in een televisie-reclame werd een aantal jaren geleden al geventileerd: "Een slimme meid is op haar toekomst voorbereid". In deze context zou ik hieraan willen toevoegen: "En het is een domme geit die haar pagina's met deprecated tags aan elkander breit". Amen!

Bij Aqtion moet je wel wat in je mars hebben om als developer aan de slag te gaan. Met asp classic / asp.net, xml en SQL Server moet je in elk geval al prima door de bocht kunnen. Op zich niet zo gek, want je streeft naar het maken van een kwaliteitsproduct en daarnaast werk je zeer nauwkeurigBlablabla. Zucht van het type heel erg diep! Volgens mij worden de prioriteiten bij Aqtion niet helemaal goed gezet. Uitgaande van onderstaande screendump (Firefox 1.5 onder Windows) zou ik zeggen dat het aantrekken van iemand die gewoon een beetje rechttoe de dijk uit webstandard compliant kan coderen prio numero uno is. Met andere woorden: probeer eerst gewoon maar eens geldige (x)html te kloppen en verder te kijken dan dat vervloekte IE. Spannender dingen komen pas later.

Volgens mij is hun eigen website nog een beetje lek ook, want het aanplakken van een OR operator aan de url levert een aardige vbscript foutmelding op die het ergste doet vrezen:

Microsoft VBScript runtime error '800a000d'

Type mismatch: 'clng'

/ast.2.2/script/templet/aqtion_4/template.asp, line 68

Of het daadwerkelijk is uit te buiten is alleen op basis van het bovenstaande niet te zeggen, maar in principe adverteert dit: kwetsbaar voor SQL injection.

Kijk, dat is nou een stijlbladelement waar we wat aan (zouden kunnen) hebben. Natuurlijk zijn jaren van gezeur over het gebruik van tabellen voor het realiseren van een kolomlayout en het geworstel met de div tag de mensen van het W3C niet ontgaan. En dus zit er in het draftdocument voor CSS3 een voorstel voor een multi-column layout module. Als deze module in de definitieve CSS3 specificatie beschikbaar komt, wordt het leven van de codekluiver weer een stukje makkelijker gemaakt. Hoewel ... hoe ga je in je code onderscheid maken tussen user agents die CSS3 ondersteunen en degenen die dat niet doen? Voor IE kan vorken middels een conditional comment uitkomst bieden. Maar hoe ga je om met oudere versies van Mozilla of Opera?
Update:
De op het moment van schrijven laatste versie van Mozilla Firefox (1.5) ondersteunt de multikolomstijl door middel van de prefix -moz. De stijleigenschap column-count wordt dus -moz-column-count. Je checkt het resultaat uit op de CSS3 multikolom demopagina. Het positioneren van een afbeelding (met behulp van float: mid-column of float: in-column) werkt trouwens (nog) niet!

CSS3 multicolumn layout module

Webstandaards zijn er om te worden gevolgd. Het door Tim Bernes-Lee opgerichtte W3C is de belangrijkste organisatie wat betreft het doen van aanbevelingen en het opstellen van internet standaards. Zo komen onder andere HTML, XML, XHTML en CSS uit de hoge hoed van het W3C.

Hiervan zijn de CSS en XHTML specificaties voor mij het meest interessant. Indien mogelijk probeer ik mijn markup- en stijlblad-code dan ook volgens de regels van de W3C specs te schrijven. Af en toe links en rechts in de spagaat vliegend om browserbugs of parse-eigenwijsheden van vooral Internet Explorer te omzeilen, maar dat terzijde.

Ik durf mezelf dus wel een trouwe volgeling te noemen. Maar ook de richtlijnen van het W3C kunnen mij, brave borst die graag streng in de code kloppende leer wil zijn, teveel worden ... Het volledige artikel lezen