W3C wil html 5-standaard in 2014 afronden

Het duurt vermoedelijk nog drie jaar voordat de html 5-standaard helemaal af is. Het World Wide Web Consortium heeft aangekondigd dat er naar verwachting nog tijd nodig is tot juli 2014 voordat de webstandaard is geratificeerd.

De W3C heeft de planning voor het afronden van de html 5-standaard op zijn site gepubliceerd. De organisatie meldt op 22 mei van dit jaar de last call voor html 5 te gaan uitbrengen, wat betekent dat er tot die tijd nog feedback op de webstandaard kan worden gegeven.

Na deze datum zal de HTML Working Group reageren op alle op- en aanmerkingen en vermoedelijk diverse wijzigingen doorvoeren in de standaard. Vervolgens start de werkgroep een testprogramma, zodat onder andere browserbouwers en webdesigners kunnen werken aan html 5-compatibiliteit. De W3C roept al zijn leden op om relevante tests aan te dragen. In juli 2014 kan de standaard dan uiteindelijk geratificeerd worden, zo verwacht de organisatie.

Hoewel de meeste browsers al met html 5 uit de voeten kunnen, bestaan er verschillende implementaties. Het definitief afronden van de standaard is daarom noodzakelijk. Tot voor kort was het echter onduidelijk hoe lang het standaardisatieproces binnen de W3C zou gaan duren.

Of toekomstige html-implementaties nog versienummers zullen dragen, is nog onduidelijk. De Whatwg-werkgroep, de initiatiefnemer van html 5, wil niet langer versienummers gebruiken, om zo van de opmaaktaal een 'levende standaard' te maken.

Reacties (43)

[Thomzh]

Het ontbreken van versienummers in de toekomst lijkt me vervelend. De taal evolueert dan misschien wel sneller, maar coördinatie tussen de verschillende browserbouwers, zoals nu door het W3C gebeurt wordt veel ingewikkelder. Op die manier wordt het voor webbouwers alleen maar moeilijker om een ingewikkelde website te maken die voor elke browser hetzelfde werkt.

[RM-rf]

Op die manier wordt het voor webbouwers alleen maar moeilijker om een ingewikkelde website te maken die voor elke browser hetzelfde werkt.

je bedoelt dat het nu met dingen als specifieke versioneringen als HTML4.01, XHTML1, XHTML1.1 en transitional of strict doctypes ... én bv de proprietaire versionerings-oplossingen van Microsoft zoals de 'EmulateIE7 en EmulateIE8' voor web-ontwikkelaars 'makkelijk' is om in verschillende browsers dezelfde website te krijgen?

Mwah, mijn mening is juist dat als er iets verschrikkelijk 'misbruikt' wordt door de Browsers-bouwers en tot verschrikkelijke incompabiliteiten leidt, het juist de 'versionering'-mogelijkheden is....

terwijl een techniek zònder versionerings-systeem, specifiek CSS (dat wel een CSS1, CSS2 en CSS3 versie kent maar deze niet gereserveerd worden met een specifieke versie-nummer door servers, hooguit door de browsers ondersteund aan de hand van 'wat ze 'kunnen' en negeren wat ze niet herkennen) véél minder problemen oplevert.
Ook bv Javascript kent géén specieke Doctype en het aanbieden van javascript in een specifieke versie (het Language-attribuut in de SCRIPT tag) al langer afgeraden wordt (deprecated) en verder geen specifieke toepassing kent (in HTML3.2 was dat wél het geval)...


Natuurlijk is het een 'mooie' gedachte ... dat je een versie van de HTML zou definieren en dat alle browsers het dan consequent zouden renderen volgens die versie, maar de werkelijkheid is dat browsers dat _nu_ al niet doen, ondanks dat er in de bestaande specificaties wel een versionerings-systeem voorhanden is...
terwijl wat MS zelf daar ook nog ens aant toevoegt wat betreft hun EmulateIE7-meta-tags helemaal een ramp is qua toepasbaarheid (vornamelijk toegepast wordt door slechte webdevellopepers om hun falen te verhullen, IE-only websites makkelijk te blijven aanbieden of veel werk te besparen aan écht compatible werken)

[Reactie gewijzigd door RM-rf op 24 juli 2024 00:26]

[BramT]

Deels mee eens, maar je mist een belangrijk puntje. Als de html specificatie 'levendig' wordt, loop je het gevaar dat wat nu de standaard is, volgende maand niet meer 100% werkt. Op die manier verplicht je website eigenaren om extra onderhoud te moeten (laten) doen. Leuk vanuit een technisch oogpunt, ook lekker voor de hele bedrijfstak natuurlijk, maar minder leuk voor de website eigenaren zelf...

Dit voorkom je dan weer alleen door enkel nieuwe zaken toe te voegen aan "de standaard". Maar met verloop van tijd ga je dan natuurlijk ook vast lopen. De eisen die er aan het web worden gesteld veranderen nou eenmaal (relatief) snel. Ook kan je dan geen correcties meer doorvoeren.

Browsers die gewoon negeren wat ze niet kunnen is juist een van de oorzaken van het hele scala aan hacks die er bestaan en de geringe 'drive' van de browserbouwers om volledig aan de specs te voldoen.

Ook ik zie waarschijnlijk wel weer wat over het hoofd maar deze puntjes laat je imho wel wat onderbelicht in je betoog.

[OddesE]

Dat gevaar zou kunnen bestaan, maar het is in deze aan het W3C en de browser bouwers om de standaard alleen op een backward compatible manier te evolueren om dat te voorkomen.

Bijvoorbeeld het toevoegen van tags is redelijk veilig. Een oudere browser kent ze gewoon niet, maar je oude pagina's zullen die tag dan ook niet gebruiken. Ga je die tag wel gebruiken dan weet je dat alleen nieuwe browsers hem herkennen.

Een van de problemen in het verleden was ook een nogal puristische insteek van het W3C waarin men tags zoals <b>, <i> en <iframe> wilde deprecaten. Deze zouden verwijderd moeten worden. Dit is gewoon niet haalbaar gebleken en met HTML 5 kiest men er resoluut voor om dit te omarmen. HTML is zoals het is. Je kunt het uitbreiden, maar niet verkleinen. En HTML 5 moet hetzelfde zijn als HTML 4, plus wat extra's. HTML 6 wordt hetzelfde als HTML 5, plus weer wat extra. Je kunt dus niet ineens bestaand gedrag gaan veranderen. Wil je toch ander gedrag, moet je nieuwe tags, nieuwe attributen voor bestaande tags of nieuwe style regels gaan verzinnen, zodat je het oude ongemoeid kunt laten.

[RM-rf]

Als de html specificatie 'levendig' wordt, loop je het gevaar dat wat nu de standaard is, volgende maand niet meer 100% werkt.

Dàt is natuurlijk zaak van de mensen achter de HTML specificatie en die hebben juist weinig 'excuus' om zoiets te doen; nóg minder dan zolang men wel kan vasthouden aan dat 'concept' van verschillende versioneringen en verschillende render-modes van browsers.
Overall is jouw voorbeeld gewoon een onrealistische situatie die zich eerder nooit zal voordeoen, juist het opstelklen van deze specificatie is een langdurig proces en als je bedenkt dat we zelfs nu nog voor 75% van de HTML-specificatie kunnen baseren op de eerste basis zoals Berners-Lee HTML beschreef in 1989; kun je voorstellen dat de basis juist verdomd weinig 'structureel verandert'... pogingen daartoe zoals XHTML en zeker XHTML1.2 en 2.0 waren snel verdoemd

Juist bij het idee van 'version-afhankelijk renderen' is overigens het voorbeeld van Microsoft en zn EmulateIE7 of EmulateIE8 Headers een goed voorbeeld van hoe je het dus _niet_ wilt hebben, en ook waarom dat zo 'fout' is en juist rechtvaardigd dat browser-bouwers verschillende render-modes gaan inbouwen.

Browsers die gewoon negeren wat ze niet kunnen is juist een van de oorzaken van het hele scala aan hacks die er bestaan

nee sorry, maar een browser die gewoon standaard conform gedrag vertoont kan natuurlijk nooit een 'hack' zijn...
'hacks' is het juist als een browser _niet_ de standaard volgt, eigen niet-conform gedrag gaat weergeven of domweg totaal fout interpreteert (bv de bekende "* HTML"-CSS-hack die inderdaad afgeraden wordt omdat die breekt bij nieuwere versie's... dat is echter een browser-fout en ligt niet aan de specificatie)

[Reactie gewijzigd door RM-rf op 24 juli 2024 00:26]

[humbug]

css veranderd enkel de opmaak van elementen. Zonder css heb je nog steeds een functionele website. Missende functionaliteit of functionaliteit die anders werkt is daar niet heel relevant. Hoogstens ziet je pagina er anders uit. Bij html ligt dat anders. Je wil graag als video site weten dat een browser een video tag aan kan. als die niet functioneert valt de basisfunctionaliteit weg. Dat is vele malen ernstiger dan of je div nu wel of geen afgeronde hoeken heeft. Voor zaken waar je het resultaat wilt kunnen garanderen zijn versie nummers dus noodzakelijk. Zonder versie nummers kom je niet verder dan een best effort en mag je zelf uitzoeken welke functie welke browser precies ondersteund.

[RM-rf]

Hoe stel je voor dat een browser die géén video aankan opeens wél dat zou kunnen als je een HTML-versionering zou inbouwen?

of leg eens uit waar een HTML-versionering dàt zou 'veranderen'..
Punt is dat jouw 'oudere' browser die video-tag nooit zal aankunnen en met bv clientsidescripting de vraag of de video-objecten juist zijn herkend binnen het DOM prima op te vragen is en ook bv een fallback als alternatief inbouwen voor 'oudere' browsers...
geen enkele 'versienummer' nodig en ook de doctype of rendermode bemoeit zich daarmee niet, het element wordt herkend door de browser of niet, domweg omdat die het juist rendert binnen zn DOM

effectief is dat al momenteel prima uitgewerkt om bv via een clientside script oudere non-HTML5-ondersteunende browsers te 'helpen' (bv verschillende script die ofwel via VML of Silverlight een fallback genereren voor de CANVAS tag) of bv en flash-fallback voor VIDEO

[Reactie gewijzigd door RM-rf op 24 juli 2024 00:26]

[YopY]

Het ontbreken van versienummers in de toekomst lijkt me vervelend. De taal evolueert dan misschien wel sneller, maar coördinatie tussen de verschillende browserbouwers, zoals nu door het W3C gebeurt wordt veel ingewikkelder.

HTML5 zoals het nu is, is meer een marketingnaam voor het grote publiek. Intern / in de standaard zal er altijd wel een versie- of revisienummer komen, anders kan een browserbouwer nooit goed een standaard implementeren.

[OddesE]

Waar het om gaat is dat je als pagina auteur nu geacht wordt bovenaan je pagina te vermelden welke versie van HTML de pagina gebruikt. Dat klinkt goed te doen maar wordt erg lastig als je pagina bestaat uit onderdelen van verschillende bronnen die het onderling niet eens worden. Bijvoorbeeld een banner leverancier die een andere HTML versie gebruikt als de iDeal koppeling

[RM-rf]

Nou en? je hoeft het toch juist niet meer te doen omdat het eigenlijk ook nonsens is dat te doen?
Je pagina wordt er écht heus niet zoveel anders op, evenmin wordt je pagina opeens beter valdierender als je vooral Strict gebruikt (sterker nog, ik vermoed dat juist bv strict XHTML doctypes vaak meer fouten bevatten, zelfs waar die bv prima valide HTML4.01 zouden zijn

deze discussie is een beetje zoals mensen op een gegeven moment dachten: "dat je tags vooral altijd moest afsluiten omdat dat moest van XHTML"... en dat als je HTML4 gebruikte en gewoon een LI, TR/TD of P niet afsloot dat dat enorm 'fout' zou zijn...
of minimaal al 'minder' omdat het versienummer niet zo goed klonk of omdat 'X-HTML een lettrer meer had en die letter ook nog eens een interssante 'X' was.

punt is nu juist dat het een beetje overdreven onzin was te denken dat useragents niet slim genoeg zijn om impliciet afgesloten tags als afgesloten te zien...
één van de goede dingen van HTML5 is juist ook dat ze afstapten van die hoogvlucht van nutteloze techno-muurstarerij en veel praktischer naar de werkelijke gebruikswaarde van HTML als omgeving keken en niet een 'XML-afgeleidde taal' (wat het domweg ook niet is, XML kun je zelfs stiekem een HTML-afgeleidde noemen, met andere en veel bredere toepassing en inderdad ook 'andere' eisen)

[Reactie gewijzigd door RM-rf op 24 juli 2024 00:26]

[Left]

Onbegrijpelijk dat de W3C die Html5 specificatie niet in kleinere stukjes heeft opgeknipt. Dan kan je voor het eerste stuk snel de specificatie afronden en verder gaan met deel 2, enzovoort.
Nu komen er weer allemaal verschillende implementaties zodat je als developer uiteindelijk weer tegen dezelfde ellende aanloopt dat html die op browser A werkt, misschien niet werkt op browser B.

[Blokker_1999]

Nu komen er weer allemaal verschillende implementaties zodat je als developer uiteindelijk weer tegen dezelfde ellende aanloopt dat html die op browser A werkt, misschien niet werkt op browser B.

Maar dat is niet de schuld van de W3C, wel van de browserbouwers die staan te roepen dat ze vandaag al HTML5 ondersteunen terwijl de standaard nog niet af is. Het beste voorbeeld is zelfs de meest besproken HTML5 tag namelijk <video>. Browserbouwers staan te springen om deze tag te implementeren, maar in de specs staat (nog) geen codec vermerld.

[Niemand_Anders]

Ik snap nog steeds niet waarom je in een standaard überhaupt een video coded specificeert.. Het is een standaard die lang moet meegaan en ze willen het er zelfs een levende standaard van maken. Dan wil je anno 2011 toch niet in een standaard een video codec opnemen terwijl in 2014 misschien wel een veel betere uitkomt. Een vaste codec betekend dus dat je niet kunt wisselen.

Mijn advies: Implementeer de video tag zoals wij nu ook de image tag implementeren. Als je een standaard flexibel wilt houden, moet je in de standaard geen harde externe specificaties opnemen. Immers zou jij later WebV omwisselen H264 dan vol doe je niet meer aan de standaard.

[Pyronick]

Je kunt ook een videocodec ontwikkelen die evolueert in de loop der jaren. Uiteindelijk komt er toch wel weer een HTML6 specificatie waarin een nieuwere codec (indien nodig) geïmplementeerd kan worden.

Er moeten toch concessie gedaan worden. Een videocodec als standaard specificeren voorkomt een hoop gerotzooi met plugins en dergelijke.

Hoewel dat natuurlijk altijd wel zo zal blijven met bedrijven die allemaal een andere filosofie hanteren.

[YopY]

Ik snap nog steeds niet waarom je in een standaard überhaupt een video coded specificeert..

Ik wel. Kijk eens wat er nu gebeurt - browserbakker A ondersteunt H.264 wel, WebM niet. Browserbakker B ondersteunt H.264 niet, WebM wel. Browserbakker C ondersteunt geen van beiden maar ontwikkelt nog eens zijn eigen videostandaard. Browserbakker D bouwt een addon voor browser van bakker B waarmee video-tags omgezet worden naar object-tags zodat hun eigen mediaspeler gebruikt wordt binnen de browser van bakker B.

Wat je door die fragementatie krijgt is dat óf contentaanbieders moeten hun video's naar al die formaten converteren, óf ze blijven bij de bestaande technologie (Flash video's) omdat ze die investering niet kunnen doen.

Maar sowieso is de video-tag niet heilig, Youtube, bijvoorbeeld, biedt het al wel aan maar zal er niet volledig op overgaan, simpelweg omdat het niet toereikend is (geen ondersteuning voor ondertitels, bijvoorbeeld).

[zap8]

"Maar dat is niet de schuld van de W3C, wel van de browserbouwers die staan te roepen dat ze vandaag al HTML5 ondersteunen terwijl de standaard nog niet af is."

Tja en de diverse browser renderen de content ook nog weer es anders. Wellicht weer een kans voor Flash om aan zijn zoveelste leven te beginnen. Want flash rendert wel alle content in de verschillende browsers hetzelfde. Wel zo makkelijk als je content ontwerpt voor het internet. Wellicht ook interessant te vermelden dat flash nu door alle mobiele os-sen zal worden ondersteund (las gisteren dant WP7 ook flash ondersteuning krijgt en Android had het al), behalve iOS van Apple.

[crisp]

Tja en de diverse browser renderen de content ook nog weer es anders.

Als het goed is zou het implementeren van het HTML5 parsing algoritme daar voor een groot deel al een einde aan moeten maken. Op dit moment hebben nog niet alle browsers echter een HTML5-compliant parser.

Want flash rendert wel alle content in de verschillende browsers hetzelfde.

Volgens mij kent ook flash wel compatibility-issues met verschillende player-versies...

[Verwijderd]

[...]
Maar dat is niet de schuld van de W3C, wel van de browserbouwers die staan te roepen dat ze vandaag al HTML5 ondersteunen terwijl de standaard nog niet af is. Het beste voorbeeld is zelfs de meest besproken HTML5 tag namelijk <video>. Browserbouwers staan te springen om deze tag te implementeren, maar in de specs staat (nog) geen codec vermerld.

En dat laatste is dan toch wel precies de schuld van het W3C.
2014. Kom op zeg. Ze zijn er al jaren mee bezig en dan nog minstens 4 jaar. Want het is maar de vraagof (eind) 2014 ook gehaald wordt. Wie weet wat er allemaal aan nieuwe technieken komen. HTML5 is dan hopeloos achterhaald.

[crisp]

Onbegrijpelijk dat de W3C die Html5 specificatie niet in kleinere stukjes heeft opgeknipt.

Dat is ook gebeurd; veel API's zijn in de loop der tijd afgesplitst van de HTML5 draft; onder andere Web Sockets, Web Storage, MicroData, Canvas 2D API en Web Messaging. Zie de changelogs.

[YopY]

Toch zullen die zaken wel inherent onder het HTML5-kopje geschaard worden. Canvas, bijvoorbeeld, is een HTML5-element, niet eentje van XHTML. Alhoewel dat misschien wel functioneel te krijgen is met vage hacks.

[noskill]

Gelukkig wordt de tijd genomen om de standaard te definieren. Het zou misselijkmakend zijn als het te snel "officieel" gelanceerd zou worden als taal, omdat de software giganten hier tegenwoordig zo voor lopen te pushen. Het ontstaan van "verschillende implementaties" is toch iets wat we graag willen vermijden, denk ik zo.

[RobertMe]

Mooi dat er nu eindelijk een definitieve versie onderweg is. Hopenlijk pakken de browsers alles snel op, zoals de standaard het voorschrijft, zodat we snel een echte html5 hebben, en niet blijven zitten met verschillende implementaties.

Ik vraag me wel af hoe het Whatwg (en evt. W3C) die "levende standaard" willen gaan uitwerken. Ik neem aan dat er dan een soort van modules komen en er modules/standaarden toevoegt, verwijderd en gewijzigd kunnen worden zonder zonder impact op HTML zelf. Een beetje als nu volgensmij de modules bij CSS3 (moeten gaan) werken, borders & background, css animations etc.

[simplicidad]

Eigenlijk maakt het niet veel uit meeste browser (en zelf IE9) volgen al min of meer dezelfde standaarden. Geloof zelf dat HTML5 de laatste HTML versie wordt met een versie nummer.

Men weet ook wel dat terwijl de specs quasi altijd hetzelfde blijven er toch zaken bijkomen. En gelukkig maar !

[Reactie gewijzigd door simplicidad op 24 juli 2024 00:26]

[shaloca]

Op het moment zijn er wat 5 grote browsers makers en die hebben allemaal hun eigen ideeen en wille de snelste en beste ervaring leveren. Ik heb er 4 van op mijn computer staan en die bijten elkaar niet. Mocht een pagina niet openen op mijn favoriet FF, dan open ik het wel met een andere. Kosten voor mij = 0. Voor websites is het natuurlijk belangrijk dat ze alle ondersteunen anders blijven normale bezoekers misschien weg. Op het werk moet ik het nog doen met IE7, wat niet voor alle pagina's even snel of goed werkt, maar dat kan ook aan de backbone op de server hier liggen die ons beschermd.
3 jaar is belachelijk lang in een industrie waar electronica en software elke 6-12 maanden worden vernieuwd en niemand geduld heeft om op een standaard te wachten.

[Xthemes.us]

Raad eens wie er in het w3c zitten en deze standaard verzinnen? Juist, de browserbouwers. Het hele idee is om deze 'eigen ideeën" samen te voegen tot 1 ding waar iedereen het mee eens is.

[Verwijderd]

W3C wordt nu alleen nog gesteund door Microsoft en Opera, terwijl Google en Mozilla zich schuilen achter WHATWG.

Dus er zijn nog steeds 2 kampen, ipv 1. En dit resulteert weer in 2 verschillende standaarden...

[svdplas]

Ik vind dat Operating systems moeten verplichten om Browsers up te daten!
om situaties als ie666 te vermijden in de toekomst

[Neko Koneko]

Ja, leuk als een bedrijf een tool heeft die alleen in IE6 draait. Komt Windows opeens aan, je MOET nu updaten. En vervolgens ligt de productie stil. Handig

[Xthemes.us]

Die situatie was voorkomen als IE6 niet ervoor benodigd was
Het mes snijdt aan 2 kanten.

Als deze applicatie gewoon in het geval van een webpagina de standaarden volgen was er geen probleem. In het geval van een 'normale' applicatie hadden ze er beter voor kunnen kiezen een browser bij het programma te bundelen.

[YopY]

Alle OSen doen dat al, IE6 wordt ook gewoon bijgewerkt als je even die update draait. Dat XP dat niet deed ten tijde van versie 1 van XP kun je ze moeilijk tien+ jaar later nog voor verantwoordelijk houden.

[Verwijderd]

Dan moeten mensen hun OS ook updaten, want anders werkt de nieuwe browser ook niet...

Ik kan bv geen IE9 op een Windows XP machine zetten, net als dat ik geen IE6 op een Windows 7 kan installeren. En dat is echt niet heel anders dan de andere browsers, behalve dat er geen gebruik wordt gemaakt van OS eigen resources.

[Gamebuster]

Ik vind dat Operating Systems gewoon hun *** moeten houden en mij zelf moeten laten bepalen welke browserversie ik gebruik.

Ze mogen me 1 keer vragen om te updaten en als ik "NEEE!" antwoord, moeten ze hun *** houden; tenminste tot de volgende major update.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 00:26]

[Jeanpaul145]

Hoewel ik snap dat ze alles officieel willen vastleggen strookt dit absoluut niet met de dagelijkse realiteit: de snelheid van de ontwikkelingen op internet- en webgebied liggen orders van grootte hoger dan hun snelheid van ratificatie, een fenomeen dat we ook steeds meer merken met wifi standaarden.
Tegen de tijd dat HTML5 echt een de jure (i.t.t. de facto) standaard is zit Jan Klaas alweer te browsen met een browser die 1 of andere draft van HTML6 ondersteunt.

[Reactie gewijzigd door Jeanpaul145 op 24 juli 2024 00:26]

[Blokker_1999]

Maar je kan nu eenmaal niet vandaag iets verzinnen en dat morgen al een standaard willen noemen. Een standaard is een afspraak tussen verschillende mensen/bedrijven/organisaties die het allemaal eens moeten worden over die standaard. Je zou de berg met opmerkingen eens moeten opzoeken en dan besef je pas hoeveel werk er bij komt kijken.

[Verwijderd]

Maar 10jaar is belachelijk en dan neem ik even aan dat ze hun deadline gaan halen, wat met 100% zekerheid niet zal gebeuren. Een standaard moet de realiteit volgen of de realiteit gaat z'n eigen standaard uitvinden, zie IE4-6.

Toen ze aan HTML5 begonnen had Facebook een duizendtal gebruikers.
Vandaag is HTML5 een waardeloze wanorde en Facebook heeft 500 000 000 gebruikers wat neerkomt op 1/4 van de mensen die internet beschikbaar hebben.

[mashell]

Kunnen we dat w3c niet gewoon opheffen? Ze gaan zo ontzettend langzaam dat ze de innovatie remmen. Soms verlang je terug naar de browserwars, een ontzettende cowboytijd maar het ging wel lekker snel. Nu hebben de ambtenaren de macht gegrepen en zijn ze druk hun werkzaamheden tot hun pensioen uit te smeren.

[Gamebuster]

Het gaat toch prima zo? Men kan nog steeds nieuwe features in browsers bakken en w3c zorgt ervoor dat deze nieuwe features standaard worden en andere browsers die features ook erin bakken.

Natuurlijk zit er een enorme vertraging tussen een experimentele feature in een browser, een standaard en de implementatie van die standaard in andere browsers, maar zorgt wel ervoor dat je niet loopt vechten met 100 browsers die allemaal anders werken: de stabiele standaarden werken op iedere browser tegenwoordig hetzelfde.

[Vhond]

Het is goed om met standaarden te werken maar:

1) Niet een partij mag en kan dat bepalen.
2) Er zijn geen sancties op uit te voeren DUS zullen er altijd wel verschillen zijn in de looks en werking van websites in de verschillende browsers
3) Het inherent is aan de meeste commerciele ontwikkelaars dat ze zich nergens aan gelegen laten liggen, enerzijds kan dat innoverend zijn, anderzijds is het drempel op werpend (zeker omdat elk commercieel bedrijf met patenten en bijbehorende rechtzaken strooit)
4) Uiteindelijk de webontwikkelaar bepaalt of iets wel of niet werkt in een bepaalde browser (dat zal over 10, 20, 30 en meer jaar niet anders zijn)
5) Het wel van moed zou getuigen als officiele, publieke instanties en bedrijven die zich gebruiksvriendelijk willen presenteren de keuze maken voor de gulden middenweg (en niet kiezen voor het toepassen van fancy technieken die maar in een heel beperkt aantal browsers goed werken)