Die link is zever. Kijk, HTML5 is jong, en we zijn gebonden aan legacy browsers tot XP verdwenen is. Maar elk van die dingen die gesteld worden, zullen binnen afzienbare tijd mogelijk zijn of zijn gewoon compleet irrelevant (3D transformaties op video: zucht...)
1. HTML 5 can’t interact with a webcam.
3. HTML5 cannot record audio from your microphone.
4. HTML5 cannot do any sort of web conferencing.
6. HTML5 cannot record from your webcam.
=> Komen allemaal op hetzelfde neer: een interface naar hardwareinputs. HTML5 zal dit wel degelijk voorzien op termijn:
http://www.w3.org/TR/html-media-capture/
2. HTML5 video cannot be used on a 3D plane.
=> is geen fundamentele beperking, is een kwestie van tijd. ter info 2D transform lukt al perfect. Zie
http://beta.theexpressiveweb.com/#!/html5-video. En dan zou ik nu graag een voorbeeld hebben van een real-life voorbeeld van 3D-getransformeerde video.
5. HTML5 cannot add dynamic objects to go over the video, like captions, titles, or navigational items.
Versta ik al helemaal niet. Graag zou ik een uitleg hebben wat de moeilijkheid is van een DIV over je video te overlayen met info. Die stelling is gewoon pertinent fout getuigd van een gebrek aan kennis omtrent HTML.
7. HTML5 cannot create desktop apps.
Gmail, Google Docs en Windows 8 anyone
Stelling die weer getuigd van een gebrek aan kennis omtrent HTML5.
8. HTML5 can’t handle video with alpha channels.
Het voorbeeld dat onder dit kopje staat is al niet meer relevant want dat kan je perfect met een canvas. Los daarvan: graag een real life voorbeeld met transparante video?
9. HTML5 doesn’t yet support Peer-2-Peer.
"While P2P is in the HTML5 spec" Then we're through zeker? Next!
10. HTML5 Doesn’t do Full Screen Mode.
Ligt dat aan HTML5? Neen he. Hint: druk eens F11 in je browser
True, sommige van de beperkingen zullen op termijn wel voorzien worden. Maar je kiest toch niet voor een applicatie te maken in een bepaalde technologie op basis van features die "mogelijk op termijn" zullen geïmplementeerd worden. Als je die functionaliteiten nu nodig hebt, dan moet je gekozen technologie die ook nu ondersteunen.
7. Maar hangt telkens af van hoe men kiest HTML5 te implementeren. Zou jij graag 3 verschillende versies van je applicatie maken voor bv iOS, Windows 8 en OSX? Een runtime zoals de AIR runtime biedt dezelfde implementatie op alle platformen.
8. Voorbeelden genoeg op het internet van iemand die doorheen een website/applicatie wandelt om er uitleg over te geven = video with alpha channels.
10. Flash kan bv. in fullscreen draaien zonder dat je browser in fullscreen modus draait. Ik denk dat men dat bedoelt.
[Reactie gewijzigd door Ventis op donderdag 17 november 2011 15:06]
Puntje zeven klopt niet in je redenatie. Het is een standaard en word dus altijd op (ongeveer) dezelfde manier ingebouwd. Het is voor een appbouwer dus niet belangrijk om 3 versies te bouwen zolang je maar een browser (of browser part zoals in KDE) tot je beschikkig hebt en met een HTML5 app mag je ervan uitgaan dat dat het geval is.
Een standaard wil nog niet zeggen dat de implementatie ervan overal hetzelfde is. HTML4 is ook een standaard en die geeft toch soms andere resultaten in verschillende browsers.
Om nu een heel banaal vb. te geven: moest Microsoft morgen beslissen om een HTML5 Canvas op Windows 8 standaard altijd met een rode border te renderen, dan zou je in je Windows 8 versie van je app aanpassingen moeten maken om deze te verwijderen.
Een canvas blijft een canvas, op alle platformen, maar het is het platform dat beslist hoe een canvas tag geïnterpreteerd en gerendered wordt.
In praktijk zal dit soort voorvallen natuurlijk beperkt blijven, maar het gevaar blijft bestaan.
Een standaard wil nog niet zeggen dat de implementatie ervan overal hetzelfde is.
Implementatie interesseert dan ook niemand. Zolang de syntax en resulterende uitvoer maar keihard vastliggen, of dat nu via OpenGL, Cairo of wat dan ook is.
HTML4 is ook een standaard en die geeft toch soms andere resultaten in verschillende browsers.
Dat ligt dan aan browsers die die standaard niet volgen, quirks modi en andere troep. Dezelfde correcte HTML4 Strict pagina in FF, Chrome, IE9 en Opera zal er quasi pixelperfect identiek uitzien.
Om nu een heel banaal vb. te geven: moest Microsoft morgen beslissen om een HTML5 Canvas op Windows 8 standaard altijd met een rode border te renderen, dan zou je in je Windows 8 versie van je app aanpassingen moeten maken om deze te verwijderen. Een canvas blijft een canvas, op alle platformen, maar het is het platform dat beslist hoe een canvas tag geïnterpreteerd en gerendered wordt.
Neen neen neen, de standaard legt juist vast hoe die tag geïnterpreteerd moet worden. Hoe je die rendert is jouw zaak, maar de standaard bepaalt hoe de syntax is, en wat eruit komt.
[Reactie gewijzigd door Bauknecht op vrijdag 18 november 2011 11:00]
Een runtime zoals de AIR runtime biedt dezelfde implementatie op alle platformen.
Ik weet totaal niet waar de klepel hangt, maar ik dacht dat AIR een soort Flash in een virtuele machine was, zoals Java, Mono, etc ook afhankelijk zijn van een klont software die de vertaalslag tussen de code en het platform doet.
Hoe ver zit ik er naast?
Want dit klopt vast niet, waarom zou Apple anders geen Flash player maar wel AIR 'player' ondersteunen?
Dat doet het ook niet. Als je in Flash Builder een app schrijft voor mobieltjes draait het op de AIR runtime als het Android of BB is. Ga je voor iOS wordt het alsnog naar ARM instructies omgezet door een LLVM compiler die adobe heeft geregeld. Dus iOS heeft geen AIR runtime.
@bernardV thanks for the info. Dat klinkt wel alsof hij voor iOS veel optimaler compileert. Ik heb voor Android ook liever ARM instructies.Net ook afhankelijk zijn van dan AIR runtime instructies. Alsof je voor iOS met C++ werkt en voor Android/BB met VisualBasic, om maar even een half acceptabele vergelijking te maken.
Als ze zo goed zijn met rechtstreeks compileren, is die AIR runtime dan niet obsolete aan het worden?
Hangt er helemaal van af hoe goed die compiler is. Maar het grote voordeel van Air is dat het platform onafhankelijk is, "write once run anywhere". Als je voor iOS specifiek gaat compileren moet je op elke iOS versie weer testen of het allemaal nog werkt. Da's nou eenmaal het inherente nadeel van native.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
13:43
12:54
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
