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:

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.
Op deze pagina's gebruik ik Javascript uitsluitend om de "Deze pagina werd het laatst gewijzigd op" boodschap af te kunnen beelden en om mijn mailadres weer te geven (dit laatste in een, misschien futiele, poging om spambots het leven wat moeilijker te maken). Gebruikers die geen Javascript tot hun beschikkinghebben zien helaas dus geen mailadres op mijn pagina. Helaas ondersteunt mijn provider het gebruik van mailformulieren (via hun CGI-server) niet meer, want dat zou een handige oplossing zijn voor dit probleem.
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

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

Copyright © 2004 - 2015 by Flying Sheep Inc.