Html-werkgroep loost versienummer

De Whatwg, de werkgroep die het initiatief nam voor de ontwikkeling van html 5, stopt met het gebruik van versienummers. In plaats daarvan wordt html een levende standaard, stelt de Whatwg. Het W3C houdt nog wel versienummers aan.

De Whatwg, waaraan onder meer medewerkers van Apple, Mozilla en Opera deelnemen, begon de ontwikkeling van de html 5-standaard. De werkgroep nam het initiatief daartoe toen het W3C besloot om zich vooral op de ontwikkeling van xhtml te richten, een meer op xml gebaseerde variant van html.

De ontwikkeling van html 5 werd gestopt, waarop de Whatwg zijn kans greep. Toen het W3C in 2007 alsnog aankondigde een html 5-standaard te ontwikkelen, zette de Whatwg-werkgroep echter de ontwikkeling van een eigen html 5-variant door.

Inmiddels heeft het W3C het werk van de Whatwg in de html 5-specificatie opgenomen en werken beide organisaties samen aan de standaard, hoewel de Whatwg ook eigen functionaliteit ontwikkelde, die niet in de 'officiële' standaard werd opgenomen. Nu heeft de Whatwg echter besloten om het versienummer van html te laten vallen. Html moet een evoluerende standaard worden, die wordt aangepast als dat nodig is, vindt de Whatwg. Vanaf nu noemt de werkgroep de html 5-standaard gewoon 'html'.

De beslissing van de Whatwg komt kort nadat het W3C juist een logo voor de html 5-standaard voorstelde. Het consortium blijft wel versienummers geven aan de nieuwe standaard. Mogelijk duidt dit op een splitsing van het W3C en de Whatwg, aangezien laatstgenoemde nu breekt met het model van concepten en uiteindelijke versies. Ook experimentele en niet-definitieve technieken worden nu in de Whatwg-html-standaard opgenomen, terwijl die nog niet zijn te vinden in de nog in ontwikkeling zijnde W3C-html 5-standaard.

Dat kan lastig zijn voor ontwikkelaars, die niet weten of ze zich aan de 'levende' Whatwg-standaard of de genummerde W3C-standaard moeten houden. Een ander bezwaar tegen een standaard zonder versienummers is dat het moeilijk wordt om tags te wijzigen of uit te faseren. Het kan dan zijn dat webpagina's stoppen met werken of anders functioneren, omdat de standaard is gewijzigd. Browsers kunnen dan onmogelijk detecteren hoe de standaard eruit zag toen de webpagina werd geschreven; iets wat met versienummers wel mogelijk is. Overigens is het ook in de html 5-standaard niet verplicht om in de doctype aan te geven aan welke versie een pagina voldoet.

In de nieuwe html-standaard zijn onder meer wijzigingen in de syntax opgenomen. Zo is het niet meer nodig om een head- en body-element te gebruiken. Ook hoeven sommige elementen, zoals onderdelen van een lijst, niet meer te worden gesloten; dat was bij xhtml wel het geval. Daarnaast zijn er nieuwe element geïntroduceerd, zoals de audio-, video- en canvas-elementen. Met dat laatste element kan een leeg object worden aangemaakt, waarop met behulp van javascript kan worden getekend. Zo kunnen bijvoorbeeld games worden ontwikkeld.

Reacties (99)

[MrDummy]

Een levende HTML standaard dat langzaam tussendoor ontwikkelt? Ja, maar hoe reageren de browsers dan op? Microsoft update niet zo snel IE in vergelijking met Firefox, en zonder versie nummer kun je ook moeilijk aangeven hoe de browser moeten aanpassen.

Er moet ergens een duidelijke aanwijzing zijn zodat men weet dat browsers goed werken.
Browsers hebben zelf al versie nummers, dus hiermee weten we ook welke standaard ze ondersteunen.

En bovendien krijgt de levende html standaard vage richtlijnen als het door diverse mensen wordt gemaakt. En daardoor dreigt er een wortelstructuur te ontstaan als iedereen zijn gang gaat. Dat is erg vervelend voor ontwikkelaars die steeds dirty correcties moeten toepassen om op diverse browsers te kunnen werken. Echt idioot. Zo komt de html kracht niet goed tot zijn recht als iedereen niet samenwerken tot 1 echte standaard met vastgelegde afspraken.

Vroeger hebben we dat gezien dat het onplezierig is en storingen kan maken in pagina opbouw, maar gaan we weer nu nog een keer dom doen met de open standaard zonder versie nummer dus zonder enig richtlijn. Alle remmen los, zo lijkt het wel.

IE heeft al eerder beloofd zich netjes aan standaarden te houden, maar de idee om versienummer weg te vallen kunnen we moeilijk aan vastknopen vanaf welke versie browser je moet hebben om bepaalde code te kunnen werken? En denk je dat iedereen hun browser graag elke week upgrade? Nee. En zeker niet iedereen weet het. Men dacht dat browser zelf klaar is en dus niet bijgewerkt hoeft te worden.

En hoe maken we de boeken dan? Met levende HTML kun je geen boek mee maken, want die zal snel verouderd raken. Een boek kun je niet upgraden.

Ik ben dus van mening dat versie nummer wel moet blijven, alleen je meldt dat niet hardop met groot "5" logo. Dat is niet noodzakelijk. Kijk maar naar PHP en MySQL. Die hebben wel versie nummers, maar HTML zelf niet meer? Dat is zo raar.

[RobertMe]

Kun je me dan eens uitleggen wat het nut van versienummers is bij HTML? Ik denk dat er voldoende sites zijn met een HTML 4 doctype, maar wel <video>, <audio>, <canvas> of whatever gebruiken. Een browser trekt zich 0,0 aan van het doctype (daarom is al eerder bij HTML5 het doctype aangepast naar <!DOCTYPE html>, zonder versienummer). Of de browser ondersteund een tag en het werkt, of de browser ondersteund het niet en het werkt dus niet.

En bovendien krijgt de levende html standaard vage richtlijnen als het door diverse mensen wordt gemaakt.

Er zijn maar twee autoriteiten op dit gebied, het W3C en de WHATWG, en het W3C neemt grotendeels alles over van de WHATWG. Het is echt niet zo dat elke gek nu z'n eigen standaard kan maken. En als Opera, Mozilla en Apple (en Google?) het binnen de WHATWG ergens over eens worden zijn er 4 van de 5 grote browsers die achter dat stuk standaard staan, voor MS is het dan slikken of stikken, waarmee het waarschijnlijk gewoon slikken word.

maar gaan we weer nu nog een keer dom doen met de open standaard zonder versie nummer dus zonder enig richtlijn

Dan word er nu dus ook gek gedaan? Delen van standaarden zijn al geïmplementeerd voordat ze af zijn en er nog flink aan dat deel van de standaard word gesleuteld. Andere delen zijn wel in zoverre af, maar versie 5 van de standaard is nog steeds niet af. Dan is er met of zonder versienummer dus echt geen verschil.

vanaf welke versie browser je moet hebben om bepaalde code te kunnen werken

Waarom wil je de browser versie weten om aan de hand daarvan de ondersteuning te bekijken? Browser sniffing is op z'n minst gezegd vies. En wat is het voordeel ervan? Als het om de semantiek gaat kun je met CSS de tags wel goed renderen (section { display: block; } en je ziet echt geen verschil tussen een browser die het wel en niet ondersteund). Andere tags zijn er juist weer op gemaakt om backwards compatible te zijn, HTML tussen <video> en </video> word door een browser die het ondersteund genegeerd (op <source/> na natuurlijk). Waardoor een browser die <video> niet ondersteund gewoon de HTML tussen de tags laat zien.

[Peter]

Dit veranderd natuurlijk helemaal niets, sterker nog, sinds dit besluit in 2009 is genomen (dit heeft weinig te maken met het HTML5 logo van het W3C) heeft de WHATWG eigenlijk continu een dergelijke werkwijze aangehouden. Het cijfertje is nu enkel weggehaald, wat de werkwijze van 2010 concludeert.

De specificatie bijgehouden door het W3C verschilt al tijden van de WHATWG versie. Zo zijn bijvoorbeekd timed tracks en het device element niet opgenomen in de versie van de eerstgenoemde. Uiteindelijk zit er maar zeer weinig in de W3C versie wat niet in de WHATWG versie zit, dus HTML zal altijd leading blijven. CSS heeft aangetoond dat het werken met modules een zeer flexibel en stabiel resultaat oplevert, waarom zou HTML niet hetzelfde kunnen?

[jvdmeer]

Na alle negatieve die ik hier lees, moet ik zeggen dat ik het een best logische stap vindt. De overgang van HTML3 -> HTML5 heeft 13 jaar gekost. Dat is in deze wereld erg lang.
En nu, terwijl HTML5 nog niet eens een echte standaard is, worden de nieuwe tags al bijna jaren ondersteunt door de verschillende browsers.

Feitelijk remt nummering de ontwikkeling. Als het strict gevolgd zou worden, kunnen de browserbouwers pas de specificatie volgen als het versienummer definitef is.
Terwijl je in praktijk ziet dat de bouwers vooruitwerken richting en bepaalde versie. Gevolg is dat zolang versie 5 niet definitief is, de "standaard" al wordt ondersteunt. Gevolg is dat de HTML na 4 eigenlijk al evolueert.
De organisatie kondigt nieuwe features aan, de browsers gaan ze ondersteunen terwijl de standaard nog niet uit is.

Voorwaarde hierbij is natuurlijk wel dat de basisprincipes van HTML niet overboord gaan en bestaande tags niet van werking veranderen. Daarnaast moeten nieuwe tags zo gekozen worden dat bij onbekendheid geen onverwachte effecten optreden. (zie het verhaaltje over de (no)script-tag van Roland684, vrijdag 21 januari 2011 18:39)

[TDeK]

Ik weet niet of dit wel de juiste weg is. We spreken wel vaker de moeilijkheden die het bekijken van een oude website met zich meebrengt; ik acht de kans dat sommige gegevens nu wel eens helemaal ontoegankelijk kunnen worden. Kijk naar XHTML 1.0 Strict, daar zijn een aantal elementen deprecated (vb. iframe) die in andere/vorige specs nog wel bestonden. Mocht HTML een rollende spec worden, wie is er dan verantwoordelijk als een bestaande website na een browserupgrade ineens niet meer werkt?
Het web is nou ook weer niet zo dynamisch (niet alle websites hebben een dedicated webteam erachter zitten).

[Roland684]

Nou is html natuurlijk wel een standaard die flexibel en vergevend is. Je kunt in een tag paramaters opgeven die bij die tag horen. Kent een browser de tag niet, mag hij doen alsof hij er niet is.
"<c foo=bar>hello world</c>" is valide html. Geen html1, 2, 3, 4 of 5, maar wel html en elke browser die deze c-tag niet kent zal "hello" afbeelden. Kent hij de tag wel, dan kan hij hem verwerken en hoeft de "hello" niet af te beelden (mag wel, maar dat zal liggen aan wat de c-tag betekent).
En als morgen de b-tag wordt afgeschaft, kunnen we geen tekst meer vet drukken (conder CSS), maar gaat er verder niets verloren

Daar zijn in het verleden wat fouten mee gemaakt, zo was er de <br> die geen einde had en is hetgeen tussen <script> en </script> juist bedoeld voor browsers die wel weten wat de script-tag is terwijl een browser die geen script kent de inhoud moet negeren (gevolg: elke browser moet de tag kennen, ook al kent hij geen javascript)
De noscript-tag is eigenlijk juist perfecte html: een browser die hem kent zal de tekst tussen de tags afbeelden terwijl browsers die de tag kennen, de tekst er tussen zullen negeren. Als dat vanaf het begin goed was nageleefd, zou mosiac nog gewoon bruikbaar zijn. Niet met de nieuwste snufjes, maar wel bruikbaar. Browsers mogen gewoon de tags die ze snappen gebruiken en de rest negeren.
Juist de script-tag is dus niet correct en zou eigenlijk als
<script javascript="write('hello wold');">Je browser ondersteund geen script</script>
geschreven moeten worden.
(de bezoeker vertellen dat zijn browser niet goed genoeg is, is overigens geen gracefull degradation maar wel bad practice)


Dat website na browser-updates niet meer werken is een probleem dat blijft. Dat los je ook niet op met een html5 specificatie. Je pagina's gaan misschien toch weer kapot als je upgrade naar een html6 browser. Voor PC's is er nog de uitweg door zowel een render-engine voor html4, 5 en 6 in 1 programma te vatten, maar op embedded systemen is dat vaak geen optie. En ook op PC's zal er een moment komen dat html5 support komt te vervallen.

Juist door te stellen dat je alleen html hebt ipv html 3.2, 4.0 en/of 5 kun je voorkomen (of dwing je af) dat de volgende versie geen dingen fundamenteel anders mag doen dan de vorige. Nu kunnen browserbouwers zeggen "met versie x+1 doen we het anders" en hebben ze in feite een vrijbrief om dingen kapot te maken. Makkelijk, dan hoef je niet voort te bouwen op wat er nu al is, ook al zijn er 999999999 webpagina's die er op vertrouwen.

html moet je niet zien als een complete browser, maar als de taal die van het internet. Niet iedereen zal alle woorden kennen, daar zullen webdesigners rekening mee moeten houden, maar er is wel 1 taal. Het wordt pas echt een ramp als we de gramatica blijven veranderen zoals met html3 en 4 is gebeurd.
(html5 zijn vooral wat nieuwe woorden, eigenlijk niet eens zo heel spannend.)

html5 wordt vast een betere standaard dan html4, maar een standaard die je maar blijft aanpassen is feitelijk geen standaard.

[Guru Evi]

Daarmee dat je je script in je script tag tussen comments (<!--) zet

[RM-rf]

en juist XHTML is een standaard die vrijwel geen browser echt juist kan renderen en effectief gezien is dat niet eens wenselijk voor een 'levend' web...
(eigenlijk is een MIME-type van 'application/XML+XHTMLnoodzakelijk en zonder die mimetype zou de browser eigenlijk niet mogen renderen. volgens de spec zelf)

XHTML is een goed voorbeeld van technocraten met heel algemene XML-data-ideeen die steeds verder afdreven van de daadwerkelijke toepassingen realiteit van het Web..
juist het opvatten van HTML als een 'levende' standaard waar zonder al te grote problemen ook nieuwe functionaliteiten/tags kunnen worden toegevoegd, zonder dat direkte 'oude' HTML zou moeten 'breken'...

dus ook standardruimte laten voor 'backwards' compatibiliteit (waar bv geen browser omheen komt, een reeele browser zal ook gewoon HTML 2.0 of HTML 3.2 goed moeten weergeven)

[Reactie gewijzigd door RM-rf op 22 juli 2024 14:59]

[CH4OS]

en juist XHTML is een standaard die vrijwel geen browser echt juist kan renderen en effectief gezien is dat niet eens wenselijk voor een 'levend' web...
(eigenlijk is een MIME-type van 'application/XML+XHTMLnoodzakelijk en zonder die mimetype zou de browser eigenlijk niet mogen renderen. volgens de spec zelf)

Wat ook alleen verplicht is bij xHTML 1.0 en xHTML 1.1 strict DTD's.

Dus nee, het is niet noodzakelijk er zijn namelijk ook nog de transitional en frameset DTD, maar dat weet jij ook wel...

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:59]

[shifter]

"vrijwel geen browser"? Onzin. Internet Explorer is de enige gangbare browser die daar tot op heden niet mee om kan gaan.

[Fuzzillogic]

Helaas is ook bijvoorbeeld Firefox niet in staat om echt goed met XHTML om te gaan. Gebruik wat namespaces en je hebt een probleem, zeker met contenteditable. Jammer, want XHTML is m.i. écht de beste oplossing, ipv HTML-pseudo-XML-meuk.

[shifter]

Zou je dat beter kunnen toelichten met voorbeelden? Het wezenlijke verschil dat een browser als Firefox op namespaces zou verliezen t.o.v. een browser die letterlijk geen iota kan met clean-cut XHTML daargelaten

[Ventieldopje]

Ook hoeven sommige tags, zoals elementen in een lijst, niet meer te worden gesloten.

Ik zie het forum over de slechtste programmeer voorbeelden al weer vol lopen, puur omdat programmeurs te lui zijn om die tags te sluiten (of een slechte editor gebruiken). Waarom maken ze dit soort keuzes en waarom niet gewoon aan de XML standaard houden

[Verwijderd]

Dit dacht ik dus ook al, ik krijg vaak kippenvel als ik zie wat voor slechte code er gebruikt wordt in tutorials en vaak ook op professionele websites. Ik begrijp goed dat het voor een lijst niet echt noodzakelijk is om een sluittag te hebben, omdat en lijstitem pas hoort te sluiten direct voor het volgende lijstitem, maar het lijkt mij beter als je consequent leert om alle tags te sluiten, daarmee voorkom je slordigheden in de rest van de code.

[pim]

Hangt echt helemaal af van het doel van de website.. Als de prioriteit ligt op snelheid, en de code wordt nooit meer bekeken door iemand, is slordig prima.

[Verwijderd]

Daar heb je gelijk in. Maar ik denk eigenlijk niet dat een browser een slordige website sneller op kan bouwen dan een (x)html valid website, een slordige website moet een browser namelijk eerst zelf nog corrigeren. Bovendien als je je aan de standaarden houdt, geeft dat meestal veel minder problemen met nieuwe browser versies, als deze de standaarden beter implementeren dan de vorige versies (denk aan IE).

[Verwijderd]

Niet netjes is niet per definitie slecht hoor. Als je een slimme parser hebt die efficiënt met die slordigheidjes als inconsistent gebruik van sluittags om kan gaan, dan kom je al een eind. Alleen dan moet die slordigheid wel een standaard zijn natuurlijk. Uiteindelijk is het belangrijkste dat het 'universeel' werkt! De gebruikers zien die slordigheid never nooit niet.

[mcdronkz]

Omdat dat op het web in de praktijk niet haalbaar blijkt. Neem voor de grap maar eens een kijkje in de geschiedenis van XHTML.

[Verwijderd]

Dit is vrijwel altijd te halen, het kost soms iets meer moeite, maar ik ben nog nooit een situatie tegen gekomen waar dat niet kon, en ik heb ondertussen al de nodige webapplicaties in elkaar gezet. De reden waarom dit echter vaak niet gebeurd is omdat dit meer tijd kost (en dus geld), en veel webdevelopers er alleen in geïnteresseerd zijn dat hun website werkt, en het maakt ze vaak weinig uit hoevel fouten deze bevatten.

[Roland684]

Maffe acties om van '<br>' '<br />' te maken en de center-tag uit te faseren en te vervangen door een constructie met stylesheets is gewoon dom. Je maakt het voor mensen complexer terwijl een computer het verschil niet ziet.

xhtml was een gedrocht waar alleen de die-hard IT-er van kon houden. Het succes van html is juist zijn toegankelijkheid en dat moet ook zo blijven.
Eenduidig (dat kan nog wel wat beter) en eenvoudig. (De basis van) html moet ieder mens ter wereld gewoon kunnen begrijpen. Het is wel een computertaal, maar wel een die gemaakt is om door mensen geschreven en begrepen te worden.

jaja, alles kan met xhtml, maar als 50% van de mensen het opgeven gaat het niet goed. Het inetrnet is voor iedereen, niet alleen voor de technisch onderlegde personen.

[Verwijderd]

<br> naar <br /> is zo'n ongelofelijk kleine aanpassing, denk niet dat ook maar iemand daar last van heb. De center tag heb je aan de ene kant wel gelijk in, maar aan de andere kant, óók met de 'normale' html was de bedoeling om in de html de inhoud te weergeven, en met een stylesheet de opmaak. Dat de center tag niet zo simpel te vervangen is met een css is eerder een gebrek in css dan in html, al ben ik het met je eens dat ze deze tag er beter in hadden kunnen laten zitten, of een beter alternatief hadden kunnen verzinnen.

Over het algemeen is xhtml niet heel veel meer dan html, maar dan alles correct afgesloten. Als jij een normale html pagina heb, is er zeer weinig wat je écht moet veranderen om deze pagina te laten valideren voor xhtml.

Bovendien, als je alle tags gewoon netjes afsluit, dan maakt dat je eigen code veel beter leesbaar, daarmee dus ook beter onderhoudbaar, en je voorkomt veel meer cross-browser problemen, waar een onderdeel eindigt heb je namelijk zelf al bepaald, dat hoeft de browser niet meer te verzinnen. Persoonlijk ben ik ook van mening dat elke webdeveloper éérst fatsoenlijk xhtml moet kunnen maken, voordat je de 'normale' html kan gaan gebruiken, je schrijft dan automatisch veel nettere code, en je zal minder snel tags weglaten, behalve als het echt volstrekt veilig is.

[ZpAz]

Imho vind ik het veel netter dat elke tag gesloten wordt (dmv zelf closing tags als <br /> e.d).

[Verwijderd]

de Whatwg-html-standaard

Whatwg is geen standaardisatieorganisatie.

[thegve]

Een standaard is toch gewoon een afspraak tussen de belangrijkste 'belanghebbenden'. Dus als een aantal grote organisaties vinden dat het een standaard is, is het een standaard.

[Zer0]

Dan is de Whatwg standaard geen (goede) standaard, aangezien de belangrijkste belanghebbenden er niet in zitten (namelijk de ontwikkelaars van web-content en de eindgebruikers)

[Peter]

Die zitten juist in grote getallen bij het WHATWG. Met name omdat de club een stuk toegankelijker is dan het W3C.

[J.J.J. Bokma]

Tja, dat is w3c ook al niet ;-) Er is wel een ISO-HTML standaard, en dat is vzwiw de enige standaard op dit gebied.

[Reactie gewijzigd door J.J.J. Bokma op 22 juli 2024 14:59]

[supersnathan94]

lekker handig. dan hebben we straks twee totaal verschillende webstandaarden die de ene browser maker wel inplementeerd (apple, mozilla en de opera dudes). en Microsoft houd het natuurlijk weer zakelijk en kiest voor de W3C variant

[Caelorum]

Ik denk dat in deze mozilla en webkit enzo ook voor de W3C variant zullen gaan. Zoals in het artikel is aangegeven is het weglaten van versienummers erg vervelend voor zowel ontwikkelaars als browserbouwers. Ik zie dan ook niet waarom Whatwg hier uberhaupt voor gekozen heeft.

[RM-rf]

WhatWG komt voort uit ontwikkelaars van Mozilla, Webkit en Opera... die juist het oneens waren met de richting van W3C:

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

[Blokker_1999]

Niet gestandaardiseerde tags zijn van allen tijde (wie herinnerd er zich de marquee tag bijvoorbeeld niet meer). Je kan dan stellen dat de standaarden van W3C een echte basis vormen voor compatibeliteit tussen alle browsers met het werk van dat whatwg als een preview van wat de toekomst bied.

En zelfs met de situatie van gisteren zie je hoe dynamisch de ontwikkeling van html is. Zo is html5 nog altijd geen afgewerkte standaard maar hebben de meeste browserbouwers al wel een deel van die specs in hun huidige of aankomende versies opgenomen (zoals de nu al zeer bekende video tag)

[Caelorum]

Wat mijn punt dan ook was, dat het zoals in het artikel al genoemd, niet meer te achterhalen is hoe een pagina moet worden gerenderd over een jaar of zelfs maar volgende maand of nog erger morgen.
Met de huidige methode kan je tenminste nog zeggen tegen de browser "jammer voor die nieuwe zooi, maar je rendert dit maar zoals het vorig jaar was bedoeld!".

[J.J.J. Bokma]

Onbekende elementen worden overgeslagen (dat was al zo), en de bekende elementen worden weergegeven zoals ze altijd weergegeven werden. Waarom zou je een p element of een h1 element ineens anders willen weergeven? Sterker, weergave (hoe het visueel er uit ziet) is iets wat via CSS geregeld wordt/zou moeten worden.

[Caelorum]

Totdat je de werking van een bijv een Table tag gaat wijzigen. Wat moet die browser dan doen?
Ik ben niet tegen nieuwe tags toevoegen buiten de standaard om, maar het is gewoon ronduit vervelend om niet zeker te weten hoe iets gerenderd gaat worden en of een browser uberhaupt nog wel iets gaat renderen.

Ik vind het persoonlijk ook erg vervelend dat ze de dtd eruit hebben gesloopt bij HTML5. Nu kan het nog wel, maar als ze dat bij bijv. HTML6 ook gaan doen. Wat moet de browser dan renderen? Moet die eerst de hele pagina gaan analyseren om te bepalen wat die moet doen? En wat als je met javascript het één en ander toevoegt? Gaat die browser dan switchen tussen HTML 5 en 6?

Het hele punt waarom we ooit standaarden kregen was omdat het anders een puinhoop werd. Zijn we er eindelijk een beetje vanaf, komt één of andere groep aanzetten dat ze het weer willen invoeren

Overigens staat mijn hele verhaal los van de scheiding tussen opmaak en opbouw.

[J.J.J. Bokma]

Waarom zou je de werking (wat is dat overigens) van een table element moeten wijzigen? Geef eens een concreet voorbeeld? Het klinkt nu te veel als "het voelt niet lekker, maar weet niet waarom". Ik zie namelijk geen enkel probleem (nog).

Verder was het idee van HTML altijd dat de browser erg vrij is in hoe dingen weergegeven worden. Bijvoorbeeld het p element zegt alleen: dit is een paragraaf. Hoe dat weergegeven wordt is helemaal niet aan HTML, maar aan CSS. En dan nog zijn er genoeg vrijheden.

Daarnaast zegt een DTD niks over werking, en volgens mij doet geen enkele browser daar iets mee. Is alleen nuttig voor validatie, en dat doen veel webbouwers toch al niet.

[Caelorum]

Verder was het idee van HTML altijd dat de browser erg vrij is in hoe dingen weergegeven worden. Bijvoorbeeld het p element zegt alleen: dit is een paragraaf. Hoe dat weergegeven wordt is helemaal niet aan HTML, maar aan CSS. En dan nog zijn er genoeg vrijheden.

Dat klopt en daar gaat het ook niet over.

Het klinkt zeker als "het voelt niet lekker". Dat komt omdat ze op deze manier teveel onzekerheden introduceren en eidenlijk geen enkel probleem oplossen.
Uit het artikel: "Html moet een evoluerende standaard worden, die wordt aangepast als dat nodig is, vindt de Whatwg.".
Waarom is het om dit te realiseren nodig om versienummers overboord te gooien? Kunnen ze niet gewoon zoals hieronder ergens genoemd versies a la 5.0.1 en 5.1.2 etc maken?

Het enigste dat ze hiermee bereiken is dat het vrijwel onmogelijk wordt een pagina te maken waarvan je weet dat het over 4 jaar nog steeds zo functioneert zoals het nu is.

Je hebt gelijk dat een DTD niets zegt over de werking, maar wel over hoe eht document moet worden opgebouwd. Daarnaast zegt een DTD in combinatie met de rest van de HTML tag, welke set van regels (dus functionaliteit) moeten worden toegepast door de browser.

[J.J.J. Bokma]

DTD zegt niks over hoe het document moet worden opgebouwd. Sterker, voor zo ver ik weet doet geen enkele browser er iets mee. Een DTD is net zo iets als BNF: het geeft aan welke elementen elkaar mogen bevatten, en welke attributen geldig zijn. Een browser raakt niet overstuur als er attributen zijn die niet in de DTD staan en ditto voor elementen. Dus als HTML 5 ineens 3 nieuwe elementen krijgt gebeurd er, zoals al vele jaren, niks. Je browser ontploft niet, raakt niet van streek, en geeft niet de pagina anders weer. Kortom, de pagina die je nu maakt werkt gewoon over 4 jaar nog prima. Misschien ziet ie er ietjes anders uit, maar dat is niets anders dan wat nu al het geval is.

Kortom, ik zie nog steeds geen enkel probleem.

[jurriaan]

Omdat er nog steeds tags worden toegevoegd die wel degelijk een vormgeving hebben en een gedefinieerde functionaliteit. Tags als preloader, audio en video en de nieuwe input types. Een vormgeving die niet zonder meer kan worden aangepast via css in veel gevallen.

Als ik een website html5 only maak (om wat voor reden dan ook) en ervan uitga dat de preloader een bepaalde werking heeft en dat de gebruiker een daarvoor geschikte visuele representatie krijgt. Dan houdt in dat de werking nooit meer gewijzigd mag worden, want er is geen manier waarop ik de browser kan vertellen welke functionaliteit ik verwacht.

Ander voorbeeld, momenteel bestaan er op het moment in html5 zowel een object, als een embed tag. Met min of meer dezelfde werking. De embed tag is nieuw en is niet dezelfde als men nu al gebruikt in html4, alhoewel die toen eigenlijk juist verwijderd was uit html. De nieuwe embed tag ondersteund echter niet dezelfde attributen als de orginele embed tag (http://lists.whatwg.org/p...010-September/000660.html). Hoe zou ik in een versieloze wereld aan de browser kunnen zeggen welke versie ik wil ? Of moet de browser extra handelingen gaan uitvoeren om aan de hand van de attributen te gaan gokken?
En ooit komt men erachter dat, hoe nobel het streven ook is om de huidige gewoontes niet te willen breken (pave the cowpath), veel van de huidige gewoontes juist zijn aangenomen om het in alle verschillende browsers te laten werken. De huidige gewoonten zijn dus niet perse juist, slechts noodzakelijk. En als ze daarachter komen zullen ze ook zien dat het echt nogal onnodig is om 2 tags te hebben die hetzelfde doen en hoogst waarschijnlijk embed weer verwijderen. Hoe weet de browser nu of in mijn code nou wel of geen embed tag mag staan?

Maar nu de tegenvraag. Wat is precies het probleem met wel een versie nummering aan te houden? Evoluerend en wel. Het is in ieder geval een extra zekerheid en duidelijkheid zowel richting ontwikkelaars als richting de browser.

[RM-rf]

@jurriaan; jouw voorbeeld zou in de voorgaande HTML versies dus probleemloos 'opgelost' zijn, die hebben wel een DTD mét een 'html-versie'... Dan rest slechts één vraagje, lost die aanwezigheid van een HTML-versionering jouw mogelijke problemen op?

Wat is precies het probleem met wel een versie nummering aan te houden?

Hét 'probleem' is vooral dat de moeite een theoretische 'oplossing-ergens-voor' in te bouwen in een specificatie, die echter in de realiteit _niet_blijkt te werken en dus _niet_ doet wat je er eigenlijk van zou willen, onzin zou zijn...

Prima _als_ je dus een effectieve wijze kunt maken om verschillende HTML-versies probeemloos te bedienen... maar, dingen als DTD op 'versie's van HTML zoals die tot nu toe bestaan losten dat niet op...
ndertussen zijn er wel volop andere oplossingen, die juistvrijwel altijd aan de gebruikerszijde ontwikkeld zijn en die wél zulke problemen gebruiksvriendelijk kunnen oplossen

[jurriaan]

Dat de browsers niks met de DTD doen is waar en ook een draak uit het verleden. Ik dacht dat het hele idee juist was dat soort dingen uit te wissen. Maar waarom niet gewoon <html version="6"> en dan afspreken dat browsers daar wel iets mee doen.

Een levende standaard zou betekenen dat je voor elk onderdeel apart zou moeten testen of de browser het ondersteund. Iets wat de komende jaren sowieso het geval zal zijn en zeker de adoptatie van html niet zal helpen. Een toekomst waarbij daarin geen enkele verbetering zal optreden zal alleen maar plug-ins helpen die een gestroomlijndere ontwikkeling bieden.

Ik denk zelf ook dat het voor browsers en vooral de grote bedrijven achter die browsers makkelijk gaat worden om onderdelen niet te ondersteunen en zo innovatie tegen te werken. Als Microsoft geen brood ziet in webworkers, waarom zou het die dan gaan ondersteunen. Met een gedefinieerde standaard kun je duidelijk afstrepen welke browser zich wel en niet aan de standaard houdt, maar een standaard waarbij constant onderdelen experimenteel zijn is er geen maatstaf. Webworkers, onderdeel van 'html' is overigens iets dat zich helemaal niet meer binnen de html afspeelt. Dit gaat over javascript. Zou het gebrek aan versies dan ook daar naartoe moeten worden doorgestrokken? Dat zou volgens mij iig een first zijn, een versieloze programmeer/scripttaal.

Ik geloof overigens helemaal niet in een splitsing. Ik denk dat whatwg gewoon de speeltuin wordt voor de ontwikkeling van html in het algemeen, vooral om de ontwikkeling draaiende te houden en het w3c niet weer naar xhtml2 te doen teruggrijpen maar sneller door te laten gaan naar nieuwe versies van html.

[RM-rf]

Maar waarom niet gewoon <html version="6"> en dan afspreken dat browsers daar wel iets mee doen.

Wàt wil je dan afspreken?

is nu net het probleem niet dat je helemaal niet kunt voorzien of en hoe eventueel gedrag van tags in toekomstige 'andere' HTML versies 'anders' zouden kunnen zijn en je dus helemaal niet vooraf weet of je juist wilt dat een oudere browser gewoon zn voorgaande gedrag aanhoud of de rendering geheel 'ophoudt'....?

Dé fouten van zulke 'strict' rendering zoals in XHTML is nu juist dat het vooral aanzet tot het gebruik van 'hacks' eromheen zoals bij Internet Explorer ... om alsnog 'oude' rendering af te dwingen, ondanks dat de content valide is...

Punt is nu net dat de eindgebruiker gewoon wil dat zn browser de voorhandende content weergeeft voor zover dit ondersteund wordt en HTML zélf blijkt ook verschrikkelijk robuust hierin...

net zoals bv Javascript en CSS welke ook veel probleemlozer functioneren ondanks dat er geen specifieke 'versionering' gebruikt wordt ...
Sterker nog, één van de belangrijke lessen voor Javascript-ontwikkelaars is dat ze moeten ophouden eerst de userAgent te sniffen en enkel op basis vaneen versienummer of useragentstring functies door te voeren, maar _juist_ direkt te testen op de aanwezigheidvan het betreffende object of functie ... Dátis de key naar crossbrowser én cross-versie-devving...


Ook dàt zou eerder een aanbeveling voor HTML moeten zijn, niet meer heel 'statisch' denken dat functionaliteiten enkel gekoppeld zijn aan een 'versie-nummer' ... maargewoonweg veel dynamischer as-is-rendering en het wrrken met fallback bij specifieke niet ondersteunde tags of attributen

[jurriaan]

ik wil dat ze afspreken zich aan de opgegeven versie/standaard te houden.. als html5 mij beloofd dat ik zelf attributen mag toevoegen aan een html tag, dan moet ik min of meer gegarandeerd hebben dat dat attribuut over 10 jaar niet opeens een andere betekenis/gevolg heeft. Juist versies zorgen ervoor dat je geen rekening hoeft te houden met onmogelijk te voorspellen wijzigingen die in de toekomst plaatsvinden.

Bij CSS is de versie minder van belang, maar voornamelijk doordat browsers claims gebruiken als "ondersteunt delen van css3" Tja.. mooie standaard dan.

Bij javascript is de versie echter wel degelijk van belang. De reden dat je in javascript niet naar een speciefieke userAgent moet kijken is omdat je daar vaak andere userAgents mee uitsluit. Juist dat zou niet nodig moeten zijn als er alleen naar versie zou worden gekeken en daar is dan ook weinig mis mee. De versie is van belang omdat javascript gewoon nog doorontwikkeld wordt. In de 1.x tak bijvoorbeeld met nieuwe syntax en Core objecten die echter slechts door een klein aantal browsers (met name firefox) worden ondersteund. Sommige daarvan zijn eigenlijk onontbeerlijk om serieus onderhoudbare canvas ria te gaan maken. Dingen als generators, iterators en E4X. Het is dus wel degelijk belangrijk welke versie van de javascript engine gebruikt wordt. Ik kan er nu (hopelijk) van uitgaan dat als de browser claimt een js engine te hebben die versie 1.6-1.99 ondersteund geen parser error geeft als ik var xml = <tag />; doe. Dat kan ik dus specifiek targeten. Browsers met een oudere versie kan je eventueel alternatieve syntax bieden of een melding. Javascript dat in versie 1.x is geschreven zal nooit door een versie 2 parser moeten worden afgehandeld. Een browser biedt of 2 versies van de engine, of biedt op een gegeven moment gewoon geen ondersteuning meer (onwaarschijnlijk).

Een voorbeeld van een soort levende standaard die wel versies heeft, wel werkt en al 10 jaar bestaat, is de oh zo verachte plugin structuur van flash/Actionscript/flex. Daarmee kan specifiek een versie van de taal worden gebruikt en weet 1 en dezelfde versie van de flashplayer welke virtual machine moet worden opgestart om de code af te handelen. Daardoor ondersteunt die speler nog steeds de content die 10 jaar geleden is gemaakt. En nog kun je die Actionscript 1 gebruiken om content te maken voor de flashplayer. Dit komt door de zekerheid die een ontwikkelaar heeft dat content gemaakt met versie X werkt zoals versie X ontworpen is.

Maar goed, terug naar html. Ik mag hopen dat de fallbacks, hoe elegant ook, alleen nodig zijn in een overgangsfase tussen html4 en html5. Gevolg van de oersoep aan tags en browsereigenaardidheden in de aanloopfase. Vanaf html5 kunnen we er toch eindelijk eens vanuitgaan dat alle browsers verwacht gedrag gaan tonen? ... pretty please

[Spockz]

@http://tweakers.net/react...=Posting&ParentID=4454588:
De reden dat er bij CSS wat minder problemen zijn omtrent het specificeren van een CSS versie is dat de wijzigingen in de CSS standaard zorgen voor een iets andere syntax en aantal extra properties + waarden. De traditie bij CSS is sowieso al dat als de engine een tag / statement niet snapt hij er niets mee doet. Vandaar is er geen zware nood om een versienummer aan de CSS te geven.

Op het moment dat de semantiek van bijv. de < operator verandert, of de semantiek van een property heb je een probleem. De browser weet dan niet meer wat de ontwikkelaar bedoelde want hij heeft geen idee van de versie waarin de ontwikkelaar de CSS wil laten interpreteren.

Het toevoegen van functionaliteit die al dan niet ondersteunt wordt is dus geen probleem bij de afwezigheid van versienummers. Het wijzigen van bestaande functionaliteit is dat dus wel.

Ditzelfde probleem steekt dus ook de kop op bij ongeversioneerde HTML. De ontwikkelaar gaat er op een bepaald moment van uit dat een element X op een bepaalde manier reageert. Vervolgens verandert er iets in de 'levendige' standaard en de browser gaat het opeens anders doen. Of erger nog, de ene browser hanteert nog het origineel, en een andere browser is al over naar de nieuwe semantiek. Dit maakt het dus erg lastig om een webpagina te ontwikkelen.

Juist het strak definiëren van een standaard en het vastleggen van de semantiek van elementen zorgt ervoor dat je je webpagina er zoveel mogelijk hetzelfde uit kan laten zien in verschillende browsers. Eindelijk hebben we het zover dat Microsoft zich aan de standaarden gaat houden en dan gaan we weer een flexibele standaard zoals we die voorheen ook al hadden tegemoet.

Ik snap dan ook niet dat er ontwikkelaars zijn die dit van harte steunen. Het is in feite een stap terug in de tijd. Ja, wellicht moet je met de huidige manier van werken langer wachten voordat er iets in de standaard zit. Maar dat is nog geen reden om versies maar geheel overboord te gooien.

[Reactie gewijzigd door Spockz op 22 juli 2024 14:59]

[RM-rf]

@Spockz... dan kun je vast reeele voorbeelden noemen waarin 'stricte' versienummers en bv verschillen tussen transitional en strict meer problemen oplossen in verschillende browsers, dan ze scheppen ?
Immers, de huidige HTML-versies hebben tot aan HTML5 ook zulke opties via DTD en doctype-definitities...

én, kun je die voorbeelden vinden van een Positieve werking van deze versienummers....?
welke weergave-probemen lost men _nu_ daarmee op, en zijn o reeel toepasbaar en bieden ook voordelen?

Daarentegen kan ik je volop voorbeelden noemen van precies het omgekeerde, bjvoorbeeld Juist de wijze waarop Explorer omgaat met stricte rendering en standaards-comliant doctype is dat je daardoor juist méér problemen krijgt qua backwards-compliance met oudere explorer versies én zelfs in de modernste explorer-versies functionaliteit verliest... waardoor een hoop devvers die een grote klantenkring hebben die voral op explorer zich baseren dus meestal kiezen óf heel bewust _niet_ standaards-compliant te werken óf via allerhande (twijfelachtige en af te raden) 'hacks' dit proberen te omgaan ...

Ik snap werkelijk niet waarom je juist niet inziet dat het FEIT dat dit probleem bij CSS niet bestaat _juist_ samenhangt met het hele concept dat je dus helemaal geen 'versie-nummering nodig hebt bij documentformaten die hooguit bepaalde data aan de eindgebruikers serveert en visueel en dynamisch toegankeljk maakt.
Het _is_ ook onmogelijk nu te gaan voorspellen hoe de huidige browser-ersies om zouden moeten gaan met toekomstige HTML-versies... wélke tags ze dan zouden moeten negeren of niet

Bv een puur dataverwerkingsformaat als XML die veelal ook systeeminterne Dataverwerkingsprocessen doorloopt heeft dat wél nodig , evenals de nodzaak dat bij een stuklopen van validatie niet wilt dat de client doorgaat met verwerking van deze gegevens (omdat ze dan niet meer integer zullen zijn, en het gevaar van doorlopende fouten erg groot is .. Voor zulke procesen voldoet nu eenmaal HTML ook helemaal niet, is daarvoor niet gemaakt en zal nooit voldoen > HTML != XML)

Stel je bv voor dat XHTML niet gewoon qua ontwikkeling na 1.1 en 1.2 modulair verder gecancelled werd, maar dat men met een XHTML2.0 doorgegaan was tot een recommendation (waarvoor wel een aanzet gegeven was, maar toen ontdekte men de ontzettende problemen qua backwards-compliance... juist dóór die vaste versionering van XHTML en de stricte validering ervan en welformedness).

Punt is nu net... dat XML-concept voldoet bij geautomatiseerde data-verwerking door data-procesen; maar heeft bij de dagelijkse realiteit voor gebruikers op het internet, waar deels een hoop gebruikers met verouderde browsers surfen of browser die niet geheel exact standards-compliant zijn, gewoonweg niet.
een ontwikkelaar die domweg zulke gebruikers gaat negeren kan niet voor serieuze klanten werken: leuk voor 'schrijfkamergeleerden' die allerhande XML-theorieen op HTML proberen, maar niet toepasbaar op de oncontroleerbaarheid en 'levendheid'van het web zélf.....

[Reactie gewijzigd door RM-rf op 22 juli 2024 14:59]

[Caelorum]

Dat de browsers niks met de DTD doen is waar en ook een draak uit het verleden.

http://msdn.microsoft.com...ry/ms535242(v=vs.85).aspx

use the !DOCTYPE declaration to specify the DTD a document conforms to, and to switch Internet Explorer 6 and later to standards-compliant mode.

Windows Internet Explorer 8 and later. The !DOCTYPE declaration helps determine the document compatibility mode of a Web page. The document compatibility mode of a Web page determines the level of conformance to industry standards, such as the Cascading Style Sheets, Level 2.1 (CSS2.1) and others. To enable the highest level of standards compliance, verify that your Web pages are rendered using the latest document compatibility mode available. For more information, see Defining Document Compatibility.

[Reactie gewijzigd door Caelorum op 22 juli 2024 14:59]

[Caelorum]

"Een DTD is net zo iets als BNF: het geeft aan welke elementen elkaar mogen bevatten, en welke attributen geldig zijn. "
Dus dan geeft het toch aan hoe de HTML moet zijn opgebouwd?

Maar het ging ook niet om dat de browser nu wel of niet de DTD gebruikt. Het gaat erom dat je zonder versies niet kunt garanderen dat iets nog werkt zoals het oorspronkelijk bedoeld was. Een browser gebruikt de opgegeven DTD wel degelijk om te bepalen welke versie HTML er is gegeven en dus welke set regels (die volgens de standaarden zijn gesteld) moet worden toegepast.

Maar zoals ik dus al eerder zei, je kan met deze voorgestelde dingen niet meer aangeven dat er met een oudere set regels rekening is gehouden. Op dit moment kan dat wellicht nog geen problemen geven, maar dat wil niet zeggen dat dat niet alsnog gaat gebeuren.
Met deze voorgestelde veranderingen creeren ze alleen nog maar meer onzekerheden terwijl het heel makkelijk anders kan zonder de in het artikel en door anderen in de comments genoemde vervelende bijwerkingen.

[RM-rf]

Een browser gebruikt de opgegeven DTD wel degelijk om te bepalen welke versie HTML er is gegeven en dus welke set regels (die volgens de standaarden zijn gesteld) moet worden toegepast.

dat zou eenvoudig te testen zijn door bv eens te kijken of, als je een HTML3.2 DTD gebruikt, je opeens functionaliteiten zou 'verliezen' en de browser opeens bepaalde tags niet meer zou interpreteren ...

test het eens, zou ik zeggen, en dan kunnen we ook stellen of je gelijk zou hebben en het gebruik van een 'oudere' DTD opeens een 'verlies' aan functionaliteit geeft... of dat dat juist _niet_ het geval is, en de DTD eigenlijk de meeste browsers 'scheiss-egal' is...
Een DTD verder niet functionaliteit 'vrijgeeft'.
hooguit gebruikt wordt om een quirky-mode te gebruien bij het rederen, met behoorlijke nadelen aangezien juist dat ook al leidde tot veel 'hacks' om bv bij explorer de DTD te laten 'negeren' (via de xml-doctype-definitie <?xml ... wat dan wel de pagina valideerde maarexplorer alsnogin quirksmode ging, wegens het vreemde gegeven dat die quirksmode eigenlijk handiger was bij het devven dan een 'valide' rendering als well-formed XHTML)

[Cronax]

Dit gebeurt inderdaad. Ik heb zo snel geen voorbeeld bij de hand maar er zijn inderdaad zaken die niet werken of anders reageren door andere DTD te gebruiken.

[Ramoonus]

alsof een browser kan ontploffen?

[RM-rf]

Wat dacht je van BLINK (uitgevonden overigens door dezelfde persoon die ook de Lynx-browser ontwikkelde, Lou Montulli http://en.wikipedia.org/wiki/Lou_Montulli)


echter, dat gebeurde allemaal vóór het W3C ontstond en het was juist de grond dat W3Cde HTML3.2 specificatie ontwikkelde toen er twee concurerrenede HTML3.0 specificaties voorlagen (van Netscape en van Microsoft)

[A4-tje]

ik denk dat ze meer evolutie willen krijgen door het zo te doen. alles wat slecht is overleeft niet en wat goed is wordt beter (of toegevoegd). op die manier moet alles in elkaar overvloeien en zijn er dus geen updates (=nieuw versienummer) meer.
maarja het nut is zoals in het artikel al staat een beetje ver te zoeken omdat het gewoon gewenst is.

[Bux666]

Dan houdt MS zich tenminste eens een keer aan een webstandaard!

[arjankoole]

Dan houdt MS zich tenminste eens een keer aan een webstandaard!

Ja, nog even en je gaat me vertellen dat Duke Nuke 'm Forever uitkomt dit jaar.

oh wacht, verkeerd voorbeeld.

[Erwin_Br]

Dan houdt MS zich tenminste eens een keer aan een webstandaard!

MS houdt zich prima aan een standaard. Hun eigen standaard. Waaraan clubjes als W3C en nu Whatwg hun voorrecht verlenen begrijp ik, vooral na berichten als deze, steeds minder. Als iedereen een "standaard" mag bedenken, waarom Microsoft dan niet? Laat Mozilla en Webkit de "MS Standaard" lekker ondersteunen. Ik bedoel, nu we er toch al 2 hebben kan er makkelijk een derde bij...

[Blue_Airplane]

Het zou voor de eerste keer zijn dat Microsoft zich eens aan een standaard houd die niet van hun eigen is

On topic:
Hoe meer er aan een standaard gehouden word des te liever.
En in mijn bescheiden mening dan wel wel graag een open standaard. ^_^

[Verwijderd]

Denk even na voor je first post doet. Snap niet dat mensen dit zo hoog waarderen.
Je hebt het precies bij het verkeerde eind.

Mozilla en webkit gaan altijd voor standaarden.
Microsoft nooit.

Nou mag je nog een keer raden wie welke kant op gaat..
Microsoft gaat weer irritant met Whatwg mee en gooit er nog wat eigen meuk doorheen.
De anderen gaan gewoon voor de normale W3C standaard, met versienummers, waar alles beheersbaar en controleerbaar blijft.

[Verwijderd]

Welke anderen?

[Peter]

Dit is absolute onzin. Microsoft blijft juist weg bij de WHATWG en het zijn met name Google en Mozilla die expirimenteren met nog-niet-gespecificeerde functionaliteiten. Tevens, waar in jouw HTML pagina's gebruik je dan zo'n versienummer? Bij een ander antwoord dan "nergens" zou ik me zorgen gaan maken.

Het WHATWG wordt voor een zeer significant deel uitgemaakt door mensen van Opera, Mozilla, Apple en Google. De HTML5 draft van het W3C is voor het grootste deel een 1- op-1 kopie van hun versie. HTML5 bestaat al sinds jaar en dag bij deze twee organen, dit gaat helemaal niets veranderen.

[spoonman]

Best wel grappig hoe alles uiteindelijk de schuld van MS is.

Volgens mij zitten ze er bij de opwarming van de aarde ook voor iets tussen ...

[downtime]

De versienummers zeiden toch al niks. Sommige browsers implementeren enerzijds features uit de HTML5-standaard, zelfs lang voordat de standaard helemaal vast ligt, maar hebben anderzijds features uit oudere standaarden niet, niet-standaard, of niet volledig geimplementeerd.

[.oisyn]

Bovendien is er helemaal geen manier meer om een versie aan te duiden in je HTML. De doctype is namelijk gewoon <!doctype html> geworden. De moeilijkheid om oude tags uit te faseren was met de introductie van dat doctype al geïntroduceerd.

[downtime]

Zijn er wel eens tags echt uitgefaseerd? Deprecated betekent volgens mij alleen dat een feature officieel geen onderdeel van de standaard meer is. In de praktijk heb ik nooit gemerkt dat een deprecated tag echt niet meer werkte in een browser.

[Roland684]

blink, layer, applet en marquee (hoewel die laatste nooit 100% gesupport is geweest) werken volgens mij nog maar in enkele browsers.

[shifter]

Exact dat doctype laat m'n bloed koken -niet alleen het kortzichtige idee dat HTML nooit en te nimmer een of andere vorm van date stamping nodig zou hebben na HTLM5, maar ook de inherente laksheid achter het concept: in bestaande browsers was een dergelijk doctype namelijk het minimum benodigde om standards mode te triggeren -dat was serieus een "good thing" van HTML5.

Hoe vaak en hoe hard moet je van de trap zijn gevallen om dat te verdedigen?

[mcdronkz]

Wat maken die versienummers eigenlijk uit? Een HTML5 document heeft een generiek doctype (<!DOCTYPE html>) waaraan een user agent toch niets over een eventuele versie af kan lezen. Het hele principe van statische versienummers gaat een beetje in tegen het dynamische en constant veranderende internet. Zolang pagina's goed gerenderd blijven worden (ook door oudere browsers), zal het mij een zorg zijn of de HTML standaarden van 2 jaar geleden, of die van 2 dagen geleden worden nageleefd.

[ATS]

Browsers moeten dus, met terugwerkende kracht, helderziend worden o.i.d.?

[mcdronkz]

Dat zou mooi zijn, maar anders is backwards compatibility een prima alternatief.

[shifter]

backwards compatibility getoetst op welke manier? een versienummer wellicht?

[Bafti]

In eerste instantie klinkt het voorstel zo slecht niet. Maar om dit te laten werken moet er functionaliteit naast elkaar werkzaam zijn. Dit word toch een grote bende.
Of willen ze html modulair gaan opbouwen zodat je tags onafhankelijk van elkaar kan toevoegen als een soort html-addons. Dat lijkt me een hel om aan de gang te krijgen maar geeft webdevellopers wel veel vrijheid.

[Cobalt]

Dat was eigenlijk ook de gedachte van xhtml 2.0. Dat je bijvoorbeeld een math module include met je namespace waarmee je vervolgens formules kan weergeven en laten uitrekenen. (MathML)

Voor de komst van html 5 had ik eigenlijk het idee dat het die kant op zou gaan. Ik denk dat html 5 gemakkelijker verbeteringen kon leveren omdat sommige browsers als IE geen xhtml kunnen verwerken.