Kennis - Het online marketing blog van Tribal

Online marketing is een vak apart en een wereld die snel verandert. Wij laten ons dagelijks inspireren door de nieuwste ontwikkelingen, tips & tools en allerlei nuttige toepassingen. Hieronder lees je welke kennis wij in huis hebben.

Foutmeldingen van W3C? Zo ga je er mee om

Door: Erik Altink

Geschatte leestijd: 4 minuten

World Wide Web Consortium, ofwel W3C, is de organisatie die zich bezig houdt met het definiëren van de standaarden die op het Internet gebruikt worden. Met alle browsers, platformen, programmeertalen, etc is de kans natuurlijk erg groot dat informatie ontoegankelijk wordt wanneer iedereen maar doet wat hij denkt dat goed is. Om er voor te zorgen dat alle websites er in alle browsers (ongeveer) hetzelfde uit zien hebben we W3C.

Nu zijn er twee online kampen: het ene kamp vindt dat een website zich 100% aan de richtlijnen van W3C moet houden en de tegenstanders die vinden dat de richtlijnen wat minder strak nageleefd mogen worden, zolang het er maar (in de gebruikte browsers) goed uit ziet.

100% foutloos is altijd succes?

Het maken van een website die 100% foutloos is (volgens de W3C standaarden) is een lastige klus. In sommige gevallen betekent het concessies doen aan presentatie of het toevoegen van extra code die je eigenlijk niet nodig hebt. Het controleren van de fouten in een website is gelukkig wel heel eenvoudig. Via de W3C Validator kan je eenvoudig zien of jouw website fouten bevat (lees voor je een klacht indient bij je webbouwer eerst het artikel verder, want misschien verandert je mening dadelijk nog).

Foutloze HTML code heeft zeker zo zijn voordelen. Over het algemeen is deze code goed te onderhouden en kunnen problemen eenvoudiger worden opgespoord en worden opgelost. Een grote misvatting is alleen dat een website die 100% aan de richtlijnen voldoet er in elke browser er goed uit ziet. Dit is niet per definitie het geval omdat afspraken op meerdere manieren kunnen worden uitgelegd. Door het verschil in uitleg kan ook een foutloze website er in verschillende browsers anders uit zien.

DocTypes

De richtlijnen van het W3C bepalen hoe een website er uit zou moeten zien en omdat deze richtlijnen continu verder ontwikkeld worden zijn de afspraken vastgelegd in templates. Een bouwer van een website kan zo’n template kiezen en geeft daarmee aan de browser aan volgens welke afspraken de website gemaakt is. Deze template worden DocType genoemd en kan je terug vinden in de HTML code (de eerste regel). Het DocType bepaalt dus doe de webbouwer wil dat de browser de website weergeeft.

De Acid test

Om browsers te testen zijn er verschillende testen beschikbaar. Een bekende is de Acid test, waar inmiddels al weer 3 versies van beschikbaar zijn. Op https://www.acidtests.org/ kan je zelf testen hoe jouw browser zich aan de richtlijnen houdt (of hoe de richtlijnen worden geïnterpreteerd). De Acid2 test werd in 2005 gemaakt en zou de volgende afbeelding moeten weergeven

smily

voor de code die 100% foutloos is (wel 2 warnings)

mo-errors

Hoewel de meest moderne browsers de afbeelding (gelukkig) goed weergeven zag de afbeelding er in de oudere versies van de browsers er iets anders uit:

 

2015-07-13_1452

Zit er op je website nog publiek met oudere browsers dan kan je er dus niet van uit gaan dat 100% foutloze HTML code goed wordt weergegeven.

Browsers zijn vergevingsgezind (en eigenwijs)

Lang geleden begon het grafische web met de Mozaik browser en vanaf het begin maakten website bouwers er een zooitje van. En gelukkig maakt het ook niet zoveel uit, want de browsers vonden het allemaal wel prima. Vergat je ergens een punt of een komma en sloot je een tag niet goed af? De browser loste de problemen op en toonde de website toch zoals je bedoeld had. Met de komst van Internet Explorer en Netscape gingen de browsers eigen standaarden gebruiken en werden bouwers van websites gedwongen allerlei kunstgrepen uit te halen om een website overal goed te tonen. Het eigenwijze is er gelukkig een beetje af (in de CSS code zitten nog altijd verschillen), maar browsers vinden nog altijd heel veel goed.

Omdat browsers heel veel goed vinden is het ook geen grote ramp wanneer een website niet volledig volgens de richtlijnen is gemaakt. De browser lost het probleem wel op en de meeste fouten leiden niet tot grote problemen.

Naast de Acid testen is er ook een browser die zich volledig aan de W3C standaarden houdt (maar geen JavaScript of geanimeerde afbeeldingen ondersteund). Wil je weten wat er potentieel mis gaat met je website omdat deze zich niet aan de standaard houdt? Download de W3C Amaya browser en bekijk je eigen website. Hieronder het voorbeeld van de website Kunstgrasnet.nl.

voorbeelden-fout

Wat hier opvalt is dat er elementen op de pagina door elkaar lopen en dat de broncode zichtbaar is in de pagina. Dit hoort uiteraard niet te gebeuren (en gebeurt ook niet in moderne browsers).

De keuze voor het DocType zorgt er voor dat het iframe in de pagina ongeldige code bevat en volgens de standaard niet werkt. Aanpassen van het DocType kan in dat geval helpen om de problemen op te lossen.

voorbeeld-goed

Het is echter niet zo dat het DocType verkeerd is, maar dat de webbouwer zich niet aan de afspraak houdt die hij zelf heeft voorgesteld.

We nemen aan dat zoekmachines, net als browsers, vergevingsgezind zijn, maar controleer altijd in de Google Search Console of de Google bot de pagina inderdaad ziet zoals je verwacht dat de pagina er uit ziet.

Dus…. wat moet je er nu mee?

Er zijn dus voordelen aan goede code, maar het wordt allemaal niet heel hard afgedwongen. Dus wat moet je nu doen als webbouwer of website eigenaar?

Sommige fouten leiden wel degelijk tot problemen en deze problemen kan je meestal vinden door de website in verschillende versies van browsers te testen. Kijk in Google Analytics naar de browsers die jouw bezoekers gebruiken en test je website in ieder geval in deze versies. Haal de website ook via de Google Search Console een keer op en bekijk hoe Google de website ziet. Zie je daar geen problemen? Steek er dan niet teveel tijd in om de website foutloos te krijgen (Google doet het zelf ook niet).

Zie je wel problemen? Dan kan het nuttig zijn de website door de W3C Validator te halen en te zien welke fouten er gevonden worden. Geef vervolgens bij je webbouwer aan welke problemen je ondervindt en wat het resultaat is van de validatie. Een goede webbouwer kan vervolgens aangeven waarom de meldingen er staan en wat de gevolgen daarvan zijn.

Er kunnen goede redenen zijn om niet aan de standaarden te voldoen. In het geval van Google scheelt het een paar bytes in het gewicht van de pagina om niet aan de standaard te voldoen. In plaats van <img src=”afbeelding.jpg” /> begrijpt elke browser ook de code <img src=afbeelding.jpg>. Het scheelt alleen 4 tekens en met het aantal bezoekers dat Google per dag krijgt scheelt dat gigabytes per dag aan dataverkeer.

Heb je vragen? Laat dan een reactie achter!

Discussie- Geen reacties

Blijf op de hoogte van handige kennis en het laatste nieuws van je favoriete online marketing bureau:

INSCHRIJVEN VOOR ONZE NIEUWSBRIEF