Erg, erg jammer. IMO slaan ze met HTML5 de plak behoorlijk mis: ALLE HTML4-legacy-meuk blijft behouden.
Legacy (deprecated) meuk als <font>, <center>, etc. is met HTML5 eruit gehaald.
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.
Eens, maar dat staat hier los van imho...
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.
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.
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
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 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...
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.
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.
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.
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.
[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.
[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...
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.
Onderbouw deze onzinne actie maar even met jouw begrip van "veel webontwikkelaars".
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.
De WhatWG heeft dat goed begrepen: De markt heeft altijd gelijk.
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!)
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
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
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.
10:11
16:26
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
