W3C dumpt xhtml 2 om zich meer op html 5 te kunnen richten
De standaardenorganisatie voor internet, het World Wide Web Consortium, of W3C, heeft laten weten eind dit jaar het werk aan xhtml 2 te staken. De inspanningen van het consortium zullen op de ontwikkeling van html 5 worden geconcentreerd.
De xhtml 2-werkgroep werd in maart 2007 in het leven geroepen om een nieuwe versie van de xhtml-standaard, een hybride vorm van xml en html, te ontwikkelen. Deze versie was van meet af aan controversieel, aangezien het backwards compatibility met zowel xhtml 1 en html 4 zou laten varen. De W3C heeft echter op 2 juli besloten om in 2010 niet met dit project verder te gaan: een deel van het werk, waaronder de serialisatie van xml, zal onderdeel van de html 5-specificatie worden. De organisatie geeft middels een faq uitleg over de toekomstplannen rondom de xhtml-standaard.
Naast het opheffen van de xhtml 2-werkgroep, maakte het W3C bekend dat het meer middelen voor de html 5-werkgroep beschikbaar gaat maken, om zo sneller resultaat met de ontwikkeling van de standaard te kunnen boeken. Een deel van de specificatie voor html 5 voorzag in een specificatie welke codecs in de audio- en video-tags in de code als standaard zouden gelden. Eerder deze week werd via een mailinglijst voor betrokkenen bekend gemaakt dat die specificatie geschrapt zal worden.
Oorzaak van het spaaklopen van de implementatie zijn geschillen over welke codecs gebruikt moeten worden: Apple wil Ogg Theora niet de standaard video-codec in Safari maken. Google is van mening dat die codec niet robuust genoeg is voor Youtube-verkeer en prefereert de H264-codec, maar zegt zijn licenties niet met derden te kunnen delen. Om die reden wil Opera geen H264-codec gebruiken: de licentiekosten zijn te hoog. Ook Mozilla heeft moeite met de licenties, terwijl Microsoft zich niet uitlaat over video-ondersteuning in zijn browser.
Reacties (113)
Oftewel, het video element is Firefox is nu totaal achterhaald. Dat zou namelijk wel best zuur zijn voor de tijd die in de implementatie daarvan heeft gezeten
Het video-element blijft onderdeel van HTML5. Alleen het onderdeel van de standaard welke codecs ondersteund moeten worden wordt geschrapt.
precies dit is een fout in het artikel
Idd 
Aangepast
Aangepast
juist, en op die manier blijft er ruimte over om zelf een implementatie te maken en dus is html5 geen standaard meer....
Niet mee eens: een <video>-element is een enorme verbetering boven het aanroepen van het ActiveX-element van Mediaspeler, het embedden van een Quicktime-object of het invoegen van een Flashanimatie.
Een gestandaardiseerde codec was wel beter geweest ja.
Een gestandaardiseerde codec was wel beter geweest ja.
Mee eens. Ik snap niet waarom developers nog uit één van deze moeten kiezen of (als ze het goed willen doen) zelf een Flash player moeten maken. Één HTML element is veel makkelijker, beter, overzichtelijker en waarschijnlijk daarom ook sneller, en niet alleen voor de developers.
Waarom is het niet mogelijk de codecs van het OS te gebruiken. Het is toch nergens voor nodig om de codec met de browser mee te compileren terwijl er al tal van codecs met het OS mee komen. Met javascript zou je het zelfs beschikbare codecs af kunnen gaan om zodoende het juiste filmpje te kunnen laten zien.
Hoe wil je dit gaan doen als een browser als FireFox op Windows, OS-X en Linux/BSD draait? Dit zou dan dus moeten betekenen dat de maker van de website moet controlleren op welk OS de browser draait, en welke code hier voor nodig is.
Verder kan dit ook veel problemen opleveren als een Microsoft, Appel of willekeurige *Unix OS bouwer de code gaat updaten naar een nieuwere release? Dan zal de website daar weer op aangepast moeten worden.
Verder kan dit ook veel problemen opleveren als een Microsoft, Appel of willekeurige *Unix OS bouwer de code gaat updaten naar een nieuwere release? Dan zal de website daar weer op aangepast moeten worden.
Het is toch ook te controleren welke browser een user draait? Waarom is dat dan lastig? Je kunt gewoon de servervariables uitlezen voor dat soort info. Hoe precies die info is is een tweede, maar de mogelijkheid bestaat. Laat de IIS en Apache (e.a.) ontwikkelaars die variable aanpassen zodat het specifiek genoeg is. Hier hoef je geen standaard voor te bedenken met een bureaucratische niet-belangeloze werkgroep. (Het laatste even doordravend op html5/video tags)
En misschien moeten FF, Opera, IE e.a. gewoon even samenwerken ipv. aanmodderen in die w3c werkgroep. Het lijkt wel een ouderwets trage overheidsinstelling!
En misschien moeten FF, Opera, IE e.a. gewoon even samenwerken ipv. aanmodderen in die w3c werkgroep. Het lijkt wel een ouderwets trage overheidsinstelling!
die variable (de AGENT, doorgaans) wordt gestuurd door de browser zelf, en is vaak genoeg te forgen indien de gebruiker dat wil, en bepaalde firewall software doet dat ook. Hetzelfde geld voor de referer, ook die wordt door de browser gestuurt en is te verwijderen of te muteren.et is toch ook te controleren welke browser een user draait? Waarom is dat dan lastig? Je kunt gewoon de servervariables uitlezen voor dat soort info.
Derhalve zijn die variabelen niet betrouwbaar genoeg.
[Reactie gewijzigd door arjankoole op zaterdag 4 juli 2009 20:02]
Firefox wordt toch apart gecompileerd voor die platvormen? Je hoeft dus helemaal niets uit te zoeken je weet bij voorbaat al welk platform je op draait nl die waarvoor je gecompileerd bent; de platform afhankelijke interface die je daarvoor nodig hebt zou binnen de browser helemaal niet mogen boeien.
[Reactie gewijzigd door farlane op zaterdag 4 juli 2009 22:06]
moet je wel voor al die platformen die content aanbieden, da's 3 of 4x zoveel formaten als 1 formaat. Niet veel sites zullen dat willen doen.
Kan je serverside niet 1 bronbestand zodanig laten aanleveren naargelang de user agent van de bezoeker? Het kost dan wel CPU-cycles van de server natuurlijk.
Ik weet in hoeverre dit mogelijk is en in hoeverre het wenselijk is. Het lijkt me een behoorlijk (potentieel) veiligheidsrisico om dit niet binnen de browseromgeving te houden.
Uiteraard kunnen de codecs van het besturingssysteem gebruikt worden, maar dat is een implementatiedetail voor de browserfabrikant. Waar dit om gaat is of bijvoorbeeld Ogg Theora verplicht moet zijn voor iedere browserfabrikant om te implementeren. Of de fabrikant nu de Theora-codec meelinkt in de browser of anders het besturingssysteem verzoekt een Theorabestand weer te geven, is voor de HTML5-werkgroep niet relevant.
Dan zou Google met Youtube dus misschien wel 3 versies online moeten hebben staan. Daar zullen ze natuurlijk weinig zin in hebben.
Mac -> H264
Linux -> Ogg Theora
Windows -> ?? wmv? wie weet?
En daarvan vinden zij dat Ogg Theora nog niet goed genoeg is.
Mij lijkt het persoonlijk voor Internet het handigst als er gekozen zou worden voor een standaard die een open source licentie heeft. Daarmee verzeker je jezelf voor de toekomst. Dat elke platform de juiste beleving heeft op internet.
Zou mooi zijn als Google nu mee gaat werken aan Ogg Theora.
Mac -> H264
Linux -> Ogg Theora
Windows -> ?? wmv? wie weet?
En daarvan vinden zij dat Ogg Theora nog niet goed genoeg is.
Mij lijkt het persoonlijk voor Internet het handigst als er gekozen zou worden voor een standaard die een open source licentie heeft. Daarmee verzeker je jezelf voor de toekomst. Dat elke platform de juiste beleving heeft op internet.
Zou mooi zijn als Google nu mee gaat werken aan Ogg Theora.
Windows 7 ondersteunt H.264 native, dus Microsoft is ook al in het (ISO standaard!) MPEG-4 bootje gestapt.Windows -> ?? wmv? wie weet?
Dat doen ze nu al. Afhankelijk van je voorkeur of van je platform (bijv. mobiele telefoon) krijg je een bepaald formaat video. Op de iPod / iPhone krijg je bijvoorbeeld mpeg4 videos en geen flash. Sommige video's zijn ook niet in alle formaten beschikbaar. Het ligt eraan wanneer ze zijn geupload (alhoewel oude populair video's ook nog worden omgezet naar nieuwe formaten) en in welke kwaliteit ze zijn geupload. Een video die in 640x480 wordt geupload zal natuurlijk nooit in HD formaat beschikbaar komen.Dan zou Google met Youtube dus misschien wel 3 versies online moeten hebben staan. Daar zullen ze natuurlijk weinig zin in hebben.
1 codec die iedereen ondersteund is veel beter, dat scheelt een berg, en daardoor werkt het altijd.
Stel iemand gebruikt Windows Media, dan werkt die content niet meer op Mac OS X, BSD of Linux. Of op systemen die geen windows media player aan boord hebben. Dat zou de standaard volledig ondermijnen. (alhoewel de huidige oplossing hetzelfde doet).
Het nadeel van wat je voorsteld behelst dat je hetzelfde stuk content 4x beschikbaar moet stellen (OGG Theora voor Linux en BSD gebruikers, H264 voor Chrome, mpeg4 voor Safari, WMV voor Windows). Dat is juist wat deze standaard had moeten voorkomen, en dat mislukt nu jammerlijk omdat ze onderling weer eens lopen te rommelen. In dat opzicht zou OGG de beste oplossing zijn, omdat die volledig vrij is van Licenties e.d.
Stel iemand gebruikt Windows Media, dan werkt die content niet meer op Mac OS X, BSD of Linux. Of op systemen die geen windows media player aan boord hebben. Dat zou de standaard volledig ondermijnen. (alhoewel de huidige oplossing hetzelfde doet).
Het nadeel van wat je voorsteld behelst dat je hetzelfde stuk content 4x beschikbaar moet stellen (OGG Theora voor Linux en BSD gebruikers, H264 voor Chrome, mpeg4 voor Safari, WMV voor Windows). Dat is juist wat deze standaard had moeten voorkomen, en dat mislukt nu jammerlijk omdat ze onderling weer eens lopen te rommelen. In dat opzicht zou OGG de beste oplossing zijn, omdat die volledig vrij is van Licenties e.d.
Stel iemand gebruikt Windows Media
Tja, dan is dat de domme fout van de webdeveloper. Persoonlijk lijkt me zo'n videotag wel handig, maar waarom niet gewoon vrijheid in de codec? Als ik een video open in windows media player hoef ik hem toch ook niet meer te vertellen welke codec ik gebruik?
Tja, dan is dat de domme fout van de webdeveloper. Persoonlijk lijkt me zo'n videotag wel handig, maar waarom niet gewoon vrijheid in de codec? Als ik een video open in windows media player hoef ik hem toch ook niet meer te vertellen welke codec ik gebruik?
Err tuurlijk. Daarom bestaan er dingen als het k-lite codec pack, omdat ie alle codecs zo lekker makkelijk zelf ergens vandaan kan trekken.
h264 is (onderdeel van) mpeg4...
Apple zal zeker geen problemen maken tegen h264, alle filmpjes in itunes zijn ook h264 encoded, ze maakten er zelfs reclame mee...
Apple zal zeker geen problemen maken tegen h264, alle filmpjes in itunes zijn ook h264 encoded, ze maakten er zelfs reclame mee...
[Reactie gewijzigd door Keneo op zondag 5 juli 2009 14:39]
Inderdaad. Maar ik moet wel zeggen dat (aangenomen dat er uiteindelijk een standaard codec komt) ik vind dat wat de standaard codec nou wordt, het royalty- en patent-free moet zijn en t liefst zelfs compleet FOSS wordt.
Tevens is mijn mening wat betreft de jankende partijen:
-Google vindt Theora niet robuust genoeg. Dan moeten ze meehelpen aan t ontwikkelen van de technologie zodat het wel aan hun robuustheidseisen voldoet. H264 zou niet moeten worden gebruikt als standaard juist vanwege de licentiekosten. Hiernaast zijn er patenten van kracht op deze codec, het is bewezen o.a. door mp3 dat dit niet bevorderlijk werkt voor de eindgebruikers. Oftewel Opera en Mozilla hebben groot gelijk H264 geen standaard te willen maken.
-Apple wil de Theora technologie niet de standaard in Safari maken. Zolang ze niet zeggen waarom moet hier geen aandacht aan worden besteed.
EDIT: doctormetal heeft wss gelijk, quicktime is idd een goede motivatie voor Apple om geen Theora te willen als standaard. Maar dit soort gelobby (zakenbelangen ipv superieure en vooral ongepatenteerde technologie) kan nooit voor optimale uitkomsten zogen op lange, of zelfs korte termijn.
Tevens is mijn mening wat betreft de jankende partijen:
-Google vindt Theora niet robuust genoeg. Dan moeten ze meehelpen aan t ontwikkelen van de technologie zodat het wel aan hun robuustheidseisen voldoet. H264 zou niet moeten worden gebruikt als standaard juist vanwege de licentiekosten. Hiernaast zijn er patenten van kracht op deze codec, het is bewezen o.a. door mp3 dat dit niet bevorderlijk werkt voor de eindgebruikers. Oftewel Opera en Mozilla hebben groot gelijk H264 geen standaard te willen maken.
-Apple wil de Theora technologie niet de standaard in Safari maken. Zolang ze niet zeggen waarom moet hier geen aandacht aan worden besteed.
EDIT: doctormetal heeft wss gelijk, quicktime is idd een goede motivatie voor Apple om geen Theora te willen als standaard. Maar dit soort gelobby (zakenbelangen ipv superieure en vooral ongepatenteerde technologie) kan nooit voor optimale uitkomsten zogen op lange, of zelfs korte termijn.
[Reactie gewijzigd door Jeanpaul145 op zaterdag 4 juli 2009 19:44]
Er is een hele simpele reden waarom Apple geen theora wil: QuickTime
Dat is waarschijnlijk stiekem wel de echte reden, maar de verklaring van Apple was dat het bedrijf twijfels heeft of Ogg Theora wel echt patent-vrij is.
http://tech.slashdot.org/...p-HTML-5-Codecs?art_pos=1
Op zich geen heel erg vreemd excuus want een videocodec is een vrij complex geheel van decodeerstappen en algoritmes, en de theorie achter de encoding is voor eigenlijk alle soorten codec's min of meer hetzelfde. Het is dus niet denkbeeldig dat Ogg Theora ook op algoritmes gebaseerd is die op zijn minst een interessant doelwit zijn voor patent trolls, en zelfs misschien wel rechtmatige patenten schenden.
http://tech.slashdot.org/...p-HTML-5-Codecs?art_pos=1
Op zich geen heel erg vreemd excuus want een videocodec is een vrij complex geheel van decodeerstappen en algoritmes, en de theorie achter de encoding is voor eigenlijk alle soorten codec's min of meer hetzelfde. Het is dus niet denkbeeldig dat Ogg Theora ook op algoritmes gebaseerd is die op zijn minst een interessant doelwit zijn voor patent trolls, en zelfs misschien wel rechtmatige patenten schenden.
Het is meer dat een partij geld wens te gaan verdienen aan H.264 en december 2010 is daar een magisch moment voor. Op dat moment verloopt de introductieperiode en moet er voor veel content geld worden afgedragen. Dit is een reden dat Google Video voor lange video's zijn deuren sluit en dat YouTube alleen nog korte filmpjes accepteert om onder deze kostengrens te blijven.
Microsoft zag deze bui een flinke tijd geleden al hangen en is bewust niet ingestapt. En voor Mozilla en Opera geldt hetzelfde, maar je het wordt wel duidelijk wie een graantje meepikt van de licentiekosten. Het is ook begrijpelijk waarom Microsoft niet in het Theora-bootje stapt door de kosten die ze aanpassingen van VC-1 hebben gestoken.
De huidige testen met Theora 1.1 versus H.264 geeft duidelijke verbeteringen weer voor Theora. Voeg hier aan toe dat er steeds meer Theora content komt uit de FOSS-wereld door conferenties die je online kan bekijken en Wikipedia die Theora heeft geselecteerd als videoformaat zit er wel een redelijke drive achter om toch ondersteuning te krijgen in webbrowsers.
En patenttrollen mogen het proberen, maar het bedrijf achter VP3 heeft zijn intellecueel eigendom in het public domain gezet. De kans is klein dat ze een voet aan de grond gaan krijgen, want software patenten staan nu ook in VS ter discussie. Daarbij moeten ze de makers gaan aanklagen en de huidige code begint steeds meer af te wijken van On2 heeft vrijgegeven. Voor eindgebruikers is er dus weinig gevaar.
De laatste partij die het probeerde op deze schaal was AT&T met Unix en er was geen betere kickstart om de issues aan te passen. En SCO probeerde dit zachtjes over te doen, maar hoe het daar mee aflopen is weet iedereen wel. Een andere bekende is misschien Fraunhoffer met MP3 en iedereen weet wel hoe succesvol hun plan tot uitvoering kwam toen ze geld wilde zien of je gingen aanklagen.
Maar voor Apple, nee dank je ik wens niet via H.264 geld af te dragen aan ze. Zeker niet als je bedenkt dat er oa Vorbis plugins zijn voor QuickTime, maar doel bewust onbruikbaar worden gemaakt in oa iTunes.
Microsoft zag deze bui een flinke tijd geleden al hangen en is bewust niet ingestapt. En voor Mozilla en Opera geldt hetzelfde, maar je het wordt wel duidelijk wie een graantje meepikt van de licentiekosten. Het is ook begrijpelijk waarom Microsoft niet in het Theora-bootje stapt door de kosten die ze aanpassingen van VC-1 hebben gestoken.
De huidige testen met Theora 1.1 versus H.264 geeft duidelijke verbeteringen weer voor Theora. Voeg hier aan toe dat er steeds meer Theora content komt uit de FOSS-wereld door conferenties die je online kan bekijken en Wikipedia die Theora heeft geselecteerd als videoformaat zit er wel een redelijke drive achter om toch ondersteuning te krijgen in webbrowsers.
En patenttrollen mogen het proberen, maar het bedrijf achter VP3 heeft zijn intellecueel eigendom in het public domain gezet. De kans is klein dat ze een voet aan de grond gaan krijgen, want software patenten staan nu ook in VS ter discussie. Daarbij moeten ze de makers gaan aanklagen en de huidige code begint steeds meer af te wijken van On2 heeft vrijgegeven. Voor eindgebruikers is er dus weinig gevaar.
De laatste partij die het probeerde op deze schaal was AT&T met Unix en er was geen betere kickstart om de issues aan te passen. En SCO probeerde dit zachtjes over te doen, maar hoe het daar mee aflopen is weet iedereen wel. Een andere bekende is misschien Fraunhoffer met MP3 en iedereen weet wel hoe succesvol hun plan tot uitvoering kwam toen ze geld wilde zien of je gingen aanklagen.
Maar voor Apple, nee dank je ik wens niet via H.264 geld af te dragen aan ze. Zeker niet als je bedenkt dat er oa Vorbis plugins zijn voor QuickTime, maar doel bewust onbruikbaar worden gemaakt in oa iTunes.
Had youtube niet onlangs de limiet van 1GB naar 2GB verhoogd? Dat spreekt je verhaal aardig tegen.en dat YouTube alleen nog korte filmpjes accepteert om onder deze kostengrens te blijven.
Discussie betekend niet dat patentclaims op dit moment kansloos zijn, in Texas win je vrijwel gegarandeerd, maar dat wordt door beroepen in andere staten, of federaal vaak verworpen. Vaak, niet altijd. En niet altijd betekend een risico waar de meeste bedrijven zich niet aan willen branden.De kans is klein dat ze een voet aan de grond gaan krijgen, want software patenten staan nu ook in VS ter discussie.
[Reactie gewijzigd door arjankoole op zaterdag 4 juli 2009 23:05]
@arjankoole: ja de grens van de videogrootte is verhoogd. van de videolengte is hetzelfde gebleven. Oftewel: de vergroting is dus ter verbetering van de kwaliteit van de filmpjes.
Ik zou niet weten waarom je Theora zou willen gebruiken als de meeste huidige apparaten gewoon native en hardware accelerated al ondersteuning hebben voor H.264. Verder vind ik zelf de beeldkwaliteit beter. Overigens zou ik niet weten waarom Wikipedia van invloed kan zijn. Ik heb nog nooit een filmpje gezien of bekeken op de wikipedia website.
Maar ja, als alleen Firefox het gebruikt schiet het voorlopig niet op en zit je nog steeds vast aan browser controles betreffende video. En natuurlijk is het een stuk lastiger om irritante HTML5 effect te blokkeren vergeleken met Flash of Silverlight. Immers je moet dan CSS en/of Javascript uitzetten wat vervolgens ook een hoop andere bruikbare functionaliteit blokkeert (formulier validatie, xmlhttprequest e.d.).
Maar ja, als alleen Firefox het gebruikt schiet het voorlopig niet op en zit je nog steeds vast aan browser controles betreffende video. En natuurlijk is het een stuk lastiger om irritante HTML5 effect te blokkeren vergeleken met Flash of Silverlight. Immers je moet dan CSS en/of Javascript uitzetten wat vervolgens ook een hoop andere bruikbare functionaliteit blokkeert (formulier validatie, xmlhttprequest e.d.).
[Reactie gewijzigd door alienfruit op zondag 5 juli 2009 00:22]
Als softwaremaker? simpel, aan Theora zijn geen licentiekosten verbonden en aan H.264 wel en die schijnen ook nog eens hoog te zijn. Bovendien zitten er voor Mozilla juridische haken en ogen aan het integreren van gepatenteerde technologie in een OSS programma.Ik zou niet weten waarom je Theora zou willen gebruiken ...
We hebben het hier over de implementatie van de video tag, dit heeft verder niets met de implementatie van html5 te maken. Dit hadden ze destijds ook met het standaardiseren van de <img> tag, welk formaat daarvoor standaard gebruikt moest gaan worden, maar daar is ook niks van terecht gekomen.
Wat ze wel kunnen standaardiseren is de markup van alle code, welke video en audio codecs er worden gebruikt voor de content laten ze aan de content provider over.
Wat ze wel kunnen standaardiseren is de markup van alle code, welke video en audio codecs er worden gebruikt voor de content laten ze aan de content provider over.
Onzin, de <img> tag bestaat ook, en kan door browser vendors ook vrij ingevuld worden met decoders. Gelukkig ondersteunen ze allemaal zo'n beetje hetzelfde (hoewel... PNG), maar hetzelfde kan gelden voor <audio> en <video>.
Ian Hickson schrijft dat hij de twee specs waar een codec verijst was heeft geschrapt.
Daarmee is eigenlijk het hele voordeel van een adio of video element verloren gegaan.
Zover ik wel heb begrepen kan het best zijn dat na verloop van tijd dit weer terug komt in de spec van html5 als de browser eigenaars er toch noch uitkomen
Daarmee is eigenlijk het hele voordeel van een adio of video element verloren gegaan.
Zover ik wel heb begrepen kan het best zijn dat na verloop van tijd dit weer terug komt in de spec van html5 als de browser eigenaars er toch noch uitkomen
Dat is niet zo. Het video-element is wel degelijk een significant onderdeel van de HTML5 specificatie, samen met de DOM storage en natuurlijk canvas (shameless plug: grappig voorbeeld te vinden in mijn blogpost: paint.canvas).
Het enige dat men verwijdert heeft uit de HTML5-specificatie is de codecs die minimaal door een HTML5-compliant browser ondersteund moeten worden - omdat voordat deze definitief is al bekend is dat de fabrikanten onderling het niet eens kunnen worden over de minimaal vereiste codecs.
De oplossing die men nu kiest is vergelijkbaar met de manier waarop in het verleden het img-element gestandaardiseerd is. Ook bij het img-element staat er in de HTML specificatie niet welke afbeeldingsformaten er gebruikt moeten/mogen worden - uiteindelijk zijn JPEG, GIF, PNG de winnaars geworden.
In het geval van het video-element zullen Ogg Theora en H264 door verschillende browsers ondersteund worden maar is er geen enkele die al deze codecs ondersteund. Dit kan opgelost worden door het downloadbaarmaken van de codes - zodat bijvoorbeeld een Safari browser via een gedownloade codec toch Ogg Theora video af kan spelen, het omgekeerde is natuurlijk ook denkbaar.
In de tussentijd kan een website de video ook aanbieden in deze twee formaten zodat er gebruiker niets hoeft te downloaden - in dat geval is er wel extra werk van de webmaster nodig, maar hoeft de gebruiker helemaal nooit iets te downloaden...
Het enige dat men verwijdert heeft uit de HTML5-specificatie is de codecs die minimaal door een HTML5-compliant browser ondersteund moeten worden - omdat voordat deze definitief is al bekend is dat de fabrikanten onderling het niet eens kunnen worden over de minimaal vereiste codecs.
De oplossing die men nu kiest is vergelijkbaar met de manier waarop in het verleden het img-element gestandaardiseerd is. Ook bij het img-element staat er in de HTML specificatie niet welke afbeeldingsformaten er gebruikt moeten/mogen worden - uiteindelijk zijn JPEG, GIF, PNG de winnaars geworden.
In het geval van het video-element zullen Ogg Theora en H264 door verschillende browsers ondersteund worden maar is er geen enkele die al deze codecs ondersteund. Dit kan opgelost worden door het downloadbaarmaken van de codes - zodat bijvoorbeeld een Safari browser via een gedownloade codec toch Ogg Theora video af kan spelen, het omgekeerde is natuurlijk ook denkbaar.
In de tussentijd kan een website de video ook aanbieden in deze twee formaten zodat er gebruiker niets hoeft te downloaden - in dat geval is er wel extra werk van de webmaster nodig, maar hoeft de gebruiker helemaal nooit iets te downloaden...
Ik hoop dat ze gewoon gebruik maken van de codecs op het platform. Zoals DirectShow voor windows, linux en Apple zullen wel wat vergelijkbaars hebbem/
Als ze alleen gebruik maken van codecs die op het platform aanwezig zijn, dan krijg je het probleem dat bijvoorbeeld je naar een Apple een andere codec moet sturen dan naar een Win32 machine en naar een Linux machine weer een eigen codec moet sturen.
Op het moment dat er enige standardisatie op het gebied van codecs plaats vind heb je dat probleem niet - waarbij we nu dus bij de patstelling gekomen zijn tussen H264 vs. Ogg Theora. Maar dat beperkt het aantal op dit moment wel tot 2 stuks en aangezien dat het leeuwendeel Ogg Theora ondersteund is dat alvast een mooie basis om mee te beginnen.
Zoals ik de berichten lees is er nog voldoende ruimte voor verbetering in de software die Ogg Theora aanmaakt - als deze op eenzelfde niveau als H264 gekomen is is er weer een minpunt van Ogg Theora verdwenen, het enige minpunt dat 't dan nog heeft is ondersteuning in de hardware voor het decoderen van Ogg Theora...
Op het moment dat er enige standardisatie op het gebied van codecs plaats vind heb je dat probleem niet - waarbij we nu dus bij de patstelling gekomen zijn tussen H264 vs. Ogg Theora. Maar dat beperkt het aantal op dit moment wel tot 2 stuks en aangezien dat het leeuwendeel Ogg Theora ondersteund is dat alvast een mooie basis om mee te beginnen.
Zoals ik de berichten lees is er nog voldoende ruimte voor verbetering in de software die Ogg Theora aanmaakt - als deze op eenzelfde niveau als H264 gekomen is is er weer een minpunt van Ogg Theora verdwenen, het enige minpunt dat 't dan nog heeft is ondersteuning in de hardware voor het decoderen van Ogg Theora...
Er is nog veel ruimte voor verbetering (en dat is goed, want als dat niet zo zou zijn, zou het niet beter kunnen worden), maar het lijkt al heel erg op H.264 bij Youtube-resoluties:Zoals ik de berichten lees is er nog voldoende ruimte voor verbetering in de software die Ogg Theora aanmaakt - als deze op eenzelfde niveau als H264 gekomen is is er weer een minpunt van Ogg Theora verdwenen
Vergelijking tussen Youtube en Theora met Big Buck Bunny
De lage resolutie-test wint Theora:
De hoge resolutie-test wint H.264, maar het is marginaal:That said, I believe that the Theora+Vorbis results are substantially better than the YouTube 327kbit/sec. Several other people have expressed the same view to me, and I expect you'll also reach the same conclusion. This is unsurprising since we've been telling people that Theora is better than H.263, especially at lower bitrates, for some time now and YouTube only uses a subset of H.263.
Vergelijking tussen Youtube en Theora met 'talking heads' materiaal. Deze test wint Theora:In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video. However, the difference is not especially great. I expect that most casual users would be unlikely to express a preference or complain about quality if one was substituted for another and I've had several people perform a casual comparison of the files and express indifference.
De reden dat Theora kan winnen bij Youtube, is omdat zelfs de 'hoge kwaliteit' video's niet echt hoge kwaliteit zijn. Theora doet het erg goed op lage bitrates. Pas bij hogere resoluties en hogere bitrates gaat H.264 het duidelijk winnen. Jammer genoeg worden de meeste tests (van Doom9 enzo) met DVD-content gedaan. Dat is niet representatief voor het gebruik op het web.It is possible to use Theora to serve streaming content on the web without inflating bitrate or dramatically decreasing quality compared to the H.264 encoding setup used by the web's most popular online streaming service.
Oh, en geen hardware-ondersteuning?
[Reactie gewijzigd door DOT op zaterdag 4 juli 2009 21:05]
Nee, geen hardware ondersteuning in de apparaten die momenteel op de markt zijn. Terwijl deze er wel zijn voor H.264. En de nieuwe PMP waar ik aan meewerkte ondersteunt ook geen Theora hardware matig. Als ik de techniek mensen goed heb begrepen zou het gedeeltelijk kunnen doen via pixel shaders (via OpenGL 2.0 ondersteuning). Maar daar heb ik geen kaas van gegeten. Maar geen ingebakken ondersteuning op de grafische chip in de device. Ze gebruiken overigens de OMAP4430.
[Reactie gewijzigd door alienfruit op zondag 5 juli 2009 00:45]
Grafische interfaces ontwerpen en maken voor mobiele toestellen <g>
De OMAP4430 heeft dit:
Met een firmware-update kan een telefoon-fabrikant dus Theora-ondersteuning toevoegen.* Programmable DSP provides flexibility for future codecs
Die vergelijking is nutteloos omdat de geluidsstreams in de youtube video's veel groter zijn en de theora versie van de video maar een keyframe rate heeft van 250. Extraam weinig keyframes.
Dat is toch wel een aparte beslissing die ik niet zag aankomen. Ik heb nog geen 2 maanden geleden een boek over Xhtml 2 gekocht...Niet dat dat verspilling is geweest aangezien de technieken dicht bij elkaar liggen.
Achja, ik neem aan dat ze daar echt wel weten waar ze het over hebben
Achja, ik neem aan dat ze daar echt wel weten waar ze het over hebben
[Reactie gewijzigd door Aggror op zaterdag 4 juli 2009 17:21]
Zijn er dan al boeken over XHTML2?
Er is heel lang strijd geweest tussen HTML5 en XHTML2. Maar gedurende de discussie werden veel mensen overtuigd van de noodzaak tot backwards compatibility. HTML5 won snel terrein, zeker toen het W3C HTML5 officieel als opvolger van HTML4 adopteerde.
Browser vendors waren het er al snel over eens dat HTML5 ondersteund moest worden. Naar mijn weten heeft geen enkele browser vendor XHTML2 support in de planning staan.
Er is heel lang strijd geweest tussen HTML5 en XHTML2. Maar gedurende de discussie werden veel mensen overtuigd van de noodzaak tot backwards compatibility. HTML5 won snel terrein, zeker toen het W3C HTML5 officieel als opvolger van HTML4 adopteerde.
Browser vendors waren het er al snel over eens dat HTML5 ondersteund moest worden. Naar mijn weten heeft geen enkele browser vendor XHTML2 support in de planning staan.
Technieken mogen dicht bij elkaar komen. Ik heb me de laatste twee jaar volledig gestort op xHTML omdat ik dat fijner vond programmeren, maar ook omdat het sneller schijnt te zijn.
Jammer dat ik dan óf xHTML 1.1 óf HTML 5 moet gaan gebruiken.
Jammer dat ik dan óf xHTML 1.1 óf HTML 5 moet gaan gebruiken.
Als je het verschil HTML/XML bedoelt, HTML 5 heeft ook een XML-versie.Ik heb me de laatste twee jaar volledig gestort op xHTML omdat ik dat fijner vond programmeren
Dat was alleen zo als je je XHTML ook met application/xhtml+xml header stuurt (dan gebruikt de browser een XML-parser, wat idd sneller is). Helaas ondersteunt IE dat niet en wordt 99% van de zogenaamde XHTML-content geserveerd als text/html, wat gewoon door de HTML-parser gaat (die het ziet als malformed HTML...) en er totaal geen snelheidsvoordeel ismaar ook omdat het sneller schijnt te zijn.
[Reactie gewijzigd door JanDM op zaterdag 4 juli 2009 19:55]
Als je kiest voor een op XML gebaseerde taal, dan is er altijd nog de mogelijkheid om "XHTML5" te gebruiken, dit is een XML serialisatie van HTML5 - met de bijbehorende nieuwe mogelijkheden.
XHTML1.1 is op zich een mooi alternatief voor de oude HTML tag-soup, maar bevat de nieuwe features zoals de canvas-, video- en audio-elementen niet.
Ook uit pragmatisch standpunt heeft XHTML1 een achterstand (met name ivm de ondersteuning door MSIE) en ook qua snelheid zijn voor zover ik weet de HTML (tagsoup) parsers nog steeds sneller (of net zo snel) dan de meeste XML parsers die in de browsers aanwezig zijn...
(Met "XHTML5"kun je net als met XHTML1.x gewoon verschillende XML talen door elkaar gebruiken - SVG en MathML kun je dan gewoon in hetzelfde document plaatsen als de "XHTML5")
XHTML1.1 is op zich een mooi alternatief voor de oude HTML tag-soup, maar bevat de nieuwe features zoals de canvas-, video- en audio-elementen niet.
Ook uit pragmatisch standpunt heeft XHTML1 een achterstand (met name ivm de ondersteuning door MSIE) en ook qua snelheid zijn voor zover ik weet de HTML (tagsoup) parsers nog steeds sneller (of net zo snel) dan de meeste XML parsers die in de browsers aanwezig zijn...
(Met "XHTML5"kun je net als met XHTML1.x gewoon verschillende XML talen door elkaar gebruiken - SVG en MathML kun je dan gewoon in hetzelfde document plaatsen als de "XHTML5")
Ik heb begrepen dat er van html 5 wel een xml-implementatie komt, misschien is dat ook wel gewoon beter. Xhtml 1 werd ook al niet geweldig ondersteund, vooral door het niet ondersteunen ervan door Internet Explorer. Html 5 doet het wat dat betreft heel wat beter. Features daarvan worden nu al her en der geïmplementeerd, terwijl de standaard nog lang niet af is.
XHTML 1.0 is eigenlijk gewoon een serialisatie van HTML naar XML ipv de standaard serialisatie van HTML naar SGML - hoewel HTML eigenlijk niet eens als SGML behandeld wordt door de browsers...
Voor HTML5 heeft men eigen regels geschreven als alternatief voor de SGML serialisatie en heeft men een XML serialisatie optie onderdeel van de standaard gemaakt...
Voor HTML5 heeft men eigen regels geschreven als alternatief voor de SGML serialisatie en heeft men een XML serialisatie optie onderdeel van de standaard gemaakt...
Erg, erg jammer. IMO slaan ze met HTML5 de plak behoorlijk mis: ALLE HTML4-legacy-meuk blijft behouden. Ze hadden de boel eindelijk eens kunnen ontdoen van alle ouwe zut, zoals XHTML2 dat wel deed, maar helaas. Zo had ook Javascript 1.x eindelijk eens vervangen moeten worden door iets beters, zoals Javascript 2, en/of bindings naar hogere programmeertalen moeten integreren.
De toevoeging van Canvas is ook too little, too late. In een wereld waarin computers en zelfs mobiele apparaten 3D-dingen kunnen doen waar je de mond van openvalt, komt de WHATWG met een library die feitelijk niet meer is dan een quick-hack-gimmick, die zelfs in het 2D-gebied nog hooguit bijzonder beperkt is. Daarentegen hebben ze SVG, waar veel interessantere dingen mee te doen zijn, lekker genegeerd.
HTML5 zou er voor webapps zijn. Waarom is er dan nauwelijks moeite gedaan om GUI-widgets toe te voegen aan HTML5? Nu blijven we met webgui's zitten die een ramp zijn qua usability, slecht presteren en/of er niet uitzien.
Ook is het natuurlijk een lachertje dat ze niet gewoon zijn overgegaan op een pure XML-notatie.. zoals XHTML2. Dat had tenminste goede uitbreidbaarheid gegarandeerd, en veel betere integratie met XML-driven apps. En het is imo nog een stuk duidelijker en logischer ook.
Dat er geen minimum video-codec is vastgelegd is werkelijk the cherry on top.
HTML5 is een zieke grap. Mijn werk als webdeveloper is er beslist niet aantrekkelijker op geworden. De WHATWG moet zich schamen.
De toevoeging van Canvas is ook too little, too late. In een wereld waarin computers en zelfs mobiele apparaten 3D-dingen kunnen doen waar je de mond van openvalt, komt de WHATWG met een library die feitelijk niet meer is dan een quick-hack-gimmick, die zelfs in het 2D-gebied nog hooguit bijzonder beperkt is. Daarentegen hebben ze SVG, waar veel interessantere dingen mee te doen zijn, lekker genegeerd.
HTML5 zou er voor webapps zijn. Waarom is er dan nauwelijks moeite gedaan om GUI-widgets toe te voegen aan HTML5? Nu blijven we met webgui's zitten die een ramp zijn qua usability, slecht presteren en/of er niet uitzien.
Ook is het natuurlijk een lachertje dat ze niet gewoon zijn overgegaan op een pure XML-notatie.. zoals XHTML2. Dat had tenminste goede uitbreidbaarheid gegarandeerd, en veel betere integratie met XML-driven apps. En het is imo nog een stuk duidelijker en logischer ook.
Dat er geen minimum video-codec is vastgelegd is werkelijk the cherry on top.
HTML5 is een zieke grap. Mijn werk als webdeveloper is er beslist niet aantrekkelijker op geworden. De WHATWG moet zich schamen.
Legacy (deprecated) meuk als <font>, <center>, etc. is met HTML5 eruit gehaald.Erg, erg jammer. IMO slaan ze met HTML5 de plak behoorlijk mis: ALLE HTML4-legacy-meuk blijft behouden.
Eens, maar dat staat hier los van imho...Zo had ook Javascript 1.x eindelijk eens vervangen moeten worden door iets beters, zoals Javascript 2, en/of bindings naar hogere programmeertalen moeten integreren.
3D kan toegevoegd worden aan <canvas>, volgens mij ondersteunt Firefox en/of Opera dat al onofficieel. Als je op bijv. Chrome Experiments kijkt zie je daar veel <canvas> gebruik, waar toch hele leuke dingen mee gedaan worden. Zonder Canvas had daar Flash/Silverlight gebruikt moeten worden.De toevoeging van Canvas is ook too little, too late. In een wereld waarin computers en zelfs mobiele apparaten 3D-dingen kunnen doen waar je de mond van openvalt, komt de WHATWG met een library die feitelijk niet meer is dan een quick-hack-gimmick, die zelfs in het 2D-gebied nog hooguit bijzonder beperkt is.
Misschien had men idd meer met SVG kunnen doen, maar die standaard heeft toch een ander doel vind ik. Canvas heeft bijv. geen DOM zoals SVG maar dat heb je vaak niet nodig en de performance is wel veel beter
Ik ben bijv. niet voor de error-handling van X(HT)ML, maar die discussie is vaak genoeg op GoT en hier gevoerd... HTML5 heeft iig wel een XML-serialisatie die je kunt gebruiken. Dat is veel mooier imho, gewoon één standaard met verschillende representaties...Ook is het natuurlijk een lachertje dat ze niet gewoon zijn overgegaan op een pure XML-notatie.. zoals XHTML2. Dat had tenminste goede uitbreidbaarheid gegarandeerd, en veel betere integratie met XML-driven apps. En het is imo nog een stuk duidelijker en logischer ook.
Ik denk dat het beter is zo: duidelijker (geen XHTML en HTML5 naast elkaar), bovendien ondersteunde IE XHTML toch niet
[Reactie gewijzigd door JanDM op zaterdag 4 juli 2009 17:54]
Aangezien alle valid HTML4 ook valid HTML5 is hebben ze het toch erin gelaten. Deprecated of niet. Ze hadden het gewoon moeten opruimen. Dat is de enige manier om er eindlijk eens vanaf te komen.
Dat Canvas misschien ooit uitgebreid kan worden met wat 3D grapjes hebben we nu niks aan. Bovendien zie ik de bui toch al hangen, gezien de mogelijkheden van de 2D Canvas API.
Het zogenaamde probleem met XML error handling is natuurlijk kul: well-formed XML te schrijven is kinderspel. Er zijn massa's editors die dat voor je regelen. En gebruikers zelf komen toch nooit met HTML noch XML in aanraking, omdat ze alles via software doen. En ook voor software is het veel makkelijker en logischer om met XML te werken.
Dat IE geen XHTML ondersteunt is een non-issue. Het gaat om HTML5, een nieuw te vormen standaard.
Dat Canvas misschien ooit uitgebreid kan worden met wat 3D grapjes hebben we nu niks aan. Bovendien zie ik de bui toch al hangen, gezien de mogelijkheden van de 2D Canvas API.
Het zogenaamde probleem met XML error handling is natuurlijk kul: well-formed XML te schrijven is kinderspel. Er zijn massa's editors die dat voor je regelen. En gebruikers zelf komen toch nooit met HTML noch XML in aanraking, omdat ze alles via software doen. En ook voor software is het veel makkelijker en logischer om met XML te werken.
Dat IE geen XHTML ondersteunt is een non-issue. Het gaat om HTML5, een nieuw te vormen standaard.
Vergeet niet dat de autoriteit van de W3C op het spel staat, het heeft meerdere standaarden vastgelegd die noch bij browserfabrikanten, noch bij webauteurs veel navolging kregen. De browserfabrikanten waren hun eigen standaard aan het ontwerpen, via de Whatwg.
Aansluiten bij wat de wereld doet is dan het beste wat je kan doen als W3C. Vandaar dat het HTML5 van de WhatWG in de HTML5-groep is overgegaan.
Het blokkeren van de transitional-tags is geen optie, er zijn anno 2009 hele volksstammen die doelbewust HTML4/transitional boven HTML4/strict verkiezen. Je zult die groep eerst degelijke alternatieven moeten bieden, anders heb je een gigantische groep die jouw als autoriteit niet serieus neemt.
Aansluiten bij wat de wereld doet is dan het beste wat je kan doen als W3C. Vandaar dat het HTML5 van de WhatWG in de HTML5-groep is overgegaan.
Het blokkeren van de transitional-tags is geen optie, er zijn anno 2009 hele volksstammen die doelbewust HTML4/transitional boven HTML4/strict verkiezen. Je zult die groep eerst degelijke alternatieven moeten bieden, anders heb je een gigantische groep die jouw als autoriteit niet serieus neemt.
De komst van HTML5 maakt het gebruik van HTML4 niet onmogelijk. Dat er dan hele volksstammen zijn die nu nog steeds deprecated(!) HTML4-zut gebruiken is dan hun probleem; ze hadden het echt kunnen zien aankomen.
Ik vind het gewoon uitermate teleurstellend dat dit alles is waar de WHATWG/W3C mee kan komen, na een DECENNIUM aan ervaring met HTML en webapps. Alsof ze zich puur laten leiden door hobbyisten voor wie een nieuwe standaard "te moeilijk" zou zijn, en door lompe IT-bedrijven die bang zijn dat ze hun archaïsche meuk niet meer aan de man kunnen brengen.
Als doorgewinterde prof die zich graag met de lean and mean cutting edge bezighoudt voel ik me behoorlijk genaaid door deze ontwikkeling.
Ik vind het gewoon uitermate teleurstellend dat dit alles is waar de WHATWG/W3C mee kan komen, na een DECENNIUM aan ervaring met HTML en webapps. Alsof ze zich puur laten leiden door hobbyisten voor wie een nieuwe standaard "te moeilijk" zou zijn, en door lompe IT-bedrijven die bang zijn dat ze hun archaïsche meuk niet meer aan de man kunnen brengen.
Als doorgewinterde prof die zich graag met de lean and mean cutting edge bezighoudt voel ik me behoorlijk genaaid door deze ontwikkeling.
Je snapt niet wat er speelde. Kijk eens wat Google gebruikt: HTML4/transitional, de homepage zit vol met <center> en <font>. Als de wereld gewoon weigert deze tags overboord te gooien, dat is dat een probleem voor het W3C, niet een probleem voor Google, die heeft gewoon een website die op alle browsers werkt en er is echt geen enkele browser die er mee weg komt om Google niet correct weer te geven.
Als HTML5 de tags niet ondersteunde had Google doodleuk HTML5 geweigerd. Op die manier bereik je precies wat er met zovele andere W3C-standaards is gebeurd, zo worden genegeerd. Beter gezegd: De hele W3C werd de afgelopen jaren steeds meer genegeerd.
De WhatWG heeft dat goed begrepen: De markt heeft altijd gelijk. De markt is mogelijk best bereid <video> gebruiken, maar wil ook <center> en <font>, dus heeft HTML5 <center> en <font>. Als je deze tags wilt afschaffen zal je eerst alternatieven moeten verzinnen die door de markt acceptabel geacht worden. Pas je dat gedaan hebt en het gebruik van <center> en <font> af begint te nemen kan je overwegen ze uit toekomstige standaarden weg te laten.
Als HTML5 de tags niet ondersteunde had Google doodleuk HTML5 geweigerd. Op die manier bereik je precies wat er met zovele andere W3C-standaards is gebeurd, zo worden genegeerd. Beter gezegd: De hele W3C werd de afgelopen jaren steeds meer genegeerd.
De WhatWG heeft dat goed begrepen: De markt heeft altijd gelijk. De markt is mogelijk best bereid <video> gebruiken, maar wil ook <center> en <font>, dus heeft HTML5 <center> en <font>. Als je deze tags wilt afschaffen zal je eerst alternatieven moeten verzinnen die door de markt acceptabel geacht worden. Pas je dat gedaan hebt en het gebruik van <center> en <font> af begint te nemen kan je overwegen ze uit toekomstige standaarden weg te laten.
[Reactie gewijzigd door dmantione op zaterdag 4 juli 2009 20:04]
Nee, dat ben ik niet met je eens. Ik kan je bijvoorbeeld vertellen dat veel webontwikkelaars <center> gebruiken omdat ze dan ook Links kunnen ondersteunen, ondersteuning van CSS is erg moeilijk in tekstgebaseerde browsers. Volgens de W3C-logica is dat geen probleem want Links zal het stijlblad negeren en toont toch de inhoud, maar ondertussen zitten Links-gebruikers wel met een site die er niet uitziet. Google ziet er perfect uit in Links, dus mogelijk was het ook voor Google een argument.
Dit soort praktische afwegingen zitten achter veel beslissingen, en ik ben het met je eens dat IE vaak een reden is om pragmatische oplossingen te kiezen. Het is echter verre van de enige reden waarom "transitional" nog altijd zo aloverheersend is.
Dit soort praktische afwegingen zitten achter veel beslissingen, en ik ben het met je eens dat IE vaak een reden is om pragmatische oplossingen te kiezen. Het is echter verre van de enige reden waarom "transitional" nog altijd zo aloverheersend is.
[Reactie gewijzigd door dmantione op zaterdag 4 juli 2009 22:27]
Maar alleen het center-element kan dan een voordeel bieden, waarbij de tekst-gebaseerde browser (welke het ook zijn moge) ook zou kunnen kiezen voor een oplossing waarbij de text-align regel wel correct afgehandeld wordt.
Alle overige regels t.b.v. de layout van de website worden toch al niet gesnapt/kunnen niet weergegeven worden in de tekst-interface en het kunnen centreren van de tekst maakt dan ook al niet uit.
Dat je daar mogelijk een probleem van maakt, dat is een keus van jouw of de website bouwer - maar om hiervoor een standaard aan te passen.
Bij HTML5 is het font-element dan ook gewoon deprecated voor websiteontwikkelaars, maar ivm backwards compatibility zijn browserfabrikanten weer wel "verplicht" om dit element (en alle andere depricated elementen) te ondersteungen - volgens die zelfde HTML5-standaard dus...
Alle overige regels t.b.v. de layout van de website worden toch al niet gesnapt/kunnen niet weergegeven worden in de tekst-interface en het kunnen centreren van de tekst maakt dan ook al niet uit.
Dat je daar mogelijk een probleem van maakt, dat is een keus van jouw of de website bouwer - maar om hiervoor een standaard aan te passen.
Bij HTML5 is het font-element dan ook gewoon deprecated voor websiteontwikkelaars, maar ivm backwards compatibility zijn browserfabrikanten weer wel "verplicht" om dit element (en alle andere depricated elementen) te ondersteungen - volgens die zelfde HTML5-standaard dus...
Onderbouw deze onzinne actie maar even met jouw begrip van "veel webontwikkelaars".Ik kan je bijvoorbeeld vertellen dat veel webontwikkelaars <center> gebruiken omdat ze dan ook Links kunnen ondersteunen, ondersteuning van CSS is erg moeilijk in tekstgebaseerde browsers.
Het schikbarend kleine deel van de webdevelopers die ook daadwerkelijk weet dat Links bestaat daargelaten, Links is een vreemde eend in de bijt. In tegenstelling tot Lynx doet het aan rudementaire formatting (iets wat je in een text browser niet zou moeten willen) en anderzijds is het allemaal zo karig mogelijk gehouden. Slecht voorbeeld voor het wel/niet willen optimaliseren voor een margebrowser -de typische gebruiker weet donders goed dat de ervaring van een site niet optimaal zal zijn.
Bij Google ligt het redelijk pragmatisch: het werkt en het is compact. Mensen hebben vaak genoeg een voorbeeld gemaakt van de Google frontpage die de standards compliance benaderde, maar dat kwam altijd uit op veel meer bytes -iets wat bij een "redelijk vaak" bezochte site als Google erg doorslaggevend kan zijn. Hoe het er uit ziet in Links heeft daar niets mee te maken.
En wie is de markt? Niet het kleine bedrijfje dat graag met state-of-the-art werkt blijkbaar. Ik zou als webdeveloper niets liever willen dan een XHTML-variant (of dat XHTML 2 is of niet, daar gaat het niet om) met alle XML-fijnheden, die gemaakt is voor het web van nu, niet voor het web van 1998. Die backwards compatibility interesseert mij als devver erg weinig; veelal werken we toch aan nieuwe projecten, en oude projecten kun je vaak prima met XSLT naar iets anders omzetten (MITS het oude project met XHTML was opgemaakt!)De WhatWG heeft dat goed begrepen: De markt heeft altijd gelijk.
Als de markt gedomineerd wordt door logge bedrijven die uit "kostenoverwegingen" maar constant blijven hangen in oude zut, dan zie ik voorlopig nog geen echte vooruitgang voor webtech.
De WHATWG/W3C had gewoon een enabler kunnen zijn voor vooruitstrevende techniek. Nu, na ruim 10 jaar HTML4, was een prima moment geweest om eens een grote opruiming te houden. In plaats daarvan komen ze met HTML5
Jammer van al die geocities en lycos websites die juist gered waren van de ondergang. Het merendeel is gebaseerd op de een van de eerste hmtl standaarden. Dat houdt toch in dat die sites niet meer (goed) werken in de nieuwe browsers? Of komt er nog een soort backward compability in browsers die de oude sites kan tonen?
In de HTML standaard geeft de server al sinds jaar en dag aan de browser de gebruikte HTML-versie door. Tot nu toe hebben browsers zich daar altijd wat van aangetrokken. Jouw vraag zou dus eerder moeten zijn: "gaat dat nu verdwijnen" waarbij het antwoord waarschijnlijk "nee" zal zijn.
Dat gebeurt dus niet, het enige dat er doorgegeven wordt, dat is het feit dat men text/html en/of application/xhtml ondersteund wordt.
Welke versie precies dat wordt niet doorgegeven, en aangezien HTML2,3.2,4 en 5 gewoon uitbreidingen op de eerdere standaarden zijn (in elk geval voor de user agent) hoeft dat ook niet...
Welke versie precies dat wordt niet doorgegeven, en aangezien HTML2,3.2,4 en 5 gewoon uitbreidingen op de eerdere standaarden zijn (in elk geval voor de user agent) hoeft dat ook niet...
Er natuurlijk wel het doctype, maar dat mechanisme wordt in HTML5 opgeblazen omdat het doctype voortaan altijd "html" is, je kunt dus alleen eerdere versies betrouwbaar detecteren. Een mijns inziens riskante beslissing.
Aangezien men de standaard zodanig specificeerd dat zaken die in het verleden toegestaan waren voor websitebouwers, altijd ondersteund moeten worden door de user agent (browser) is het loslaten van de versie-switch dus niet direct een groot probleem.
In de praktijk is het ook haast onmogelijk om nog een onderscheid te maken tussen de verschillende HTML-versies omdat browsers dit in het verleden nooit gedaan hebben. Er zijn dus plenty HTML4 Strict documenten met HTML4 Transitional inhoud en zelfs met proprietaire inhoud.
Mocht er in de toekomst ooit toch behoefte zijn aan een nieuwe versie, dan kan men het doctype gewoon weer introduceren - persoonlijk schat ik echter in dat de kans dat die switch nodig is echter zeer laag in.
Waarbij de oplossing van HTML5 er ook nog eens voor zorgt dat alle bestaande browsers de inhoud in standards-mode weergeven, en eigenlijk was dat het enige praktische nut van de complete DOCTYPEs: Het selecteren van de rendermodus en dan vooral de quirks mode voor oude documenten...
In de praktijk is het ook haast onmogelijk om nog een onderscheid te maken tussen de verschillende HTML-versies omdat browsers dit in het verleden nooit gedaan hebben. Er zijn dus plenty HTML4 Strict documenten met HTML4 Transitional inhoud en zelfs met proprietaire inhoud.
Mocht er in de toekomst ooit toch behoefte zijn aan een nieuwe versie, dan kan men het doctype gewoon weer introduceren - persoonlijk schat ik echter in dat de kans dat die switch nodig is echter zeer laag in.
Waarbij de oplossing van HTML5 er ook nog eens voor zorgt dat alle bestaande browsers de inhoud in standards-mode weergeven, en eigenlijk was dat het enige praktische nut van de complete DOCTYPEs: Het selecteren van de rendermodus en dan vooral de quirks mode voor oude documenten...
Tja, het is nu alleen wachten op een Flash achtige applicatie voor SVG of <canvas>-gebeuren. Ik ga zelf iig niet aan de slag in JavaScript. Ik zou dan nog liever Flash of Silverlight gebruiken.
Als ik een simpele animatie wil maken wil ik niet meteen aan de slag gaan met Javascript of CSS stylesheets. Gewoon animeren en vervolgens van mij part code generation door de tool.
Als ik een simpele animatie wil maken wil ik niet meteen aan de slag gaan met Javascript of CSS stylesheets. Gewoon animeren en vervolgens van mij part code generation door de tool.
[Reactie gewijzigd door alienfruit op zondag 5 juli 2009 00:13]
Dus met andere woorden omdat Apple in de eerste plaats te KOPPIG is, Opera te gierig, en Google te hebberig gaat het niet door.
Dat is wel erg kortzichtig:
- Apple: Zou jij iets willen laten vallen waar je veel tijd en geld in gestoken hebt en naar jou mening beter is?
- Opera: Je kunt het ook bij de licentie houders leggen, zij willen er veel geld voor hebben
- Google: De statement in dit artikel dat Google niet wil delen is erg kort door de bocht. In de mail word gesproken over niet kunnen ipv niet willen. Iets totaal anders. In dat licht zit het probleem eerder bij de licentie houders.
Vergeet Mozilla niet. Als non-profit-organisatie zijn zij ook niet bereid om te betalen voor *elke* Firefox/Gecko-installatie met h.264-support. Vind ik niet vreemd.
Dus de dwarsligger was m.n. Apple. Zou die ook gewoon Theora hebben ondersteund, dan had Microsoft het nakijken. Vroeg of laat zou ook MS wel bijdraaien.
De enige hoop is dat Firefox, Opera en (o.a.)Wikipedia gezamelijk genoeg overtuigingskracht hebben om van Theora dan maar gewoon een de-facto standaard te maken. Overigens is er al sinds tijden een oplossing voor browsers die geen <video /> met Theora ondersteunen: in dat geval wordt automatisch een Java-applet gebruikt voor het weergeven van de Theora video.
Dus de dwarsligger was m.n. Apple. Zou die ook gewoon Theora hebben ondersteund, dan had Microsoft het nakijken. Vroeg of laat zou ook MS wel bijdraaien.
De enige hoop is dat Firefox, Opera en (o.a.)Wikipedia gezamelijk genoeg overtuigingskracht hebben om van Theora dan maar gewoon een de-facto standaard te maken. Overigens is er al sinds tijden een oplossing voor browsers die geen <video /> met Theora ondersteunen: in dat geval wordt automatisch een Java-applet gebruikt voor het weergeven van de Theora video.
Waarom zouden we Theora willen? Achterhaalde codec met achterhaalde prestaties.
Omdat we een geen zin hebben in het alsmaar blijven betalen voor licenties, gezeik met patenten en gedoe met standaarden. Video is nu net zo normaal geworden als afbeeldingen. Dan is het toch wel zo fijn als er een gestandaardiseerd formaat voor is.
Technisch gezien zijn JPEG en PNG ook achterhaald. Zou je daar graag ook het commerciele JPEG2000 voor in de plaats zien? En ondersteunt je browser dat? En je fotoviewer? En... ?
En Theora 1.1 doet het best aardig, zelfs vergeleken met h.264
Technisch gezien zijn JPEG en PNG ook achterhaald. Zou je daar graag ook het commerciele JPEG2000 voor in de plaats zien? En ondersteunt je browser dat? En je fotoviewer? En... ?
En Theora 1.1 doet het best aardig, zelfs vergeleken met h.264
Als je hier kijkt:
http://people.xiph.org/~greg/video/ytcompare/comparison.html
Dan valt dat blijkbaatr nog wel mee, is een vergelijking met de huidige youtube codec en Theora.
http://people.xiph.org/~greg/video/ytcompare/comparison.html
Dan valt dat blijkbaatr nog wel mee, is een vergelijking met de huidige youtube codec en Theora.
Apple? Vergeet Microsoft niet.
Apple heeft nog het fatsoen gehad om hun besluit te voorzien van een slap verhaaltje over potentiele inbreuk op patenten. Op zichzelf geen onzinnig argument, maar gezien Apple nooit vies is geweest van een settlement op zijn tijd en geen enkel probleem hebben met het feit dat de kernel van OS X van net zo'n riskante open source basis komt ...niet erg sterk allemaal.
Microsoft heeft daarentegen gewoon geen intentie gegeven uberhaubt iets te gaan doen met <video>. Dat is gezien het marktaandeel wat ze nu nog hebben redelijk funest.
Apple heeft nog het fatsoen gehad om hun besluit te voorzien van een slap verhaaltje over potentiele inbreuk op patenten. Op zichzelf geen onzinnig argument, maar gezien Apple nooit vies is geweest van een settlement op zijn tijd en geen enkel probleem hebben met het feit dat de kernel van OS X van net zo'n riskante open source basis komt ...niet erg sterk allemaal.
Microsoft heeft daarentegen gewoon geen intentie gegeven uberhaubt iets te gaan doen met <video>. Dat is gezien het marktaandeel wat ze nu nog hebben redelijk funest.
Waarom zou het me nou niet verbazen als Microsoft straks ineens met een compleet gratis Windows Media for Webbrowsers-licentie zou komen?
Gaat MS dan ook de Google business style overnemen? Mails en telefoontjes van gebruikers doorspitten om hen te overladen met 'gerichte' reclame? Laat dan maar zitten die gratis licentie. Maar als ze zichzelf blijven, laat MS gerust hun gang gaan.
Juist niet, we willen onze video's overal kunnen kijken en als MS zichzelf blijft, blijft het een gesloten spec en Windows-onlyMaar als ze zichzelf blijven, laat MS gerust hun gang gaan.
[Reactie gewijzigd door JanDM op zaterdag 4 juli 2009 20:04]
Maar WMV/WMA is geen gesloten spec en ook niet Windows only (Flip4Mac, ffmpeg). Je kan de specs zo opvragen bij MS. Implementatie licensie is niet gratis, maar dat is MPEG (1, 2, 4/H.264, mp3, aac, etc) ook niet.
Eindelijk kunnen we van de discussie HTML vs. XHTML afsluiten. Ik heb nooit begrepen wat XHTML toevoegt. Het is imo veel belangrijker om (X)HTML strict te gebruiken, dus zonder de depricated tags, vooral van wegen accessability. XHTML was vooral bedoelt om websites op minder krachtige apparaten te gebruiken doordat een XML parser vele male sneller is dan een SGML parser. De techniek heeft de standaard echter al ingehaald en is overbodig geworden. Gelukkig zijn ze al vanaf 2004 met de standaard bezig (W3C vond toen der tijd het voortzetten van de HTML standaard onzin, dit duurde tot 2007 toen ze eindelijk overstag gingen)
Maar de depricated tags moeten wel behouden blijven. Het internet is enorm groot, en de mensen die content publiceren hebben niet allemaal informatica gestudeerd. Iedereen moet een website kunnen maken. Misschien is de code dan niet helemaal top, het doet dan wel wat de bouwer voor ogen had. Daarnaast zie ik de term "depricated" meer als een waarschuwing: Bij de volgende versie kan het wel eens gedaan zijn met de ondersteuning.
Daarnaast depricated of niet, XHTML/HTML, transitional/strict... alle browser fabrikanten vinden het belangrijker dat zo veel mogelijk websites goed te zien zijn, anders wordt heel snel naar de browser fabrikant gewezen, ipv de website maker.
Al met al is 1 standaard voor het www toch een utopie.
Maar de depricated tags moeten wel behouden blijven. Het internet is enorm groot, en de mensen die content publiceren hebben niet allemaal informatica gestudeerd. Iedereen moet een website kunnen maken. Misschien is de code dan niet helemaal top, het doet dan wel wat de bouwer voor ogen had. Daarnaast zie ik de term "depricated" meer als een waarschuwing: Bij de volgende versie kan het wel eens gedaan zijn met de ondersteuning.
Daarnaast depricated of niet, XHTML/HTML, transitional/strict... alle browser fabrikanten vinden het belangrijker dat zo veel mogelijk websites goed te zien zijn, anders wordt heel snel naar de browser fabrikant gewezen, ipv de website maker.
Al met al is 1 standaard voor het www toch een utopie.
Belangrijker nog: een browser dient vandaag content te kunnen weergeven die iemand 10 jaar geleden gepubliceerd heeft (toen die tags nog niet depreciated waren), dat noemen ze digitale duurzaamheid. Om die reden moet een serieuze standaard voor een document reader backward compatible zijn. Een werkgroep die een "standaard" produceert die dat uitsluit heeft volgens mij een dosis realiteitszin nodig. Ik ben blij dat ze xhtml-2 hebben laten vallen.Maar de depreciated tags moeten wel behouden blijven. Het internet is enorm groot, en de mensen die content publiceren hebben niet allemaal informatica gestudeerd.
[Reactie gewijzigd door berend_engelbrecht op zaterdag 4 juli 2009 19:18]
Waarom moet de standaard backward compatible zijn? Dat de document reader backward compatible is, sure. Maar een nieuwe standaard hoeft niet specifiek backward compatible te zijn lijkt mij. Je hebt namelijk tegenwoordig van die mooie <!DOCTYPE tags aan het begin van de meeste documenten, waarmee je precies aan kan geven welke standaard je document gebruikt. Als je die verplicht maakt voor de standaard is het totaal geen probleem om alle backward compatible meuk te laten vallen. Je kijkt dan simpelweg naar wat voor document het is en aan de hand daarvan parse je dit op een bepaalde manier. De enige manier waarop het problemen veroorzaakt is als je een document wat gebruikt maakt van een oude standaard simpel retagged naar de nieuwe standaard zonder de rest van je document aan te passen... Maarja, dan vraag je imo ook om problemen.
Het geheel lijkt me meer een gevalletje van "incremental vs. radical", een dicussie die af en toe ook wel eens langskomt bij KDE/Gnome. HTML5 is een doorontwikkeling van HTML5 en voegt daar maar kleine dingetjes aan toe. Een "incremental" update dus, terwijl XHTML2 alles overhoop wordt gegooid, een "radical" update. Soms is de laatste gewoon nodig voor vooruitgang, omdat je een bepaald iets maar zover kunt verbeteren met kleine wijzigingen. Radicale structuur veranderingen zitten er niet in want die zijn te radicaal.
Al met al lijkt dit af en toe meer een politiek spelletje dan een keuze die gebaseerd op wat nou echt technisch goed is.
Het geheel lijkt me meer een gevalletje van "incremental vs. radical", een dicussie die af en toe ook wel eens langskomt bij KDE/Gnome. HTML5 is een doorontwikkeling van HTML5 en voegt daar maar kleine dingetjes aan toe. Een "incremental" update dus, terwijl XHTML2 alles overhoop wordt gegooid, een "radical" update. Soms is de laatste gewoon nodig voor vooruitgang, omdat je een bepaald iets maar zover kunt verbeteren met kleine wijzigingen. Radicale structuur veranderingen zitten er niet in want die zijn te radicaal.
Al met al lijkt dit af en toe meer een politiek spelletje dan een keuze die gebaseerd op wat nou echt technisch goed is.
Ik zie het al helemaal voor me, alle browser fabrikanten gaan unaniem mee in de radicale variant en ondersteunen ook XHTML 2. Wel jammer dat je dan iedereen ineens hoort dat de download ineens 5MB groter is geworden en je telefoon na een update nog maar 1 webpagina per minuut weergeeft. oid.
In een bedrijfsomgeving waarbij alle variabelen bekend zijn kan je zo'n scenario uitvoeren. Het internet is echter een organisch geheel en volgt niet specifiek een standaard. Door een tweede standaard te gebruiken die dusdanig anders is zal je altijd een twee strijd houden tussen de standaards. Als ik een browser zou maken zou ik echt niet twee standaarden willen ondersteunen. Dat was ook de reden denk ik, dat WHATWG aan HTML 5 was begonnen (o.a. Apple, Mozilla en Opera. Microsoft misschien niet, maar die ondersteunen XHTML 1 toch al niet.)
> Al met al lijkt dit af en toe meer een politiek spelletje dan een keuze die gebaseerd op
> wat nou echt technisch goed is.
Wat technisch goed is wordt bepaald door de gebruiker. Tot nu toe is het overgrote deel van de gebruiker prima te vrede met wat hij/zij op internet ziet.
In een bedrijfsomgeving waarbij alle variabelen bekend zijn kan je zo'n scenario uitvoeren. Het internet is echter een organisch geheel en volgt niet specifiek een standaard. Door een tweede standaard te gebruiken die dusdanig anders is zal je altijd een twee strijd houden tussen de standaards. Als ik een browser zou maken zou ik echt niet twee standaarden willen ondersteunen. Dat was ook de reden denk ik, dat WHATWG aan HTML 5 was begonnen (o.a. Apple, Mozilla en Opera. Microsoft misschien niet, maar die ondersteunen XHTML 1 toch al niet.)
> Al met al lijkt dit af en toe meer een politiek spelletje dan een keuze die gebaseerd op
> wat nou echt technisch goed is.
Wat technisch goed is wordt bepaald door de gebruiker. Tot nu toe is het overgrote deel van de gebruiker prima te vrede met wat hij/zij op internet ziet.
Hoe kom je daarbij?? Een XML-parser is juist *VEEL* eenvoudiger en sneller dan het SGML-gedrocht van HTML. Daarnaast heeft elke hedendaagse browser al een XML-parser. Het renderwerk is voor een groot deel met CSS op te lossen. De extra inspanning van XHTML 2 zou voor browserfabrikanten echt wel minimaal zijn.Ik zie het al helemaal voor me, alle browser fabrikanten gaan unaniem mee in de radicale variant en ondersteunen ook XHTML 2. Wel jammer dat je dan iedereen ineens hoort dat de download ineens 5MB groter is geworden en je telefoon na een update nog maar 1 webpagina per minuut weergeeft. oid.
Dat is nu net de keuze die bij HTML5 gemaakt is - de specificatie is opgesplitst in twee delen, één voor de User Agent (browser) en 1 voor de HTML-ontwerper.Waarom moet de standaard backward compatible zijn? Dat de document reader backward compatible is, sure. Maar een nieuwe standaard hoeft niet specifiek backward compatible te zijn lijkt mij.
Door de specificatie op deze manier op te splitsen komen er als het waren duidelijke regels voor de UA, die een einde kunnen maken aan alle onduidelijkheden op dat gebied. In de regels voor de UA worden dan ook alle elementen/atributen gespecificeerd die volgens HTML4 depricated zijn, met als gevolg dat er volgens HTML5 wel duidelijkheid komt over het weergeven van deze markup.
In het deel voor de HTML-ontwerper komen deze elementen niet terug en de ontwerper wordt ook geacht deze niet meer te gebruiken als hij/zij een valid HTML5-document maakt...
Het probleem is dat, wat technisch goed (het beste is) inderdaad door politiek geblokkeerd kan worden - in dit geval komt dat vooral omdat een bepaalde (enigszins monopolistische partij) het vertikte om XHTML in haar browser te ondersteunen - uiteindelijk is er toen door diverse andere browserfabrikanten besloten om via een meer compatible upgrade-pad toch tot een nieuwe HTML-standaard te komen.Al met al lijkt dit af en toe meer een politiek spelletje dan een keuze die gebaseerd op wat nou echt technisch goed is.
Door bovenstaande splitsing toe te passen heeft men toch nog enige netheid in het geheel gebracht, maar een schoonheidsprijs voor een perfecte standaard zou ik het niet willen geven. Maar goed, het is nu eenmaal niet anders en zolans nog niet alle browsers de slag naar XHTML maken is dit het beste wat we er van kunnen maken...
Je kan dan toch gewoon de oude variant van de browser engine activeren als die doctype wordt gebruikt? En bij HTML5 content gewoon de nieuwe variant? Ik zie het probleem niet echt.
Precies. Bovendien blijft er toch veel overlap, dus de browsers worden er echt niet 2x zo groot van qua download.
Browsers ondersteunen meerdere standaarden. Afhankelijk van je doctype kiest de browser hoe hij parst. Als je niet de juiste doctype meegeeft, wordt je document gewoon anders geïnterpreteerd (meestal 'quirks mode' genoemd). Die oude krokodillen blijven dus werken, maar niet zo snel, want meer werk om te parsen (achterhalen wat de developer bedoelt met zijn onlogische nonsens). Ondertussen genieten mensen die zich wél iets aantrekken van standaarden van de parsesnelheid die een strikte standaard biedt, en de garantie dat je pagina correct wordt weergegeven op browsers die de standaard ondersteunen.
Ik snap aan de ene kant het probleem wel van Mozilla en Opera, die willen (kunnen) namelijk niet de licentiekosten die nodig zijn voor elke installatie als er voor H.264 wordt gekozen. (Voor alle duidelijkheid, die kosten zijn $0,20 per installatie.)
Aan de andere kant, waarom moet er nou weer voor een non-standaard codec worden gekozen. Met non-standaard bedoel ik dan niet dat hij niet gestandaardiseerd is, maar dat het niet een codec is die veel gebruikt wordt. H.264 en MPEG-2 zijn op dit moment de meest gebruikte codecs, en ja, daar zitten helaas licentiekosten aan. Maar als die codecs buiten de browser liggen, is dat toch geen probleem? Zo goed als iedere Windows-installatie heeft wel een MPEG-codec, en tegenwoordig is het ook niet moeilijk om aan een H.264-codec te komen. Het lijkt me dat dat bij andere OS'en ook het geval is.
Aan de andere kant, waarom moet er nou weer voor een non-standaard codec worden gekozen. Met non-standaard bedoel ik dan niet dat hij niet gestandaardiseerd is, maar dat het niet een codec is die veel gebruikt wordt. H.264 en MPEG-2 zijn op dit moment de meest gebruikte codecs, en ja, daar zitten helaas licentiekosten aan. Maar als die codecs buiten de browser liggen, is dat toch geen probleem? Zo goed als iedere Windows-installatie heeft wel een MPEG-codec, en tegenwoordig is het ook niet moeilijk om aan een H.264-codec te komen. Het lijkt me dat dat bij andere OS'en ook het geval is.
jouw oplossing is dus feitelijk, elke gebruiker die zijn browser installeert te vertellen, ja nu kan je surfen maar als je ook filmpjes wil kijken moet je maar rond zoeken naar een plek om iets genaamd H.264 ondersteuning te downloaden?
Daarnaast er zijn patenten aan verbonden, aan deze codec. Dan zie ik liever dat apple en google gewoon ipv te klagen over robuustheid en de ander die niet eens een reden geeft. Hun inspanningen eens bundelen en een FOSS codec maken, of die dan theora moet heten zal me een zorg zijn.
overigens ben ik pas op dat punt bereid iets te ondersteunen dat niet backwards compatible is.
Daarnaast er zijn patenten aan verbonden, aan deze codec. Dan zie ik liever dat apple en google gewoon ipv te klagen over robuustheid en de ander die niet eens een reden geeft. Hun inspanningen eens bundelen en een FOSS codec maken, of die dan theora moet heten zal me een zorg zijn.
overigens ben ik pas op dat punt bereid iets te ondersteunen dat niet backwards compatible is.
Als je zo redeneert dan zou je dus ook geen SVG-ondersteuning in de browser nodig hebben. Zo vaak wordt dat toch niet gebruikt?Aan de andere kant, waarom moet er nou weer voor een non-standaard codec worden gekozen. Met non-standaard bedoel ik dan niet dat hij niet gestandaardiseerd is, maar dat het niet een codec is die veel gebruikt wordt.
Zonder de mogelijkheid om iets te gebruiken zal het ook nooit een breed toegepaste worden - dat geldt ook voor Ogg Theora, zodra er browsers komen die het gebruik er van mogelijk maken zal het breder gebruikt worden, maar als er geen enkele browser komt die het gebruik ervan mogelijk maakt...
Maar op die manier verplaats je het probleem naar de gebruiker, en dat is nu net iets dat Mozilla, Opera (en wellicht ook Google?) niet willen.Zo goed als iedere Windows-installatie heeft wel een MPEG-codec, en tegenwoordig is het ook niet moeilijk om aan een H.264-codec te komen. Het lijkt me dat dat bij andere OS'en ook het geval is.
Juist het meeleveren van de codec maakt het weer gemakkelijker voor de gebruiker - maar als je dan voor iedere download (van een gratis product) een aantal euro's aan licentie geld moet ophoesten, daar wordt je als leverancier niet vrolijk van. Google heeft dat probleem blijkbaar al opgelost (wellicht door een overeenkomst t.b.v. hun gebruik bij YouTube - maar die overeenkosmt geldt alleen voor Google Chrome en niet voor het open source Chromium project).
En kan je HTML 5 als XML schrijven?
Ja, dat kan. HTML5 wordt min of meer de erfgenaam van XHTML. Maar in plaats van een overgang van SGML naar XML is nu het idee dat de webontwikkelaar bepaalt wat hij het meest geschikt vindt.
Ja - er is een mogelijkheid om de HTML5 standaard te serialisen van en naar XML, zodat je daarna weer van de extra XML features gebruik kunt maken (denk aan namespaces en dergelijke).
Het serialisen van/naar XML is al vanaf het eerste begin onderdeel van de HTML5 standaard...
(overigens moet je de code alleen als XML versturen als je de code ook daadwerkelijk door een parser/serialiser haalt die voor de garantie zorgt dat je altijd 100% correcte XML code genereert. Mocht je dat niet willen of kunnen, gebruik dan de eigen serialisatie van HTML5 - die aan de browser kant zodanig gespecificeerd is dat eventuele fouten van de maker van het HTML-document voor 99.9% gladgestreken wordt zonder dat de gebruiker daar enige melding [denk aan de gele parse-error schermen bij XML fouten] van krijgt)
Het serialisen van/naar XML is al vanaf het eerste begin onderdeel van de HTML5 standaard...
(overigens moet je de code alleen als XML versturen als je de code ook daadwerkelijk door een parser/serialiser haalt die voor de garantie zorgt dat je altijd 100% correcte XML code genereert. Mocht je dat niet willen of kunnen, gebruik dan de eigen serialisatie van HTML5 - die aan de browser kant zodanig gespecificeerd is dat eventuele fouten van de maker van het HTML-document voor 99.9% gladgestreken wordt zonder dat de gebruiker daar enige melding [denk aan de gele parse-error schermen bij XML fouten] van krijgt)
waarom niet <video codec="theora" href="video.ogg"></video>? en dan alle codecs verplicht ondersteunen?
Nou, omdat men het over dat "verplicht ondersteunen" niet eens kon worden, zoals je kunt lezen. Wat je stelt was ongeveer het idee.
Dat is nu net het probleem - op dit moment kunnen de browserfabrikanten het niet eens worden over de codecs die minimaal ondersteund moeten worden.
De standaars is nu echter al zodanig opgezet dat je in 1 video-element meerdere source-elementen op kunt nemen, bijvoorbeeld:
[code]
<video width="800" height="600">
<source src='video.ogv' type='video/ogg; codecs="theora, vorbis"'>
<source src='video.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'>
</video>
[/code]
Met deze code kan de aanbieder van content dus browsers met Ogg Theora en H.264 bedienen - hierbij is er wel het nadeel dat'ie de video wel 2x zal moeten encoderen, maar dat kun je eventueel ook nog eens aan een programma op de server uitbesteden. Waarbij de encodering natuurlijk wel gecached moet worden of gelijk bij het opslaan van de bron ge-encodeerd moet worden...
De standaars is nu echter al zodanig opgezet dat je in 1 video-element meerdere source-elementen op kunt nemen, bijvoorbeeld:
[code]
<video width="800" height="600">
<source src='video.ogv' type='video/ogg; codecs="theora, vorbis"'>
<source src='video.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'>
</video>
[/code]
Met deze code kan de aanbieder van content dus browsers met Ogg Theora en H.264 bedienen - hierbij is er wel het nadeel dat'ie de video wel 2x zal moeten encoderen, maar dat kun je eventueel ook nog eens aan een programma op de server uitbesteden. Waarbij de encodering natuurlijk wel gecached moet worden of gelijk bij het opslaan van de bron ge-encodeerd moet worden...
Als ik even kritisch ga zijn op HTML5: Wat is de meerwaarde van meerdere source-tags gegeven dat we al HTTP content-negotiation hebben?
Hm, dat is inderdaad een erg interessant punt en voor een erg groot deel kan ik met je stelling meegaan. Zeker omdat je op die manier de HTML markup erg clean kan houden, je hoeft immers niet meerdere source elementen op te geven.
Aan de andere kant wordt er helaas niet erg goed gebruik gemaakt van de content negotiation - kijk maar eens in de gemiddelde header van een browser. Dat'ie image/gif, image/png en image/jpeg aan kan wordt niet door alle browsers goed aangegeven en dit geldt ook voor andere formaten die een browser weer kan geven.
Tel daarbij op dat je als auteur van een statische website niet direct gebruik kunt maken van content negotiation, dan kom je al snel bij bovenstaande oplossing uit. Waarbij volgens mij het ook nog eens mogelijk is om in zo'n video-element weer een ander element te embedden - men kan daarmee ook al enigszins bereiken wat meerdere source elementen mogelijk maakt alleen dan op een minder nette manier...
Aan de andere kant wordt er helaas niet erg goed gebruik gemaakt van de content negotiation - kijk maar eens in de gemiddelde header van een browser. Dat'ie image/gif, image/png en image/jpeg aan kan wordt niet door alle browsers goed aangegeven en dit geldt ook voor andere formaten die een browser weer kan geven.
Tel daarbij op dat je als auteur van een statische website niet direct gebruik kunt maken van content negotiation, dan kom je al snel bij bovenstaande oplossing uit. Waarbij volgens mij het ook nog eens mogelijk is om in zo'n video-element weer een ander element te embedden - men kan daarmee ook al enigszins bereiken wat meerdere source elementen mogelijk maakt alleen dan op een minder nette manier...
Daar heb je SMIL toch al voor?
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
