Gedachten over webdesign

Hoe ik ben begonnen

Toen ik eenmaal een internetaansluiting had leek het me wel leuk om een eigen homepage te hebben. Aangezien in niets wist van HTML maakte ik mijn eerste pagina volgens het principe "kijken en jatten".
Daara kocht ik een klein boekje over HTML en JavaScript. Om het makkelijk te houden maakte ik gebruik van een zogenaamde WYSIWYG HTML editor.
Mijn eerste website was dan ook een aardig broddelwerkje. De HTML voldeed aan geen enkele standaard, de opmaak was rommelig en verschilde per pagina.
Verder werd al snel duidelijk dat WYSIWYG in HTML redelijke flauwekul is. Wat ik op mijn computer in mijn browser zie biedt geen enkele garantie voor hoe de pagina er op een andere computer met een andere browser uitziet.
Zo kwam ik er al snel achter dat veel leuke gadgets er heel aardig uitzien in de Internet Explorer, maar in de meeste andere ("standards compliant") browsers absoluut niet werken. Om dan nog maar te zwijgen van niet grafisch geörienteerde browsers (zoals Lynx, of bijv. een Braille browser).
Zodoende ben ik snel afgestapt van het WYSIWYG principe en gebruik ik een tekst editor. Aanvankelijk het Kladblok van Windows®, later een zelfgemaakte editor (EPlus).

Het moet (en kan) anders

Sinds de restyling van 2003 en verder probeer ik meer uit te gaan van de standaarden van de W3C organisatie. De nieuwe pagina's zijn allen gevalideerd HTML 4.01. De opmaak is, conform de standaarden, nu geheel vormgegeven d.m.v. Cascading Style Sheets versie 2.1.

"Frames are evil"

Vanaf de eerste versie van mijn website heb ik gebruik gemaakt van frames. Dit leek een handige oplossing om het menu mooi aan de linkerkant van het scherm te houden en de "content" aan de rechterkant. Het geheel ziet er dan fraai uit en het menu hoeft niet iedere keer opnieuw geladen te worden als het "content"-frame ververst wordt. Vandaar ook de mooie knopjes in het menu. Bijkomend voordeel is dat je, om het menu aan te passen, slechts één bestand hoeft te wijzigen en niet alle pagina's van je site.
Dat lijkt dus een leuk concept, waar niets mis mee is. Zeker, in het verleden waren er browsers die geen frames ondersteunden, maar dat is anno 2005 toch geen issue meer ?

Frames kennen echter ook vele nadelen, die mijns inziens uiteindelijk belangrijker zijn dan het design-gemak van frames. Google maar eens op frames are evil of kijk eens op de What's wrong with frames pagina van de Web Design Group

Een korte samenvatting van argumenten tegen het gebruik van frames:

Frames gaan over layout, niet over structuur. Dit druist fundamenteel in tegen het hele concept van HTML. Voor layout dient CSS gebruikt te worden. In HTML 4.01 Strict en in XHTML worden frames niet meer ondersteund. HTML dient platform onafhankelijk te zijn (onafhankelijk dus van het besturingssysteem en de hardware). Frames zijn dit per definitie niet.
Frame(set)s zijn niet adresseerbaar. Er is geen enkele manier om naar een bepaalde combinatie van frames (bijv. "menu.htm" in linker frame & "pagina2.htm" in rechter frame) te verwijzen via een link, noch is het mogelijk om zoiets op te slaan als een bladwijzer of favoriet in je browser.
Als gevolg van bovenstaande zal een gebruiker die via een zoekmachine op een van je pagina's terecht komt het meestal moeten stellen zonder je "menu" frame. Voor deze persoon is je site dan waarschijnlijk slecht tot niet navigeerbaar.
Niet alle browsers (IE bijvoorbeeld) ondersteunen het printen van een enkel frame, zodat de gehele frameset geprint wordt. Dat is niet altijd de bedoeling (of wens) van de gebruiker.
de PageUp-, PageDown- en de cursortoetsen werken alleen op het actieve frame. Dus moet de gebruiker daar eerst op klikken met de muis, om daarna met het toetsenbord te kunnen scrollen.
Frames worden niet door alle moderne browsers ondersteund. Gebruikers met een dergelijke browser zien niets op je pagina, tenzij je frameset een <NOFRAMES> sectie heeft. Maar dat betekent weer dat je in essentie twee versies van je website moet onderhouden, één voor browsers met frames ondersteuning, en één voor browsers zonder. Daarmee is een eind gekomen aan het aanvankelijk gedachte "design-gemak" van frames !
Samenhangend met bovenstaande: frames zijn erg lastig voor mensen met een visuele handicap die aangepaste browsers gebruiken.

Dit gezegd hebbende is er natuurlijk niets mis met het visuele concept van (bijv.) een twee-koloms uiterlijk met het menu in de ene kolom en de "content" in de andere. Gelukkig is dit ook goed te doen met behulp van CSS.
Zorgen dat het menu steeds in zicht blijft (wat met frames erg gemakkelijk is) is wat moeilijker. Niet omdat er geen geschikte CSS code voor is, maar omdat Internet Explorer (zelfs in versie 6) dit ("position: fixed") niet ondersteunt.
Zoals je zult merken als je je wat meer bezighoudt met de principes van webdesign: er is heel wat mis met Internet Explorer !.

Een nadeel van deze methode met CSS is dat je het menu op alle pagina's hebt staan. Dat is lastig als je het menu verandert, maar daarvoor kun je HTML-preprocessors gebruiken of gereedschap dat tekst in meerdere bestanden gelijktijdig kan veranderen. Zie bijvoorbeeld mijn Multi File Text Replacer op de software pagina. En als je op de server waar je pagina's staan de beschikking hebt over een script taal, dan kun je zogenaamde "server side includes" gebruiken, waarmee je het hele menu weer mooi in een bestandje kunt bewaren.

Liquid design

Het idee dat ik controle heb over de presentatie van mijn pagina's in andermans browser is een mythe van de WYSIWYG gelovigen. HTML is daar principieel ook helemaal niet voor bedoeld. Als het goed is geeft de "markup" aan welke betekenis iets heeft in het geheel van de tekst. Dit heeft in principe niets met visuele opmaak te maken.
Natuurlijk is de betekenis in het geheel van de tekst vaak verbonden aan een bepaalde opmaak, maar hiervoor is geen universele standaard. Zo kan de code voor nadruk (<em>) bijvoorbeeld een (browser afhankelijke) visuele opmaak meekrijgen van vet of cursief, maar zal in een speach-reader lijden tot een met meer nadruk uitgesproken tekst. Zou je nu niet de <em> code gebruikt hebben, maar bijvoorbeeld <b> (vet), dan krijgt de tekst uitsluitend in visuele browsers nadruk. Andere browsers (en hun gebruikers) zal het dan ontgaan dat de tekst nadruk behoefte.
In principe zou de structuur van de pagina, zoals vastgelegd in de passende HTML markup, voldoende moeten zijn om de pagina goed te kunnen volgen. Alle (visuele) opmaak middels CSS die daar bovenop komt is slechts een esthetisch sausje. Met deze filosofie zorg je er tevens voor dat de pagina in vrijwel iedere browser goed te interpreteren is (zowel voor de browser als voor de gebruiker).

"Liquid design" is een ontwerpfilosofie die beoogt om je webpagina in moderne grafische browsers beeldvullend weer te geven. Dat gebeurt dus onafhankelijk van de venstergrootte en het door de gebruiker ingestelde letttertype. De pagina vloeit als het ware in het (veranderlijke) venster. Er mag dan ook geen deel van de pagina buiten de (breedte) van het venster vallen; geen horizontale schuifbalken meer.

Om dit te bereiken moet je de inhoud ("content") van je pagina geen vaste breedte meegeven (iets waar WYSIWYG-programma's juist erg van houden). Door groottes van elementen relatief t.o.v. elkaar weer te geven ontstaat (binnen redelijke grenzen) een schaalbaar geheel. Dit geldt dus ook voor je lettertype. Een vastgestelde lettergrootte (in punten of pixels) is leuk op de computer van de ontwerper, maar als je ooit geprobeerd hebt om een pagina met een 10 punts (of erger nog 12 pixel) lettergrootte te lezen op een scherm met een resolutie van 1280x1024 pixels of hoger, dan weet je hoe vervelend dat kan zijn.
Sterker nog, als je de lettergrootte zo definieert (zoals velen doen), dan is het voor de gebruiker vaak niet meer mogelijk om zijn lettergrootte op het scherm aan te passen om het geheel wat beter leesbaar te maken.
Deze laatste overweging heeft er ook toe geleid dat ik de oude knopjes (plaatjes) in het menu (hoewel visueel erg fraai) vervangen heb door tekst. Niet alleen laadt dat sneller, maar de tekst in het menu is nu volledig schaalbaar, zodat ook mensen die kleinere lettertypen niet goed kunnen zien toch door mijn site kunnen navigeren.

Overigens hoeven niet alle elementen op je pagina "liquid" te zijn. Zo zijn sommige elementen (bijv. het menu) op deze pagina's absoluut gepositioneerd en kaders hebben een in pixels opgegeven breedte.

Javascript

Niet alle browsers ondersteunen Javascript. Ook zijn er er genoeg gebruikers die (om veiligheidsredenen) Javascript uit hebben staan in hun Browser. Als je wilt dat je pagina toegankelijk is voor die gebruikers, dan moet je er voor zorgen dat eventueel gebruikt Javascript niet essentieel is voor de inhoud van die pagina.
Ik gebruik op mijn pagina's geen JavaScript meer. Verder zijn veelgebruikte "onMouseover()" en "onMouseout()" effecten ook prima te vervangen door gebruik te maken van de hover-effecten in CSS en het title-attribuut van bijvoorbeeld links.

Enkele interessante en relevante links over webdesign en aanverwanten

Alle standaarden (HTML, XHTML, CSS) vind je bij De W3C organisatie
De enige officiële W3C HTML Validation Service
Met de WDG HTML Validator kun je een hele site ineens valideren.
Offline HTML valideren ? HTML TidyGUI Klein, gratis en snel !
Of probeer eens de gratis CSE HTML Validator Lite
De enige officiële W3C CSS Validator
JavaScript problemen ? Zoek eerst eens in de JavaScript FAQ
De Gecko DOM Reference, onmisbaar voor Dynamisch HTML in Mozilla-achtige browsers.
Barbara de Zoete's Overzicht Webontwerp - PretLetters. Een echte aanrader.
Diverse HTML, CSS en JavaScript tutorials kun je vinden op How To Create
Kijk op de website van AnyBrowser.com hoe je site er in verschillende browsers uitziet.

Websites toegankelijk maken voor iedereen
(dus ook voor mensen met een handicap)

Stichting Bartiméus Accessibility: toegankelijkheid van Internet
Drempels Weg: toegankelijk websites bouwen
De W3C Richtlijnen voor de Toegankelijkheid van Web Content 1.0
Op Vischeck kun je laten simuleren hoe je website eruit ziet voor kleurenblinden en kun je afbeeldingen laten corrigeren zodat de kleuren voor kleurenblinden geoptimaliseerd worden.
Op "Color matters" staat een interessante verhandeling over het gebruik van kleuren op computers en het web.

Inhoud