W3C: html5-standaard is klaar

Het Worldwide Web Consortium heeft na circa vijf jaar van html5 een officiële webstandaard gemaakt. De definitieve html5-specificatie is al twee jaar beschikbaar en veel sites gebruiken de nieuwe versie van html, maar html5 had nog niet de officiële 'recommendation'-status.

Die status heeft html5 nu wel gekregen. Samen met css 3.0 en javascript moet html5 complexe webapplicaties mogelijk maken. Html5 biedt onder meer een video-tag, waarmee websites eenvoudig video's kunnen insluiten zonder dat de gebruiker plug-ins hoeft te installeren. Ook nieuw is het canvas-element, waarop bitmaps kunnen worden getekend en dat onder meer games in de webbrowser mogelijk maakt.

De W3C stelde de definitieve specificaties in december 2012 vast. Sindsdien zijn geen veranderingen in de opmaaktaal meer doorgevoerd. Wel moest het W3C nog wat knopen doorhakken, zoals de codec die voor de video-tag zou worden gebruikt. In de praktijk biedt html5 nu ondersteuning voor meerdere codecs; websites kunnen meerdere versies van een video serveren voor verschillende soorten apparaten.

De toevoeging van digital rights management aan html, iets waarvoor onder meer Netflix flink lobbyt, moet nog gebeuren. De toevoeging rekent onder meer op weerstand van Mozilla, hoewel die browsermaker heeft aangegeven de techniek met tegenzin toch te zullen implementeren. Hoewel html5-drm al in gebruik is, komt het waarschijnlijk pas in de standaard met html 5.1.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (194)

Hopelijk bevatten alle browsers straks alle functionaliteit.
Heel fijn voor development, HTML5 en CSS3.

De meeste browsers hebben al het grootste deel van de standaard geïmplementeerd,maar er is inderdaad nog een hoop werk te doen.

Ik ben benieuwd wanneer we eindelijk de prefixes van CSS3 kunnen afschaffen. Dan zou het helemaal ideaal zijn

Voor veel dingen in CSS3 zijn de prefixes dit al niet eens meer nodig.

Voorbeelden:
Border-radius: http://caniuse.com/#search=border-radius
Box-shadow: http://caniuse.com/#search=box-shadow

Spijtig genoeg zijn het wel de prefix varianten die vaak nog steeds gebruikt worden, en regelmatig zonder de standaard versie erbij.

Dat veel mensen nog steeds prefixes gebruiken wil niet zeggen dat de ondersteuning voor non-prefixed varianten er niet is. Het betekent gewoon dat veel developers maar wat aanrommelen en niet up to dat blijven met wat er wel en niet kan. Browsers kunnen ook niet ineens zomaar support voor de prefixes verwijderen omdat oudere sites dan stoppen met werken.

Ik wil daarop wel een uitzondering maken; in applicaties waar zeer brede browsersupport nodig is implementeer ik de prefixes bewust. Neem bijvoorbeeld(!) versies van Firefox ouder dan versie 12, welke nog geen silent update ontvingen. Door het implementeren van prefixes (vaak met behulp van een mixin voor een precompiler zoals LESS) kan je dus ook de browser coverage van je applicatie vergroten

Firefox <12?

Ik ben blij dat wij standaard niks verkopen dat moet werken op browsers ouder dan twee versies terug. We supporten IE9 op dit moment best effort, 10 en 11 gewoon helemaal en voor andere browsermakers doen we min of meer hetzelfde. Als een klant support wil voor archaïsche browsers moet 'ie dat aangeven en er extra voor betalen. Dat willen ze meestal niet.

Dat gezegd hebbende: ik denk niet dat we snel zo ver terug gaan als IE7 of FF12. Sommige dingen zijn de resulterende hoofdpijn niet waard.

Het wil niet zeggen dat de non-prefixed variant er niet is in de browser, maar vaak is die non-prefixed variant niet opgenomen in de CSS en dus niet toegankelijk voor browsers die de standaard willen horen.

Inderdaad, IE11 mobile heeft pas een update gekregen waarbij de browser webkit- prefixes weghaalt als deze niet ook zonder prefixes zijn opgeschreven. Zelfs bijvoorbeeld twitter deed dit.

Bij de meesten niet nee.

Probleem is dat oude devices geen update krijgen (waarschijnlijk) en je dus nog wel even aan legecy-support moet doen. Al ben ik zelf met een aantal prefixes gestopt als het toch alleen maar visueel en niet structureel meer is. Als je een oud toestel gebruikt met verouderde browser, krijg je van mij ook een verouderde weergave.

[Reactie gewijzigd door Martinspire op 29 oktober 2014 11:13]

IE kent input type = date nog niet, erg jammer.

Firefox ook niet.

Zijn wel meer browsers die niet alle dingen herkennen. Maar bv input type=range weer wel (gelukkig). Al vind ik het zelf ook wel raar waarom Date nog niet werkt, die kan namelijk veel gebruikt worden.

Maakt ook niet echt uit, op zich zou de implementatie van HTML5 nu pas mogen beginnen om alles netjes te doen, maar browsermakers staan daar al veel verder in.

Waarschijnlijk pas over een paar jaar als oude browserversies de wereld uit zijn geholpen.

Mja maar je moet je afvragen hoeveel moeite het kost en hoeveel het oplevert. Als je nu overgaat bij Mobile op Android 4.x, iOS 8.x en WP 8.1, dan heb je van elk platform ongeveer 50% te pakken. Of laatste Chrome/FF, Safari 6.x, IE11.
Meer ondersteunen kost ook veel meer tijd (gaat redelijk exponentieel omhoog). En het is zeker niet nodig als je je bedenkt dat mensen met een ouder toestel ook minder apps hebben, dan wel kopen. Of minder met hun mobiel doen en meer met andere apparaten.

Vooral de tijd die het kost, wordt vaak onderschat waardoor je allerlei hacks e.d. krijgt die het geheel niet bepaald stabieler maken.

Ongeveer 50% is niet acceptabel. Je hakt gewoon je inkomsten in 2 als je site maar werkt voor 50% van de bezoekers. Bij Android draait nog ongeveer 10% op 2.X. Het ondersteunen van dit begint nu een beetje een twijfelgeval te worden, maar het is zeker nog de moeite om ervoor te zorgen dat de basics werken op dat platform.

Hetzelfde geldt voor iOS7 en in mindere mate iOS6. De 7 moet nog absoluut ondersteuning krijgen en over de 6 moet er nagedacht worden.

Windows Phone is gelukkig makkelijker. Omdat er zo weinig WP7 toestellen zijn verkocht, en de meeste daarvan een update naar WP8 gekregen hebben kan je daar gewoon versie 8 targetten.

Om nog maar te zwijgen over desktop browsers. Ze zijn al een pak beter, maar dat betekent niet dat plots niemand maar IE8/9 of oude Safari's gebruikt. Compatibiliteit blijft iets waar je over na moet denken. Je hebt geen prefixes meer voor een border-radius, maar voor nieuwe features moet je nog altijd goed oppassen. Dat is het grote nadeel van al die nieuwe HTML/CSS features. Uiteindelijk moeten ze ook werken in wat oudere browsers waarbij je dan een hoop extra javascript nodig hebt om hetzelfde effect te bekomen.

Je hakt je inkomsten alleen in als je ook veel verdient aan die oude systemen. Nu is het misschien 50%, maar over een paar maanden (als je klaar bent), is het aandeel iOS en WP bij nieuwe versies al hoger. Net als dat er weer mensen overstappen naar nieuwe Android.
En bij een website heb je nog altijd desktop bezoekers (naast mobile) waardoor je wel meer hebt dan precies 50%.

Maar ik bedoel ook niet om meteen alles te droppen. Ik bedoel alleen dat de site in ieder geval qua structuur moet kloppen. Border radius e.d. zijn alleen maar visueel en voegen weinig toe aan de functionaliteiten. Stel je gebruikt Flexbox, dan is het ondersteunen van Box (de oude versie) niet zo'n probleem. Wat je daarna nog overhoudt is gewoon te oud (zelfs Android 2.3 snapt display: -webkit-box).

In plaats van te kijken hoeveel mensen een systeem gebruiken in het algemeen, moet je kijken naar je product/platform/site en daarbij nagaan wat de bezoekers gebruiken. In NL zijn mensen wat verder up2date dan in Afrika, maar die laatsten tellen ook gewoon mee in de worldwide statistieken. NL-specifiek wordt nergens echt goed en betrouwbaar bijgehouden, dus is het lastig te zeggen hoeveel je met een bepaalde ondersteuning kunt dekken.

Men lijkt alleen te ver door te slaan in het ondersteunen van browsers. Oude systemen leveren gewoon minder op, waardoor je het moet afwegen hoe ver je wilt gaan. Zeker als je een app-ervaring wilt bieden. In 2015 kun je best wat wegsnijden, zonder gigantische omzet mis te lopen. Ben je afhankelijk van reclame, dan heb je al andere problemen (adblockers e.d.)

[Reactie gewijzigd door Martinspire op 29 oktober 2014 11:54]

Natuurlijk moet je het ook wat slim spelen en kijken naar je doelpubliek. Op Tweakers hoeven ze niet jaren lang nog ondersteuning te bieden omdat mensen veel meer up to date zijn (alhoewel was er niet nog een IE5.5 gebruik in de statistieken een paar jaar terug? )

Wat ik wel bedoel is dat je niet kan assumpties maken over mensen op basis van wat ze gebruiken. Android 2.3 is heel ouderwets, maar de mensen die het gebruiken hebben ook nog altijd een maag dus zullen een aantal keer per dag honger krijgen. Het project waar ik nu aan werk laat mensen toe online eten te bestellen. Mensen met Android 2.3 horen dus ook gewoon tot het doelpubliek. Dat betekent niet dat ik vele tientallen uren ga steken om elke feature in orde te krijgen, maar ik zorg er wel voor dat de website bruikbaar is.

Waar je de lijn trekt is natuurlijk gewoon een keuze die gemaakt wordt. Zeg je "alleen de laatste versies", dan kan je lekker snel vooruitgaan en moet je bijlange zoveel bugs niet fixen. Het ontwikkelproces gaat een pak goedkoper zijn maar je gaat ook een hoop bezoekers missen. Ik denk niet dat er een juist antwoord is. Heb je het geld gewoon niet? Vergeet het dan. Lanceer je site en zorg dat je inkomsten binnen krijgt. Is de web front end maar een heel klein deel van de totale kost (bij een groot systeem a la SAP etc), dan is de kleine investering om het met bijna alles compatibel te maken vaak wel een goed idee omdat de procentuele extra kost een fractie is van het extra publiek dat je krijgt.

Hoe dan ook. Ik klaag zeker niet. De laatste 5 jaar is het van rampzalig naar geweldig gegaan. Je kan developen op een desktop browser en het werkt gewoon direct bij 70% van de gebruikers (desktop of mobile). Ook vieze layout issues zijn veel minder geworden. Hier en daar scheelt het nog een paar pixels, maar over het algemeen zijn er weinig issues. De oude browsers van nu zijn maar een kleine herinnering aan de hel dat het was een paar jaar geleden.

Hoop het inderdaad ook, en ook wanneer mijn notificaties eindelijk gaan werken. Nu werkt het alleen op Chrome en FF
https://developer.mozilla...n/Using_Web_Notifications

Dat is, zover ik begreep, ook geen onderdeel van de HTML5 status maar vn de volgende JS (ECMAScript Harmony) release.

i know maar had de stille hoop dat ik dit topic zag

Eigenlijk is dat voor het grootste gedeelte al geregeld: De nieuwste versies van zowel Chrome, Firefox en zelfs IE(11) hebben voor de meeste css properties al geen prefixes meer nodig. Kwestie van tijd voordat we het niet meer hoeven gebruiken.

Eh, naar mijn ervaring was het juist dat Chrome/Safari/WebKit die prefixes nog het langste nodig had. IE was later met het implementeren, maar daar werkte het wel direct zonder prefixes.

Al moet ik toegeven dat ik de laatste jaren niet heel veel aan websites gesleuteld heb.

Ik maak nu al een paar jaar gebruik van css-pre-compilers in combinatie met een aantal mixin libraries, probleem van de prefixes meteen opgelost.

Vanaf IE10 merk ik dat FF steeds vaker de 'zwakke' broeder is onder de browsers, howel de verschillen gelukkig steeds minder groot worden. En niet te vergeten de native Android browser die regelmatig voor hoofdbrekens zorgt.

Leuk plaatje, maar zwaar outdated. IE is tegenwoordig best een aardige browser en de meeste HTML5- en CSS3-dingetjes ondersteunt hij prima.

Ik doel met name op CSS, veel style elementen verschijnen in internet Explorer bijzonder genoeg anders als in chrome/Firefox. Dat is best wel vreselijk vervelend.

Edit: de snelheid van internet Explorer is er dan weleenswaar op vooruit gegaan. Als mis ik de ondersteuning voor bijvoorbeeld adblokkers. En internet Explorer spammed nog steeds het logboek vol met foutmeldingen. Maar dat is nooit anders geweest bij IE

[Reactie gewijzigd door MGutker op 29 oktober 2014 10:11]

Dat hoor je wel meer, dus zal ik het zeker niet tegenspreken!
Hoewel, recentelijk verneem ik die geluiden nauwelijks meer. Overigens heb ik het zelf in al die jaren ervaring nog nooit ontmoet. Zelf hebben we in het verleden een verenigingswebsite opgezet en bijgehouden, dus wij weten wat er speelt bij html en css. Voor ons was dit ook de aanleiding om verschillende browsers aan boord te hebben, gewoon om te testen wat we hadden gemaakt. En hebben we nog nooit verschillen in weergave aangetroffen. Kan natuurlijk zijn dat we met onze html toepassingen nooit een conflictsituatie hebben gecreëerd. En met de komst van IE10 en -11 lazen we dat deze aan alle html-normen zouden voldoen. Dat zou dan toch niet het geval zijn? Kun je misschien een voorbeeld noemen waar het wel misgaat?

Ik snap deze opmerkingen nooit.
Het is inderdaad vervelend dat je soms rekening moet houden met verouderde software. Maar zeker als je over CSS spreekt heb ik hier weinig moeite mee met IE.

Vaak heb ik de meeste problemen met Firefox of Safari (Vooral mobile) die bepaalde dingen niet ondersteunen, maar de uitdaging om het overal netjes werkend te krijgen is toch leuk :-)?

Gewoon zorgen dat je overal mee werkt en weet wat je "code" voor resultaat heeft voorkomt frustraties. IE 11 ondersteund geloof ik vergeleken met de meeste browsers juist lekker veel.

Hulde aan Mickeysoft

Goh, ik denk dat dat wel meevalt, en dat kom je tegenwoordig ook bij de andere browsers tegen (backface-visibility in chrome bvb)

Misschien als je IE7/8 gebruikt o.i.d. ik ben momenteel een webpagina aan het maken voor een client en gebruik CSS3 animaties. Dit werkt ook op IE10/11 perfect.

Ook ik heb overigens 0 meldingen van IE11 in mijn event log, terwijl ik dit dagelijks veel gebruik i.c.m. de Citrix Receiver plugin en SharePoint.

Vanaf IE10 hoef je bijna geen specifieke IE fixes meer te schrijven. IE7 en 8 zorgden voor veel meer problemen. Gelukkig kom je die tegenwoordig al een stuk minder tegen. We houden er bij de ontwikkeling van nieuwe sites en applicaties ook eigenlijk al geen rekening meer mee.

Als mis ik de ondersteuning voor bijvoorbeeld adblokkers.

Internet Explorer heeft al sinds versie 9 een ingebouwde adblock functie. AdBlock Plus bestaat ook al een tijdje.

Uhm. Wat? De TPL instellingen staan gewoon in het instellingenmenu. En AdblockPlus is gewoon te downloaden van hun website. Hoe moeilijk kan het zijn?

adblock plus op IE installeren is net zo makkelijk als bij chrome hoor..

Zijn addons in Chrome en Firefox makkelijk te vinden en in te stellen voor mensen die computers gebruiken in huis-tuin-en-keukenmodus? Natuurlijk niet. De meeste mensen weten niet eens wat een addon is, laat staan dat ze 'm installeren.

Afgezien daarvan heeft IE inderdaad een jammerlijk tekort aan addonsupport maar daar ging het hier helemaal niet over. Jij riep dat IE op HTML-vlak (en later was het ineens CSS-vlak) tekortschiet terwijl dat allemaal best wel meevalt als je eens naar CanIUse.com gaat en eens goed rondkijkt. IE is allang niet meer het gehandicapte kindje onder de browsers. Ik zit tegenwoordig vaker gekke uitzonderingscode te schrijven voor Firefox of Chrome dan voor IE...

Held van de dag! Die website caniuse.com is een wereld opener voor Me. Dat ik die nog niet eerder heb gezien

Is die standaard adblock ook makkelijk te vinden en in te stellen voor mensen die computers gebruiken in de huis-tuin-en-keuken modus?

Ja, invoegtoepassingen beheren. Optie traceerbeveiligingen.

of rechtstreeks naar: http://www.iegallery.com/nl-nl/trackingprotectionlists

Of https://adblockplus.org/

Bij welke style elementen heb je daar last van dan?

Verder heeft IE een Add-Blocker aan boord. (Trackingprotection gecombineerd met de juiste lists). AdBlock Plus is er trouwens ook voor IE.

"En internet Explorer spammed nog steeds het logboek vol met foutmeldingen." Leg die eens uit?

Ooit gekeken in het applicatie logboek van internet Explorer via de event viewer van Windows?

Ik in ieder geval niet, maar nu wel. Ik heb een aantal werkstations hier bekeken, waarvan een aantal die al geruime tijd meedraaien (Windows 7).

0 meldingen.

Idem voor Windows 8.

Kan verder ook nergens op internet meldingen vinden die jouw bevindingen onderschrijven?

[Reactie gewijzigd door Glashelder op 29 oktober 2014 10:55]

Nou, ik kijk net ff in mijn applicatie logboek van internet explorer via de event viewer, en nul komma nul voor IE. Niet onder 'Windows logs'-'Applications' of 'Applications and...'-'Internet explorer'....
dussssssss............
En waarom zou je IE willen verwijderen, genoeg applicaties die daar gebruik van maken (want waarom zelf weer een browser gaan maken als deze standaard al op de PC meegeleverd wordt)..

Ooit gekeken in het applicatie logboek van internet Explorer via de event viewer van Windows?

Net wel even een keer.

0 Meldingen.

Nee hoor, als je naar dingen kijkt zoals Web Componenten waarbij Chrome en Safari en Opera de boel al geïmplementeerd hebben en Safari ook bezig is... is er nog geen SPOOR van te herkennen bij het Internet Explorer team. Ze lopen gelukkig nu wel aardig mee met de standaard. Maar qua innovatie lopen ze achter en proberen ze weinig nieuwe dingen uit die nodig zijn om de web te laten evolueren.

Shadow DOM wordt straks heel belangrijk mijlpaal bij alle browsers waarbij praktische alle browsers ready zijn. Behalve... IE.

[Reactie gewijzigd door Anoniem: 145867 op 29 oktober 2014 17:44]

Ik denk niet dat het helemaal eerlijk is om Microsoft af te rekenen op het feit dat een standaard die nog hevig in ontwikkeling is nog niet is geïmplementeerd is in hun browser, mede omdat Mozilla en Google, de grootste concurrenten, de scepter zwaaien in het opzetten van de standaard. Verder ondersteunt Firefox het ook niet zonder in about:config te gaan klooien en Safari helemaal niet. Microsoft zal intern vast ook wel aan het spelen zijn met webcomponents maar ze hebben dat gewoon nog niet exposed. Dat lijkt me de komende 12 maanden ook niet noodzakelijk, je kan dit soort features toch pas gaan gebruiken als veruit het grootste deel van de wereld een browser gebruikt die compatible is, en dat zal met de huidige gebruikersaantallen van IE9 en IE10 nog wel even niet het geval zijn.

Vergeet ook niet dat je zo'n complex eigen component niet even zomaar gracefully laat degraden. Daar komt nogal wat javascript aan te pas en als je dat toch moet schrijven kun je net zo goed alles via JS laten lopen.

Dat klopt, maar Web Components biedt zoveel voordelen voor de developer in termen als hergebruik en onderhoud. Ik kijk er erg naar uit. Ik zou persoonlijk willen dat alles wat sneller gaat. Maar als iets werkt in Chrome, Safari, Firefox etc. moeten we nog altijd wachten op IE.

IE is een afwachtende browser en implementeert wat op dat moment een standaard is. Dit is niet slecht, maar ook niet direct goed.

Ik denk dat veel front end developers al heel erg blij zijn dat IE zich nou weer goed aan de standaard houdt. Dat zorgt voor minder werk.

Het probleem is dat websites zich zo aan het evolueren is dat het praktisch gewoon volwaardige applicaties beginnen te worden dat het gewoon een spannende tijd is. Ik zie waar het heen gaat en het is er nog niet terwijl ik het wel graag zie. Ongeduld misschien wat zich uitdrukt in ongenoegen naar IE.

IE is ook niet meer zo afwachtend. Voor veel CSS3-features was het de eerste browser die ze ondersteunde zonder prefix. Ik ben wel benieuwd naar IE12 wat dat betreft. Ik heb al eens geroepen dat ik daadwerkelijk zou overwegen over te stappen naar IE als het addon support had.

Ik kijk trouwens ook uit naar webcomponenten maar ben daarin wel realistisch: ik verwacht niet ze de komende 3 jaar te kunnen implementeren. Daarna kan ik daar langzaamaan mee beginnen.

http://compass-style.org/reference/compass/css3/

Prefixes? Waar?

[Reactie gewijzigd door pietermx op 29 oktober 2014 09:57]

Uiteindelijk kun je daarmee ook bepalen wat je wel of niet ondersteund.
En met andere automators (Grunt, Gulp, e.d.) heb je er weer een aparte module voor nodig.

Nu nog iedereen aan de laatste browserversie zien te krijgen

Het blijf zo jammer dat je IE niet op alle OS'en naar de laatste versie kan krijgen

Safari ook niet. De windows versie blijft hangen op versie 5.1.7 (http://support.apple.com/kb/dl1531). Om de ipad versie van een website te debuggen hebben we Safari 6 nodig, en moeten we speciaal een OSX aanschaffen.

Gelukkig zijn er zat alternatieve, en zijn mijn twee favoriete browsers (firefox en chrome) momenteel ook wel de populairste voor iedereen die een bewuste beslissing maakt.

*ik zeg bewuste aangezien er onder de IE meer gebruikers zitten uit ontwetendheid dan die er specifiek voor kiezen

Als je iets developed wat op een iPad moet werken, kan je het beste testen op een iPad natuurlijk.

Safari 5 op Windows ondersteunen wij sowieso al niet meer, die is gewoon te oud. Tenzij de klant er extra voor wil betalen.

Ja, dat doe je ook op een ipad maar om de ontwikkeltools aan te zetten koppel je hem aan je desktop via Safari 6

http://webdesign.tutsplus...le-safari--webdesign-8787

Ik gebruik tegenwoordig gewoon de emulatortools van Chrome, dan gaat het meestal wel goed; de Safari van iOs is wel goed qua standaarden.

Yes, alleen specifieke bugs waarvoor je een console nodig hebt zijn anders een hel om te op te lossen. Vooral bij specifieke maatwerk applicaties voor klanten willen we nog wel eens wat waardes zien terug te krijgen. Emulatoren werken ook maar tot bepaalde hoogte.

Precies leukste is als er een bug komt in IOS 8.0.2 en je hebt alleen een iPad 1 liggen.. Dan kan je dus ook specifiek een model iPad bestellen om een bug op te lossen.

Kwestie van verrekenen in de ontwikkelingskosten lijkt me

Ging meer om de tijd die ik nodig had, moest dus weer een dag wachten voor de nieuwe iPad er was

Als je alleen chrome gebruikt moet je alleen even rekening houden met de viewport, als je deze niet standaard instelt op het volledige scherm houd safari over het algemeen wat extra ruimte over die je niet met css kunt aanroepen.

Ik doe het ook, maar ik heb geen iPad en ben er wel eens tegenaan gelopen.

OSX aanschaffen is de 'cost of doing business', maar met aan een mac mini uit het jaar kruik waar je nog 10.9 op kan draaien zou je voldoende aan moeten hebben. Werkte vroeger veel met VMs om verschillende versies van Windows en browsers te draaien en te testen. Maar er zijn ook diensten die dit voor je doen.

OSX kan je ook perfect in een VMWare draaien.

Het probleem is dat dit niet bepaald legaal is, ivm. licenties. We hebben het hier over professionals en bedrijven, niet amateurs die aan het prutten zijn op illegale meuk. En als je als professional/bedrijf wel aan het prutten bent met illegale meuk: Shame on you!

Jij lijkt The Mentalist wel, jij kan uit 1 zinnetje opmaken hoe mijn leven in elkaar zit, sterk :-)
OT: Zowel VMWare als OSX zijn gekochte versies. Het tweaken (hm, op welke site zitten we hier?) is toegelaten, niet? Het is voor mij gemakkelijker om op m'n develop machine te schakelen tussen de OS's dan naar een fysiek andere machine.

Je kunt het natuurlijk ook andersom doen. Werken op een mac, maar Windows in VM

Maar je hebt gelijk, ontwikkelen voor OSX en iOS zijn niet heel fijn als je op Windows werkt. Wat je wel kunt doen is lokale server draaien en daar een andere machine op laten bezoeken en die middels live-reload constant te refreshen bij wijzigingen.

Wat ook de meeste front end developers doen. Ga maar naar een AngularJS evenement of iets anders qua front end. 99% macbooks. Waarschijnlijk deels om die reden en natuurlijk dat veel ontwikkel tools makkelijk in OSX werken + photoshop en dergelijke werken op OSX. De reden waarom ze vaak niet voor Linux kiezen.

Front-end development hoeft helemaal niet op Windows. Node, Angular e.d. werken prima op een windows-bak. Daar heb je geen OSX of Linux voor nodig. Net als veel IDE's of PHP/ASP/Ruby/Java/Python.

Nee de reden is dat ze het toch van de baas krijgen en omdat het een bepaalde status heeft gekregen. Wij hebben het op het werk ook, maar had net zo lief een Windows-bak gehad. Niet in de laatste plaats omdat de rest van het netwerk volledig is ingericht op Windows en wij door allerlei hoepels moeten om te kunnen printen en whatever.

Waar test je dan Safari voor OSX? Gewoon wel een collega die wel een Macbook heeft waarop je je front end creatie kunt testen? En ja ik weet dat je praktisch alles wel op Windows kan doen. Het kost soms alleen wel wat meer moeite. Veel tools moet je draaien in de command line maar ook die kun je installeren op Windows.
https://www.cygwin.com/
Ook met de nieuwe powershell gaat het al een stuk beter.

Dat is alleen nodig voor het laatste stukje testing. Voor het grootste deel kun je het allemaal wel op Windows doen, maar Safari gedraagt zich grotendeels als Chrome en anders kun je ook een iPad pakken bv (komt ook in de buurt).

Maar nee, Safari test ik niet continue en heeft ook nooit veel meer nodig. Wel Chrome Firefox en IE.

Hoe ga jij dan IE testen? (IE is toch heel wat anders dan Chrome of Firefox en heeft wat meer aandacht nodig dan Safari)

[Reactie gewijzigd door Martinspire op 29 oktober 2014 19:37]

Persoonlijk vind ik dat het niets met status te maken heeft. Ik werk als backend programmeur en voor tools als ssh, git, composer en diverse shell scripts wil ik gewoon een terminal.

Dit is de voornaamste reden om zakelijk voor een mac te gaan. De command prompt is te beperkt en ssh via public key authenticatie kan wel onder windows maar dat is aanzienlijk meer werk.

Prive gebruik ik gewoon ubuntu als ik wil developpen en dat werkt voor mij net zo goed

Safari onder Windows is dan ook EOL.

Geweldig! Misschien kan tweakers het voorbeeld nemen! Ironisch genoeg gebruikt tweakers in deze pagina nog steeds flash video, waarom niet vervangen met het <video> element> of video.js ?

Huh? Ik heb geen flash geinstalleerd, maar ik kan die video gewoon bekijken. Misschien ondersteunen ze beide (?)

IE en Chrome hebben allebei flash ingebouwd, maar daarnaast, tweakers heeft ondertussen ook HTML5. Het is zelfs pas geupdate waardoor ze de echte fullscreen modus gebruiken ipv een heigth en width van 100%, een zeer welkome verbetering.

Ik zou het nog steeds fijner vinden als ze gewoon de browser video laten spelen ipv met eigen controls en ui.

[Reactie gewijzigd door WoutervOorschot op 29 oktober 2014 12:53]

Eh ja, ik gebruik chromium, en heb dus geen flash standaard.

Ik zou het nog steeds fijner vinden als ze gewoon de browser video laten spelen ipv met eigen controls en ui.

Daar kun je natuurlijk even een bookmarklet (oid) voor schrijven: gewoon de DOM doorzoeken naar dat video node, en dan die video met native controls openen in een nieuw window.

De native controls wil ik vooral op m'n telefoon, de tweakers videospeler is namenlijk niet echt heel handig op Touch.

Hopelijk gaan ze nu bedenken hoe ze NaCl onderdeel van de standaard kunnen maken. Want asm.js is natuurlijk helemaal knudde.

Hopelijk word Flash nu uitgefaseerd, maar het zal nog wel even blijven voor spellen e.d.

Flash 5 (12 jaar geleden?) kon ongeveer al wat de browsers nu pas een beetje native beginnen te snappen met HTML5. Toen was ook de authoringomgeving een stuk beter nog dan de meeste HTML5 tooling van nu.

Uiteraard zal het gebruik van Flash uiteindelijk wel gaan afnemen / uitsterven, maar ik denk dat dit nog wel even duurt gezien de voorsprong die ze hebben/hadden. Nu is de tijd voor de ontwikkelaars om de juiste tooling voor HTML5 te bouwen zodat ook de wat mindere 'ontwikkelaar' (lees: webdesigner die wat minder clue heeft van de taal zelf) websites kan maken met daarin de rich UI die we gewend zijn van Flash.

De tijd zal het leren in ieder geval

Altijd weer interessant dat mensen Flash naar voren halen. Je kan met Flash nog steeds meer dan HTML5 maar ik moet zeggen dat het wel de goede kant op gaat met HTML5 qua mogelijkheden. Echter als je die draadjes hierboven leest over browser compatibilty, dat was nu juist een heel belangrijke reden waarom Flash eind jaren 90 razendsnel populair werd, je maakte content in Flash en iedereen die de plugin had zag hetzelfde. Checken met andere browseres en OSsen was niet eens nodig,content draaide overal hetzelfde. Het Flash en crash verhaal heb ik eigenlijk al sinds ik op het net zit en flash op m'n windows bakken draai (ergens eind jaren 90) eigenlijk nooit last van gehad. Wellicht is dat iets met latere OSX versies waar ik geen ervaring mee heb. Overigens itt Flash wil HTML5 nog wel eens heftig crashen (in FF of Chrome). Anyway het zou mooi zijn als in de nabije toekomst je fatsoenlijke dingen met geluid zou kunnen doen, want dat vind ik (persoonlijk) toch wel het grootste probleem met HTML5 en eigenlijk ook wel best bizar als je weet dat je je dat allemaal wel al 15 jaar geleden kon met Flash (simpele maar strakke geluidsloopjes) op computers die veel langzamer draaiden en waarbij het surfen vaak nog via modems ging.

Flash draaide veel slomer op OSX (inmiddels al jaren niet meer), ik maakte regelmatig OS-detects die swf's met verschillende framerates aanbood per OS, als de timing van animaties erg belangrijk was. En op de eerste OSX-versies draaide alles eigenlijk brak, wat voornamelijk door Safari kwam.

Je kunt nog steeds lightweight flash-spul maken zonder dat de plugin over zijn nek gaat, maar het zijn vooral slechte scripts en te zware video-codecs, i.c.m. budget hardware, die de player zijn slechte naam geven.

Qua geluid en html5 zou ik me eens verdiepen in javascript audio-libraries, want dat heeft bepaald niet stilgestaan, zoals howler.js of SoundJS.

Maar wat compatibility betreft denk ik nog wel eens met weemoed terug aan de Flash-tijd. Het ingeslagen pad van html, js, css, php etc is bij tijden verbijsterend dom en omslachtig. Ik heb nu redelijk wat html5 video projecten gedaan, en het blijft behelpen, hoewel de verminderde cpu-load van html5 video wel een enorme stap vooruit is vergeleken met Flash. Dus fijn dat die standaard nu af is, maar in mijn ogen leven we nog in het stenen tijdperk, waarbij het massale webkit-gebruik ook weer flinke stappen terug is.

Ik kan niet wachten op html6!

Bedankt voor je reactie en tips aangaande geluid. Ik zal hierbij toch nog iets dieper ingaan op mijn bevindingen met html5 en geluid, wellicht dat het ook voor mede-tweakers nog interessant is

Ik ben gewend om met korte loopjes te werken. Dus daar eerst even wat over. Je kan dat eigenlijk het beste met wav en aac files doen omdat die zo worden gesaved zoals je ze hoort. Wat je hoort in de editor zo worden ze ook gesaved. Het probleem met MP3 is dat bij het wegsaven van een MP3 file er een hele korte pauze in het begin van de file ontstaat. Waardoor als je de file looped er een klik/ tik geluid onstaat bij loopen. De mini pauze kun je er bijna afhalen als je je MP3's encode met Lame, maar deze redt het toch niet helemaal. Waardoor het afhankelijk van de loop het wel of niet kan werken.
Howler ondervangt dit tikken/klikken bij loopen helaas niet bij mp3s. Bij howler kun je echter ook wav en m4a kiezen om af te spelen (met beide formaten bestrijk je alle belangrijke browsers). Echter op een of andere manier werkt het soms niet goed en krijg je toch weer kliks/ tiks en dan vnl (FF en Explorer) met tragere machines. Ik heb er de vinger nooit op kunnen leggen wat precies het probleem is. Wellicht toch processor power.

Dan is er ook nog seamlessloop (gratis) dat ook mooie resultaten met MP3 loops beloofd.
https://github.com/Hivenfour/SeamlessLoop
Mijn ervaringen hier zijn ook uiteenlopend en zou deze ook niet adviseren.

Verder beloofd de audio library van p5js (gratis) interessant te worden, maar dit is allemaal nog erg vers
http://p5js.org/

Als we het over strak en collisions hebben dan is het ook nog allemaal zo zo. Echter is er een pakket Construct 2 (light versie gratis, voor Benno helaas windows only) dat geluid ongekend strak neer kan zetten. Construct is eigenlijk een software pakket dat bedoelt is om html5 games te bouwen en heeft een heel actieve community. Ik ben er dan ook enthousiast over als het over collisions en geluidseffecten gaat. Echter ook dit pakket heeft moeite met strakke korte geluidsloopjes.

Linkje naar construct 2
https://www.scirra.com/

[Reactie gewijzigd door zap8 op 29 oktober 2014 14:10]

Ik had dat loop-probleem in Flash ook altijd met mp3: mixers en sequencers etc bouwde ik daar ook altijd met wavjes. Als je met korte loops werkt, is het dan een probleem om met wav (en dus grotere files) te werken?

De html5 (om enigzins ontopic te geraken) webaudio api zou dat inmiddels toch goed moeten kunnen handelen, in bepaalde browsers?

Probleem met wav blijft dat niet alle grote browsers wav ondersteunen (MSIE zo uit m'n hoofd). Compatibilty...

Inderdaad, Flash 4/5 was een light weight plug-in om dynamiek toe te voegen aan statische websites en was compatible met alle soorten webbrowsers. Het was zelfs mogelijk om de content zonder browser af te spelen (eventueel in combinatie met Director). Helaas is Flash zijn doel compleet voorbij geschoten. In de loop der jaren gegroeid tot een lomp gedrocht dat veel geheugen en cpu load vreet.

HTML5 biedt zeker mooie mogelijkheden. Alleen dat de makers van webbrowsers, met Microsoft aan top, zich niet houden aan de standaarden of de standaarden anders interpreteren, maakt het maken van websites op basis van HTML5 die werken op alle platformen een hel voor de programmeurs.

Dat MS zich niet houdt aan de standaarden is een verhaaltje dat al relatief oud is. En outdated. MS heeft zich met IE9-10-11 herpakt en is misschien niet altijd cutting edge op vlak van nieuwe features, maar minstens zo snel als FF én compliant.

Tip: update even je kennis over browsers

Toch nog ff een opmerking over browsers. Apple's Safari ondersteund pas sinds OSX Yosemite (heel recent dus) en iOS8 standaard webgl. Daarvoor werd het ook onder OSX wel ondersteund, maar moest je als gebruiker allerlei trucs uithalen om dat te enablen.

Ik geef je gelijk dat Flash in principe een rijkere technologie is.

Echter, conceptueel zit ik persoonlijk niet te wachten op de "rich UI" die web noobs in elkaar draaien. Een mooie UI ok, maar allerlei eye candy en onzinnige navigatie, ik ben blij dat we daar van verlost zijn.

Je draagt hier in interessant punt aan. Wellicht het verschil tussen het net als consumptie of creatief medium. Denk dat vooral de eerst 5 tot 10 jaar er veel werd geexperimenteerd met van alles en nog wat. Langzamerhand zie je dat dingen uitkristaliseren en dat het net steeds meer om consumptie gaat (heldere sites met duidelijk communicatie), experimenteren levert echter ook weer allerlei verrassende kanten op, en mis zelf toch wel de iets meer verrassende ervaringen. Behalve wat verschil in layout neigt zo langzamerhand alles richting hetzelfde. Als ik wat wil snel kopen via internet is dat allemaal wel okay, maar die eenheid boeit mij persoonlijk nu werkelijk ook weer niet als het gaat om een andere ervaring dan consumptie.

Dat klopt, de trend is usability boven eye candy, en dat is op zich logisch. Bijna iedere web aktie gaat om het opvragen van informatie en discussie en daarin wint snelheid en eenvoud het.

Als het op entertainment aankomt, dan nog wint vaakt de eenvoud, denk bijv aan video sites. Slechts bij games en simulaties zie ik een rol voor rich UI, en natuurlijk voor muzikanten en artiesten die altijd menen een totaal onbruikbare maar uiterst hippe site te moeten hebben.

Ik hoop dat het afsterft. Er zijn een hoop redenen om het niet te doen. Overigens helemaal gelijk betreft de tooling. Flash zou nu eigenlijk een prima tool kunnen zijn voor het verwerken van canvas en de scripts die daarvoor nodig zijn. Een prima visuele omgeving om dat te doen.

Ik heb wel het idee dat HTML wat meer zal blijven en met ontwikkelingen als nodeJS door blijven zetten, dat het behoorlijk goed kan worden als een compleet integraal ding. Misschien zal dit dan wel een "native" manier worden. Het is natuurlijk geen C nog, maar is het nog allemaal wel nodig als de meeste API's beschikbaar zijn.

Time management is wel altijd nog en cruciaal dingetje wat ik vind dat beter kan. Zoals wanneer je games maakt in de browser je op een andere manier met je FPS moet omgaan.Maar goed, zover ben ik zelf nog niet gekomen ;-)

NodeJS = server side
HTML = client side

NodeJS en HTML hebben dus niets met elkaar te maken, behalve dat je (met beetje of een hoop eigen code) Node kunt gebruiken om HTML te compilen/serveren.

Om nog even terug te komen op de mensen die het over vendor-prefixes hadden; gebruik autoprefixer (hier zijn ook een paar NPM'etjes van), deze fixed de vendor prefixes automatisch voor alles dat volgens caniuse.com relevant is. Je geeft hierbij als configuratie op welke browserversies je wilt ondersteunen.

En tot slot de oplossing voor je timefix; laat het tijdsverloop in je game niet afhankelijk zijn van het FPS of AnimationFrame. Quite simple?

Ik weet dat NodeJS server side is,... maar het is samen een behoorlijk groeiende oplossing. Node kan als prima backend fungeren met dezelfde code als voor de front-end.

En tot slot de oplossing voor je timefix; laat het tijdsverloop in je game niet afhankelijk zijn van het FPS of AnimationFrame. Quite simple?

Dat is momenteel de enige oplossing die ik ken, maar zoals ik zei, ik moet er nog wat meer induiken

Je bedoelt de full Javascript stack:
- NodeJS
- ExpressJS
- MongoDB
- AngularJS
- Polymer
En dan draaiend op NGinx.

Bijvoorbeeld, Maar ik heb het dan meer over een verpakte versie in een app ;-)

Node-Webkit?

Adobe heeft het wel door hoor . Ze zijn immers all-in op betere tooling voor HTML5. Zie bijv Animate [0].

[0]: https://creative.adobe.com/products/animate

Veel spellen worden anders al in HTML5, WebGL, Canvas, Javascript etc geschreven. Sterker nog, ik heb flash volledig uitgeschakeld staan vanwege de vele bugs en crashes die het veroorzaakt. Het scheelt irritante reclame, en kom nog zelden sites tegen waarvoor ik een andere browser opstart waar wel flash aanstaat.

Een ander voordeel is dat Flash zeker een hoop van je hardware resources snoept, en je daar nu een stuk minder last van hebt.

De huidige browsers verbruiken anders ook massaal veel geheugen. Er is gewoon meer geheugen beschikbaar, waardoor je er minder last van hebt.

Nee, het voordeel van de HTML5 familie ligt niet in performance of efficientie. Ook de authoring tools en features van Flash waren 10 jaar geleden al beter dan wat we nu hebben met HTML5 (en waarvan veel API's nogal vluchtig erbij zijn gelapt omdat Flash te rap moest vervangen kunnen worden na de introductie van de iPhone zonder Flash).

Het grote voordeel van HTML5 is dat het patentvrij is, er meerdere bedrijven inspraak hebben op de API en je voor de implementatie ook niet vasthangt aan 1 vendor.

Klopt, ik surf al jaren met Flash uit en zeker de laatste twee jaar hoef ik het zelden nog aan te zetten.

Adobe is allang bezig met het vervangen van Flash.
Flash zal blijven bestaand in de vorm van 'Air' applicaties (soort van .net).
Flash voor web wordt gewoon HTML5, CSS3 en JS. Hiervoor gebruik je het Adobe product Edge Animate. Lijkt sterk op de Flash ontwikkelomgeving. Persoonlijk zie ik eigenlijk het zelfde Adobe ontwikkel traject onstaan als voor Flash. Want Edge ontwikkel omgeving is net zo 'krom' als Flash ontwikkel omgeving van 10-jaar terug. Toen was het lastig om iets moois te programmeren; start, stop, goto, labels al dat soort zooi zie je ook weer in Edge Animate. Je 'script' in JS maar als je de editor opent, mis je iets. Het voelt niet JS aan. Dus komen er weer vele, vele releases die dit proces gaat verbeteren. Maar ik zie het als een soort van klanten binding (Vendor lock-in). Je moet toch, ook het komende jaar, weer nieuwe producten kunnen verkopen. Maar er zijn gratis alternatieven!

Dat zit niet in de HTML standaard, dat zit in de plugins/supported content, iets wat buiten de scope van HTML(5) valt. Maar Flash is al redelijk ver op z'n laatste been, met dank aan de audio en video tag in HTML5 en de browsersupport die daar nu voor is en steeds groter word.

Goed nieuws! Hopelijk komt er ook meer documentatie beschikbaar met de 'echte' juiste structuur.
En niet een online tutorial waar het hele web mee vol ligt waarbij de developer 'denkt' dat het juist is.

Vindt het persoonlijk nogal onduidelijk, bijvoorbeeld;
Mag er een <header> ook gebruikt worden in een <article>.
En is het nu toegestaan om meerdere H1's te gebruiken op een pagina omdat deze in een <article> zit.

Ben ik met je eens! Veel van die tutorials online zijn bar slecht. Je zoekt je het apezuur voordat je een correcte/werkende oplossing vindt. Geldt ook voor tutorials voor andere zaken als css3 en javascripts enzovoort.

Mwa, tutorials zijn vaak óf voortborduursels van andere tutorials en de auteur zijn eigen variatie daarvan, óf interpretaties van de standaarden - en interpretaties verschillen tussen mensen (en browsers overigens). Je moet de juiste bronnen kunnen vinden. Of natuurlijk wat je wilt bouwen anders oplossen.

Mag er een <header> ook gebruikt worden in een <article>.

Jup dat mag, al zullen de meeste <header> gebruiker voor de header van een pagina.

Mja enerzijds wel, anderzijds geef ik liever met <header> structuur aan de content dan aan de pagina. Tegenwoordig zit het vaak samen in de hoofdnavigatie waardoor je al snel <nav> gebruikt.

webplatform.org is een goed initiatief om daar iets aan te doen, maar nog steeds een work in progress..

Verder vind je veel terug op de site van w3c zelf: http://www.w3.org/TR/html5/

En dan staat daar nergens dat je geen header mag plaatsen in een article:

http://www.w3.org/TR/html5/sections.html#the-article-element
> Content model:
> Flow content.

http://www.w3.org/TR/html5/sections.html#the-header-element
> Content model:
> Flow content, but with no header, footer, or main element descendants.

In het begin misschien niet altijd even duidelijk, maar het staat er wel.

[Reactie gewijzigd door Valanga op 29 oktober 2014 12:30]

Wat mij opvalt is dat de verschillende browsers het allang bestaande html5 al goed hebben doorgevoerd.

Echter: Ondanks dat renderen de verschillende browsers toch nog verschillend!! Denk aan tekst die flink verspringt. Een webdesigner zal dus alsnog moeten kloten met verschillende css-files voor verschillende browsers.

[Reactie gewijzigd door Anoniem: 353647 op 29 oktober 2014 11:28]

HTML en CSS zijn nooit bedoeld om pixel-perfectie te bieden. Het uitgangspunt is nooit geweest dat als browser A en B beide de specs volledig implementeren dit in zou houden dat ze exact hetzelfde renderen. Jouw vetgedrukte opmerking is dan ook by design.

Dat dit ontwerpers, marketeers etc. slecht uitkomt is jammer (voor hun), maar heeft verder niets met de specificaties an sich te maken. Een goede webdesigner zal dan ook met een ontwerp komen dat hier tegen op is gewassen, en niet met een ontwerp dat valt of staat met de precisie van de rendering (die sowieso over verschillende besturingssystemen ook nog eens af zal wijken als het op tekst aankomt).

Tekst die verspringt heeft vaak te maken met het wisselen tussen cpu en gpu verwerkingen. Als iets animeert, wordt dat vaak met de GPU gedaan, maar is er een soort transitie tussen de 2 die mogelijk een flickering toepast. Dit is wel op te lossen, maar is de afgelopen paar maanden telkens veranderd qua hoe je dat doet.

Een webdesigner zal dus alsnog moeten kloten met verschillende css-files voor verschillende browsers.

Alleen als hij teveel gedesigned heeft en alles pixel-perfect wil hebben. Web is geen print, en onderlinge verschillen tussen browsers zijn normaal - de taak van een webdesigner is om daar flexibel mee om te kunnen gaan, niet om zodanig veel uitzonderingen te ontwikkelen dat alles er pixel-perfect uitziet volgens zijn visie.

Overigens slaat dat meer op CSS dan de HTML5 standaard; de meeste browsers zullen er op documentniveau hetzelfde mee omgaan.

[Reactie gewijzigd door YopY op 29 oktober 2014 15:02]

Dat ben ik met je eens!

Op naar HTML6! Wat kunnen we daarvan verwachten, of kijk ik nu iets te ver in de toekomst?

Bekijk deze eens: HTML6 - The Spec That Brings Us Freedom

Dat is slechts een mening van een persoon/hobbyist die enkele suggesties doet.

In de conclusie staat:

This is simply an idea. It's an idea I've personally had for years, but it's in no way finished.

Waar, maar hij heeft het all bij de w3c mensen neergelegd. Nu nog kijken in hoevere ze het gaan implementeren.

"I wasn't going to submit this but I've actually received quite a few people saying they want me to, so I was wondering where I'd submit a proposal / concept I did? Link here: http://html6spec.com/
Thanks,Oscar"

HTML6 from Oscar Godson on 2013-01-07 ([e-mail] from January 2013)

[Reactie gewijzigd door blade1989 op 29 oktober 2014 09:26]

Dit kan allemaal al hoor, in de vorm van Web Components API (voornamelijk dan custom elements en shadow dom). Zie ook Google Polymer die polyfills aanbiedt voor browsers die web components nog niet implementeren.

Ik denk dat HTML helemaal naar je eigen hand zetten en dat we straks niet vast zitten aan de DIV's.

DIV's zullen straks verleden tijd zijn. Wat is het nut uberhaupt van een DIV. Geef het beestje een naam! Juist Web Components wordt de volgende omkeer van het web.

Een leuke link, maar inhoudelijk een matig artikel naar mijn mening:

- De persoon pleit eigenlijk voor XML in HTML. Dat betekent dat hij blijkbaar de complete XHTML2 historie gemist heeft, welke jammerlijk gefaald is.

- Alles wat hij zegt, custom tags, kan al in HTML5 dmv Web Components, wat pas echt een web revolutie wordt.

Ik vond de XHTML standaard anders wel fijn. Zou het dan ook graag zien in combinatie met HTML 5 (XHtml 5)

Het was simpelweg een stuk netter.

Uhm, XHTML syntax is gewoon compatible met HTML5.

XHTML2 is echter een totaal ander verhaal.

Je bent bij XHTML verplicht de DocType op te geven BV <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Terwijl je het bij HTML5 <!DOCTYPE html> moet invullen en dat volgens mij ook verplicht is. Dus op dat punt zijn ze al niet compatible met elkaar. Om een dingetje te noemen.

Dat is dan ook het enige verschil. Daarna kun je zowel losse als strenge syntax gebruiken, het zal altijd werken.

Nha, we krijgen eerst nog HTML 5.1 over 2 jaar en HTML 5.2.

Ironisch dat juist Microsoft aan het filmpje meegewerkt heeft, gezien de resultaten uit het verleden... Misschien is er toch nog hoop voor ze met de ontwikkelingen van de laatste jaren. Gaat de semi-monopolist zich toch nog verantwoordelijk gedragen.

Microsoft beseft al jaren dat ze niet meer weg komen met een browser die de standaarden niet ondersteund.
Na versie 9 is Internet Explorer een redelijke browser geworden en IE11 ondersteund soms beter de standaarden dan bijvoorbeeld chrome.

kijk eens op HTML5test in IE en daarna in chrome http://html5test.com/

Handig als je je bron even controleert, ze geven zelf al aan dat ze naast HTML5 ook experimentele dingen testen die dus geen HTML5 zijn maar misschien wel eens op een dag HTML5 worden, dit geeft dus geen beeld van of de browser goede HTML5 ondersteuning biedt, je zou zelfs kunnen redeneren dat Chrome maar wat willekeurige functies implementeert en het HTML5 noemt ipv de daadwerkelijke standaard volgt...

Je moet niet vergeten dat die experimentele delen niet meetellen voor de score, ze worden alleen ter indicatie aangegeven.

Als je perse kritiek wil hebben op HTML5test moet je zeggen dat ze conformiteit niet testen. Ze testen of een browser iets uit de HTML5 standaard ondersteunt, niet of hij het ook juist ondersteunt of implementeert.

Klik eens op de tab about the test.

Dan zie je dat ze een andere domeinnaam nodig hebben. html5andotherthingstotest.com zou de lading beter dekken.

Veel van die zooi op html5test heeft vrijwel niks met de html5 specificatie te maken.
Ze noemen die zooi dan aan HTML5 gerelateerd specificaties maar dat is een zelf verzonnen idee en juist voor die overige specs geven ze 95% van de score.
Zaken die daadwerkelijk in de html5 specificatie staan bepalen hogsten 5% van de score op die site. En zelf voor die zaken waar ze dan wel punten voor geven controleert die site niet of de werking conform de spec is maar alleen of de elementen ondersteunt worden. Niet hoe goed ze ondersteunt worden.

Een echte goed conformance test van een Web specificatie ziet er heel anders uit:
Bijvoorbeeld:
http://test262.ecmascript.org/
http://w3c-test.org/tools/runner/index.html (van http://www.w3.org/html/wg/wiki/Testing)

[Reactie gewijzigd door Anoniem: 80466 op 29 oktober 2014 10:05]

HTML5Test is alles behalve representatief. Ten eerste telt het ook dingen mee die niet onderdeel van de HTML5 standaard zijn, laat staan een onderdeel van een standaard. Ten tweede test het alleen of de browser reageert op iets, niet of die reactie ook correct is.

Er is een tijd een versie van de HTML5Test geweest waar alle niet standaard tests eruit waren gehaald waarmee alle browser vrijwel gelijk opgingen.

[Reactie gewijzigd door Loller1 op 29 oktober 2014 10:13]

Die pagina komt niet door de w3c validator heen:

http://validator.w3.org/

Ik ben niet echt bekend met html5 en weet ook eerlijk gezegd niet wat de errors betekenen, maar als ik web paginas maakte nam ik wel de moeite om ze bij w3c te checken.

Maarja, deze pagina van tweakers faalt ook bij w3c, dus die test zal wel niet zo veel meer betekenen.

Html5test test ook zaken die niet (meer) in de HTML5 standaard zitten. Zaken als SVG, Video en andere dingen, vallen buiten de HTLM5 standaard maar zijn een eigen standaard geworden die apart wordt ontwikkeld.

Dus in feite werken alle browsers prima met de nieuwe standaard, maar ondersteunen ze nog niet alle extra elementen en API's omdat die nog in ontwikkeling zijn.

Toch blijven ze achter de rest aan hobbelen.

https://html5test.com/results/desktop.html

Zoals hierboven ook al aangegeven controleert die test nauwelijks op HTML5. maar meer over experimentele zaken. Daarnaast word ook getest op de ondersteuning van WebGL, en Web SQL. Twee zaken die niets met HTML 5 te maken hebben.

Gebruik dan een test van W3C zelf: http://w3c-test.org/tools/runner/index.html

Damn, wat duurt die lang

Ook ironisch dat Microsoft de enige is die de implementatie van de standaard volledig volgt, in tegenstelling tot Chrome en Firefox. Die laatste twee hebben nog diverse fouten in hun implementatie zitten omdat zij zich baseerde op verouderde versies.

In de praktijk biedt html5 nu ondersteuning voor meerdere codecs; websites kunnen meerdere versies van een video serveren voor verschillende soorten apparaten.

Dus alle browsers moeten alle gespecificeerde codecs ondersteunen? Of moet elke video in meerdere formaten aangeboden worden? Anders blijven we toch hangen in situaties met niet werkende video's...

Dat laatste gebeurt nu al. Je moet als developer kijken wat de browser waar je in draait ondersteund en dan het juiste formaat aanbieden. Jammer maar waar.

Verder niks dan hulde voor HTML5 en ik hoop dat bedrijven het nu ook echt gaan gebruiken. Zeker op mobile devices is het erg aangenaam als de developers de juiste inputs gebruiken en jij het juiste virtuele toetsenbord voorgeschoteld krijgt (bv eentje met het @ als het een email adres is dat je in moet vullen).

Meerdere codes. Maar dat is het probleem van het nog niet vaststaan van de HTML5 Video standaard. Uiteindelijk moet het een enkele codec worden, maar Google, Microsoft en anderen zijn het nog niet helemaal eens. Toch kun je wel meerdere files eraan koppelen om op elke browser een video af te spelen.

HTML5 Video staat los van de HTML5 standaard.

Ja, je moet dus meerdere formaten serveren.
Hoe bedoel je dat HTML5 video los staat van de HTML5 standaard?

Je moet als developer kijken wat de browser waar je in draait ondersteund en dan het juiste formaat aanbieden.

Andersom: je biedt de video in 1 of meerdere formaten aan en de browser pakt dan zelf de juiste.

Edit: moet reactie op sys64738 zijn.

[Reactie gewijzigd door Rafe op 29 oktober 2014 17:49]

Het is een goede zaak dat Windows XP eindelijkt gedropt is waardoor nieuwe Windows klanten nu standaard al beginnen op IE10. Dit zal de overstap naar CSS3/HTML5 alleen maar versnellen en bevorderen. IE7 is bijv. al verwaarloosbaar, maar over een paar jaar dan kunnen we de oude browsers helemaal negeren en wat betreft design en animatie helemaal los gaan!

Goede zaak, kijk er nu al naar uit

Het is een goede zaak dat Windows XP eindelijkt gedropt is waardoor nieuwe Windows klanten nu standaard al beginnen op IE10.

Helaas.... Windows 7 is uitgerust met IE8. En die is nogsteeds brak als het gaat om standaarden. Zolang Win7 nog ondersteund wordt kun je er rustig van uit gaan dat IE8 een veelgebruikte browser blijft.
(nog sterker: Mijn huidige werk laptop heeft nogsteeds IE8 en de meeste bedrijfs-applicaties draaien niet op Chrome/FF/Opera/IE10+)

Ik heb er weinig problemen meer mee om outdated browsers te weigeren / niet te bedienen op websites. Heel leuk dat bedrijven bedrijfs-applicaties hebben die een antieke browser nodig heeft, maar dan installeren ze maar twee browsers naast elkaar. Je kunt niet altijd in de oertijd blijven leven. Dit is nu ook een verantwoorde keuze om te maken aangezien Microsoft al lang geen monopolie meer heeft met Internet Explorer, dus je gooit ook niet een te groot deel van je potentiële bezoekers weg.

Leuk dat jij er geen problemen mee hebt maar ik kan me zo voorstellen dat bedrijven niet zomaar 10-20% van hun doelgroep willen buiten sluiten.

Nog sterker: als je je vooral richt op grote bedrijven dan sluit je zo'n beetje de helft van je potentiele klantenkring buiten door oudere browsers te weigeren.
En nee, dat bedrijf, wat jij graag als klant wilt, gaat zijn policies niet aanpassen omdat jij het wilt. Jij hebt iets te verkopen dan moet jij ook zorgen dat je klanten je kunnen vinden.

Klein voorbeeldje:
Ik moet voor mijn werk in een hotel zitten. Mijn bedrijfslaptop heeft IE8. De site van Hotel X ondersteund dat niet. Da's jammer voor Hotel X want daar ga ik dus niet boeken. De site van Hotel Y ondersteund het wel: Mooi, die hebben er weer een klant bij.

Gelukkig zijn er meer criteria dan browserondersteuning in de keuze van een bedrijf. In jouw hotel-voorbeeld, bijvoorbeeld, interesseert het mij meer hoe de verblijfservaringen zijn dan of ik met mijn bedrijfslaptop kan boeken of niet. Bovendien moet je het wel héél bont maken als webdeveloper wil je een site maken die in het geheel niét bruikbaar is in Internet Explorer 8. Het zou zomaar kunnen dat visuele effecten niet werken zoals ze zouden moeten, popup-menu'tjes niet verschijnen of weet ik wat, maar het boeken van de kamer zou wel moeten lukken. En in jouw voorbeeld zou ik gewoon de telefoon pakken.

Internet Explorer 8 is uitgebracht in maart 2009. Da's bijna 6 jaar geleden. In computer-termen een eeuwigheid. Als ik aan klanten uitleg dat het ze 30% extra kosten oplevert om een 6 jaar oude browser te ondersteunen, terwijl er in de tussentijd 3 nieuwere versies van dezelfde browser en tientallen nieuwe versies van andere browsers zijn uitgebracht zijn ze snel om hoor.

Ik wil natuurlijk best IE8 ondersteuning garanderen maar daar moet dan ook gewoon flink voor betaald worden.

Gelukkig zijn er meer criteria dan browserondersteuning in de keuze van een bedrijf. In jouw hotel-voorbeeld, bijvoorbeeld, interesseert het mij meer hoe de verblijfservaringen zijn dan of ik met mijn bedrijfslaptop kan boeken of niet. Bovendien moet je het wel héél bont maken als webdeveloper wil je een site maken die in het geheel niét bruikbaar is in Internet Explorer 8. Het zou zomaar kunnen dat visuele effecten niet werken zoals ze zouden moeten, popup-menu'tjes niet verschijnen of weet ik wat, maar het boeken van de kamer zou wel moeten lukken. En in jouw voorbeeld zou ik gewoon de telefoon pakken.

Ik heb het hier niet over een hypothetisch geval. Dit is wat ik zelf vorige week nog mee gemaakt heb. Een goede verblijfservaring krijg je alleen maar door er naartoe te gaan en er te verblijven, dat zie je niet op internet en hoor je niet over de telefoon. Dat selectiecriterium is dus simpelweg niet beschikbaar. En de telefoon pakken? Waarom zou je? Dat kost alleen maar meer tijd en moeite. Ik ben er ook van overtuigd dat ik daar niet uniek in ben. Bottom line: Veel grote bedrijven zitten op IE8, iedereen die iets wil leveren aan die grote bedrijven kan maar beter zorgen dat hun website dus (goed) werkt anders ben je de helft van je doelgroep bij voorbaat al kwijt.

Internet Explorer 8 is uitgebracht in maart 2009. Da's bijna 6 jaar geleden. In computer-termen een eeuwigheid. Als ik aan klanten uitleg dat het ze 30% extra kosten oplevert om een 6 jaar oude browser te ondersteunen, terwijl er in de tussentijd 3 nieuwere versies van dezelfde browser en tientallen nieuwe versies van andere browsers zijn uitgebracht zijn ze snel om hoor.

30% extra kosten stelt geen drol voor als het alternatief is 50% van je doelgroep niet bereiken.

30% extra kosten stelt geen drol voor als het alternatief is 50% van je doelgroep niet bereiken.

Dan heb jij duidelijk een andere doelgroep dan ik, qua klanten. Als je het over 10% IE8 gebruikers hebt is het al veel. Ik bouw dan ook veelal websites die voor consumenten bedoelt zijn, niet bedrijfsapplicaties.

Ik vind het gewoon geen realistische eis. Ze hebben twee opties: ofwel zorgen (erin investeren) dat hun bedrijfskritische applicaties wél werken in een niet-antieke browser, ofwel voor elke nieuwe opdracht er flink in investeren dat het wel weer op de antieke browser werkt. Of een nog makkelijkere oplossing: het antieke IE8 behouden voor de antieke applicaties (ik heb weinig vertrouwen in de veiligheid van die applicaties als het zes jaar oude technologie vereist, overigens) en daarnaast een moderne browser als Chrome of Firefox installeren.

Maar ja, de klant is koning, als zij er fors voor willen betalen moeten ze dat helemaal zelf weten natuurlijk.

Croga, dat is echt aangeprate (Microsoft) 'bullshit' en het nadeel daarvan is in het verleden ook zichtbaar geweest namelijk "Het lange leve van een outdated browser". Wat denk je van de kosten, ontwikkelkosten om die oude meuk te handhaven? Er zijn mogelijkheden zat om iets anders ernaast te installeren en systeembeheerder die begint te miepen dat het allemaal niet kan zit ook nog in het stenen tijdperk. De update policy en niet altijd foutloze updates van MS heeft deze angst aangejaagd. In de jaren erna is er een hoop veranderd alleen sommige systeembeheerder niet. Heb dat zelf meerdere malen meegemaakt.

Wat je wel moet doen is een melding opnemen op de site en de gebruiker informeren dat ze een oude browser gebruiken. Dan is meteen het probleem duidelijk, helaas gebeurd dat nog veel te weinig. Wanneer een gebruiker steeds meer ziet dat sites niet werken MOET de gebruiker wel overstappen. Dat is nu juist de bedoeling, de rollen omdraaien dus. Wanneer de gebruiker geen verschil ziet is er geen reden om over te stappen op een andere browser en hou je dus een oude browser overeind. Gebruiker denkt: "Waarom switchen, werkt toch prima?"
Een melding en een link naar een info pagina:
http://www.illumation.net/nl/info/intimation/msie

Wat die doelgroepen betreft, zoals jij zegt, dat is op niets gestaafd. Wanneer het de overheid betreft, kan ik mij wel indenken dat het nog onder IE8 moet werken maar of dat voor elke website geldt? Nee, dan zou je onderzoek moeten doen.

Wanneer je IE8 nog nodig hebt voor bedrijfsapplicaties dan moet je gewoon een modernere browser ernaast installeren. Is mogelijk en niet moeilijk.

[Reactie gewijzigd door codebeat op 29 oktober 2014 13:24]

Wanneer je IE8 nog nodig hebt voor bedrijfsapplicaties dan moet je gewoon een modernere browser ernaast installeren. Is mogelijk en niet moeilijk.

Als je in de omgekeerde wereld leeft zou dat inderdaad mogelijk zijn. Maar bekijk het eens van de kant van het bedrijf waar ik werk.... Laat ik het Bedrijf X noemen.

In Bedrijf X heeft iedere gebruiker een browser nodig. Deze hebben ze voornamelijk om bedrijfsapplicaties te kunnen gebruiken. Deze applicaties zijn geschreven voor IE8 en werken niet op een andere browser. Er is dus IE8 op de PCs geïnstalleerd. Nagenoeg alle websites die voor zakelijke doeleinden nodig zijn werken ook gewoon onder IE8. Waarom zou Bedrijf X dan investeren in iets anders dan IE 8? Er is geen business case, geen geld te verdienen dus gaan we ook geen geld uitgeven.
Als we kijken naar de grote bedrijven in Nederland dan staat Bedrijf X voor minstens de helft van de bedrijven. Neem een KPN, PostNL, veel overheid, een groot deel van Philips en nog zo een paar.

Bedrijf Y wil graag producten verkopen. Hun doelgroep zijn voornamelijk grote bedrijven. Neem gerust Hotel X uit mijn eerdere post als voorbeeld. Om deze producten te verkopen laten ze een website bouwen. Deze website kost 100'000 euro en heeft ondersteuning voor alleen de meest moderne browsers. Dat betekend dat Bedrijf Y via de website nooit Bedrijf X zal bereiken. Daarmee hebben ze dus door eigen keuzes 50% van hun doelgroep uitgeschakeld.

Bedrijf Z verkoopt grofweg dezelfde producten als Bedrijf Y. Ze besteden echter 130'000 euro aan hun website en maken hem daarmee geschikt voor wat oudere browsers. Door 30% meer geld uit te geven hebben ze in één klap hun bereik verdubbelt!

En ga nou nog eens nadenken wie er hier iets moet veranderen.
Moet Bedrijf X geld investeren in de installatie van een nieuwere browser? Wat levert ze dat op dan? Helemaal niets.
Of moet Bedrijf Y mischien gewoon wat extra geld uitgeven aan hun website? Zodat ze tenminste hun doelgroep kunnen bereiken?


The Real World werkt nou eenmaal anders dan al die idealen die er in de techniek uitgesproken worden.

Ik denk dat de mensen die IE8 nog gebruiken geen geld willen uitgeven. Probleem opgelost. Voor een gebruiker is het supersimpel een alternatieve browser te installeren. Ik denk dat je meer energie moet steken in het goed weergeven op een tablet en telefoon dan IE8, zeker wanneer je dingen wilt verkopen. Daarnaast is niet gezegd dat het niet zal werken onder IE8, wellicht werkt het wel maar ziet het er niet uit.

Een website van 100.000-130.000, dat moet wel een heeeeleeee bijzondere website zijn dan. Leef je nog in een ander tijdperk?

Browser stats, kijk hier:
http://www.netmarketshare....aspx?qprid=2&qpcustomd=0

En oja, als je als bedrijf een beetje aan systeembeheer doet, dan heb je vast wel een onderhoudsscript (of je maakt er één) dat automatisch een andere browser kan uitrollen. Zoveel geld hoeft dat niet te kosten en al zeker geen 30.000 euro.

[Reactie gewijzigd door codebeat op 29 oktober 2014 14:13]

Bedrijf X draait dus op 6 jaar oude software en... loopt hopeloos achter op de markt, loopt daarmee elk jaar miljoenen mis aan verloren inkomsten en productiviteit (ook omdat IE 8 enkele factoren langzamer is dan nieuwere browsers), en geeft dus volledig geen prioriteit aan IT of de mensen die significante hoeveelheden tijd op een PC werken

Wat veel bedrijven zich moeten realiseren is dat een groot deel van hun personeel een groot deel van hun tijd achter de PC doorbrengen. Goede PC's met goede software zou daarom prioriteit #1 moeten zijn, even hoog als goede arbeidsomstandigheden, kantoorruimte, en andere zaken die om het personeel draait.

Ik wil een analogie maken met fysieke arbeid, maar dat gaat niet op omdat een 6 jaar oude hamer nog even goed hamert dan een nieuwe - mits die goed is.

Dat klopt, maar de meeste mensen die 2014 aangrepen om een nieuwe systeem te kopen ( danwel laptop of desktop ) deden dit niet aan de hand van zelfbouw, of iig zelden. De kant en klare systemen in de winkels zijn zo goed als allemaal uitgerust met Windows8 en draaien dus op IE10 ( of IE11 op 8.1 ). De niet IT'ers gaan hier écht geen moeite voor doen, anders zouden ze ook geen IE8 gebruiken. "Als het maar werkt, internet is internet"

Denk dat de nieuwe toestroom aan Win7 gebruikers dus minimaal zal zijn, de techies onder ons hebben al lang FireFox of Chrome geïnstalleerd

[Reactie gewijzigd door quintox op 29 oktober 2014 12:50]

Windows 7 PCs kunnen upgraden tot aan IE11's laatste revisie, dus dat is op zich geen probleem.

Erg mooi dat dit de nieuwe standaard gaat worden, geen client side software meer zoals Flash, voor nu ben je het meest compatible met Chrome vwbt HTML 5 support.

http://html5test.com/comp...-32/ie-11/safari-8.0.html

Waar baseer je dat op?
Hopelijk niet op html5test.com aangezien deze 'test' natuurlijk scheef is. En dat geven ze zelf ook toe overigens http://html5test.com/about.html. Tja, als je dan overgaat tot oordelen

Naja voordat ik teveel links post zijn er zat indicaties dat dit zo is,
De tests die gedaan worden geven ja of nee bij een bepaalde functie, dit resultaat geeft een score, of de designer het in productie ook daadwerkelijk zo gaat gebruiken is dan niet belangrijk.

http://fmbip.com/litmus/
http://mobilehtml5.org/
https://html5test.com/results/desktop.html

En uiteraard staat die informatie bij about om niet aansprakelijk te zijn voor informatie die op de website staat, net zoals de voorwaarden van alle andere website's.

" "

[Reactie gewijzigd door Distrax1988 op 29 oktober 2014 09:26]

Naja, wel lezen he..

Why do you include specifications that are not part of HTML5?

Het probleem is dat geen van deze testen zuiver is. Als je wilt oordelen of vergelijken dan vind ik dat je alleen de (candidate) recommendations mag testen. Dus geen 'draft' zaken en zaken die niet eens in de specificatie voorkomen.

Die overige specificaties tellen niet mee in de score, die staan er bij ter indicatie.

Bewijs dat maar.

En nog erger:

We decided to award points for each feature depending on how important that feature is for web developers and how difficult it is to implement that feature

Deze 'Niels Leenheer' geeft een eigen waardeoordeel (dat meeweegt in de score) over de moeilijkheidsgraad van de implementatie van een feature.

because otherwise a browser that only supports the small and simple features would score as high or higher than a browser that went the extra mile and decided to tackle the big features

Omdat een browser dan misschien hoger scoort omdat ie meer ondersteunt

Ik zie het alweer, totaal Microsoft develop minded, oftwel geen discussie mee te beginnen zonder M$ producten te roepen.

Wat voor test is volgens jou wel dan meetbaar en waardevol, er worden harde protocollen en features neer gezet, de test gaat deze 1 voor 1 na en geeft hier positief of negatief als uitkomst, ok 100% zal de test niet zijn maar je gaat me niet vertellen dat op 4 site's waar een score van 500+ gehaald is dat dit ineens 100 zal zijn bij een user end to end test.

Nogmaals indicatief en daarvoor zijn deze testen voldoende om een mening te schetsen.

ooh vergeet ik bijna je smiley

[Reactie gewijzigd door Distrax1988 op 29 oktober 2014 10:54]

Dat is natuurlijk onzin. We leven in een wereld van getallen waarvan vaak niet meer gekeken wordt hoe die getallen tot stand zijn gekomen.

Bewijs dat maar.

Simpel, pak een rekenmachine en tel de scores bij elkaar op. Dan zie je dat ze niet meetellen.

Of, als dat teveel moeite is, vergelijk de score tussen twee browsers waarbij het enige verschil ondersteuning van een aantal van die 'extra' standaarden is*. Je zult zien dat ze evenveel punten krijgen.

Daarom staat er ook: "The following tests go beyond the requirements of the HTML5 specification and are not counted towards the total score."

^{*Pak versie 33 en 34 beta van Firefox voor OS X, het enige verschil is ondersteuning voor h264. Ze scoren beide exact evenveel punten omdat die extra punten niet meetellen voor het totaal.}

Erg mooi voorbeeld van gebruik van HTML5:

Helaas, je browser ondersteunt geen flash of H264 video's. Gebruik voor het afspelen van de video een andere browser, bijvoorbeeld Google Chrome.

Tweakers is de enige site waar ik dit te zien krijg, elders werken de HTML5 players perfect.

Komt omdat tweakers ervoor gekozen heeft zijn videos in h.264 te encoden voor HTML5, een codec die niet in alle browsers zit. De enige oplossing zou zijn om daarnaast ook nog een webm versie te voorzien zodat een Firefox deze wel kan weergeven, maar dat kost weer extra CPU tijd en extra opslag. Vind het zelf ook spijtig daar ik op vele systemen geen flash heb staan en zelf ook nog altijd Firefox gebruik.

Het is ook de moeite niet waard. Op Windows en Linux ondersteunt Firefox gewoon h264 (gebruikt de codec van het onderliggende OS) en binnen een paar weken geldt dat ook op OSX. Het wachten is op Firefox 34.

Het wordt overigens hoog tijd dat Windows onderstening voor h.265 gaat bieden.
Zowel voor plaatjes als voor video.

Enkel en alleen als je de juiste codecs hebt geïnstalleerd staan. En dat kan jij als sitebeheerder niet garanderen.

De bedoeling van een standaard was net dat alles out-of-the-box moet werken, maar met <video> lukt dat dus al niet meer en krijgen we dezelfde problemen als we vroeger met <img> hebben gehad.