World Wide Web standaarden!
Kees Grinwis pluist een website uit

In toenemende mate wordt het internet belangrijker, vrijwel niemand kan zich meer een wereld zonder e­mail voorstellen. Ook het 'world wide web' neemt een steeds belangrijker plaats in, ook hier geldt dat men moeilijk kan voorstellen hoe men zonder het web (van informatie) moet leven. In dit artikel hoop ik in te gaan op het nut en de noodzaak van standaardisatie, hierbij hoop ik met name rond de web-standaarden een en ander duidelijk te maken.

Om maar gelijk een mogelijk misverstand te voorkomen, dit artikel zal u niet helpen om een website te kunnen openen die niet goed (of helemaal niet) aan de webstandaarden voldoet. Met dit artikel in de hand is het niet mogelijk om een door Word gegenereerde HTML pagina goed te bekijken in een RISC OS browser, dit is zelfs voor de niet-Microsoft browsers op het MS-Windows platform al niet eens mogelijk!

Misschien vraagt u zich nu wel af wat ik in dit artikel dan wel hoop te behandelen. Wel, dat is hoe het mogelijk is om een website te maken die wel voldoet aan de standaarden, zodat iedereen deze kan openen - ongeacht welke browser er gebruikt wordt! Ik hoop dit te doen aan de hand van diverse voorbeelden, zodat ook gelijk duidelijk wordt hoe moeilijk (of makkelijk) het is om een website te maken die aan deze standaarden voldoet. Als dit mogelijk is natuurlijk!

Voor ik hiermee verder ga moet ik nog wel één mogelijk misverstand uit de weg ruimen, als een site niet goed afgebeeld wordt in een RISC OS browser (zoals ANT Fresco, WebsterXL, Oregano of Webite), is het niet altijd de schuld van de website-bouwer. Ondersteuning van RISC OS browsers voor alle, en dan met name de meest recente, standaarden is er helaas [nog] niet.

Om te beginnen zal ik aangeven welke site bij het ontwikkelen en/of valideren van een website heel erg handig (danwel noodzakelijk) is, dat is de validator van het World Wide Web Consortium (W3C). Deze site maakt (helaas) ook gelijk goed duidelijk dat de meeste RISC OS browsers de web standaarden [nog] niet volledig beheersen. Om dit goed duidelijk te maken zal ik een schermafbeelding van Oregano en Mozilla plaatsen.


(Oregano 1.10 op RISC OS)

(Mozilla 1.2.1 op MacOS X 10.2)

Zoals uit deze afbeeldingen te zien is verschillen de browsers nogal van mening over hoe de pagina opgemaakt moet worden. Helaas voor ons RISC OS gebruikers is de afbeelding van Mozilla de beste, dit komt voornamelijk omdat in de browsers voor ons platform de ondersteuning voor CSS nog steeds erg summier is.

Toch toont deze site ook aan dat het mogelijk is om een website te bouwen die gebruik maakt van de modernste technieken, maar toch goed af te beelden op browsers die al weer enige tijd oud zijn. In een volgend artikel zal ik, als het om dit soort constructies gaat, de omgekeerde weg gaan bewandelen: Namelijk het maken van een website met technieken die voorhanden zijn in browsers als Fresco, Oregano en WebsterXL, maar extraatjes voor gebruikers van browsers die wel de nieuwe standaarden aankunnen zoals de laatste versies van Mozilla, Konquerer, Safari, Opera en Netscape.

Om te beginnen gaan we eens kijken naar de startpagina van de site van de Big Ben Club, deze site hebben we allemaal wel eens bezocht dus moet toch eigenlijk wel bekend zijn. Het opgeven van een bestaande internet-site in de W3C-validator is erg simpel, namelijk simpelweg het invoeren van de URI in het invoerveld met de naam 'Address' en op de knop 'Validate URI...' drukken. Op het moment van schrijven komen er wel een aantal fouten in de site naar voren. We zullen deze stap voor stap doorlopen en er een oplossing voor vinden.

Om te beginnen wil de validator niet eens wat met de pagina doen, dat komt namelijk omdat er een aantal structurele fouten in zitten. Pas als we deze fouten gecorrigeerd hebben kunnen we de pagina zelf laten controleren. De fouten zijn te vinden in de header van de pagina (dat is het gedeelte dat voor de <body> tag staat in een website), door deze te verwijderen kunnen we de pagina verder valideren. Gelukkig kunnen we dat ook opgeven op de website van de HTML validator, zoals te zien is in de onderstaande afbeeldingen.

Nadat we de ontbrekende (of foutieve) code toegevoegd hebben kunnen we de pagina nogmaals laten valideren, zoals te zien is weet de validator nu wel welke 'Doctype' en 'Encoding' er gebruikt wordt.

Op het moment van schrijven zitten er in deze ene pagina (bijgevoegd als normaal tekst-bestand zodat u deze kunt bekijken) 11 fouten, die allemaal niet nodig geweest zouden zijn. Het zijn namelijk geen uitbreidingen op de standaard die door de meeste (zo niet alle) browsers gebruikt en herkend worden - hierover later meer. Het zijn simpele syntaxis fouten, die in iedere andere programmeer- of markup- taal foutmeldingen zou genereren, de meeste code in browsers wordt dan ook besteed aan het corrigeren van fouten die door schrijvers van HTML gemaakt worden.

Ik zal deze punten groeperen per fout en deze in het kort toelichten.

1. Line 25, column 11: document type does not allow element "H4" here; missing one of "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag

          <H4><B> ENTER </B></H4>
             ^

Met deze constructie lijkt niets mis te zijn, toch zit er een fout in. Wat er namelijk gebeurt is dat er een "<h4>" tag gebruikt wordt binnen een "<a href...>" tag. Deze constructie is binnen HTML verboden, binnen een "<a href..." mogen geen anders tags voorkomen die de blok-structuur van de pagina beïnvloeden. De tags die hier niet onder vallen zijn: font, b, u, i en strike.

De tweede fout is het gebruiken van een ampersand tekentje in de HTML broncode, een ampersandje (&) is evenals een kleiner en groter dan teken een speciaal HTML/SGML teken en mag dus niet zo maar gebruikt worden.

2. Line 30, column 70: cannot generate system identifier for general entity "Body"

.="mailto:postbus@bigbenclub.nl?Subject=wwwInfo&Body=Hallo%20BBC%20postbus,">
                                                ^

Deze fout is overigens eenvoudig op te lossen, namelijk door het vervangen van alle enkelvoudige ampersand-tekentjes door de HTML entity "&amp;". Voor de website zelf veranderd er niets, want de browser converteert alle bekende entities naar het bijbehorende karakter.

De punten 3, 4 en 5 gaan over dezelfde fout, dus deze kunnen we verder negeren.

Het volgende punt lijkt opnieuw niet echt fout te zijn, ook hier geldt echter dat de computer altijd gelijk heeft. :-)

6. Line 78, column 14: invalid comment declaration

  <!-- Title: --Big Ben Club -->
                ^

De fout is namelijk het gebruik van twee streepjes "--" achter elkaar in een commentaarblok, deze twee streepjes hebben dan namelijk een speciale betekenis. De volgende tekenreeks "-->" geeft namelijk het einde van een commentaarblok aan, en om die reden mag men niet zomaar twee streepjes achter elkaar plaatsen. Weghalen van deze streepjes verandert niets aan de site, dus verwijderen we ze gewoon.

Punt zeven is weer gerelateerd aan punt 6 en geeft alleen maar aan waar met het commentaar begonnen is, ook deze kunnen we dus verder negeren.

De volgende twee foutmeldingen, fout 8 en 9 gaan over hetzelfde probleem. Hier wordt redelijk duidelijk aangegeven wat er mis is, zoals te zien is in de onderstaande foutmelding. Het attribuut "type" moet nog toegevoegd worden, maar verdere uitleg ontbreekt helaas nog.

8. Line 80, column 71: required attribute "TYPE" not specified (explain...).

  ...ipt" src="http://m1.nedstatbasic.net/basic.js">
                                                   ^

Welke attribuut we toe moeten voegen is ons al verteld, maar wat er voor gegevens in moeten is niet aangegeven. Toch is het voor mij direct duidelijk, ik ga proberen om dit nu ook voor de lezer te verduidelijken.

Het is namelijk mogelijk om meerdere soorten scripts te draaien in een HTML pagina, de algemene standaard is JavaScript, maar andere mogelijkheden zijn er ook. Voorbeelden zijn VBScript (IE) en PerlScript. Nu is het attribuut "language" nooit gestandaardiseerd en iedereen mag daar invullen wat hij of zij leuk vindt. Om toch standaardisatie mogelijk te maken heeft men het attribuut "type" toegevoegd en hiervoor een MIME type verplicht gesteld.

Het MIME type van JavaScript is "text/javascript" dus door de volgende tekst toe te voegen (type="text/javascript") is ook deze fout opgelost.

10. Line 87, column 90: "NOSAVE" is not a member of a group specified for any attribute (explain...).

  ...cC4ClRbEiVkXajV1A" border="0" nosave width="18" height="18">
                                          ^

Punt 10 is simpel op te lossen, namelijk het weghalen van de "nosave" tag. Hier wordt duidelijk gebruik gemaakt van een browser-specifieke tag die weinig toevoegt aan de werking van het geheel. Verwijderen is dan ook geen enkel probleem.

11. Line 87, column 112: required attribute "ALT" not specified (explain...).

  ...der="0" nosave width="18" height="18">
                                          ^

De laatste fout is ook eenvoudig op te lossen, namelijk gewoon een lege "alt" tag toevoegen. Hoewel het plaatje verder niet belangrijk is, moeten alle plaatjes voorzien zijn van een alternatieve tekst - ook al is deze leeg.

Het resulterende HTML bestand heb ik voorzien van nog één extra HTML tag, zodat de browser denkt dat hij de pagina opgehaald heeft van http://www.bigbenclub.nl/. Deze tag is overigens geheel volgens de standaard, dus de pagina blijft OK. Als u de pagina opent en op een van de links klikt gebeurt er precies hetzelfde als wanneer u naar de Big Ben site gegaan zou zijn.

Overigens zit er in de pagina ook nog een conceptuele fout, waardoor de Nedstad teller niet meer getoond wordt, dit heb ik uiteraard ook gefixed en de bewuste file bij het artikel gevoegd.

In dit artikel heb ik geprobeerd om, aan de hand van een praktijkvoorbeeld, uit te leggen hoe men een webpagina kan laten controleren op fouten. Door uw eigen pagina door de validator te halen en de fouten te corrigeren neemt het aantal websites die 95 tot 100% correct zijn verder toe, zodat het einddoel van een world wide web die met alle mogelijke browsers bekeken kan worden weer een stapje dichterbij komt. Uiteraard moeten deze browsers nog ook aan de standaarden voldoen.

Indien gewenst kan men zelfs aangeven dat men de moeite genomen heeft om aan de standaarden te voldoen door dit aan te geven via een 'This page is valid ???' afbeelding, zoals te zien is aan het begin van deze alinea.

Laten we vooral ons best blijven doen onder het motto: "Alles kan beter!"