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
@JanvanLeeuwen Ben zelf in de weer geweest met WebSockets (icm Python) en het was me al duidelijk dat niet iedere browser hetzelfde protocol praat. Ik denk wel overkomelijk verschillen maar onprettig als energie in die verschillen opgaat. Het gaat ook om iets relatief nieuws en hoop dat toch dt de tijd zijn werk doet en op termijn het meest recente protocol door een ieder ondersteund wordt.
Maar dan nog, ik denk nog dat HTML5 genoeg en meer biedt om de concurrentie met native apps aan te gaan. Via het artikel en de reacties iig weer nieuwe dingen ontdekt. Dat is toch wel mooi aan de IT, er is meer dat je niet weet dan je wel weet en iedere dag leer je weer wat.
De reden dat er codegeneratoren zijn is dat het uitcoderen van html5, css3 en javascript niet meer van deze tijd is. Tenminste: op het laagste niveau. Ik denk dat de meesten ook allerlei frameworks gebruiken die ook allerlei overhead en redundantie bevatten. Soms wat overdone, maar wel productief. Deze kunnen alle genoemde uitzonderingen, exoten en verouderde versie opvangen.
Het spijt me Leen, maar dat de generatoren alle uitzonderingen etc. opvangen kunnen is een sprookje uit de verkoopfolder van die generatoren.
Kontroleer maar eens de kode die er uit komt.
Wie je verteld heeft dat het “uitcoderen” (wat is dat nu weer?) van HTML5, CSS3 en javascript niet meer van deze tijd zou zijn, was nog nooit in internet op ontwikkelaars fora. Zelfs met Joomla/Wordpress/Drupal/Typo3 is een behoorlijke kennis van de basistechniek vereist om ze bedrijfsmatig in te zetten.
Je reaktie verklaart waarom ik zoveel sites vindt die niet eens door de html- of css-validering komen en daar 300 fouten of meer laten zien.
Daar wordt Google niet blij van en dus ook je ranking niet.
HTML5 is helemaal niet de toekomst, het is al het heden. Misschien niet bij bedrijven en zzp’ers die zich richten op CMS’en en dergelijke, maar wel bij kleine, innovatieve bedrijfjes (en zzp’ers). Het wordt ook steeds makkelijker (en mooier!) gemaakt met nieuwe open source bibliotheken, zoals Leaflet dat gebruik maakt van de Canvas, of D3JS voor SVG data visualisatie. Wel zal inderdaad veel functionaliteit nog steeds aan de serverkant geimplementeerd zijn. Jouw taxi is een leuk voorbeeld: zijn locatie is leuk, maar je wilt dat de centrale de locaties ziet en op basis daarvan een taxi naar een klant kan sturen. De route naar de klant komt dan uiteraard uit een cloud service.
@Jan: het blijven uitcoderen van al die uitzondering is zonde van de tijd. Tijd die je nuttig kunt gebruiken voor mooie en leuke functionaliteit.
Het is nog steeds zo dat we het oplossen van al die problemen leuker vinden dan productief goede en nuttige software maken. Je bent een held als je responsive software kunt maken. Dat moeten frameworks doen en wat mij betreft generatoren, geen typewerk van senior software engineers.
Dat je zoveel sites vindt met problemen komt juist doordat het allemaal handwerk blijft.
@Leen,
juist niet, de sites met de vele fouten komen uit generatoren/frameworks.
Dat kun je vinden in de bronkode van dat soort sites.
Op maat maken voor verschillede browsers etc. doe je met kode blokken die iedereen al x maal heeft ingezet en gebaseerd op de vraag of je die doelgroep wel wilt aanspreken.
Hopen kode erin smijten om iedereen te bedienen leidt tot een situatie waar de verhouding inhoud tot kode onder de 5% daalt, vraag google eens wat dat voor je seo betekent.
Je bent (G)een held als je responsive software kunt maken, het betekent dat je kunt lezen. Mediaqueries is geen toverij maar een beetje nadenken en dat dan omzetten.
@Jan: JavaScript is inmiddels de front-end ontgroeid en stuwt op naar de server-side. E.e.a. wordt netjes uiteengezet in een blog van Kurt Cagle, zie: http://blogs.avalonconsult.com/blog/generic/why-javascript-is-the-future-of-enterprise-computing/
Geen enkele technische oplossing is zaligmakend. HTML is sinds lang een standaard en het is al lang knap dat vrijwel alle browsers een acceptabel beeld van de gemiddelde website, webshop of webapplicatie maken.
De aanbieder van content zal altijd een bepaalde doelgroep voor ogen hebben. Zo al hij, als het goed is, zijn content geschikt maken voor de techniek of het platform dat de doelgroep gebruikt. Of zijn content moet zo interessant zijn dat de doelgroep bereid is om een technische switch te maken.
HTML5 biedt als standaard behoorlijk wat mogelijkheden om ook media als video goed aan te beiden. De tabel en bovenstaande discussies geven al aan welke technieken dan beter wel of niet kunnen worden gebruikt.
Kortom.. stem af op wie je wilt dat je content bekijkt en je bent klaar 🙂
Bedankt Luuk,
dat probeer ik Leen dudelijk te maken. Beweren dat je voor iedere browser en ieder platform je content aan MOET bieden vind ik verkeerd.
Als je daar generatoren voor gebruikt krijg je zoveel kode dat de verhouding content tot kode onder de 5% daalt, de laadtijd voor pagina’s onacceptabel wordt en je dus je doelgroep geen dienst bewijst.
Dat HTML5 de standaard wordt is duidelijk maar het hangt van de browser-ondersteuning af.
Bedankt Ralf Meelker,
deze aanvulling laat een goede richting zien, nu maar hopen dat steeds minder gebruikers javascript blokkeren want dat zie ik toch regelmatig.
Ik ben het met de schrijver van het artikel eens, wanneer javascript of iets dat er op lijkt aan de serverkant werkt, wordt dat de standaard defacto.
Het zou een hoop problemen oplossen.