Now when we look at new things added to HMTL, new features, new browser APIs, what we tend to ask, of course, is: how well does it work? How well does this thing do what it claims it’s going to do? That’s an excellent question to ask whenever you’re evaluating a new technology or tool. But I don’t think it’s the most important question. I think it’s just as important to ask: how well does it fail?
—Jeremy Keith

HTML validatie

Streefdoel: valide code;
https://html5.validator.nu (enkel online validatie) of alternatief https://validator.w3.org (zowel online als via file upload of tekstvak);;
uitgewerkt voorbeeld (probeer eerst zelf).

HTML-code laten nakijken.

Je typt een URI in. De browser vraagt dan aan de webserver het gevraagde HTML-bestand. Dit bestand wordt dan gelezen door de browser en verwerkt tot een boomstructuur (ouders, kinderen, …). Maar wat als deze ontvangen HTML-code fouten bevat omdat de front-end developer die ze schreef niet aandachtig was of het niet belangrijk vond?

Browsers zijn zeer complexe stukken software, o.a. omdat een browser probeert om foute HTML-code zo goed mogelijk te interpreteren. Mogelijk zie je zelfs aan de uiteindelijke lay-out van de pagina op het scherm niet dat er iets fout was. Maar het is evengoed mogelijk dat er heel wat mis loopt met de lay-out.

HTML-code laten nakijken kan eenvoudig door een stuk software, validator genaamd. Die kan je wijzen op dingen die niet toegelaten zijn, op een stomme typfout, op een element dat niet correct afgesloten is enz. Het is natuurlijk perfect mogelijk om rommelcode te schrijven die geen fouten bevat. Maar het zou een basishouding van elke developer moeten zijn om code zoveel mogelijk te testen. Zeker als het zo eenvoudig is, zoals in het geval van de HTML-validator. Vooraleer je voor dit OPO je code afgeeft, kijk je dus elke pagina in de HTML-validator na op fouten!

Een uitgewerkt voorbeeld

Bekijk onderstaande code. Ze bevat een aantal HTML-fouten. Vind je ze allemaal? Onder de code tonen we in een filmpje hoe we te werk gaan in de HTML-validator. Via ‘Toon / verberg oplossing’ kan je zelf al beknopt controleren of je alle fouten terugvond.

Stomme typfout in de sluittag van head;
elke head moet verplicht een title hebben;
een ul mag alleen li elementen bevatten, de p moet dus weg;
elke img moet verplicht een alt attribuut hebben (desnoods leeg);
de validator houdt niet van het attribuut loading in de Google-iframe, dus verwijder dit;
er is een waarschuwing (‘warning’) dat de section geen titel heeft, maar dat is dus geen fout;
de body is niet netjes afgesloten, wat geen fout is (maar wel slechte programmeerpraktijk).

<html lang="nl">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</haed>
<body>
  <header>
    <h1>HTML met syntaxisfouten</h1>
  </header>
  <main>
    <section>
      <ul>
        <p>Er zijn heel wat dingen die fout kunnen lopen:</p>
        <li>typfout in de naam van een element;</li>
        <li>elementen vergeten te sluiten;</li>
        <li>enz</li>
      </ul>
      <p>Laat daarom je code altijd nakijken door een stuk software dat weet 
      wat er kan en moet in HTML: een validator. We gebruiken die van 
      <a href="https://html5.validator.nu">html5.validator.nu</a>.</p>
      <p><img src="img/foto2.jpg"></p>
      <p>Je vindt UCLL Campus proximus in Haasrode.</p>
      <iframe src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d2519.
      193996470273!2d4.7258333163305615!3d50.
      84609176665782!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.
      1!3m3!1m2!1s0x47c166ba515fdd4d%3A0xb2dba6fd812b1730!2s
      Hogeschool%20UCLL%20-%20Campus%20Proximus!5e0!3m2!1snl!
      2sbe!4v1642955623429!5m2!1snl!2sbe" width="600" height="450" style="border:0;" 
      allowfullscreen="" loading="lazy"></iframe>
    </section>
  </main>
</html>

Soms is de validator die ik in onderstaand filmpje gebruik (https://html5.validator.nu) niet bereikbaar. Bovendien werkt die enkel met online bestanden, wat dus betekent dat je die HTML-bestanden eerst op de server moet zetten. Een alternatief is de (even goede) validator van het W3C: https://validator.w3.org.

Valideer!

Streef naar foutloze code. Een goed beginpunt is codevalidatie. Dat kan zowel voor HTML als later voor CSS. Valide code is geen synoniem voor goede code. Het is niet moeilijk om valide code te schrijven die inhoudelijk (semantisch) niet OK is. Zo is het bvb perfect mogelijk om een hele site te maken met in body voor de lay-out enkel het div element. Maar of dat een goed idee is …

Zullen we er een hoofdregel van maken? Voor dit OPO geef je gevalideerde code af. Code (laten) nakijken is iets dat je geregeld doet en dat een belangrijk onderdeel van je workflow moet worden. Het is niet omdat je code vorige week in orde was, dat dat nu na enkele toevoegingen nog zo is.

In dit verband een kleine waarschuwing voor iets wat ik geregeld hoor. Een student heeft een site met alle code gevalideerd. Vlak voor de deadline moet er nog iets klein toegevoegd of verbeterd worden. Vaak vindt men het dan niet meer de moeite om nog een keertje te valideren. Een fout is echter zo snel gemaakt. Daarom: maak van validatie en testing in het algemeen het laatste wat je doet vooraleer een site in productie gaat.