Het grote HTML5 topic

zaterdag 28 augustus 2010 14:59

Acties:

0 Henk 'm!

Topicstarter

(X)HTML5

Introductie:

quote: http://en.wikipedia.org/wiki/HTML5
HTML5 is currently under development as the next major revision of the HTML standard. Like its immediate predecessors, HTML 4.01 and XHTML 1.1, HTML5 is a standard for structuring and presenting content on the World Wide Web. The new standard incorporates features like video playback and drag-and-drop that have been previously dependent on third-party browser plug-ins such as Adobe Flash, Microsoft Silverlight, and Google Gears.

Een aantal nieuwe features:

MathML en SVG gebruiken in text/html
Nieuwe elementen
Nieuwe form controls en methods
Nieuwe attributen
Offline data storage
Nieuwe forms
Multi-threaded javascript
Offline applicatie caching
Canvas element voor 2D drawing

Doctype:

Met HTML5 bestaat er niet langer een verschil tussen Strict/Transitional/etc. Tevens gebruiken HTML5 en XHTML5 dezelfde doctype, lekker makkelijk!

quote: http://xhtml5.nl/naslag/html/doctype
<!DOCTYPE html>

Het verschil tussen HTML5 en XHTML5 kun je aanduiden door het correcte MIME type mee te geven:

HTML5: text/html
HTML5: text/xml
XHTML5: application/xhtml+xml
XHTML5: application/xml

Nieuwe elementen:

<article>
<aside>
<audio>
<canvas>
<command>
<datalist>
<details>
<embed>
<figcaption>
<figure>
<footer>
<header>
<hgroup>
<keygen>
<mark>
<meter>
<nav>
<output>
<progress>
<rp>
<rt>
<ruby>
<section>
<source>
<summary>
<time>
<video>

Bron: http://www.w3schools.com/html5/html5_reference.asp

Zie tevens een lijst met deprecated elementen.

Nieuwe attributen:

contenteditable
contextmenu
data-yourvalue
draggable
hidden
item
itemprop
spellcheck
subject

Bron: http://www.w3schools.com/...ef_standardattributes.asp

Local storage:

Met HTML5 komt er ook een nieuwe manier om data lokaal (dus op de PC van de gebruiker) op te slaan. Door deze vorm van local storage op te nemen in de HTML5 specificatie heeft men ervoor gezorgd dat de opslagmethode browseronafhankelijk is en dus in principe in elke browser zou moeten kunnen werken.

Met de nieuwe opslagmethode zou je ongeveer 5MB aan data op de clientpc op kunnen slaan (de beschikbare ruimte kan variëren, afhankelijk van de wensen van de gebruiker en implementatie van de browser), wat gebeurt via een key/value pair. Hier zie je een voorbeeld van local storage:

quote: http://diveintohtml5.org/storage.html
Let’s see HTML5 Storage in action. Recall the Halma game we constructed in the canvas chapter. There’s a small problem with the game: if you close the browser window mid-game, you’ll lose your progress. But with HTML5 Storage, we can save the progress locally, within the browser itself. Here is a live demonstration. Make a few moves, then close the browser tab, then re-open it. If your browser supports HTML5 Storage, the demonstration page should magically remember your exact position within the game, including the number of moves you’ve made, the position of each of the pieces on the board, and even whether a particular piece is selected.

Zie ook: http://www.w3schools.com/html5/html5_webstorage.asp

Offline applicatie caching:

Met HMTL5 is er een nieuwe manier op webpagina's/bestanden offline op te slaan zodat deze gebruikt kunnen worden wanneer er geen beschikking is over een internetverbinding. Dit gebeurt via het zogenaamde cache manifest, waarmee ingesteld kan worden welke bestanden lokaal opgeslagen mogen worden en welke van het netwerk gehaald moeten worden.

De voordelen hiervan kunnen vrij groot zijn:

quote: http://www.webreference.c...TML5-Application-Caching/
* offline browsing
As the name indicates, the user will be able to browse through the site even when he is offline.
* speed
Files that are cached locally will load much faster. Usually style sheets are shared across all pages of a website. The first time you load a page from a website, it will take some time to download the style sheet, but when you click on other pages, the browser won't need to download the file again.
* reduced load on server
Every time you load a page that has some cached elements, the browser will poll the server to check if the cached file has been updated; if it hasn't, then it won't download it. By doing so, the load on the server is considerably reduced.

Forms:

De HTML5 specificatie biedt een dertiental nieuwe field types, namelijk:

Color
Date
Datetime
Datetime-local
Email
Month
Number
Range
Search
Time
Tel
Url
Week

Zie ook: http://www.w3schools.com/html5/html5_form_input_types.asp

Deze nieuwe form types kunnen de gebruiker een aantal hele handige features bieden wanneer ze volledig geïmplementeerd zijn door de browser. Een aantal voorbeelden:

Bij date, datetime, week, etc. field types kan html automatisch een datepicker tevoorschijn toveren waar de user een tijdstip uit kan kiezen. Dit zorgt ervoor dat je niet meer met Javascript hoeft te rommelen hiervoor.
Automatische controle op bijvoorbeeld het email field type. Dit biedt een client-side controle of het ingevoerde e-mailadres een echt adres is (of in ieder geval een adres met een @ en een .).
De iPhone (en vast ook andere smartphones) passen hun toetsenbord aan aan het field type. Bij de keuze voor number krijg je dus een toetsenbord met nummers, in plaats van letters.
Wanneer de browser het field type niet herkent wordt deze gewoon als type="text" weergeven, waardoor je je form alsnog gewoon kunt gebruiken. Het kiezen voor de nieuwe forms heeft dus altijd voordeel.
Nieuwe attributen zoals autofocus, autocomplete, placeholders,etc. Zie http://www.w3schools.com/html5/html5_form_attributes.asp

Semantiek:

Door de toevoeging van nieuwe elementen kunnen documenten veel semantischer worden opgebouwd. Enkele voorbeelden:

HTML:

<div class="article">
    <div class="head">
        <h1>Artikelnaam</1>
    </div>
    <div class="content">
        <p>Lorem ipsum dolor sit amet, ...</p>
    </div>
</div>

Zou geschreven kunnen worden als:

code:

<section>
    <article>
        <header>
            <h1>Artikelnaam</h1>
        </header>
        <section>
            <p>Lorem ipsum dolor sit amet, ...</p>
        </section>
    </article>
</section>

Semantiekfreaks kunnen dit naar hartelust aanpassen.

Zoals te zien is beschrijf je elementen in een document veel beter op deze manier.

En ander voordeel:

HTML:

1 2	</div> </div>

Wordt:

code:

1 2	</article> </section>

Op deze manier is veel duidelijker te zien waar de afsluittag bij hoort. Erg handig als je een hele zooi geneste elementen hebt

Browsersupport:

Op de volgende pagina is een overzicht te vinden van tags die ondersteund worden door de verschillende lay-out engines:

Wikipedia: Comparison of layout engines (HTML5)

FAQ:

Q: Wanneer komt HTML5 uit

A: Hierover verschillen de meningen... Volgens de W3C time table zal HTML5 eind 2010 een W3C Recommended status krijgen. Ian Hickson daarentegen gokt dat de nieuwe versie van HTML5 pas volledig compleet zal zijn in het jaar 2022. Veel browsers ondersteunen echter al een hoop features van HTML5, dus je kunt er al prima mee werken.

Q: Alle nieuwe elementen zien er raar uit in mijn browser

A: Dat kan kloppen, de elementen zijn al wel te gebruiken maar hebben nog geen eigen stijl. Het toevoegen van display: block aan de CSS van alle nieuwe elementen zou dit op moeten lossen.

Q: Help, mijn <opmaakelementen> zijn verdwenen

A: Don't worry! Dit kan simpel met CSS worden opgelost.

Q: Heeft er iemand nog vragen

A: DM me

Links:

Tot slot:

HTML5 is nog niet klaar, maar kan al wel gebruikt worden. Dit topic is bedoeld om je ervaringen te delen, handige informatie met elkaar te delen en discussies te voeren over de toepassingen van HTML5.

zaterdag 28 augustus 2010 16:58

Acties:

0 Henk 'm!

Sebazzz

3dp

Nog een tip, voor IE support lager dan 9 kan je met een Javascript hack de section e.d. elementen toevoegen door van document.createElement gebruik te maken. Er zitten uiteraard twee flaws aan deze methode, ten eerste is javascript required, ten tweede moet je zoals in de TS staat alle elementen expliciet stylen met een CSS display property.

Ik zou deze methode nog niet voor professioneel development gebruiken, maar HTML 5 uberhaupt niet

[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]

zaterdag 28 augustus 2010 17:05

Acties:

0 Henk 'm!

orf

Sebazzz schreef op zaterdag 28 augustus 2010 @ 16:58:
Nog een tip, voor IE support lager dan 9 kan je met een Javascript hack de section e.d. elementen toevoegen door van document.createElement gebruik te maken.

Modernizr is daar wel leuk voor.

zaterdag 28 augustus 2010 17:07

Acties:

0 Henk 'm!

Avalaxy

Topicstarter

Sebazzz schreef op zaterdag 28 augustus 2010 @ 16:58:
Ik zou deze methode nog niet voor professioneel development gebruiken, maar HTML 5 uberhaupt niet

Nouja, deels.

Ik zou voor een professionele site nog niet de HTML5 elementen gebruiken omdat deze later nog markup mee kunnen krijgen, of wijzigingen aan de implementatie van browsers. Echter kun je prima al gewoon een HTML5 doctype gebruiken en dus (bijvoorbeeld) de nieuwe form field types gebruiken, die gewoon backwards compatible zijn met HTML4.01.

zaterdag 28 augustus 2010 17:10

Acties:

0 Henk 'm!

Voutloos

orf schreef op zaterdag 28 augustus 2010 @ 17:05:
[...]
Modernizr is daar wel leuk voor.

Modernizr lijkt puur voor detectie van features en niet voor het oplossen van missende features?

[ Voor 60% gewijzigd door Voutloos op 28-08-2010 17:11 ]

{signature}

zaterdag 28 augustus 2010 17:20

Acties:

0 Henk 'm!

orf

Voutloos schreef op zaterdag 28 augustus 2010 @ 17:10:
[...]
Modernizr lijkt puur voor detectie van features en niet voor het oplossen van missende features?

HTML 5 elements in IE
Modernizr runs through a little loop in JavaScript to enable the various elements from HTML5 (as well as abbr) for styling in Internet Explorer. Note that this does not mean it suddenly makes IE support the Audio or Video element, it just means that you can use section instead of div and style them in CSS. As of Modernizr 1.5, this script is identical to what is used in the popular html5shim/html5shiv library. Both also enable printability of HTML5 elements in IE6-8.

zaterdag 28 augustus 2010 17:25

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Sebazzz schreef op zaterdag 28 augustus 2010 @ 16:58:
Ik zou deze methode nog niet voor professioneel development gebruiken, maar HTML 5 uberhaupt niet

Mwah, het doctype vast gebruiken kan geen kwaad en zorgt meteen dat IE9 uiteindelijk je site goed rendert. Daarnaast hangt het wel of niet gebruiken van de elementen af van je doelgroep. Als die voor 99% een moderne browser gebruikt zou ik zeker HTML5 overwegen. Doe je een klus voor een gesloten bedrijfsnetwerk waar men nog IE6 gebruikt, doe het dan vooral niet. Use the best tool for the job.

orf schreef op zaterdag 28 augustus 2010 @ 17:05:
[...]

Modernizr is daar wel leuk voor.

Ik zou daar liever de variant van GoogleCode voor gebruiken. Die doet namelijk niets behalve die elementen mogelijk maken.

Dat is meteen ook de code die aangehaald wordt in de quote in je post hier boven me.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

zaterdag 28 augustus 2010 17:31

Acties:

0 Henk 'm!

orf

NMe schreef op zaterdag 28 augustus 2010 @ 17:25:
[...]
Ik zou daar liever de variant van GoogleCode voor gebruiken. Die doet namelijk niets behalve die elementen mogelijk maken. Dat is meteen ook de code die aangehaald wordt in de quote in je post hier boven me.

Maar met Modernizr heb je dan direct een mooie toolkit om ook te kijken of je nog aanvullende JS moet gebruiken om sommige elementen ook daadwerkelijk functie te geven.

zaterdag 28 augustus 2010 18:23

Acties:

0 Henk 'm!

Sebazzz

3dp

NMe schreef op zaterdag 28 augustus 2010 @ 17:25:
[...]

Mwah, het doctype vast gebruiken kan geen kwaad en zorgt meteen dat IE9 uiteindelijk je site goed rendert. Daarnaast hangt het wel of niet gebruiken van de elementen af van je doelgroep. Als die voor 99% een moderne browser gebruikt zou ik zeker HTML5 overwegen.

Zelfs op Tweakers.net, een ICT site waar geeks op zitten die het beste willen hebben, is dat percentage voorlopig nog niet 99%, zelfs al trekken we er IE6 en IE7 vanaf.

[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]

zaterdag 28 augustus 2010 18:29

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Sebazzz schreef op zaterdag 28 augustus 2010 @ 18:23:
[...]

Zelfs op Tweakers.net, een ICT site waar geeks op zitten die het beste willen hebben, is dat percentage voorlopig nog niet 99%, zelfs al trekken we er IE6 en IE7 vanaf.

Ik noem ook maar wat willekeurige voorbeelden. Bovendien zijn er prima situaties te bedenken waar je 100% zeker weet dat al je gebruikers gebruik maken van browser X, bijvoorbeeld binnen een bedrijfsnetwerk. Daarnaast werken de aangehaalde javascripts prima, dus als javascript geen probleem is zie ik geen reden om niet alvast te kiezen voor future-proof HTML5 op plekken waar dat geen problemen oplevert.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

maandag 30 augustus 2010 15:56

Acties:

0 Henk 'm!

_Thanatos_

Ja, en kaal

Buiten het feit dat de doctype van HTML maar poep is (doctype ipv schema; geen versienummer) en het op SGML gebaseerd is ipv het superieure XML... Die discussie is nu wel gevoerd.

Ander nadeel nog:
HTML5 is pas zinnig op het moment dat IE8 helemaal uitgefaseerd is. HTML5 kan niet zonder CSS3 als je zo'n waarde hecht aan de semantiek van die nieuwe tags. Want als je mooie visuele stijltjes wilt maken, dan wil je niet voor het probleem komen te staan dat je toch weer allerlei wrappers nodig hebt die de semantiek doen verwazen in een spagetti van divs.

Daarbij is het nog maar de vraag wat de waarde van die extra semantiek is, want het heeft pas nut als screenreaders voor blinden, de toetsenbordnavigatie voor mensen die geen muis kunnen gebruiken, en de zoekmachines er ook echt wat mee doen. Als dat niet het geval is, is <article> en <section> precies evenveel waard als een <div>.

Nog een nadeeltje dan:
Er wordt geen enkele eis gesteld aan de javascript-parser. In feite zou een HTML5-browser met javascript 1.2 mogen werken, terwijl het nu toch echt weleens tijd wordt voor ECMAscript 5. Dit geldt ook voor <video> en <audio> waar geen eis wordt gesteld voor de minimale codec-support. Er is nu wel WebM, maar dat is ook maar so-so. In de praktijk moet je meerdere video's aan de browser willen geven, en dit zal voor audio evenzo gelden.

[ Voor 20% gewijzigd door _Thanatos_ op 30-08-2010 15:59 ]

日本！🎌

maandag 30 augustus 2010 16:01

Acties:

0 Henk 'm!

harrald

_Thanatos_ schreef op maandag 30 augustus 2010 @ 15:56:
Buiten het feit dat de doctype van HTML maar poep is (doctype ipv schema; geen versienummer) en het op SGML gebaseerd is ipv het superieure XML... Die discussie is nu wel gevoerd.

Ander nadeel nog:
HTML5 is pas zinnig op het moment dat IE8 helemaal uitgefaseerd is. HTML5 kan niet zonder CSS3 als je zo'n waarde hecht aan de semantiek van die nieuwe tags. Want als je mooie visuele stijltjes wilt maken, dan wil je niet voor het probleem komen te staan dat je toch weer allerlei wrappers nodig hebt die de semantiek doen verwazen in een spagetti van divs.

Daarbij is het nog maar de vraag wat de waarde van die extra semantiek is, want het heeft pas nut als screenreaders voor blinden, de toetsenbordnavigatie voor mensen die geen muis kunnen gebruiken, en de zoekmachines er ook echt wat mee doen. Als dat niet het geval is, is <article> en <section> precies evenveel waard als een <div>.

Nog een nadeeltje dan:
Er wordt geen enkele eis gesteld aan de javascript-parser. In feite zou een HTML5-browser met javascript 1.2 mogen werken, terwijl het nu toch echt weleens tijd wordt voor ECMAscript 5. Dit geldt ook voor <video> en <audio> waar geen eis wordt gesteld voor de minimale codec-support. Er is nu wel WebM, maar dat is ook maar so-so. In de praktijk moet je meerdere video's aan de browser willen geven, en dit zal voor audio evenzo gelden.

Beetje kip ei verhaal denk ik

Dus jij wil wachten met html5 omdat de screenreaders en zoekbotjes er nog niks mee doen? tuurlijk doen ze er nu niks mee als er geen websites zijn die het gebruiken.

En je kan nu al wel delen van html5 gebruiken.

maandag 30 augustus 2010 16:02

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

_Thanatos_ schreef op maandag 30 augustus 2010 @ 15:56:
HTML5 is pas zinnig op het moment dat IE8 helemaal uitgefaseerd is. HTML5 kan niet zonder CSS3 als je zo'n waarde hecht aan de semantiek van die nieuwe tags. Want als je mooie visuele stijltjes wilt maken, dan wil je niet voor het probleem komen te staan dat je toch weer allerlei wrappers nodig hebt die de semantiek doen verwazen in een spagetti van divs.

Ehm...why? Je kan de nieuwe elementen ook zonder CSS3 prima stylen?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

maandag 30 augustus 2010 16:15

Acties:

0 Henk 'm!

Hiroj

NMe schreef op maandag 30 augustus 2010 @ 16:02:
[...]

Ehm...why? Je kan de nieuwe elementen ook zonder CSS3 prima stylen?

Precies, je kunt HTML5 al gebruiken met CSS2.
Persoonlijk zie ik enkel voordelen in HTML5. Zo hoef je bijvoorbeeld niet meer per se een aparte <div> of <p> aan te maken om je (nieuws)artikelen te plaatsen, maar gebruiken we voortaan gewoon <article>.

HTML5 zal dus een hoop dingen voor de programmeur overzichtelijker maken en voegt voor de gebruiker eventueel extra functionaliteit toe.
Echter wat ik mij eigen afvraag is; nu HTML5 over audio en video tags beschikt, hoe zal ons dataverkeer daardoor eruit gaan zien?

maandag 30 augustus 2010 16:26

Acties:

0 Henk 'm!

Sebazzz

3dp

Hiroj schreef op maandag 30 augustus 2010 @ 16:15:
[...]

Echter wat ik mij eigen afvraag is; nu HTML5 over audio en video tags beschikt, hoe zal ons dataverkeer daardoor eruit gaan zien?

Ik denk niet dat dat significant zal veranderen. Huidige oplossingen zouden eerder vervangen worden, maar veel zou dat niet schelen in dataverkeer.

[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]

maandag 30 augustus 2010 16:27

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Sebazzz schreef op maandag 30 augustus 2010 @ 16:26:
[...]

Ik denk niet dat dat significant zal veranderen. Huidige oplossingen zouden eerder vervangen worden, maar veel zou dat niet schelen in dataverkeer.

Als het al scheelt wordt het hooguit beter omdat je niet een complete Flash-file hoeft te downloaden om een filmpje te bekijken of muziek te luisteren.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

maandag 30 augustus 2010 16:35

Acties:

0 Henk 'm!

mcDavid

Hiroj schreef op maandag 30 augustus 2010 @ 16:15:
[...]

Echter wat ik mij eigen afvraag is; nu HTML5 over audio en video tags beschikt, hoe zal ons dataverkeer daardoor eruit gaan zien?

Niet heel anders denk ik. Op dit moment worden datsoort functies ook al gebruikt, met de nodige plugins (flash, silverlight, mediaplayers, enz.).

Wat vooral het verschil is, is dat straks die plugins niet meer nodig zijn. Voor de gebruiker thuis scheelt dat een hoop rekenkracht, voor de developer scheelt dat een hoop gedoe (minder verschillende talen dus overzichtelijker), en voor beide scheelt het een hoop compatibility-problemen.

Dat laatste is nog wel even spannend, want daar is ook een open en universeel gebruikte codec voor nodig. Maar met WebM lijkt dat wel goed te komen.

maandag 30 augustus 2010 21:58

Acties:

0 Henk 'm!

Verwijderd

HTML5, een grote stap voorwaarts. Ik vraag me alleen af hoe lang het zal duren voordat HTML5 websites mainstream worden gezien de gigantische hoeveelheid mensen die nog met een verouderde browser werken.

Ik vraag me echter wel af wat de technische verschillen zijn tussen XHTML5 en HTML5 gezien het feit dat de doctypes straks hetzelfde zullen zijn. Waarom überhaubt nog HTML gebruiken?
Verder ben ik ook heel benieuwd naar de nieuwe multi-threading mogelijkheden van javascript en in hoeverre je daar invloed op zult hebben als programmeur/scripter. JS is immers al ietwat multi-threaded van nature, dus wellicht dat dit alleen qua performance leuk zal zijn.

maandag 30 augustus 2010 22:03

Acties:

0 Henk 'm!

Avalaxy

Topicstarter

Verwijderd schreef op maandag 30 augustus 2010 @ 21:58:
Ik vraag me echter wel af wat de technische verschillen zijn tussen XHTML5 en HTML5 gezien het feit dat de doctypes straks hetzelfde zullen zijn.

Tadaaa: http://wiki.whatwg.org/wi...es_Between_HTML_and_XHTML

Waarom überhaubt nog HTML gebruiken?

Waarom überhaupt nog XHTML gebruiken nu de XHTML "exclusieve features" MathML en SVG ook in HTML5 zijn te gebruiken met text/html MIME-type?

Well-formedness errors, nounou

Oh wait, beter voorkomen we deze discussie

[ Voor 4% gewijzigd door Avalaxy op 30-08-2010 22:08 ]

dinsdag 31 augustus 2010 08:58

Acties:

0 Henk 'm!

Hiroj

Verwijderd schreef op maandag 30 augustus 2010 @ 21:58:
HTML5, een grote stap voorwaarts. Ik vraag me alleen af hoe lang het zal duren voordat HTML5 websites mainstream worden gezien de gigantische hoeveelheid mensen die nog met een verouderde browser werken.

Ik vraag me echter wel af wat de technische verschillen zijn tussen XHTML5 en HTML5 gezien het feit dat de doctypes straks hetzelfde zullen zijn. Waarom überhaubt nog HTML gebruiken?
Verder ben ik ook heel benieuwd naar de nieuwe multi-threading mogelijkheden van javascript en in hoeverre je daar invloed op zult hebben als programmeur/scripter. JS is immers al ietwat multi-threaded van nature, dus wellicht dat dit alleen qua performance leuk zal zijn.

Voordat HTML5 een standaard is zullen we wel inmiddels 2 á 3 browser versies verder zijn. Meeste mensen zullen dan ook afgestapt zijn van hun stokoude computers. Tegenwoordig heb je op de nieuwere computers vaak ook de laatste browser versie staan, zeer zeker met Windows.

dinsdag 31 augustus 2010 09:56

Acties:

0 Henk 'm!

Verwijderd

Avalaxy schreef op maandag 30 augustus 2010 @ 22:03:
Waarom überhaupt nog XHTML gebruiken nu de XHTML "exclusieve features" MathML en SVG ook in HTML5 zijn te gebruiken met text/html MIME-type? Well-formedness errors, nounou

Precies de reden waarom ik altijd XHTML gebruik. Je krijgt toch nettere code, hoe je het ook went of keert. HTML is voor mensen die te lui zijn om hun tags af te sluiten.

Oh wait, beter voorkomen we deze discussie

Ik voel een HTML vs XHTML "welles-nietes"-battle opkomen

Hiroj schreef op dinsdag 31 augustus 2010 @ 08:58:
[...]

Voordat HTML5 een standaard is zullen we wel inmiddels 2 á 3 browser versies verder zijn. Meeste mensen zullen dan ook afgestapt zijn van hun stokoude computers. Tegenwoordig heb je op de nieuwere computers vaak ook de laatste browser versie staan, zeer zeker met Windows.

Daar zeg je wel wat, ware het niet dat nog steeds heel veel bedrijven nog achter moeten blijven qua besturingssystemen omdat hun webapplicaties niet op moderne browsers kunnen draaien. Lees: IE6 only. Dat geldt ook voor scholen en andere openbare instanties die nog in het stenen tijdperk leven qua ICT.

dinsdag 31 augustus 2010 10:38

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

html5 doctype
Geen reden om niet te gebruiken. Geeft je veel meer vrijheid en is backwards compatible. Dus gewoon standardsmode in alle browsers. Je hebt zelf de keuze of je xhtml5 of niet wilt gebruiken. Veel social media springen hier ook al op in. Zo maken de nieuwe video-embed methodes van Vimeo en YouTube gebruik van iframes en video-tags (beiden niet mogelijk in xhtml strict uiteraard).

Sowieso als je natuurlijk een enigszins moderne website wilt en ook iPad/iPhone etc wilt ondersteunen is html5 bijna een must vandaag de dag. Voor video kom je er helemaal niet meer onderuit.

html5 specifieke tags (op video/audio na)
Persoonlijk zeg ik nog niet gebruiken tot IE9 een aanzienlijk marktaandeel heeft. Nu zadel je nog 60-70% van je bezoekers op met een JS-based hack, terwijl ze hier zelf helemaal geen voordeel aan ondervinden.

html5 video
Kom je bijna niet meer omheen vandaag de dag met tientallen miljoenen iDevices in het wild. En eerlijk gezegd vind ik de video-tag stukken beter werken dan Flash video-players. Je moet iets meer versies van de video beschikbaar hebben, maar hier zijn genoeg oplossingen voor. Verder kun je eenvoudig html5 video gebruiken met Flash fallback en dat allemaal zonder JS-requirement (in ieder geval zodra Firefox hun ui-bug fixed

). Dat is wederom ook de reden dat Vimeo/YouTube overgaan op de iframe-methode.

Al met al is er geen reden op html4 of xhtml te blijven hangen, tenzij je jezelf op korte termijn in de vingers wilt snijden.

dinsdag 31 augustus 2010 11:11

Acties:

0 Henk 'm!

Verwijderd

Verwijderd schreef op dinsdag 31 augustus 2010 @ 09:56:
[...]

Precies de reden waarom ik altijd XHTML gebruik. Je krijgt toch nettere code, hoe je het ook went of keert. HTML is voor mensen die te lui zijn om hun tags af te sluiten.

Sinds wanneer ben je in HTML verplicht om je tags niet af te sluiten?

dinsdag 31 augustus 2010 11:21

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Precies, je kunt HTML5 al gebruiken met CSS2.
Persoonlijk zie ik enkel voordelen in HTML5. Zo hoef je bijvoorbeeld niet meer per se een aparte <div> of <p> aan te maken om je (nieuws)artikelen te plaatsen, maar gebruiken we voortaan gewoon <article>.

Sterker, je mag gewoon CSS1 gebruiken. M.a.w. de CSS-standaard is helemaal niet relevant in een discussie over HTML. CSS3 is een aparte discussie (mijnsinziens veel interessanter dan HTML5).

En een div/p gebruiken om je nieuwsartikelen te plaatsen? Dan mis je volgens mij het hele idee van waar de p-tag voor bedoeld is. Binnen je article dien je uiteraard nog steeds gewoon je content op te maken met paragraphs.

dinsdag 31 augustus 2010 11:28

Acties:

0 Henk 'm!

idutcher

Het boek: "HTML5 for webdesigners" vind ik zeker een aanrader, voor degene die snel iets willen leren.
Het is een boek met ongeveer 85 pagina's dacht ik, en je kan bijna direct aan de slag met HTML5.

Ik gebruik zelf alleen docktype op het moment, maar binnenkort maar wat gaan spelen met JS .

dinsdag 31 augustus 2010 11:41

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Verwijderd schreef op dinsdag 31 augustus 2010 @ 09:56:
[...]

Precies de reden waarom ik altijd XHTML gebruik. Je krijgt toch nettere code, hoe je het ook went of keert. HTML is voor mensen die te lui zijn om hun tags af te sluiten.

HTML verbiedt je niet om je tags af te sluiten en ik sluit dus zonder uitzondering al mijn tags af. Daar heb ik geen XHTML voor nodig, dus als dat je enige voordeel is boven HTML, dan zou ik mijn mening maar eens herzien als ik jou was.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

dinsdag 31 augustus 2010 12:57

Acties:

0 Henk 'm!

Verwijderd

Verwijderd schreef op dinsdag 31 augustus 2010 @ 11:11:
[...]

Sinds wanneer ben je in HTML verplicht om je tags niet af te sluiten?

Dat zeg ik toch nergens?

In HTML hoef je niet je tags af te sluiten, dat is alles wat ik bedoelde met "luie" webdevvers.

NMe schreef op dinsdag 31 augustus 2010 @ 11:41:
[...]

HTML verbiedt je niet om je tags af te sluiten en ik sluit dus zonder uitzondering al mijn tags af. Daar heb ik geen XHTML voor nodig, dus als dat je enige voordeel is boven HTML, dan zou ik mijn mening maar eens herzien als ik jou was.

Zie hierboven.

Blijkbaar is begrijpend lezen voor sommige mensen toch nog best moeilijk.

dinsdag 31 augustus 2010 12:59

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Verwijderd schreef op dinsdag 31 augustus 2010 @ 12:57:
[...]

Dat zeg ik toch nergens? In HTML hoef je niet je tags af te sluiten, dat is alles wat ik bedoelde met "luie" webdevvers.

[...]

Zie hierboven.

Blijkbaar is begrijpend lezen voor sommige mensen toch nog best moeilijk.

Die sneer is nergens voor nodig. Daarnaast gaat "hierboven" niet in op wat ik zeg: waarom zou HTML ondergeschikt zijn aan XHTML alleen omdat HTML de mogelijkheid heeft om tags open te laten? Als je die mogelijkheid niet gebruikt is er op dat vlak geen enkel verschil tussen de standaarden en daarom is het een non-argument voor de keuze voor XHTML.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

dinsdag 31 augustus 2010 13:32

Acties:

0 Henk 'm!

Verwijderd

NMe schreef op dinsdag 31 augustus 2010 @ 12:59:
[...]

Die sneer is nergens voor nodig. Daarnaast gaat "hierboven" niet in op wat ik zeg: waarom zou HTML ondergeschikt zijn aan XHTML alleen omdat HTML de mogelijkheid heeft om tags open te laten? Als je die mogelijkheid niet gebruikt is er op dat vlak geen enkel verschil tussen de standaarden en daarom is het een non-argument voor de keuze voor XHTML.

Wederom: ik stel ook nergens dat XHTML superieur is aan HTML, enkel dat je wordt geforceerd om well-formed HTML te schrijven. Die "sneer" lijkt me dus volkomen terecht in dit geval

dinsdag 31 augustus 2010 14:11

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Die forcering moet niet uit de standaard komen, maar uit je kwaliteit als ontwikkelaar.

Je kunt net zo goed een puinhoop van XHTML maken, wat de meeste XHTML-developers ook doen is mijn ervaring. Zelfs als je al je tags netjes afsluit

Het afsluiten van tags is daarom een non-issue. Kwaliteit van frontend-code ligt in semantiek, accessibility, performance en compatibility, niet in het wel of niet afsluiten van tags.

[ Voor 40% gewijzigd door Bosmonster op 31-08-2010 14:14 ]

woensdag 1 september 2010 10:59

Acties:

0 Henk 'm!

moozzuzz

Verwijderd schreef op dinsdag 31 augustus 2010 @ 09:56:
Precies de reden waarom ik altijd XHTML gebruik. Je krijgt toch nettere code, hoe je het ook went of keert. HTML is voor mensen die te lui zijn om hun tags af te sluiten.

offtopic:
Persoonlijk voel ik me niet erg lui en als je XHTML nodig hebt om netter te coden moet je misschien toch maar een carriere als slager of bakker ambiëren (met alle respect voor slagers en bakkers overigens).

Een feature die ik niet meteen link aan HTML5 is de Multi-threaded javascript. Verder verwacht ik erg veel van de vernieuwingen op vlak van forms. Ik gebruik ze al in nieuwe hobbyprojectjes. Of je dan bij een <input type="date"> meteen een browser-datepicker wenst is wel de vraag. De huidige javascripts hebben net het voordeel dat je je datepicker helemaal kan customizen.

Of de nieuwe structuur-gerelateerde elementen (nu nog niet geimplementeerd) meteen gebruikt moeten worden ben ik wat minder van overtuigd. Eenmaal geimplementeerd door een nieuwe browserversie, krijgen die wellicht een browser-specifieke style toegemeten die mogelijks invloed heeft op je layout. Extreem voorbeeld: stel dat IE of FF het in hun hoofd halen om een article standaard een border-left: 2px solid orange; mee te geven ben je daar wellicht niet zo erg mee gediend.

woensdag 1 september 2010 11:18

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

moozzuzz schreef op woensdag 01 september 2010 @ 10:59:
[...]

Of de nieuwe structuur-gerelateerde elementen (nu nog niet geimplementeerd) meteen gebruikt moeten worden ben ik wat minder van overtuigd. Eenmaal geimplementeerd door een nieuwe browserversie, krijgen die wellicht een browser-specifieke style toegemeten die mogelijks invloed heeft op je layout. Extreem voorbeeld: stel dat IE of FF het in hun hoofd halen om een article standaard een border-left: 2px solid orange; mee te geven ben je daar wellicht niet zo erg mee gediend.

Iets dat effect heeft op je lay-out hoor je sowieso al per definitie gewoon te definiëren in je CSS, ook als het defaultgedrag van browsers dat onnodig maakt. Juist omdat je nooit alle browsers checkt.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

woensdag 1 september 2010 11:19

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Daarnaast is default styling ook gewoon beschreven in de standaard.

woensdag 1 september 2010 11:40

Acties:

0 Henk 'm!

Hiroj

NMe schreef op dinsdag 31 augustus 2010 @ 11:41:
[...]

HTML verbiedt je niet om je tags af te sluiten en ik sluit dus zonder uitzondering al mijn tags af. Daar heb ik geen XHTML voor nodig, dus als dat je enige voordeel is boven HTML, dan zou ik mijn mening maar eens herzien als ik jou was.

Het is en blijft een eigen voorkeur hebben in hoe jij je opmaak regelt. Zelf zorg ik er altijd voor dat mijn werk er netjes uitziet. Andere vinden dit weer niet nodig en dat moet ook kunnen vind ik.

En als het niet nodig is, tja dan is het ieder zijn eigen keuze hoe zij het gaan gebruiken.
Het is niet zo dat iemand (tot dusver) jou dwingt om een bepaalde manier van programmeren aan te nemen.

donderdag 13 januari 2011 12:11

Acties:

0 Henk 'm!

rickiii

Hoe zit het eigenlijk met de hardware decoding van WebM?

Sinds het nieuws bericht over het wegvallen van H264 ondersteuning uit Chrome, lees ik veel commentaar waarin wordt beweerd dat dit nadelig kan zijn voor mobile devices die softwarematig WebM zullen moeten decoderen terwijl ze allemaal een H264 hardware-decoder aan boord hebben.

Maar hoe zit het met decoding in PC's. Als ik nu een gloednieuwe PC (met top-videokaart) koop dan kan ik waarschijnlijk alle huidige H264 en WebM (HD) content vlekkeloos afspelen, maar zit er nog wel een verschil tussen de twee? Zal mijn PC significant meer processorkracht nodig hebben om WebM (HD) content te decoderen?

Ik denk altijd heel goed na voordat ik iets stoms zeg

donderdag 13 januari 2011 12:19

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Dat hangt van de browser/decoder af, of ze hardware-versnelling inbouwen voor het decoden van WebM of niet.

Hardware-versnelling voor bijvoorbeeld h.264 zit in OS X ingebakken, dus is dat makkelijk ondersteunen. Voor WebM zal daar nog en flinke inhaalslag voor gemaakt moeten worden.

[ Voor 103% gewijzigd door Bosmonster op 13-01-2011 12:21 ]

donderdag 13 januari 2011 12:33

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Het grootste nadeel is dat Chrome-gebruikers Flash nodig zullen hebben om H.264-video te kunnen bekijken en dat gebruikers van andere browsers datzelfde voor WebM moeten doen. Althans, op zijn minst in de overgangsperiode. Dus uitgerekend nu browsers unaniem voor eenzelfde standaard kiezen komt Google even roet in het eten gooien met een standaard die ze zelf verzonnen hebben. Granted, de standaard is open, maar ze maken het niet makkelijker voor webdevelopers maar juist moeilijker.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 12:52

Acties:

0 Henk 'm!

mcDavid

NMe schreef op donderdag 13 januari 2011 @ 12:33:
Het grootste nadeel is dat Chrome-gebruikers Flash nodig zullen hebben om H.264-video te kunnen bekijken en dat gebruikers van andere browsers datzelfde voor WebM moeten doen. Althans, op zijn minst in de overgangsperiode. Dus uitgerekend nu browsers unaniem voor eenzelfde standaard kiezen komt Google even roet in het eten gooien met een standaard die ze zelf verzonnen hebben. Granted, de standaard is open, maar ze maken het niet makkelijker voor webdevelopers maar juist moeilijker.

Niet helemaal mee eens. Tot nu toe zaten alle browsers op een ander pad. Door H.264 te droppen, lijkt de uitkomst van de "codec-oorlog" toch wel min of meer beslist in het voordeel van WebM. Safari en Opera hebben nu weinig keus meer dan die beslissing gewoon te volgen. Kortom, door de oorlog tot een vervroegd einde te brengen kunnen webdevelopers eindelijk aan de slag met HTML-video zonder het risico te lopen "de verkeerde codec" te kiezen.

Ik denk (hoop) dat weinig developers flash zullen verkiezen boven HTML5 met als enige reden H.264 kunnen te blijven gebruiken.

[ Voor 5% gewijzigd door mcDavid op 13-01-2011 12:55 ]

donderdag 13 januari 2011 12:59

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

mcDavid schreef op donderdag 13 januari 2011 @ 12:52:
[...]

Niet helemaal mee eens. Tot nu toe zaten alle browsers op een ander pad. Door H.264 te droppen, lijkt de uitkomst van de "codec-oorlog" toch wel min of meer beslist in het voordeel van WebM. Safari en Opera hebben nu weinig keus meer dan die beslissing gewoon te volgen. Kortom, door de oorlog tot een vervroegd einde te brengen kunnen webdevelopers eindelijk aan de slag met HTML-video zonder het risico te lopen "de verkeerde codec" te kiezen.

Waarom zouden Safari en Opera Chrome volgen? Chrome heeft een marktaandeel van 10%, en zolang Microsoft niet overstag gaat naar WebM (en dat zie ik niet snel gebeuren) zullen we altijd een tweedeling hebben. Waardoor de codec-oorlog dus juist verre van beslist is en webdevelopers weer de pineut zijn met conditionele code en eventueel zelfs dataduplicatie in de vorm van video in beide formaten.

Ik denk (hoop) dat weinig developers flash zullen verkiezen boven HTML5 met als enige reden H.264 kunnen te blijven gebruiken.

Wat moeten we dan? Overstappen op WebM en maar voor lief nemen dat dat in IE niet werkt? Of beide formaten gebruiken waardoor je dus elke film dubbel op je server hebt staan?

[ Voor 18% gewijzigd door NMe op 13-01-2011 13:00 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 13:11

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Dat is nu toch niet anders? Je moet nu ook h.264 + WebM + Flash ondersteunen als je een video html5-ready wilt tonen. Dat Chrome h.264 support dropt verandert daar niets aan.

De reden dat juist MS en Apple huiverig zijn met het gebruik van WebM is doordat het onduidelijk is of hier in de toekomst patent-issues voor op zullen treden. Het mag opensource zijn, maar er is veel techniek geleend. Als die ontwikkelaars/bedrijven in de toekomst ineens geld ruiken heeft de WebM standaard (en ondersteunende bedrijven) een flink probleem.

Voor MS/Apple is h.264 een veel minder risicovolle keuze. De patenten en licenties zijn volledig duidelijk.

donderdag 13 januari 2011 13:19

Acties:

0 Henk 'm!

rickiii

Bosmonster schreef op donderdag 13 januari 2011 @ 13:11:
Voor MS/Apple is h.264 een veel minder risicovolle keuze. De patenten en licenties zijn volledig duidelijk.

Het is niet zo duidelijk als het lijkt
http://www.streaminglearn...hat-you-need-to-know.html

Ik denk dat ik daarom ook achter de beslissing van Google sta.
Het is een pijnlijke beslissing op de korte termijn om eventuele grotere schade in de toekomst te voorkomen.

Ik denk altijd heel goed na voordat ik iets stoms zeg

donderdag 13 januari 2011 13:27

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Wat ik dan weer niet begrijp is waarom er support voor specifieke codecs moet zitten in de browser. Daar hebben we het OS toch voor? Waarom kan ik straks geen h.264 content meer afspelen in Chrome, terwijl de codec gewoon geïnstalleerd is?

[ Voor 28% gewijzigd door .oisyn op 13-01-2011 13:28 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 13:32

Acties:

0 Henk 'm!

mcDavid

NMe schreef op donderdag 13 januari 2011 @ 12:59:
[...]

Waarom zouden Safari en Opera Chrome volgen? Chrome heeft een marktaandeel van 10%, en zolang Microsoft niet overstag gaat naar WebM (en dat zie ik niet snel gebeuren) zullen we altijd een tweedeling hebben. Waardoor de codec-oorlog dus juist verre van beslist is en webdevelopers weer de pineut zijn met conditionele code en eventueel zelfs dataduplicatie in de vorm van video in beide formaten.

Wat ik begrepen is, is dat IE nog helemaal geen codec gaat implementeren maar alleen plugins hiervoor ondersteunt. En ze hebben toegezegd dat WebM ook dmv een plugin te gebruiken zal zijn.

Alleen de "echte" browsers hebben zelf codecs aan boord. Waarbij Safari op H.264 zat, Firefox op OGG/Theora en WebM, en Chrome op H.264 en WebM. OGG/Theora viel al min of meer af als serieuze kandidaat, en H.264 nu ook.

donderdag 13 januari 2011 13:38

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 13:11:
Dat is nu toch niet anders? Je moet nu ook h.264 + WebM + Flash ondersteunen als je een video html5-ready wilt tonen. Dat Chrome h.264 support dropt verandert daar niets aan.

Nu kun je het nog af met H.264 en Flash als fallback. WebM-ondersteuning voegt niets toe omdat Chrome H.264 nog ondersteunt en zij eigenlijk als enige echt op WebM lopen hameren.

.oisyn schreef op donderdag 13 januari 2011 @ 13:27:
Wat ik dan weer niet begrijp is waarom er support voor specifieke codecs moet zitten in de browser. Daar hebben we het OS toch voor? Waarom kan ik straks geen h.264 content meer afspelen in Chrome, terwijl de codec gewoon geïnstalleerd is?

Dat verbaast mij eerlijk gezegd ook een beetje. De beste manier om future proof te zijn is door afhankelijkheid voor codecs bij het OS te leggen en eventueel de gebruikelijke codecs bij de installatie van de browser mee te installeren op het OS.

mcDavid schreef op donderdag 13 januari 2011 @ 13:32:
[...]

OGG/Theora viel al min of meer af als serieuze kandidaat, en H.264 nu ook.

Inventariseer voor de grap eens hoeveel jaren (ja, jaren) aan filmmateriaal er nu in H.264 op het web staat. Dat komt omdat Flash video meestal gebruik maakt van H.264 voor video, al dan niet in HD-formaat. Overstappen van Flash naar HTML5 wordt niet bepaald makkelijker als je al je content opnieuw moet uploaden en/of encoden. En dat terwijl zowel H.264 als WebM zo hun eigen licentieproblemen hebben.

[ Voor 21% gewijzigd door NMe op 13-01-2011 13:41 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 13:50

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 13:38:
[...]

Nu kun je het nog af met H.264 en Flash als fallback. WebM-ondersteuning voegt niets toe omdat Chrome H.264 nog ondersteunt en zij eigenlijk als enige echt op WebM lopen hameren.

Je vergeet alleen Firefox dan even voor het gemak.

rickiii schreef op donderdag 13 januari 2011 @ 13:19:
[...]
Het is niet zo duidelijk als het lijkt
http://www.streaminglearn...hat-you-need-to-know.html

Ik denk dat ik daarom ook achter de beslissing van Google sta.
Het is een pijnlijke beslissing op de korte termijn om eventuele grotere schade in de toekomst te voorkomen.

Voor h.264 is het duidelijk dat er eventueel betaald moet worden. Maar Apple heeft hier de licenties al voor en dat is allemaal al ingecalculeerd: duidelijkheid.

Bij WebM kan ineens een hele serie rechtzaken en claims om de hoek komen kijken op een willekeurig moment in de toekomst: onzekerheid.

Het enige dat Google doet is haar eigen standaard pushen. Daar kan ik ze geen ongelijk in geven, maar vanuit bedrijfseconomisch standpunt is WebM een enorme gok.

mcDavid schreef op donderdag 13 januari 2011 @ 13:32:
[...]
Wat ik begrepen is, is dat IE nog helemaal geen codec gaat implementeren maar alleen plugins hiervoor ondersteunt. En ze hebben toegezegd dat WebM ook dmv een plugin te gebruiken zal zijn.

Dit vind ik een zeer kwalijke zaak. Het hele idee van HTML5 video en audio is dat de browser NATIVE video en audio kan afspelen. Dus juist zonder tussenkomst van externe factoren als plugins of codecs. Maar goed, standaarden om zeep helpen is iets dat je wel aan Microsoft over kan laten.

[ Voor 88% gewijzigd door Bosmonster op 13-01-2011 14:10 . Reden: versimpeld en ingekort ]

donderdag 13 januari 2011 14:02

Acties:

0 Henk 'm!

OkkE

CSS influencer :+

.oisyn schreef op donderdag 13 januari 2011 @ 13:27:
Wat ik dan weer niet begrijp is waarom er support voor specifieke codecs moet zitten in de browser. Daar hebben we het OS toch voor? Waarom kan ik straks geen h.264 content meer afspelen in Chrome, terwijl de codec gewoon geïnstalleerd is?

Ik denk dat ze dit doen om er zo zeker van te zijn dat "het werkt". Wanneer de browser voor de codec zorgt - en elke browser dit doet - weet je iedergeval zeker dat een video is af te spelen. Anders wordt het een beetje net als Fonts, je weet nooit zeker of iemand de codec wel heeft geïnstalleerd.

Maar dat werkt alleen goed wanneer alle browsers de zelfde codec inbouwen natuurlijk... Anders zit je als nog met X verschillende versies van een video op je server.

[ Voor 11% gewijzigd door OkkE op 13-01-2011 14:03 ]

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.

donderdag 13 januari 2011 14:06

Acties:

0 Henk 'm!

mcDavid

NMe schreef op donderdag 13 januari 2011 @ 13:38:
[...]

Nu kun je het nog af met H.264 en Flash als fallback. WebM-ondersteuning voegt niets toe omdat Chrome H.264 nog ondersteunt en zij eigenlijk als enige echt op WebM lopen hameren.

Dan heb je firefox er niet bij, die blijft hardnekkig H.264 weigeren.

Dat verbaast mij eerlijk gezegd ook een beetje. De beste manier om future proof te zijn is door afhankelijkheid voor codecs bij het OS te leggen en eventueel de gebruikelijke codecs bij de installatie van de browser mee te installeren op het OS.

Helemaal mee eens. Zouden daar technische problemen in schuilen?

Inventariseer voor de grap eens hoeveel jaren (ja, jaren) aan filmmateriaal er nu in H.264 op het web staat. Dat komt omdat Flash video meestal gebruik maakt van H.264 voor video, al dan niet in HD-formaat. Overstappen van Flash naar HTML5 wordt niet bepaald makkelijker als je al je content opnieuw moet uploaden en/of encoden. En dat terwijl zowel H.264 als WebM zo hun eigen licentieproblemen hebben.

Dat is wel waar natuurlijk. Al denk ik dat dat een overkomelijk probleem is als WebM toch wint. Al was het alleen al omdat 90% van dat filmmateriaal bij google zelf staat.

donderdag 13 januari 2011 14:07

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

OkkE schreef op donderdag 13 januari 2011 @ 14:02:
[...]

Ik denk dat ze dit doen om er zo zeker van te zijn dat "het werkt".

Er is niet mis met het meeshippen van een codec met de browser, maar imho wel met codecs die je niet meelevert expres niet supporten.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 14:12

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

.oisyn schreef op donderdag 13 januari 2011 @ 14:07:
[...]

Er is niet mis met het meeshippen van een codec met de browser, maar imho wel met codecs die je niet meelevert expres niet supporten.

De oorzaak van het probleem is simpel: Ze zijn het (nog) niet eens over de te gebruiken codec. Op zich geen ramp, aangezien HTML5 nog verre van af is.

Losse codecs of plugins zijn symptoombestrijding. Het uiteindelijke doel is het oplossen van het probleem: dat ze het eens worden over een te gebruiken standaard

OkkE schreef op donderdag 13 januari 2011 @ 14:13:
[...]

Oh zo, inderdaad helemaal mee eens. Als ik h.264 geïnstalleerd heb staan wil ik die ook kunnen afspelen ja.

Dat is misschien wenselijk voor jou als gebruiker (eigenlijk als gevolg van de onenigheid, anders was het geen probleem natuurlijk). Maar het is absoluut niet wenselijk vanuit het oogpunt van HTML5 als standaard/

[ Voor 27% gewijzigd door Bosmonster op 13-01-2011 14:15 ]

donderdag 13 januari 2011 14:13

Acties:

0 Henk 'm!

OkkE

CSS influencer :+

.oisyn schreef op donderdag 13 januari 2011 @ 14:07:
[...]

Er is niet mis met het meeshippen van een codec met de browser, maar imho wel met codecs die je niet meelevert expres niet supporten.

Oh zo, inderdaad helemaal mee eens. Als ik h.264 geïnstalleerd heb staan wil ik die ook kunnen afspelen ja.

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.

donderdag 13 januari 2011 14:14

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Bosmonster schreef op donderdag 13 januari 2011 @ 14:12:
[...]

De oorzaak van het probleem is simpel: Ze zijn het (nog) niet eens over de te gebruiken codec. Op zich geen ramp, aangezien HTML5 nog verre van af is.

Losse codecs of plugins zijn symptoombestrijding. Het uiteindelijke doel is het oplossen van het probleem: dat ze het eens worden over een te gebruiken standaard

Ok, dus je vindt dat een browser ook alleen maar die fonts mag weergeven die met de browser meegeleverd zijn?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 14:19

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 14:12:
[...]

De oorzaak van het probleem is simpel: Ze zijn het (nog) niet eens over de te gebruiken codec. Op zich geen ramp, aangezien HTML5 nog verre van af is.

Nee, welke standaard ze zouden moeten gebruiken is gewoon een non-discussie. In feite zouden browsers gewoon alles moeten kunnen afspelen wat de mediaspeler op je pc ook kan. Er is gewoon geen standaard nodig als je het afspelen van video netjes kan delegeren naar het OS en dat alleen overneemt als je zelf een specifieke codec aan boord hebt in je browser.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 14:19

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

.oisyn schreef op donderdag 13 januari 2011 @ 14:14:
[...]

Ok, dus je vindt dat een browser ook alleen maar die fonts mag weergeven die met de browser meegeleverd zijn?

Tuurlijk niet. Maar stel browser X ondersteunt font A en B. En browser Y ondersteunt font C en D. Tuurlijk kun je je oplossing dan zoeken in het kunnen installeren van custom fonts, maar daar zijn ontwikkelaars en gebruikers niet mee geholpen.

Beter is een standaard fontset afspreken.

Voor audio en video speelt dit wel iets anders, aangezien je maar 1 codec nodig hebt om video of audio goed af te kunnen spelen. Dus waarom zou je andere codecs willen installeren, als de oplossing is dat ze gewoon native allemaal dezelfde ondersteunen

In vergelijking met je font-opmerking. Stel browser X ondersteunt font A en browser Y ondersteunt font B. De fonts zien er echter exact hetzelfde uit. Lijkt me handiger als ze het dan eens worden over welk font te gebruiken dan dat je zowel A als B kunt installeren.

NMe schreef op donderdag 13 januari 2011 @ 14:19:
[...]

Nee, welke standaard ze zouden moeten gebruiken is gewoon een non-discussie. In feite zouden browsers gewoon alles moeten kunnen afspelen wat de mediaspeler op je pc ook kan. Er is gewoon geen standaard nodig als je het afspelen van video netjes kan delegeren naar het OS en dat alleen overneemt als je zelf een specifieke codec aan boord hebt in je browser.

Wat je nu zegt druist compleet in tegen het hele principe en de filosofie achter HTML5 video. Namelijk dat er een standaard is waar je als developer van op aan kan en als gebruiker geen last hebt van verschillende codecs. Native ondersteuning dus zonder tussenkomst van externe factoren als plugins en codecs. Op dezelfde manier als je een plaatje op een website plakt. Daar hoef je ook niet na te denken of jij of je gebruikers wel dat image-formaat kunnen lezen. Daar zijn afspraken over gemaakt en support is native.

Het sleutelwoord voor HTML5 video en audio is native. Video en audio gebruiken moet zo simpel worden als het gebruik van een img-tag.

De standaard is dus geen non-discussie, maar essentieel voor het succes van HTML5 video.

[ Voor 36% gewijzigd door Bosmonster op 13-01-2011 14:34 ]

donderdag 13 januari 2011 14:38

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Bosmonster schreef op donderdag 13 januari 2011 @ 14:19:
Beter is een standaard fontset afspreken.

Ik heb ook nooit anders beweerd. Maar een gemaakte afspraak impliceert niet dat je dingen die buiten de afspraak vallen expliciet niet ondersteunt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 14:48

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

.oisyn schreef op donderdag 13 januari 2011 @ 14:38:
[...]

Ik heb ook nooit anders beweerd. Maar een gemaakte afspraak impliceert niet dat je dingen die buiten de afspraak vallen expliciet niet ondersteunt.

In het geval van video heb je maar 1 formaat nodig. Codecs ondersteunen die buiten de afspraak vallen is dus helemaal niet nodig. Mits die afspraak er is, maar daar heb ik wel vertrouwen in dat dat gaat gebeuren. We zijn het afgelopen jaar al van 3 naar 2 potentiele kandidaten gegaan. We moeten alleen niet verwachten dat dit over een nacht ijs gaat.

Je kunt nu ook wel een custom img-format gaan ondersteunen via een externe plugin. Maar wie zit daar op te wachten? En wie gaat dat gebruiken?

[ Voor 16% gewijzigd door Bosmonster op 13-01-2011 14:48 ]

donderdag 13 januari 2011 14:48

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 14:19:
[...]

Wat je nu zegt druist compleet in tegen het hele principe en de filosofie achter HTML5 video. Namelijk dat er een standaard is waar je als developer van op aan kan en als gebruiker geen last hebt van verschillende codecs. Native ondersteuning dus zonder tussenkomst van externe factoren als plugins en codecs. Op dezelfde manier als je een plaatje op een website plakt. Daar hoef je ook niet na te denken of jij of je gebruikers wel dat image-formaat kunnen lezen. Daar zijn afspraken over gemaakt en support is native.

Het sleutelwoord voor HTML5 video en audio is native. Video en audio gebruiken moet zo simpel worden als het gebruik van een img-tag.

De standaard is dus geen non-discussie, maar essentieel voor het succes van HTML5 video.

Wat jij nu zegt hoeft helemaal niet uitgesloten te worden door de mogelijkheid om codecs op het systeem te gebruiken. Dat kan allemaal net zo transparant met dezelfde <video>-tag. Je kan zélfs gewoon native codecs gebruiken die in de browser zitten en voor codecs die je niet kent een fallback te doen naar codecs die op het systeem staan. Je verliest daar niks mee terwijl je gebruiker veel beter overweg kan met verschillende types video zonder daarvoor Flash te hoeven gebruiken of allerlei conditionele scripts die bepalen welke video geladen moet worden. Standaarden zijn leuk maar die horen er door overleg te komen en niet omdat één of twee browserfabrikanten eenzijdig besluiten geen gebruik te willen maken van een bepaalde codec die zich ook nog eens in de praktijk al bewezen heeft.

Bosmonster schreef op donderdag 13 januari 2011 @ 14:48:
[...]

Je kunt nu ook wel een custom img-format gaan ondersteunen via een externe plugin. Maar wie zit daar op te wachten? En wie gaat dat gebruiken?

Ook dat is geen eerlijke vergelijking, want in tegenstelling tot video komt imagecompressie helemaal niet zoveel ter sprake. PNG is eigenlijk de enige echte vernieuwing op het web die we gezien hebben sinds de BMP, JPEG en GIF-tijden in het begin, en die is dus ook vrijwel direct ondersteund.

Kijken we naar video, dan hebben we een breed scala aan audio- en videocodecs gezien. Audio is via wave, MP3 en OGG naar technieken als AC3 overgegaan en wat video betreft hebben we behalve de hier genoemde compressietechnieken natuurlijk MPEG, DivX, Xvid, enz. gezien.

[ Voor 19% gewijzigd door NMe op 13-01-2011 14:52 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 14:56

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 14:48:
[...]

Wat jij nu zegt hoeft helemaal niet uitgesloten te worden door de mogelijkheid om codecs op het systeem te gebruiken. Dat kan allemaal net zo transparant met dezelfde <video>-tag.

Wat jij nu zegt schuift heel de discussie over de HTML5 standaard aan de kant en grijpt weer terug naar het probleem dat HTML5 juist probeert op te lossen.

Zoals ik eerder al zei, de hele wens om externe codecs te kunnen gebruiken komt puur voort uit de onenigheid over de te gebruiken codec. Als die onenigheid opgelost is, is die wens er ook niet meer. Als alle browsers bijvoorbeeld WebM ondersteunen is er helemaal geen noodzaak meer tot ondersteuning van nog meer formaten.

Zie mijn voorbeeld mbt tot het img-formaat. Alle browsers ondersteunen PNG/GIF/JPG. Daar kun je van op aan. Tuurlijk kun jij een formaat verzinnen dat heet NME en dat ondersteunen via een plugin. Maar wie is daarmee geholpen? Het enige dat je daarmee doet is juist weer fragmenteren en je bezoekers met een probleem opzadelen. Iets dat HTML5 juist wil oplossen cq voorkomen.

Ook dat is geen eerlijke vergelijking, want in tegenstelling tot video komt imagecompressie helemaal niet zoveel ter sprake. PNG is eigenlijk de enige echte vernieuwing op het web die we gezien hebben sinds de BMP, JPEG en GIF-tijden in het begin, en die is dus ook vrijwel direct ondersteund.

Kijken we naar video, dan hebben we een breed scala aan audio- en videocodecs gezien. Audio is via wave, MP3 en OGG naar technieken als AC3 overgegaan en wat video betreft hebben we behalve de hier genoemde compressietechnieken natuurlijk MPEG, DivX, Xvid, enz. gezien.

Dit raakt kant noch wal. IMG-formaten zijn prima te vergelijken met video-formaten. Het voorbeeld spreekt zelfs nog in het voordeel van video wat dat betreft, aangezien je daar feitelijk aan 1 formaat genoeg hebt en je bij afbeeldingen veel meer specialistische compressies hebt.

Over PNG is op een gegeven moment ook gewoon een afspraak gemaakt dat die ondersteund ging worden. En niet via een plugin-constructie, maar native. Daar plukken wij als developer (en gebruiker dus ook) de vruchten van. Want we weten zeker dat de browsers hier native ondersteuning voor hebben en hoeven niet bang te zijn of iemand wel de juiste codec heeft geinstalleerd.

Het is apart dat je aan de ene kant eerst zegt dat je het vervelend vindt dat je 2 formaten moet ondersteunen als developer, maar vervolgens wel pleit voor een externe plugin/codec structuur ipv een standaard.

[ Voor 38% gewijzigd door Bosmonster op 13-01-2011 15:01 ]

donderdag 13 januari 2011 15:01

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 14:56:
[...]

Zoals ik eerder al zei, de hele wens om externe codecs te kunnen gebruiken komt puur voort uit de onenigheid over de te gebruiken codec. Als die onenigheid opgelost is, is die wens er ook niet meer. Als alle browsers bijvoorbeeld WebM ondersteunen is er helemaal geen noodzaak meer tot ondersteuning van nog meer formaten.

Dat is een Appleredenatie^TM. Vergelijk het met de manier waarop Flash niet ondersteund wordt op de iPhone met de redenatie dat dat verouderd is en niemand het meer zou moeten gebruiken. Daarmee maak je dus het halve web ontoegankelijk in die overgangsperiode, want niet elke developer gaat direct overstappen.

Zie mijn voorbeeld mbt tot het img-formaat. Alle browsers ondersteunen PNG/GIF/JPG. Daar kun je van op aan. Tuurlijk kun jij een formaat verzinnen dat heet NME en dat ondersteunen via een plugin. Maar wie is daarmee geholpen? Het enige dat je daarmee doet is juist weer fragmenteren en je bezoekers met een probleem opzadelen. Iets dat HTML5 juist wil oplossen cq voorkomen.

Nogmaals: jij kan als je dat graag wil best je codec support inbouwen in je browser, maar waarom zou je tegenwerken dat codecs die je al op je computer hebt staan gebruikt worden voor het afspelen van video die je niet kent? Je hebt daar niet eens een plugin voor nodig wat je eigen videospeler, die je voor je eigen codec al ingebouwd hebt, heeft die interface al... En nogmaals: video staat niet stil, er worden om de zoveel maanden nieuwe standaarden verzonnen die weer betere compressie en kwaliteit hebben. Waarom zou je het gebruik daarvan blokkeren omdat browsers een monopolie van oude compressietechnieken gebruiken?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 15:10

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 15:01:
[...]

Nogmaals: jij kan als je dat graag wil best je codec support inbouwen in je browser, maar waarom zou je tegenwerken dat codecs die je al op je computer hebt staan gebruikt worden voor het afspelen van video die je niet kent? Je hebt daar niet eens een plugin voor nodig wat je eigen videospeler, die je voor je eigen codec al ingebouwd hebt, heeft die interface al... En nogmaals: video staat niet stil, er worden om de zoveel maanden nieuwe standaarden verzonnen die weer betere compressie en kwaliteit hebben. Waarom zou je het gebruik daarvan blokkeren omdat browsers een monopolie van oude compressietechnieken gebruiken?

Nogmaals: dat is een korte-termijnoplossing (symptoombestrijding)

Een standaard is een lange-termijnoplossing.

Niemand zegt dat ze tegenwerken. Maar de HTML5 standaard dicteert native support. Dat is het hele idee achter de standaard.

Je bent vrij om gewoon je Quicktime of Flash plugin te gebruiken met je eigen codecs als je dat graag wilt (maar daar willen we juist vanaf toch?)

[ Voor 38% gewijzigd door Bosmonster op 13-01-2011 15:15 ]

donderdag 13 januari 2011 15:17

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Het verschil is dat jij ideologisch redeneert vanuit de standaard, maar dat NMe en ik het hebben over huidige browserimplementaties. I don't care wat HTML5 zegt, ik vind het kut dat Chrome niet gewoon de geïnstalleerde codecs kan gebruiken om momenteel bestaande content af te spelen. Als ik Chrome straks update, dan kan ik die ene pagina die toevallig een H.264 had geëmbed in een <video> tag niet meer bekijken, terwijl mijn PC prima in staat is die content af te spelen.

[ Voor 25% gewijzigd door .oisyn op 13-01-2011 15:18 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 15:22

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

No pain, no gain

donderdag 13 januari 2011 15:30

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

mcDavid schreef op donderdag 13 januari 2011 @ 14:06:
Dan heb je firefox er niet bij, die blijft hardnekkig H.264 weigeren.

Firefox weigert wel meer, zo ook recent met Web SQL Databases.

Als ze dit soort dingen echt gaan doorzetten ontstaat er vanzelf een fork. En dat is reeds al gebeurd! Wild Fox. Zoals het ook met oude Gecko/Mozilla is gebeurd. Het idee Firefox is wat dat betreft ongrijpbaar.

offtopic:
Lol, onze eigen Elledan

Verder snap ik de discussie niet zo erg. Video-formaten zullen voorlopig door YouTube worden gepushed, waarom zou je bepaalde formaten weigeren? Momenteel kan er ook H.264 worden afgespeeld op Linux? Dus dat kan al in alle Open Source software.

[ Voor 32% gewijzigd door LauPro op 13-01-2011 15:36 . Reden: hmm ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 15:31

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

.oisyn schreef op donderdag 13 januari 2011 @ 15:17:
Het verschil is dat jij ideologisch redeneert vanuit de standaard, maar dat NMe en ik het hebben over huidige browserimplementaties.

Dat inderdaad, maar niet alleen dat. Als we 5 jaar verder kijken hebben we vast weer een of andere nieuwe standaard nodig voor de beste video-ervaring. Of misschien is 10 jaar verder makkelijker voor te stellen aangezien we dan vast een of andere 3D-videocodec nodig gaan hebben. Moeten we dan wéér deze complete codec-oorlog gaan voeren? Of kunnen browsers dan gewoon gebruik maken van wat er aan codecs aanwezig is op het systeem zelf totdat ze na eeuwig bakkeleien eindelijk één standaard uitkiezen? Ik weet wel wat ik als developer én als eindgebruiker prettiger zou vinden.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 15:35

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

LauPro schreef op donderdag 13 januari 2011 @ 15:30:
[...]
Firefox weigert wel meer, zo ook recent met Web SQL Databases.

Web SQL is ook al afgeschoten voor de HTML 5 standaard, dus waarom zouden ze nog moeite doen?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 15:40

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Firefox is wel vaker stellig over bepaalde zaken, ook bijvoorbeeld ActiveX (hun goed recht imo overigens). Het is op zich goed om principieel te zijn maar de meerderheid van de gebruikers gaat toch voor functionaliteit en oplossingen die werken.

Dus dat betreft zal Firefox misschien een technologische voortrekkersrol hebben, al hoewel ik bij Chrome meer zie gebeuren dan bij FF.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 15:56

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 15:31:
[...]

Dat inderdaad, maar niet alleen dat. Als we 5 jaar verder kijken hebben we vast weer een of andere nieuwe standaard nodig voor de beste video-ervaring. Of misschien is 10 jaar verder makkelijker voor te stellen aangezien we dan vast een of andere 3D-videocodec nodig gaan hebben. Moeten we dan wéér deze complete codec-oorlog gaan voeren? Of kunnen browsers dan gewoon gebruik maken van wat er aan codecs aanwezig is op het systeem zelf totdat ze na eeuwig bakkeleien eindelijk één standaard uitkiezen? Ik weet wel wat ik als developer én als eindgebruiker prettiger zou vinden.

Dat zal dan op dezelfde manier gebeuren als ooit ook PNG is toegevoegd aan de native image-mogelijkheden.

Als we met codecs zouden werken zou je nu nog steeds niet zeker weten of een browser de PNG-codec heeft geinstalleerd. Of misschien een van de andere mogelijke 32bit image formaten die verzonnen zouden zijn.

Het is misschien ideologisch, maar dat is ook het hele idee van een standaard. We zitten al 20 jaar te kutten met plugins. HTML5 video wil daar een einde aan maken door een video-tag te introduceren en een standaard native video-afhandeling. Ik vind het opvallend dat daar nu, met een beetje discussie over de te gebruiken standaard, ineens zoveel weerstand bij komt kijken.

Wat dat betreft spreek je jezelf ook een beetje tegen. Eerst zei je namelijk dat je niet blij was met het droppen van h.264 in Chrome, omdat je dan ook WebM moet gaan ondersteunen naast h.264 en Flash. Terwijl je vervolgens opteert voor externe codecs om zoveel mogelijk verschillende formaten te kunnen ondersteunen.

Als we nu die knoop niet doorhakken wat betreft een enkele native supported codec, dan kom je juist over die 5 a 10 jaar in de problemen. Dan heb je codecs voor xvid, divx, h.264, webm, mkv, avi en weet ik het allemaal niet. En dan ook nog in 3D formaat natuurlijk. Is dat nu niet net iets waar we als developers vanaf willen?

Het resultaat als dit gebeurt is simpel: Dan blijven we gewoon Flash+h.264 gebruiken voor video, want daarvan weten we zeker dat bijna alle clients dit ondersteunen.

donderdag 13 januari 2011 16:06

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Bosmonster schreef op donderdag 13 januari 2011 @ 15:56:
Als we nu die knoop niet doorhakken wat betreft een enkele native supported codec, dan kom je juist over die 5 a 10 jaar in de problemen. Dan heb je codecs voor xvid, divx, h.264, webm, mkv, avi en weet ik het allemaal niet. En dan ook nog in 3D formaat natuurlijk. Is dat nu niet net iets waar we als developers vanaf willen?

Wat voor problemen zijn dat precies? Die codecs kan je vaak indien ze niet aanwezig zijn op afroep installeren. En bovendien heb je gewoon codec packs met honderden codecs. Tevens maakt het voor de gebruiker niet zoveel uit. Chrome zal beginnen met pushen met hun eigen YouTube, Microsoft heeft aangegeven elke gangbaar formaat te ondersteunen (naast wmv). En voor de rest is het gerommel in de marge. Ook voor Firefox zullen gebruikers niet blij worden van de overhead die plugins hebben, tenzij Flash eens echt efficiënt gaat worden, zal nog wel wat versies duren. Er ontstaat een serieuze fork, even opnieuw installeren en klaar.

Als jij op je site in .ogg in een <audio> tag wil zetten, dan zal de gebruiker daarvoor een codec moeten hebben. Of je gaat naar een gangbaarder formaat.

De browser/standaardenmarkt ligt er maar net aan hoe de wind staat.

[ Voor 5% gewijzigd door LauPro op 13-01-2011 16:07 ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 16:06

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 15:56:
[...]

Dat zal dan op dezelfde manier gebeuren als ooit ook PNG is toegevoegd aan de image-mogelijkheden.

Dan ga je ervanuit dat er maar één 3D-codec gaat zijn om uit te kiezen. We hebben nu WebM en H.264, wie zegt dat we over 10 jaar niet 2 of 3 gangbare 3D-codecs hebben? Denk je zelf ook niet dat de codec-oorlog die jij nu voorstelt de techniek alleen maar gaat vertragen?

Wat dat betreft spreek je jezelf ook een beetje tegen. Eerst zei je namelijk dat je niet blij was met het droppen van h.264 in Chrome, omdat je dan ook WebM moet gaan ondersteunen naast h.264 en Flash. Terwijl je vervolgens opteert voor externe codecs om zoveel mogelijk verschillende formaten te kunnen ondersteunen.

Dat spreekt zich helemaal niet tegen.

Er is nogal een verschil tussen het droppen van een standaard (en het daarmee onmogelijk maken om die te gebruiken) en het optioneel maken van een standaard (waardoor je de gebruiker zelf de controle geeft). Firefox en Chrome willen native WebM ondersteunen en alle anderen H.264? Best. Kunnen ze mooi die andere codec alsnog beschikbaar maken door de codec (optioneel!) mee te installeren met de browser en vervolgens de browser laten decoden. Codec niet aanwezig? Simpel, melding geven en als je als browsermaker weet dat die codec wel beschikbaar is en werkt voor je browser even een downloadlinkje erbij doen voor de installer. Zo blijf je flexibel en hoef je niet elke keer als er een betere techniek uitkomt dezelfde discussie te voeren over welke codec gebruikt moet worden.

Als we nu die knoop niet doorhakken wat betreft een enkele native supported codec, dan kom je juist over die 5 a 10 jaar in de problemen. Dan heb je codecs voor xvid, divx, h.264, webm, mkv, avi en weet ik het allemaal niet. En dan ook nog in 3D formaat natuurlijk. Is dat nu niet net iets waar we als developers vanaf willen?

Waarom willen we daar vanaf? We willen toch ook niet massaal af van GIF, ondanks dat JPEG en PNG het in 99.99% van de gevallen kan vervangen?

Het resultaat als dit gebeurt is simpel: Dan blijven we gewoon Flash+h.264 gebruiken voor video, want daarvan weten we zeker dat bijna alle clients dit ondersteunen.

Dat is juist het effect nu Firefox en Chrome voor de ene standaard gaan en alle andere browsermakers voor de andere.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 16:10

Acties:

0 Henk 'm!

garagaholic

NMe schreef op donderdag 13 januari 2011 @ 15:31:
[...]

Dat inderdaad, maar niet alleen dat. Als we 5 jaar verder kijken hebben we vast weer een of andere nieuwe standaard nodig voor de beste video-ervaring. Of misschien is 10 jaar verder makkelijker voor te stellen aangezien we dan vast een of andere 3D-videocodec nodig gaan hebben. Moeten we dan wéér deze complete codec-oorlog gaan voeren? Of kunnen browsers dan gewoon gebruik maken van wat er aan codecs aanwezig is op het systeem zelf totdat ze na eeuwig bakkeleien eindelijk één standaard uitkiezen? Ik weet wel wat ik als developer én als eindgebruiker prettiger zou vinden.

Dit was overigens hetgeen waar mijn 'bezwaar' zou liggen bij het native ondersteunen van standaard X in alle browsers.

Wikipedia: Video compression

Ik vroeg me een beetje af wat nou precies populaire codecs waren door de tijd heen en volgens bovenstaande link zijn we nu met de h.264 aan de langst lopende standaard sinds H.120 van 1984-1990 bezig. Hoog tijd voor een nieuwe standaard dus (blijkbaar

).

Zelf zie ik meer heil in een plugin model. De markt zoekt namelijk vanzelf wel een 'de facto' standaard uit. Een grote speler als Youtube gaat voor een bepaalde plugin en je weet daarna zelf ook al wel wat het overgrote deel van de andere videoaanbieders gaat doen. Een de jure standaard biedt in feite alleen maar jaaaren rompslomp en geruzie, kost veel geld en levert uiteindelijk een mank product op (of in het geval van HTML 5 video tot op heden nog helemaal niets!).

Daarnaast sluit je vanuit de standaardenorganisatie op voorhand al (veelbelovende) nieuwe codecs uit van deelname aan het gestandaardiseerde web, omdat je nu eenmaal voor X, Y of Z hebt gekozen. Als we, zoals NMe al aangeeft over 5 jaar allemaal mooie nieuwe codecs hebben, gaat het hele gesteggel weer van voren af aan beginnen (wat betekent dat er weer 5 jaar gediscussieerd gaat worden, we 5 jaar met óf oude codecs of wéér 5 verschillende implementaties zitten). Veel handiger is als OS bouwers codecs aanbieden aan de gebruikers en dat dit wordt gezien als onderdeel van windows/OS X/Android/iOS/WebOs/Meego et cetera et cetera.

Als ontwikkelaar is het dan zaak om te weten wat de meest gebruikte standaard (hint; zie YT) is zodat je weet dat je in ieder geval een mooie 90% van de gebruikers direct kan serveren. 90% is een hele mooie score en, zoals het er nu naar uit ziet, een stuk betere score dan een gestandaardiseerde codec voor HTML5 ooit zal gaan behalen. Je hebt mensen die zeggen "kom we hakken de knoop door, fuck andermans mening/gedachten hier over, we moeten een keuze maken" terwijl er ook veel anderen zijn die met de hakken in het zand gaan om maar vooral dat tegen te houden. Je zult zien dat er zo meteen een keuze wordt gemaakt waar niet iedereen achter staat en je gewoon wéér een gefragmenteerde markt hebt. Het verschil met de situatie nu is dat er dan wél mensen kunnen gaan roepen "maar dát is de standáárd!".

donderdag 13 januari 2011 16:14

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

garagaholic schreef op donderdag 13 januari 2011 @ 16:10:
[...]

Zelf zie ik meer heil in een plugin model. De markt zoekt namelijk vanzelf wel een 'de facto' standaard uit.

Daar wil ik graag even afstand van doen.

Plugins heb je niet nodig. Je zal als browsermaker een videospeler moeten opnemen in je browser. Als je die zo schrijft dat hij gebruik kán maken van aanwezige codecs op het systeem heb je verder geen plugin nodig.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 16:22

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Ok ik geef het op. Het lijkt wel alsof per ongeluk ik in de tijdmachine naar 1995 ben gestapt.

Blijkbaar zien we meer heil in versplintering dan standaardisatie.

donderdag 13 januari 2011 16:24

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Standaardisatie is wat anders dan inflexibel zijn.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 16:26

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ok ik geef het op

En terecht, je lult in cirkels

Bosmonster schreef op donderdag 13 januari 2011 @ 15:56:
Het is misschien ideologisch, maar dat is ook het hele idee van een standaard. We zitten al 20 jaar te kutten met plugins. HTML5 video wil daar een einde aan maken door een video-tag te introduceren en een standaard native video-afhandeling. Ik vind het opvallend dat daar nu, met een beetje discussie over de te gebruiken standaard, ineens zoveel weerstand bij komt kijken.

.oisyn schreef op donderdag 13 januari 2011 @ 15:17:
Het verschil is dat jij ideologisch redeneert vanuit de standaard, maar dat NMe en ik het hebben over huidige browserimplementaties. I don't care wat HTML5 zegt, ik vind het kut dat Chrome niet gewoon de geïnstalleerde codecs kan gebruiken om momenteel bestaande content af te spelen. Als ik Chrome straks update, dan kan ik die ene pagina die toevallig een H.264 had geëmbed in een <video> tag niet meer bekijken, terwijl mijn PC prima in staat is die content af te spelen.

Je doet steeds net alsof ik tegen een standaard codec in HTML5 ben. Dat ben ik helemaal niet. Waar ik op tegen ben, is een browser (dus geen standaard, maar een implementatie ervan) die weigert een andere codec af te spelen, ookal is die codec aanwezig op mijn systeem. Mijn browser laat ook BMP's zien, is nou ook niet echt bepaald een webstandaard. Waarom kan hij dan geen H.264 laten zien? Dat Chrome native support voor H.264 dropt vind ik prima. Maar waarom geen DirectShow of Video for Windows implementatie als fallback, die gebruik maakt van whatever codecs ik op mijn system geïnstalleerd heb staan (met alle bijbehorende voordelen, zoals live configurable ffdshow filters, van dien)

[ Voor 11% gewijzigd door .oisyn op 13-01-2011 16:30 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 13 januari 2011 16:28

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Eerlijk gezegd zie ik het probleem niet zo (nog steeds). Het staat browserbakkers toch vrij om zoiets te maken:

<video>-element > Multimedia Runtime > OS.

De runtime handelt verder plugins/audio/video af.

Microsoft kiest WMP als runtime.
Firefox kiest bijvoorbeeld VLC.
Chrome kiest WebM als runtime.
Safari kiest voor Quicktime (bleh).
Opera kiest voor..?

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 16:38

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

LauPro schreef op donderdag 13 januari 2011 @ 16:28:
Eerlijk gezegd zie ik het probleem niet zo (nog steeds). Het staat browserbakkers toch vrij om zoiets te maken:

<video>-element > Multimedia Runtime > OS.

De runtime handelt verder plugins/audio/video af.

Microsoft kiest WMP als runtime.
Firefox kiest bijvoorbeeld VLC.
Chrome kiest WebM als runtime.
Safari kiest voor Quicktime (bleh).
Opera kiest voor..?

Maar welke codec moet ik dan gebruiken als aanbieder?

donderdag 13 januari 2011 16:54

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 16:38:
[...]

Maar welke codec moet ik dan gebruiken als aanbieder?

Als je dat wil: de standaard. Als je dat niet wil (of nog niet kan): elke willekeurige andere codec, zolang je je bewust bent van het feit dat je klanten/gebruikers die ook moeten hebben.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 16:55

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 16:54:
[...]

Als je dat wil: de standaard. Als je dat niet wil (of nog niet kan): elke willekeurige andere codec, zolang je je bewust bent van het feit dat je klanten/gebruikers die ook moeten hebben.

Prima, dus we moeten om dit bruikbaar te maken toch eerst een standaard hebben, want dat laatste is nu net waar we vanaf willen als aanbieder.

Maar als er een standaard is, waarom zou je dan nog precies die willekeurige andere codec willen gebruiken?

M.a.w. is dat boeiend voor de discussie over de HTML5 video standaard?

Het neemt namelijk geen enkele argumenten weg van Google om achter WebM te staan of Apple om achter h.264 te staan. Uiteindelijk is dit dus een goede manier om uiteindelijk een keuze uit te stellen en de developers de komende jaren nog steeds hun video in 3 formaten te moeten aanbieden.

[ Voor 28% gewijzigd door Bosmonster op 13-01-2011 17:02 ]

donderdag 13 januari 2011 17:06

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 16:55:
[...]

Prima, dus we moeten om dit bruikbaar te maken toch eerst een standaard hebben.

Die standaard zou in principe browserspecifiek kunnen zijn. Zolang er fallback is in de vorm van een codec voor andere standaarden maakt dat namelijk niet zo uit. Op het moment dat iedereen het eens wordt over de te gebruiken standaard kun je altijd nog "de standaard" herdefiniëren, en als jouw eerste keuze niet "wint" kun je zelfs zowel jouw oude "standaard" en de nieuwe standaard native ondersteunen.

Maar als er een standaard is, waarom zou je dan nog precies die willekeurige andere codec willen gebruiken?

M.a.w. is dat boeiend voor de discussie over de HTML5 video standaard?

De overstapperiode is het makkelijkste voorbeeld: veel website hebben hun Flashvideo's al in H.264 encoded, en overstappen naar HTML5 video wordt een stuk makkelijker als je dat kan blijven gebruiken zonder het opnieuw te moeten encoden. Een ander voorbeeld zou zijn wanneer je echt een specifieke codec nodig hebt voor een bepaalde toepassing en die graag online en inline beschikbaar wil stellen. Met standaarden moet je altijd oppassen dat je jezelf niet te zeer vastpint.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 17:12

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 17:06:
[...]

Die standaard zou in principe browserspecifiek kunnen zijn. Zolang er fallback is in de vorm van een codec voor andere standaarden maakt dat namelijk niet zo uit. Op het moment dat iedereen het eens wordt over de te gebruiken standaard kun je altijd nog "de standaard" herdefiniëren, en als jouw eerste keuze niet "wint" kun je zelfs zowel jouw oude "standaard" en de nieuwe standaard native ondersteunen.

Tuurlijk. Maar dan stap je wel heel makkelijk over de reden heen waarom een Google WebM ondersteunt en een Apple h.264. Hun argumentatie verandert niet op het moment dat het middels een externe codec gebeurt. Apple zal niet ineens een WebM codec gaan aanbieden en Google zal niet ineens h.264 gaan aanbieden. Het verandert dus feitelijk niets aan het landschap.

Als je het door externe developers zou laten implementeren wordt het er niet veel beter van. Dan zit je naast ondersteuning waarvan je weet dat die er is, ook nog eens met een versnipperde externe codec-ondersteuning. Dan weet je als aanbieder helemaal niet meer waar je aan toe bent en val je terug op de grootste gemene deler: Flash+h.264(+WebM). En ben je dus weer terug bij af.

Daarom ben ik van mening dat die codecs nu niets oplossen. En als er een standaard uiteindelijk uitgerold is, zijn de codecs feitelijk overbodig.

[ Voor 24% gewijzigd door Bosmonster op 13-01-2011 17:19 ]

donderdag 13 januari 2011 17:21

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 17:12:
[...]

Tuurlijk. Maar dan stap je wel heel makkelijk over de reden heen waarom een Google WebM ondersteunt en een Apple h.264. Hun argumentatie verandert niet op het moment dat het middels een externe codec gebeurt. Apple zal niet ineens een WebM codec gaan aanbieden en Google zal niet ineens h.264 gaan aanbieden. Het verandert dus feitelijk niets aan het landschap.

Wanneer ze zélf geen gebruik maken van de codec die ze niet willen gebruiken en dat delegeren naar het OS lijkt het me niet dat ze bang hoeven zijn voor licentieproblematiek. Daarnaast, die argumenten van Google noch Apple zullen gaan veranderen en beiden zullen ze niet graag overstappen. Is het dan niet een illusie om te denken dat er überhaupt op korte termijn een alom geaccepteerde standaard komt zolang er niemand is die die standaard af kan dwingen behalve de marktleider?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 17:25

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 17:21:
[...]

Wanneer ze zélf geen gebruik maken van de codec die ze niet willen gebruiken en dat delegeren naar het OS lijkt het me niet dat ze bang hoeven zijn voor licentieproblematiek. Daarnaast, die argumenten van Google noch Apple zullen gaan veranderen en beiden zullen ze niet graag overstappen. Is het dan niet een illusie om te denken dat er überhaupt op korte termijn een alom geaccepteerde standaard komt zolang er niemand is die die standaard af kan dwingen behalve de marktleider?

We zijn het afgelopen jaar al van 3 naar 2 gegaan. Apple is met h.264 in de minderheid en hun bezwaar tegen WebM is voornamelijk een afwachtende houding. Zodra een Google en Microsoft overstag zijn is er voor Apple weinig reden meer achter te blijven.

Het is niet onwaarschijnlijk dat Apple het komende jaar WebM zal gaan ondersteunen na een tijdje de kat uit de boom te hebben gekeken.

Het is wat dat betreft jammer dat Microsoft geen knoop doorhakt en h.264 laat vallen, dan waren we snel klaar

edit: dat gaat niet gebeuren ook zo te zien

nieuws: Microsoft haalt uit naar Google over WebM-besluit

Het wordt nog een leuk gevecht het komende jaar.

[ Voor 9% gewijzigd door Bosmonster op 13-01-2011 17:33 ]

donderdag 13 januari 2011 17:34

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Ja, en dat hele gevecht zou er niet zijn als ze gewoon codecs op mijn systeem zouden gebruiken. Of liever: dat gevecht zou er wel zijn maar ik zou er als developer of eindgebruiker geen last van hebben.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 17:38

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 17:34:
Ja, en dat hele gevecht zou er niet zijn als ze gewoon codecs op mijn systeem zouden gebruiken. Of liever: dat gevecht zou er wel zijn maar ik zou er als developer of eindgebruiker geen last van hebben.

Dat zeg je elke keer, maar ik snap die redenatie niet. Als developer heb je daar wel last van. Je weet namelijk nog steeds niet of gebruiker X met zijn Chrome browser de x.264 codec heeft geinstalleerd. Of gebruiker Y met zijn Internet Explorer de WebM-codec. En dan hebben we het nog maar niet over ondersteuning voor mobiele platformen (iOS, Android, etc). Het gevolg is dat je toch de standaard browserfunctie zult moeten ondersteunen. Het gevolg is dus dat je meer moet ondersteunen ipv minder.

[ Voor 15% gewijzigd door Bosmonster op 13-01-2011 17:39 ]

donderdag 13 januari 2011 17:40

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

En het is natuurlijk compleet onmogelijk om in je browser een waarschuwing op te gooien dat je benodigde codec niet aanwezig is, eventueel met downloadlink of zelfs een volautomatische installatie daarvan?

Daarnaast: juist de mobiele platformen van dit moment gebruiken grotendeels H.264. En niet zomaar, ze hebben zelfs een chip aan boord om het decoden te regelen zodat de batterijduur bespaard wordt.

[ Voor 33% gewijzigd door NMe op 13-01-2011 17:41 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 17:51

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 17:40:
En het is natuurlijk compleet onmogelijk om in je browser een waarschuwing op te gooien dat je benodigde codec niet aanwezig is, eventueel met downloadlink of zelfs een volautomatische installatie daarvan?

Nee, maar wel onwenselijk. Die codec zou dan van een externe partij moeten komen. Wie gaat dat allemaal bijhouden? En die moet volgens jou in het OS geinstalleerd worden. Dit gaat simpelweg nooit gebeuren.

Voor dit principe is al een model uitgevonden: plugins. En daar willen we dus vanaf. (Installeer nu de RealVideo plugin! Installeer nu de Quicktime plugin! Installeer nu de Google WebM plugin! Installeer nu de Silverlight plugin! Installeer nu de Flash plugin! You get the point..)

Daarnaast: juist de mobiele platformen van dit moment gebruiken grotendeels H.264. En niet zomaar, ze hebben zelfs een chip aan boord om het decoden te regelen zodat de batterijduur bespaard wordt.

Dus die moet je in ieder geval ondersteunen, naast die andere codec die je wilde.

[ Voor 14% gewijzigd door Bosmonster op 13-01-2011 17:57 ]

donderdag 13 januari 2011 17:59

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Bosmonster schreef op donderdag 13 januari 2011 @ 17:38:
Dat zeg je elke keer, maar ik snap die redenatie niet. Als developer heb je daar wel last van. Je weet namelijk nog steeds niet of gebruiker X met zijn Chrome browser de x.264 codec heeft geinstalleerd. Of gebruiker Y met zijn Internet Explorer de WebM-codec. En dan hebben we het nog maar niet over ondersteuning voor mobiele platformen (iOS, Android, etc). Het gevolg is dat je toch de standaard browserfunctie zult moeten ondersteunen. Het gevolg is dus dat je meer moet ondersteunen ipv minder.

Ik kan er geen traan om laten eerlijk gezegd. Het is de gehele multimedia-industrie hun eigen schuld dat iedereen aan loopt te kloten met de diverse multimediaformaten die er reeds op de markt zijn. Iedereen moet zijn eigen formaatje en het moet net elke keer wat anders.

En op het moment dat o.a. ISO/IEC zich ermee gaat bemoeien dan is het hek van de dam. Gezeik en gegooi met modder. Geen standaardisering want dat is eng. Het zou maar zo kunnen zijn dat de industrie 20 jaar vast zit aan een standaard (JPEG anyone?). En WAT is daar precies mis mee? Die dingen werken gewoon, klaar.

Ga je als frontend ontwikkelaar absoluut niet bemoeien met een videoformatkeuze. Neem gewoon de gangbare van op dat moment.

Het is wel zo prettig als jij over 5 jaar een paar wielbouten van je auto wil vervangen en dat de bout met juiste tap nog leverbaar is. Of die boutjes nou in een plastic zakje zitten of kartonnen doosje boeit niet zoveel.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 18:41

Acties:

0 Henk 'm!

Struikrover

Tof, ik wist niet dat er een HTML5 topic bestond. Heb de posts eens even doorgelezen, en afgezien van de eeuwigdurende discussie over welk videoformaat er uiteindelijk wel of niet komt vond ik wel een aantal interessante weetjes terug die ik nog niet wist

. Het heeft mij in ieder geval overgehaald om voortaan mijn doctype ook als html te zetten, zodat ik op die manier iig HTML5 alvast ondersteun.

Wat ik me nog wel afvroeg: HTML5 heeft tags als <article> en <header>. Als ik deze tags nu al gebruik, hebben ze dan naast de semantische functie eenzelfde gedraging als de <span> tag? Eigenlijk een lege tag die je met CSS nog kan en moet stylen?

donderdag 13 januari 2011 18:49

Acties:

0 Henk 'm!

Avalaxy

Topicstarter

Struikrover schreef op donderdag 13 januari 2011 @ 18:41:
Wat ik me nog wel afvroeg: HTML5 heeft tags als <article> en <header>. Als ik deze tags nu al gebruik, hebben ze dan naast de semantische functie eenzelfde gedraging als de <span> tag? Eigenlijk een lege tag die je met CSS nog kan en moet stylen?

Ze hebben volgens mij (nog) geen opmaak, maar wel een margin/padding als ik me niet vergis. Ik moest ze iig resetten om het netjes werkend te krijgen in IE8

donderdag 13 januari 2011 18:59

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

code:

<!-- Contains the content and the menu on the right side --> 
<section id="main"> 
    <!-- left side of the container, containing the content --> 
    <section id="content">

Zo schiet je er natuurlijk niet zoveel mee op toch

? Ik dacht juist dat het de bedoeling is om die secties dan als child aan te spreken in je CSS.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 19:07

Acties:

0 Henk 'm!

Avalaxy

Topicstarter

LauPro schreef op donderdag 13 januari 2011 @ 18:59:
code:
1
2
3
4
 
<section id="main"> 
     
    <section id="content">
Zo schiet je er natuurlijk niet zoveel mee op toch ? Ik dacht juist dat het de bedoeling is om die secties dan als child aan te spreken in je CSS.

Hihi, mn HTML is sowieso erg rommelig

Meer een testcase om te klooien met HTML5

(is ook al vrij oud though)

donderdag 13 januari 2011 19:17

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

Het is sowieso niet de bedoeling om sections te gaan gebruiken ipv divs. Div's gebruik je voor de opmaak, sections voor bij elkaar horende delen content (dus geen opmaak).

Op tweakplanet.net wordt section stelselmatig misbruikt

Verder trouwens wel een nette poging tot html5 opmaak overigens. Het is nog best lastig om alle elementen goed toe te passen (en er is zelfs nog niet echt een best practice voor, daarvoor wordt het nog te weinig gebruikt).

[ Voor 54% gewijzigd door Bosmonster op 13-01-2011 19:28 ]

donderdag 13 januari 2011 19:56

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

Bosmonster schreef op donderdag 13 januari 2011 @ 17:51:
[...]

Nee, maar wel onwenselijk. Die codec zou dan van een externe partij moeten komen. Wie gaat dat allemaal bijhouden? En die moet volgens jou in het OS geinstalleerd worden. Dit gaat simpelweg nooit gebeuren.

Voor dit principe is al een model uitgevonden: plugins. En daar willen we dus vanaf. (Installeer nu de RealVideo plugin! Installeer nu de Quicktime plugin! Installeer nu de Google WebM plugin! Installeer nu de Silverlight plugin! Installeer nu de Flash plugin! You get the point..)

Ik heb het hierboven al gezegd maar zal het nogmaals doen: nee, geen plugins. Een plugin wordt gebruikt om features aan je browser toe te voegen. In dit geval is die feature, de mediaspeler, er al. Alles wat je nodig hebt is support voor codecs die je OS native al heeft op dezelfde manier zoals het codecs aanbiedt aan een normale mediaspeler. De browser heeft niks aan plugins nodig want de interface heb je al in je native <video> support.

Dus die moet je in ieder geval ondersteunen, naast die andere codec die je wilde.

Juist. En dat zijn Google en Mozilla nu aan het ondermijnen. Websites die mobiel spul willen ondersteunen kunnen geen kant op als WebM de standaard wordt. Zelfs de nieuwste telefoons van dit moments hebben nog geen hardwarematige WebM-ondersteuning. Apple heeft dus sowieso nog een reden om absoluut niet overstag te gaan. En intussen zitten wij als ontwikkelaars met een <video>-tag die we niet kunnen gebruiken...

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 13 januari 2011 20:15

Acties:

0 Henk 'm!

Struikrover

Nog een term die ik voorbij zie komen waarvan ik me afvraag of hij wel klopt: XHTML5. Voor zover ik weet is XHTML toch pas bij versie 1.1, en is nog niet eens zeker of versie 2 wel breed ondersteund wordt?

donderdag 13 januari 2011 20:20

Acties:

0 Henk 'm!

Avalaxy

Topicstarter

XHTML5 staat los van de vorige XHTML1.1/1.2 en 2.0

Het is gewoon 'verwerkt' in HTML5.

donderdag 13 januari 2011 20:21

Acties:

0 Henk 'm!

Freeaqingme

Men is gestop tmet de ontwikkeling van xhtml. In plaats daarvan maakt men ook een xml versie van html5, en die wordt xhtml5 genoemd.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.

donderdag 13 januari 2011 20:27

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

NMe schreef op donderdag 13 januari 2011 @ 19:56:
Alles wat je nodig hebt is support voor codecs die je OS native al heeft op dezelfde manier zoals het codecs aanbiedt aan een normale mediaspeler. De browser heeft niks aan plugins nodig want de interface heb je al in je native <video> support.

Je hebt alleen nog maar plugins (codecs) nodig voor je mediaplayer ipv je browser

.

edit: Als je al nu ziet hoe makkelijk je een App op je mobiele telefoon zet, kan ik mij niet voorstellen dat het downloaden/upgraden van een codec zoveel moeite gaat zijn!

Juist. En dat zijn Google en Mozilla nu aan het ondermijnen. Websites die mobiel spul willen ondersteunen kunnen geen kant op als WebM de standaard wordt. Zelfs de nieuwste telefoons van dit moments hebben nog geen hardwarematige WebM-ondersteuning. Apple heeft dus sowieso nog een reden om absoluut niet overstag te gaan. En intussen zitten wij als ontwikkelaars met een <video>-tag die we niet kunnen gebruiken...

Ik denk sowieso niet dat XHTML5 iets is voor de komende 2-3 jaar. En tegen die tijd is er allang weer een nieuw mobiel toestel uit. Die ontwikkeling gaat heel erg rap, ik zie geen probleem.

[ Voor 7% gewijzigd door LauPro op 13-01-2011 20:31 ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

donderdag 13 januari 2011 20:55

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Html

NMe schreef op donderdag 13 januari 2011 @ 19:56:
[...]
Juist. En dat zijn Google en Mozilla nu aan het ondermijnen. Websites die mobiel spul willen ondersteunen kunnen geen kant op als WebM de standaard wordt. Zelfs de nieuwste telefoons van dit moments hebben nog geen hardwarematige WebM-ondersteuning. Apple heeft dus sowieso nog een reden om absoluut niet overstag te gaan. En intussen zitten wij als ontwikkelaars met een <video>-tag die we niet kunnen gebruiken...

Dat zitten we feitelijk toch al. De html5 standaard is nog experimenteel. Het merendeel van de gebruikers draait IE7 of 8 en ondersteunt het in z'n geheel nog niet.

Je zit je dus erg druk te maken over iets dat nog in een test- en ontwikkelstadium verkeert. Dan kun je wel nu al oplossingen gaan bedenken, maar beter kun je het gewoon even de tijd geven. Het lost zichzelf vanzelf op de komende tijd. En als alle browsers dalijk gewoon WebM of h.264 ondersteunen, dan hoeven we ook niet meer ingewikkelde oplossingen te bedenken als codec-download-systemen, wat met alle (mobiele) OS'en en browsers echt geen makkelijke opgave is.

Momenteel zit je met h.264 (en dezelfde versie in Flash) voor 99% gebakken. En mocht het toch WebM worden, ook Flash zal WebM ondersteunen tegen die tijd. Dus dan hou je altijd je proprietaire fallback.

[ Voor 15% gewijzigd door Bosmonster op 13-01-2011 21:06 ]

donderdag 13 januari 2011 23:34

Acties:

0 Henk 'm!

Peter

Freeaqingme schreef op donderdag 13 januari 2011 @ 20:21:
Men is gestop tmet de ontwikkeling van xhtml. In plaats daarvan maakt men ook een xml versie van html5, en die wordt xhtml5 genoemd.

XHTML5 is een serializatie van normale HTML5 code die op een striktere manier geparsed wordt, inderdaad op een XML-manier. Dit is echter in de HTML5 specificatie opgenomen. Je kunt ze ook prima combineren.

Bosmonster schreef op donderdag 13 januari 2011 @ 17:38:
[...]

Dat zeg je elke keer, maar ik snap die redenatie niet. Als developer heb je daar wel last van. Je weet namelijk nog steeds niet of gebruiker X met zijn Chrome browser de x.264 codec heeft geinstalleerd.

http://www.whatwg.org/spe...dom-navigator-canplaytype

Avalaxy schreef op donderdag 13 januari 2011 @ 18:49:
[...]

Ze hebben volgens mij (nog) geen opmaak, maar wel een margin/padding als ik me niet vergis. Ik moest ze iig resetten om het netjes werkend te krijgen in IE8

De standaard User Agent styles voor de nieuwe sectioning elementen is enkel "display: block", net als een gewoon <div>-element dus.

NMe schreef op donderdag 13 januari 2011 @ 19:56:
[...]

Juist. En dat zijn Google en Mozilla nu aan het ondermijnen. Websites die mobiel spul willen ondersteunen kunnen geen kant op als WebM de standaard wordt.

Realiseer je dat het bedrag aan royalties die Mozilla jaarlijks aan de MPEG-LA zou moeten afdragen tegen de 10% van hun jaaromzet aankomt. Natuurlijk hebben ze het geld wel, en anders kunnen ze het zonder teveel problemen krijgen, maar het gaat hier om een puur principiële kwestie die ook Google en Mozilla delen.

De H.264 codec is nou eenmaal bedolven onder de patenten, sterker nog, er is een reële kans dat een aantal van deze patenten nu bij Google liggen (VP3 van On2 werd voor H.264 uitgegeven). VP8 is dit ook, maar voor een implementator scheelt het enorm in de kosten als Google zowel de ontwikkeling als de zekerheid biedt. Van de browser vendors zijn Microsoft en Apple de enige die commerciële lasten zouden ervaren bij het ondersteunen van WebM gezien ze lid zijn van de patent-pool van de MPEG-LA.

Het cynische artikel van Tim Sneath (Microsoft) kan mijns inziens dan ook met een korrel zout bekeken worden; een soortgelijk scenario deed zich eerder dit jaar voor met Giorgio Sardo: Microsoft staat als bedrijf niet achter een dergelijke uitspraak. Enige uren geleden heeft Microsoft via het officiële @IE Twitter account deze tweet geretweet. Daarnaast zitten er in de codebase van de laatste IE9 Platform Previews expliciete uitzonderingen voor de WebM codec. Als Microsoft ondersteuning toevoegt dan moet Apple wel volgen, en daar zijn ze zich zeer zeker van bewust.

vrijdag 14 januari 2011 00:45

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Html

LauPro schreef op donderdag 13 januari 2011 @ 20:27:
[...]
Je hebt alleen nog maar plugins (codecs) nodig voor je mediaplayer ipv je browser .

edit: Als je al nu ziet hoe makkelijk je een App op je mobiele telefoon zet, kan ik mij niet voorstellen dat het downloaden/upgraden van een codec zoveel moeite gaat zijn!

Met hardware is dat een stuk lastiger. Video decoden kost veel meer vermogen van je GPU/CPU als het softwarematig moet gebeuren. Mobiele apparaten die niet de juiste hardware aan boord hebben kun je dus niet meer gebruiken voor nieuwe films zonder dat je batterij eronder lijdt.

Ik denk sowieso niet dat XHTML5 iets is voor de komende 2-3 jaar. En tegen die tijd is er allang weer een nieuw mobiel toestel uit. Die ontwikkeling gaat heel erg rap, ik zie geen probleem.

Mja, maar hoeveel mobiele telefoons zie jij overstappen op WebM zolang er nog geen decoding hardware voor is en zolang de standaard nog niet uitgekozen is? Tegen de tijd dat duidelijk is welke codec de standaard wordt zijn we 1-2 jaar verder. Daarna heb je nog ontwikkeltijd voor de nieuwe telefoons die eventueel gebruik zouden moeten maken van WebM, laten we daar een half jaar voor nemen. Pas over 2 jaar komen dus telefoons uit die native WebM ondersteunen. Rekening houdend met het feit dat veel mensen een telefoon ten minste twee jaar houden zit je dus nog 4 jaar opgescheept met H.264 support om mobiele gebruikers tevreden te stellen.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

vrijdag 14 januari 2011 02:45

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

NMe schreef op vrijdag 14 januari 2011 @ 00:45:
Mja, maar hoeveel mobiele telefoons zie jij overstappen op WebM zolang er nog geen decoding hardware voor is en zolang de standaard nog niet uitgekozen is? Tegen de tijd dat duidelijk is welke codec de standaard wordt zijn we 1-2 jaar verder.

quote: http://www.webmproject.org/hardware/
Q: Are there commercial chipsets in the market using the WebM video hardware IP?

A: A number of semiconductor chipset manufacturers have licensed the WebM video decoder IP. The first chips are expected on the market in 2011.

Niet waar dus, men verwacht Q1 2011 al de eerste chips op de markt, dan is het een kwestie van prototypes maken en goed testen, daar zal Google vast wel vol op inzetten. Als ze de multimediamarkt hebben dan is de weg open.

Verder is die hardware niet zo spannend, er komt geloof ik o.a. ogg e.d. in. Daar zijn al jaren chips van op de markt, wat dingen bij elkaar gooien en software maken en klaar. Hebben ze nog geen 6 maanden voor nodig bij Google schat ik.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

Onderwerpen

(X)HTML5

Introductie:

Doctype:

Nieuwe elementen:

Nieuwe attributen:

Local storage:

Offline applicatie caching:

Forms:

Semantiek:

Browsersupport:

FAQ:

Links:

Tot slot: