De Heilige Graal voor de webdesigner was altijd “backward compatibility”; dat je site het goed doet in oude browsers. Maar wordt het onderhand niet eens tijd dat we ons bezig gaan houden met forward compatibility?

Dit artikel verscheen eerder in: A List Apart

Vraag: Jullie website ziet er mooi uit in Internet Explorer 6, maar vreselijk in Netscape 4.7. Is dit nou het soort webdesign wat jullie bepleiten bij je lezers? Het ernstigste probleem is nog wel dat het er niet eens uitziet als dezelfde pagina!

En overigens, de knoppen die er kennelijk voor moeten zorgen dat de lezer een ander lettertype kunnen kiezen doen het niet in NS 4.7.

Ik ben zelf webdesigner en vind het belangrijk dat mijn sites er niet alleen goed uit zien in beide browsers, maar dat alle gebruikers hetzelfde ontwerp en dezelfde lay-out zien.

Kunnen jullie me uitleggen waarom jullie maar voor één browser ontwerpen?

Met vriendelijke groeten,
[naam bekend bij de redactie]

Antwoord: Dankjewel voor je vraag. Het is niet zo dat wij voor slechts één browser ontwerpen. In feite ontwerpen we voor alle browsers en toepassingen; we houden ons namelijk aan de aanbevelingen van de W3C, inclusief de standaarden voor XHTML 1.0 Transitional en Cascading Style Sheets.

Hierdoor ziet A List Apart er uit zoals het hoort in Opera 5, Opera 6, MSIE5, MSIE5.5, MSIE6, Netscape 6 en Mozilla. De tekst is leesbaar in willekeurig welke browser of Internet toepassing, van Netscape 1.0 tot Palm Pilots en webtelefoons.

Wij houden ons aan de aanbevelingen van de W3C, niet aan de (on)hebbelijkheden van oude, niet-gestandaardiseerde browsers (of ze nou van Netscape of Microsoft of wie dan ook zijn). Waarom is dat een goed idee? Hier leggen we het uit:

1. De Style Guide van de New York Public Library
2. To Hell With Bad Browsers in A List Apart
3. Upgrade Campaign: Developer Tips van het Web Standards Project

A List Apart gebruikt Method 2: Invisible Object van het Web Standards Project om zijn tekst beschikbaar te maken voor elke browser of toepassing, zelfs als die browser of toepassing niet CSS of de andere web standaarden ondersteunt die we gebruikt hebben in het eenvoudige ontwerp van onze site.

Problemen met oude ontwerpgewoontes

Voor 2000 was er niet één browser die zich volledig hield aan de aanbevelingen van het W3C. We leerden allemaal dat we er alles aan moesten doen om onze sites goed te laten werken in al die browsers. Het maakte niet uit dat de code niet valideerde, we hoefden niet eens stil te staan bij het werk van het W3C, en bij hun doel om websites uitwisselbaar en toegankelijk te maken voor iedereen.

Voordat de W3C-aanbevelingen gedefiniëerd waren en voordat ze ondersteund werden door browsers hadden de meesten van ons ook geen andere mogelijkheid dan te ontwerpen en bouwen met de eigenaardigheden van de diverse browsers in het achterhoofd. Maar deze werkwijze heeft tenminste vier belangrijke nadelen:

1. Onze sites waren zo niet toegankelijk voor mensen met functiebeperkingen.
2. Onze sites deden het niet in sommige browsers en als browsers veranderden ging er nog meer mis. Als je bijvoorbeeld iets gebouwd had met behulp van Netscape 4 layers, werkte hij niet meer in Netscape 6, laat staan in MSIE of Opera.
3. Het maakte onze sites duurder dan noodzakelijk, aangezien we zoveel tijd en dus geld (van onze klanten!) besteedden aan het schrijven van “workaround” code.
4. En door het uiterlijk (design) zo onlosmakelijk vast te kitten aan structuur (de content) werd het erg moeilijk om de sites te gebruiken met draadloze of andere alternatieve web-toepassingen. Zoals we A List Apart nu opbouwen, met valide XHTML en CSS, is het relatief gemakkelijk om snel “wireless markup versions” te maken.

Helaas is het, terwijl ik dit eind 2001 schrijf, nog steeds zo dat tienduizenden professionele web designers en ontwikkelaars zich richten op de eigenaardigheden van niet–gestandaardiseerde browsers. Ze verdiepen zich niet in de aanbevelingen van de W3C en gebruiken de richtlijnen niet. Terwijl die er juist voor gemaakt zijn om problemen op te lossen en er voor te zorgen dat nu en in de toekomst uitwisselbaarheid en toegankelijkheid gewaarborgd zijn.

Het doel van de W3C aanbevelingen

De W3C stelde aanbevelingen zoals XHTML en CSS op om er voor te zorgen dat het web niet gefragmenteerd zou raken: niet meer en meer verschillende browsers en toepassingen die elkaar niet verstaan, maar daarentegen een web dat voor iedereen werkt, zoals voorzien door Tim Berners–Lee, de man die het web uitvond.

De enige manier waarop wij ontwerpers en bouwers onze bijdrage kunnen leveren aan het bereiken van dit nobele streven is door het naleven van de aanbevelingen, terwijl we ons best doen om er voor te zorgen dat onze sites zo goed mogelijk werken in browsers die zich niet houden aan de standaarden.

Elke site is anders

Natuurlijk is het zo dat elke site anders is en natuurlijk moet je je referrer logs goed bekijken en praten met je klant (of je baas als je intern werkt) om het optimale moment te bepalen waarop je gaat switchen van het ouderwetse, niet–gestandaardiseerde web design naar de door het W3C aangeraden methodiek.

De manier die beschreven wordt in de NYPL Style Guide (valide XHTML, tables voor de basis–layout, CSS voor alle andere dingen) werkt in elke browser, hoewel het ontwerp er minder goed uit kan zien in 4.0 en oudere browsers. Ik volg deze methode zelf vaak wanneer ik een site ontwerp voor klanten en adviseer hem ook wanneer ik als consultant wordt ingehuurd: het is dé manier om documentstructuur in te bouwen in grootschalige sites met veel content en deze voor te bereiden op de toekomst.

De methode die we bij A List Apart gebruiken (XHTML voor structuur, CSS voor layout en ontwerp) zorgt er daarentegen voor dat iedere lezer toegang heeft tot de tekst van de site, maar staat toe dat het ontwerp volkomen verdwijnt als de browser er niet mee om kan gaan. En er is niet één 4.0 browser die er mee om kan gaan.

Wij nemen maar aan dat mensen die er voor kiezen om 4.0 browsers te blijven gebruiken daar hun redenen voor hebben; we nemen ook aan dat de meeste van deze mensen zich niet erg bezig houden met een mooi ontwerp. Ze willen gewoon de informatie vinden die ze zoeken, en met de aanpak die wij hier gebruiken vinden ze die informatie ook. Het is zelfs zo dat het percentage mensen dat ALA bezoekt met Netscape 4 gestegen is (van ongeveer 6% naar ongeveer 11%) sinds we het ontwerp onzichtbaar hebben gemaakt voor niet–gestandaardiseerde browsers, in februari 2001.

A List Apart is een niet–commerciële site; we hebben deze site op deze manier opgezet om andere ontwerpers te prikkelen om na te denken over het heden en de toekomst van het web, in plaats van je altijd uit de naad te werken om maar tegemoet te komen aan oude, niet–gestandaardiseerde browsers.

Als we willen dat onze sites toekomst hebben, moeten we ons in onze bouwmethodes richten naar de toekomst (XML, scheiden van structuur en uiterlijk) in plaats van naar het verleden (er precies hetzelfde uitzien in elke browser, ongeacht de schade die dit berokkent aan documentstructuur, uitwisselbaarheid en toegankelijkheid).

Voor meer informatie over web standaarden: zie The Web Standards Project en vooral het W3C. Je kunt ook verder zoeken in de A List Apart-artikelen die je in de “Related Stories” (naast het artikel) vindt.

Veel succes en nogmaals bedankt voor je brief.
Jeffrey

Dit artikel verscheen eerder in: A List Apart

• Home
• Artikelen
• Colofon