Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

HTML5 alleen is niet zaligmakend

 

HTML HTML5 developer ontwikkelaar

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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4774400). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

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.

@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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×