Als je ooit de aandrang niet hebt kunnen onderdrukken om naar de HTML-code van een webpagina te kijken, dan was je daar waarschijnlijk meteen weer van genezen. Die code is niet voor mensen bestemd en dat is goed te zien. De code is gemaakt om een webpagina in compacte vorm van een computer ergens op de wereld naar je browser te sturen. Die ontvangt de HTML en tekent hem daarmee op het beeldscherm van je computer. De pagina bestaat dus niet echt. Hij wordt op dat moment voor je samengesteld.

De argeloze toeschouwer heeft de indruk dat de pagina net zo ‘levensecht’ is als het geluid uit de telefoon of het het beeld van een televisie. Maar niets is minder waar. Inhoud, navigatie, lay-out en gedrag worden geïnterpreteerd uit de HTML-code, vergelijkbaar met het assembleren van een apparaat aan de hand van een bouwtekening. Maar dan met probleem dat van de HTML-code nooit in detail is vastgesteld wat het resultaat van de codes precies moet zijn. In deze Techniek in Vorm zullen we ons beperken tot de (typo)grafische eigenschappen aan de kant van de browser van de gebruiker. De andere kant, de webserver die met programma’s als XSLT en PHP de HTML-code berekent, komt in een later artikel een keer aan de orde.

Bij het ontstaan van HTML (HyperText Markup Language) ging het al fout. Het doel van de standaard, op 30 april 1993 door CERN (Zwitserland) vrijgegeven voor algemeen gebruik, diende om wetenschappelijke artikelen op een netwerk te kunnen publiceren.

Wetenschappers zijn niet zo kritisch over de vormgeving van hun publicaties. Oorspronkelijk was voorzien dat de codes <h1>, <h2>, <h3>, <h4> en <h5> voldoende zouden zijn om niveaus van koppen aan te geven, onder het motto “als je het verschil maar kunt zien”. Samen met nog een beperkt aantal ander codes zoals <img> voor het plaatsen van afbeeldingen, <table> voor tabellen en <a> voor het maken van (hyper)links naar andere pagina’s, kwam daarmee begin jaren negentig een eenvoudige ‘standaard’ beschikbaar. Veel makkelijker om mee te werken dan de zeer complexe SGML-codering die in de jaren tachtig vooral door grote uitgeverijen werd gebruikt.

Maar de simplificatie ging vooral ten koste van de vormgeving en de kwaliteit van de typografie. De codes <h1> tot <h5> geven dan wel een relatief verschil aan tussen de koppen in een tekst, maar het is onduidelijk hoe groot ze precies zijn. De exacte weergave op het scherm is voor een groot deel afhankelijk van factoren die de zender van de informatie niet in de hand heeft, zoals:

• het platform waarop de browser draait (Apple, Linux of Windows);
• het type browser (Netscape, Explorer, Safari, Mozilla Firefox of een van de andere soorten browsers die in met enige regelmaat ontstaan);
  
• het versienummer van de browser;
  
• over welke lettertypen de PC van de gebruiker beschikt;
  
• de grootte, kwaliteit en resolutie van het beeldscherm;
  
• het aantal beschikbare kleuren in de interface van de PC;
  
• de door de gebruiker ingestelde grootte van letters;
  
• en vooral ook de grootte van het window waarin de pagina wordt getoond.

Dit betekent dat nooit met zekerheid is te voorspellen of informatie wel zichtbaar is zoals het door de auteur of vormgever van een pagina bedoeld is. In gunstige gevallen beperkt het verschil zich tot het verlopen van een tekst, waardoor deze niet meer lijnt met andere informatie op de pagina. Maar het kan ook gebeuren dat tekst helemaal niet zichtbaar is, dat knoppen niet werken of hele pagina’s niet worden gevonden. Bij de ene browser wel en bij de andere niet. In Windows wel, op de Mac niet. Of juist andersom.
Het aantal typografische beperkingen van de basisset HTML codes is enorm. Hierdoor kun je op de meeste sites wel een typografisch probleem herkennen. Grofweg zijn er twee manieren waarop ‘ontwerpers’ met die beperkingen ‘omgaan’.

• De ‘ontwerper’ van de site is zich niet bewust van het probleem of vindt het niet belangrijk;7
• De ontwerper van de site heeft genoeg ervaring om met kunst en vliegwerk allerlei technieken aan te wenden om de beperkingen te omzeilen.

We zullen beide apart bekijken.

Auteurs die zich niet druk maken over de vorm van pagina’s hebben het onmiskenbare voordeel dat het niet uitmaakt op welke computer en met welk type browser hun informatie wordt bekeken. Er is geen eenduidige verschijningsvorm, dus die kan ook niet worden aangetast. Er is weinig code nodig , dus de pagina is makkelijk te onderhouden en snel te downloaden. Dit soort pagina’s is herkenbaar aan de default instellingen van de meeste browsers (zoals een symmetrische opbouw, onderlijnde hyperlinks in kleur, de standaard lettertypes, met tabellen en regels die over de volle breedte van een window lopen en daarmee onleesbaar worden). Blog’s, wetenschappelijk publicaties, handleidingen zijn sprekende voorbeelden van deze aanpak.
Een belangrijk nadeel is dat de vorm zo afhankelijk is van de eigenschappen van de omgeving waarin de pagina wordt afgebeeld, dat aspecten als typografische kwaliteit en identiteit van de afzender ver te zoeken zijn. De standaard basiselementen van een huisstijl, zoals kleur, layout, lettertype zijn niet eenduidigheid gedefinieerd in HTML.

Dit in tegenstelling tot pagina’s waar een ontwerper zich mee bemoeit, niet gehinderd door ervaring met en interesse in de techniek. Een pagina wordt – veelal in Photoshop – in pixels ontworpen, waarna iemand anders de techniek van de layout en de interface maar in HTML moet zien op te lossen. Of anders in programma’s als DreamWeaver die kant en klare HTML code in elkaar bakken, waar later niets meer mee te beginnen is.

De ervaring van de webontwerper laat zich vaak meten aan het aantal ‘work-arounds’ waarmee de beperkingen van HTML worden omzeild, bijvoorbeeld, door binnen de pagina een onaanvaardbaar aantal verschillende talen en systemen (waaronder HTML, CSS, Javascript, SVG, Java, Flash) te combineren. Bovendien worden allerlei elementen oneigenlijk gebruikt zoals transparante plaatjes om stukken layout op hun plaats te houden, tabellen als layout en andere HTML codes met bepaalde onbedoelde neven-effecten.

Het grootste probleem van deze oplossing is dat de werking totaal onvoorspelbaar is. Door het gebrek aan standaard hebben veel sitebouwers zich in de loop der tijd ingesteld op de nukken van een bepaald – vaak hun eigen – type browser met als motto “bij ons werkt het", zonder te testen of dat in een andere omgeving ook zo is. Pijnlijke voorbeelden hiervan zijn de (openbare) sites van nogal wat gemeenten en andere overheden, groot-grutters en vooral banken, een belangrijk reden waarom Mac gebruikers zich genoodzaakt zien om er een PC op na te houden, uitsluitend voor het doen van betalingen. In zekere zin kan je het de bouwers van dergelijke sites niet verwijten, duidelijke standaardisatie en terugkoppeling ontbreekt. Het belangrijkste mondiale informatiesysteem, Internet, hangt als een lappendeken aan elkaar en met elke introductie van een nieuw operating systeem of type browser wordt het erger.

Een bloemlezing van cumulerende dagelijkse problemen voor de webontwerper:

• Het gebrek aan adequate opmaak instructies heeft een hele generatie aan websites opgeleverd die tabellen gebruiken voor het positionering van informatie. Het voordeel van tabellen in HTML is dat de informatie altijd op de pagina staat maar dat is ook meteen het belangrijkste nadeel: het is niet te voorspellen op welke plaats de informatie op de pagina komt te staan omdat iedere browser er een eigen strategie op na houdt wat de breedte van kolommen is.
• Het instellen van positionering en regelbreedte met behulp van CSS werkt prima, behalve dan dat tijdens de berekening van de pagina niet bekend is welk lettergrootte de gebruiker op zijn PC heeft ingesteld.>
• De ontwerper is gedwongen om de lettertypen te kiezen die op de PC van de gebruiker staan. Zelfs als we uitgaan van de standaard fonts van Windows en OSX, dan nog is het niet zeker of die er op staan,
• Het alternatief is om koppen in plaatjes te zetten. Maar lang niet alle content management systemen zijn in staat om deze automatisch te genereren. Hetgeen de redacteur verplicht om in Photoshop koppen te typen, een zeer ongewenste werkwijze.

Bovendien maakt deze aanpak het erg lastig voor slechtlezende gebruikers om de letter in hun browser extra groot zetten. Een plaatje schaalt niet mee.

• Veel ontwerpers proberen de problemen te omzeilen door de hele site dan maar in Flash te bouwen, waarbij ze vergeten dat de verkregen vormvrijheid en typografische kwaliteit tegelijk een onwerkbaar systeem opleveren omdat de auteur een dergelijke site nauwelijks zelfstandig kan beheren. Een Flash document is een applicatie binnen een pagina, niet het equivalent van een site.
  
• Over de problemen met Javascript, een persiflage van echte object-georiënteerde programeertalen zoals Python en Java, zullen we het in dit stukje maar niet eens meer hebben.

Waar het heen moet? Ik weet het ook niet zo, maar de aard van het probleem maakt wel dat het waarschijnlijk niet van het ene op het andere moment opgelost zal worden. Iedere standaard die wordt ingevoerd om de situatie verbeteren zal het probleem alleen maar vergroten. De miljoenen pagina’s die per dag worden toegevoegd, verkleinen alleen maar de kans dat het ooit nog structureel zal worden opgelost. Een uitdaging dus.