Om te verduidelijken wat html5 voor webontwikkeling betekent, heb ik een aantal stukken tekst van internet gehaald die ik aanvul met ervaringen uit de praktijk. Het valt namelijk op dat er heel veel over html5 geroepen wordt maar meestal niet door de mensen die er in de praktijk mee moeten omgaan.
Een van de peilers van mijn bedrijf is het maken van websites/webapplicaties en/of het aanpassen van cms’en/webapplicaties aan de wensen van klanten door middel
van modules en/of met zelf in PHP geschreven oplossingen. Maar goed, eerst even wat achtergrond over html5.
De html5 specificatie is tot stand gekomen in een samenwerking tussen het World Wide Web Consortium (W3C) en de Web Hypertext Application Technology Working Group (WHATWG). WHATWG was aan het werk met web forms en applications, en W3C was aan het werk met Xhtml 2.0. In 2006 besloot men daarvan een nieuwe versie van html te maken. Tot die tijd werden hoofdzakelijk html 4.01, Xhtml1 en Xhtml 1.1 gebruikt, Xhtml wordt nog steeds heel veel gebruikt (56,6 procent volgens w3tech) omdat het door de meeste webbrowsers goed ondersteund wordt.
De nieuwe mogelijkheden voor html5 moesten gebaseerd zijn op html, CSS, DOM, and JavaScript; het aantal externe plugins (zoals Flash) reduceren; een betere fout afhandeling realiseren; meer markup (tags) hebben die scripts zouden vervangen en apparaat-onafhankelijk zijn.
Het idee is goed, wat daarvan tot nog toe terecht gekomen is vinden we terug in internet, waar vele sites nog nauwelijks aan deze wensen voldoen.
Als meest interessante nieuwe mogelijkheden in html5 worden volgende punten genoemd:
1. Het <canvas> element voor 2D
Veel heb ik daarvan nog niet zien terugkomen bij controle van de broncode van websites, het vullen van een rechthoek met grafische effecten door javascript is klaarblijkelijk niet geliefd, omdat hetzelfde eenvoudiger bereikt kan worden met een schaalbaar grafisch bestandje.
2. De <video> en <audio> elementen voor media playback
Dit zie je inmiddels wel veel terugkomen alhoewel er de nodige haken en ogen zijn. Wil je een video op je site aanbieden die in (bijna) iedere browser werkt, dan ben je nog steeds verplicht om een terugval-systeem te bieden dat werkt naar het principe probeer één, werkt dat niet dan twee, werkt dat niet dan drie, enzovoort. Je hebt je video dan in vier formaten nodig, mp4 (met de patent-belaste h264 codec), webm, ogg, flv (en een flash-videospeler). De reden is dat de ene browser dit niet wil afspelen en de andere dat niet, op apple werkt flash helemaal niet meer.
Een overzicht met veel te veel No's
Video met een eigen tag
Browser |
MP4 |
WebM |
Ogg |
Internet Explorer 9+ |
YES |
NO |
NO |
Chrome 6+ |
YES |
YES |
YES |
Firefox 3.6+ |
NO |
YES |
YES |
Safari 5+ |
YES |
NO |
NO |
Opera 10.6+ |
NO |
YES |
YES |
Audio met een eigen tag
Browser |
MP3 |
Wav |
Ogg |
Internet Explorer 9+ |
YES |
NO |
NO |
Chrome 6+ |
YES |
YES |
YES |
Firefox 3.6+ |
NO |
YES |
YES |
Safari 5+ |
YES |
YES |
NO |
Opera 10+ |
NO |
YES |
YES |
3. Ondersteuning voor local storage
Met html5, kunnen webpagina's lokaal gegevens opslaan in de browser (de cache) van de gebruiker, op zijn harde schijf of ssd. De data wordt bewaard in sleutel/waarde paren, en een pagina krijgt alleen toegang tot de data die het zelf bewaard heeft. Klinkt aardig, een webpagina mag iets lokaal opslaan dat alleen door deze webpagina te gebruiken is. Het probleem is dat iedere vorm van lokaal opslaan tevens een achterdeur naar het systeem van de client is en dus een risico.
4. Nieuwe content-specifieke elementen, zoals <header>, <nav>, <article>, <section>
Op zich een goed idee voor de leesbaarheid van html5-code. Gebruiken we niet meer <div id=’article’> maar voortaan <article>, dat is zinnig ook als het meer cosmetisch werkt als functioneel. De nieuwe semantische elementen om een webpagina duidelijker in te delen in html5 zijn: <header>, <nav>, <section>, <article>, <aside>, <figcaption>, <figure>, <footer>..
5. Nieuwe form-controls, zoals date, time, email, url, search
Wanneer je de aangegeven nieuwe form-controls op verschillende browsers probeert, zie je dat de browsers daarvoor niet klaar zijn, heel veel werkt gewoon niet. De controle op datum werkt in de ene browser wel en op de andere niet en meestal kun je toch rommel invullen die door het formulier geaccepteerd wordt.
6. De toepassing van inline SVG (Standard Vector Graphics).
Dat is een aangelegenheid die mij zeer ter harte gaat. Kleurovergangen, en alles wat zo op grafische gebied te toveren is, kun je met Standard Vector Graphics realiseren. De bestandsgrootte blijft steeds klein en de scherpte optimaal, per slot worden alleen paden en richtingen vastgelegd en niet iedere pixel. Bij design dat van een telefoon met 320 pixel tot een breedbeeld met boven de 2560 pixel goed moet werken is SVG optimaal, maar niet iedere browser ondersteunt het of in voldoende mate. Het is zelfs mogelijk animaties met SVG te maken, Google biedt met Swiffy transformaties aan van flash naar SVG. Voor wie geen Powerpoint gebruiken wil, zijn ook presentaties mogelijk met SVG. Daarvoor gebruik je Inkscape en JessyInk, die spelen dan gewoon in de browser.
7. Slepen en plaatsen (drag and drop)
Dat moet dan wel weer via Javascript gebruiken, dit ligt dicht bij het gebruik van Ajax waarbij Ajax al wat langer in gebruik is, of dit zich doorzet als html5 is af te wachten.
8. Geolocation met behulp van javascript
Voor telefoons is dit natuurlijk een punt van voordeel bij het programmeren van websites met PHP. Bijvoorbeeld is het zo mogelijk op basis van de coördinaten van het apparaat te berekenen welke van de restaurants/musea/tankstations het dichtste bij is. Het bergt ook het gevaar dat een ‘app’ in de achtergrond hele bewegingsprofielen opslaat en doorstuurt.
Samenvattend
Html5 is slechts een deel van het verhaal, bij iedere webstandaard die ingevoerd wordt horen namelijk ook webbrowsers die dat ondersteunen en daar schiet nog veel te kort. De afgelopen vijf jaar is het niet beter geworden met standaards, maar eerder slechter. Hoeveel conditional statements er nodig zijn om een website goed te laten werken op IE 6 tot en met 10, Firefox 3.6 tot 22.0, Chrome 5 tot 25, Safari x tot y enOpera 7 tot 12 is niet meer te tellen.
Spreken we over responsive design dan spreken we over CSS3 in combinatie met html5. Waar je met behulp van media-queries stapsgewijs voor verschillende schermformaten de layouts definieert, wat in de praktijk betekent dat voor vier omslagpunten vijf layouts gemaakt worden.
Hoeveel code nodig is om alles te laten werken op verschillende browsers en apparaten laat zien dat er problemen zijn om standaards te zetten en om zich er aan te houden.
Lees ik dan dat bepaalde bedrijven codegeneratoren propageren, dan wordt ik heel treurig. Een codegenerator produceert namelijk te veel code. Dat kan zo ver gaan dat van de 100 procent gegenereerde code slechts 5 procent nodig is om exact de zelfde website te maken. Wellicht zijn de moderne generatoren wat beter, maar als ik zie wat er met Wordpress op het web gesmeten wordt, waar de verhouding tekst tot code slechts 5 procent bedraagt dan heb ik mijn twijfels. Wie interesseert zich eigenlijk nog voor bandbreedte vandaag de dag?
Ik wil niemand de hoop wegnemen, maar dat alles met html5 beter wordt geloof ik niet, het is zeker een stap voorwaarts maar niet de haarlemmer olie waarvoor het maar al te graag verkocht wordt. Voortgang hangt af van de makers van de browsers en of ze zich aan standaards houden, want daar draait het om. Dan is het nodig dat er geen met patenten belaste codecs zoals h264 gebruikt worden en dat vrije formaten zoals SVG eindelijk door alle browsers compleet ondersteund worden.
Ik geef de hoop niet op, maar ervaar dagelijks dat er in vijf jaar een duidelijke teruggang te zien is in het gebruik van standaards in internet en dat is jammer.
Jan van Leeuwen, eigenaar/directeur Stajl IT