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
Jan,
Leuk artikel. Wat voor mij interessant is, is te weten wat is je visie omtrent het web-based maken van applicaties in de toekomst. Hoe zie je de plek van HTML5 in dit kader? Als HTML5 niet de juiste oplossing is wat denk je dat het wel de juiste oplossing/middel is om applicaties daarmee onafhankelijk van de onderliggende OS en binnen je browser aan te bieden?
HTML5 en CSS3 zijn de komponenten voor de presentatie, funktionaliteit leg je daarachter met PHP, Perl, Java-applets (Dalvik), Ruby of wat dan ook.
Wat vooral belangrijk is dat er een standaard komt/is/blijft die door alle grote browsers geaccepteerd wordt, daar zit het patent-belaste h264 voor video behoorlijk in de weg, firefox weigert het terecht te gebruiken.
Web8 of ogg zijn betere alternatieven voor het web.
Wanneer toegelaten wordt dat er met patenten afgeschermde formaten in de standaards opgenomen worden, dan is dat het einde van een globale communicatie daarmee wordt de digitale kloof vergroot.
HTML is een middel en zelfs een goed middel, voorop gesteld dat er open standaards gebruikt worden die door alle browsers ondersteund worden anders zijn we terug bij de problemen van IE6.
Jan, leuk artikel, wist niet dat je zoveel met HTML5 bezig was.
Wat ik denk dat Reza bedoeld met zijn vraag: Momenteel worden er veel apps ontwikkeld voor IOS, Android en bijvoorbeeld Windows Modern UI (Windows Phone en Windows 8). Dit is niet handig omdat een bedrijf dat heel veel en breed moet investeren om voor elk platform applicaties te schrijven. Native apps functioneren echter in de regel wel weer beter dan HTML 5 apps. Vandaar die spagaat waarin bedrijven nu zitten.
HTML5 lijkt hierin een belofte, maar wordt toch nog niet massaal opgepakt om diverse redenen waarover jij ook schrijft.
Wat moeten bedrijven nu doen om deze impasse te doorbreken? Wat zijn de keuzes en alternatieven? Wat denk je dat de toekomst heeft?
De browser is aan de ene kant primitief en moet het hebben van de grootste gemene deler, ofwel functionaliteit die platform onafhankelijk is en daardoor niet kan profiteren van de sterke kanten van bijvoorbeeld een OS. Ook het realiseren van rijke ervaring die op alle browsers werkt is zeker niet triviaal. Aan de andere kant is de kracht wel van een browser dat elk device er 1 heeft. Dus een slimme browser applicatie kan dus veel breder gebruikt worden dan een app voor een specifiek platform.
Zelf geloof ik dat er een nieuw soort browser komt die wel rijke en krachtige functionaliteit ondersteund, maar ook op elk device kan draaien. Een nieuwe standaard, maar die niet zo primitief is als bijvoorbeeld de HTML standaard.
Ik zou mijn centjes nog niet durven zetten op native apps of HTML5…
Henri & Jan,
Wat ik er mee bedoelde is het aanbieden van applicaties/desktop binnen HTML5 i.p.v. apps of traditionele desktop. Een product dat hier goed bezig mee was en al een tijd overgenomen is is InstallFree Nexus.
De technologie en oplossing van deze jongens waren heel goed. Ik ben benieuwd waar ze mee zullen komen.
Terug naar Jan, hoe zie je de toekomst van applicaties en desktop streaming via HTML5?
Ik verwacht dat zowel web apps als native apps richting HTML5 gaan. Met JavaScript als de standaard implementatie (van ECMAScript) in HTML5 (als forked subset van de HTML Living Standard) en de beschikbaarheid van native containers (uiteenlopend van PhoneGap tot, jawel daar is ie dan, Windows 8) lijkt het onderscheid tussen web en native qua taalkeuze steeds minder relevant. Wellicht moeilijk te slikken voor ‘echte’ programmeurs die in het verleden een allergie voor JavaScript hebben ontwikkeld, maar de tendens is zichtbaar. ECMAScript dialecten zoals Google Dart en Microsoft TypeScript kunnen de verbeteringen van toekomstige ECMA versies stuwen, maar ik durf mijn centen wel op HTML5+JavaScript (en CSS3) in te zetten. Sterker nog, het zou mij niet eens verbazen als full blown line-of-business applications ook die kant op gaan. Enfin, niemand heeft een glazen bol die de toekomst voorspellen kan… maar ik meen een tendens te zien.
Zoals ik al zei, HTML en CSS zijn er voor de presentatie, niet voor de funktionaliteit. Daarvoor gebruik je Java, Javascript, PHP, Perl, Ruby etc.
Pas bij het samengaan ontstaat een app.
Waarbij opgemerkt moet worden dat javascript op de client draait en niet op de server, daar heb je voor een goede app ook een scripttaal nodig. Uitwisselen van data tussen server en client is nog steeds een ramp.
Dat browser-georienteerd werken de toekomst heeft geloof ik in beperkte mate, niet ieder programma is daarvoor geschikt. Het is de inkompatibiliteit van browsers die roet in het eten gooit.
De oorzaken daarvan zijn over het algemeen afscherming van de eigen belangen, dat doen MS, Adobe maar zelfs Google.
Voor alle eerlijkheid moet ik bekennen dat ik zoveel als het maar gaat probeer klanten op browser-georienteerde programma’s te krijgen die bij voorkeur bij een webhoster staan. De volgende stap is de cloud maar hier in opper-oostenrijk duurt dat nog even.
Ik ben pas geleden bezig geweest met het maken van hybrid apps voor mobile met html5/javascript/css/cordova m.b.v. IBM Worklight en de SDK van Blackberry (ook te gebruiken met de SDK van Android en IOS). Door dit te combineren met libraries van JQuery en/of Dojo kun je de meeste problemen met verschillende browsers ondervangen. De SDK’s maken er dan echte mobile apps van.
Ik herken de problemen uit jouw artikel natuurlijk ook. Maar toch lijkt de industrie zwaar in te zetten op HTML5. De trend is toch dat de desktops/laptops vervangen worden door tablets en smartphones en die hebben in ieder geval moderne browsers die inzetten op html5. Hiermee wordt de belangrijkheid van de grootste onruststoker op browsergebied van de laatste 10 jaar Microsoft met IE minder. Ook de nieuwe Firefox OS en Ubuntu Touch gaan voor html5. Ik zou aanraden dit goed in de gaten te houden.
Geolocation hoort trouwens officieel niet bij HTML5.
Bedankt Cees voor de aanvullingen.
Inderdaad de browsers op telefoons en tablets zijn moderner en ondersteunen meer, tenzij het apple is . . . ! Vergeef het me ik heb wat moeite met apple.
De w3c beschrijft de “Geolocation API Specification” en of het in, of net niet in, HTML5 zit is minder interresant dan het gegeven dat je daarmee apps kunt bouwen die “de dichtsbijzijnde xyz” kunnen vinden.
Ik heb met een taxi-ondernemer te maken en kan daar misschien een oplossing bieden.
Dat HTML5 zowel HTML4.01 als XHTML gaat vervangen is duidelijk, maar hoelang dat gaat duren is een open vraag gezien het tempo waarmee dit soort standaards in het verleden aangenomen zijn.
@JanvanLeeuwen Leerzaam artikel en reacties. HTML5 Is misschien niet zaligmakend maar ik denk wel dat er een toekomst is. Vind het iig een leukste dingen van dit moment. Zeker in combinatie met Javascript zijn er mooie mogelijkheden . Ben daar erg enthousiast over. Lees allemaal onbekende nieuwe dingen over HTML5. De context specifieke elementen zijn mooi, bijna html ouwe stijl. Tegenover de meer abstracte tags. Local storage is handig. En over communicatie gesproken, de websockets is een mooie uitbreiding. De mogelijkheden om van de extra functionaliteit van de mobiele apparaten te gebruiken zijn aantrekkelijk. Denk dat de html5 javascript server side software combinatie voldoende mogelijkheden biedt om een applicatie te maken.
En die vele standaarden, het houdt ook nooit op. Het lijkt er wel eens op dat de een aantal grote softwaremakers elkaar zoveel mogelijk in elkaars vaarwater willen zitten. Dat met de videoformaten. Maar toch een hoop zaken gelijk zeker met de libraries die je afschermen van de ellende die voor mijn gevoel steeds minder wordt. Nog een goede reden voor de HTML5 Javascript combinatie.
En eens, van codegeneratoren wordt je inderdaad niet altijd blij. Maar voor de rest ben ik minder somber.
@ Louis Kossen
Bedankt voor de verdere aanvullingen.
Bij Websockets begrijp ik je enthousiasme maar ook daar is de ondersteuning van browsers nog niet zoals die zijn moet helaas.
Probeer maar eens op een PC met Chrome, dat werkt en met Firefox niet.
Het enige waarover ik somber ben is de neiging van grote spelers om hun implementatie niet standaardconform te maken en het blokkeren van standaards defacto vanwege dubieuze patenten.
Het web moet open blijven, daar zit de kracht.
Over HTML5 ben ik best enthousiast maar met enkele kanttekeningen, alle nieuwe websites/webprogramma’s maak ik met HTML5, dat spreekt voor zich.