Voorstel voor HTML 5 ingediend bij W3C

Mozilla, Opera en Apple hebben de W3C voorgesteld HTML 5 als basis te nemen voor de verdere ontwikkeling van html. De drie bedrijven hebben in een werkgroep jarenlang aan de update van de html-specificatie gewerkt.

De Web Hypertext Application Technology Working Group is in 2004 ingesteld uit onvrede over de trage ontwikkeling van html. W3C moet die ontwikkeling in goede banen leiden en dacht dat te doen door xhtml voor te stellen als opvolger van html. Deze taal is vergelijkbaar met html, maar gebaseerd op xml. Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer. Een ander probleem volgt uit het feit dat de verwerking van xml stokt zodra er een fout in de syntaxis voorkomt. De meeste xhtml-pagina's die er zijn laten zich daarom als html-documenten verwerken door browsers. Ondanks dat dit misvormde html oplevert, kunnen browsers ermee overweg omdat ze html als tag-soup verwerken: ze proberen er het beste van te maken.

Op dit moment handelt iedere browser invalide html op eigen wijze af, maar daar moet HTML 5, ook wel Web Applications 1.0 genoemd, een einde aan maken door standaardregels op te leggen voor de verwerking van misvormde html. HTML 5 stapt mede daarom voor een deel af van de sgml-onderlaag van html. Daarnaast specificeert HTML 5 een aantal api's en opmaakelementen die in de praktijk al gebruikt worden en wordt nieuwe functionaliteit gedefinieerd, zoals de elementen 'canvas', 'article' en 'section'.

De Whatwg stelt concreet aan het W3C voor dat hun HTML 5 de basis vormt voor de verdere evolutie van html-afspraken, dat het consortium officieel de naam 'HTML 5' adopteert en dat Ian Hickson van de werkgroep bijdraagt aan de verdere uitwerking van de specificatie. Het wekt geen verwondering dat de drie bedrijven nu met hun voorstel komen: begin maart nodigde de W3C geïnteresseerden uit om toch aan de huidige html-specificatie verder te werken in de recent opgerichte html-werkgroep.

Reacties (94)

[Verwijderd]

Als Google nou eens in hun pagerank algoritme iets opneemt zodat (X)HTML fouten je pagina doen zakken ...

[XplodingForce]

Google is gericht op het laten zien van de beste resultaten. Een site die brak gecode is, kan best goede informatie bevatten en dus een goed resultaat zijn.

Dit zal google dus echt niet doen, aangezien dan de zoekresultaten ernstig verslechteren.

[Luxx]

Google is gericht op het toegankelijk maken van informatie, een site met valide html is beter toegankelijk, en levert de informatie 'beter' aan de gebruiker. Kortom, ergens is het wel logisch om daar iets mee te doen.

Helaas is het in de praktijk zo dat een slechte pagina vaak (in IE) alsnog goed gerenderd wordt, en dús is het ergens wel logisch dat Google hier niets in ziet.

[user109731]

Google is gericht op het toegankelijk maken van informatie, een site met valide html is beter toegankelijk, en levert de informatie 'beter' aan de gebruiker. Kortom, ergens is het wel logisch om daar iets mee te doen.

Beter toegankelijk voor de parser misschien, maar een validerende xhtml pagina kan minder toegankelijk zijn dan een html pagina met enkele kleine foutjes. De relevantie van de content (en daar gaat het om) is al helemaal niet omgekeerd evenredig met het aantal fouten in de html.

Helaas is het in de praktijk zo dat een slechte pagina vaak (in IE) alsnog goed gerenderd wordt, en dús is het ergens wel logisch dat Google hier niets in ziet.

Jammer, maar ansich niets mis mee, als die error correctie maar gedefinieerd is, zodat het in alle browsers hetzelfde werkt

[Nijn]

Goeie!
Dan maak ik morgen een ad-farm met alle mogelijke onderwerpen in 100% correct (x)html.
Ben ik toch al minimaal 50% van de (echte) pagina`s kwijt omdat er een fout in zit. (Lees: Geschreven zijn om te werken in IE)

[Jogai]

Dat is een super idee!! Wedden dat dan de kwaliteit omhoog gaat!

[alex3305]

De kwaliteit van (X)HTML misschien wel, maar niet de kwaliteit van de informatie.

Als ik dus een pagina goed code over rental cars, maar slechte informatie heb dan kom ik hoger te staan dan sites die goede informatie hebben over rental cars, maar slechte code.

Dat is denk ik dus niet the way to do it!

[Verwijderd]

wat een onzinplan over google. Mensen mogen best brakke code gebruiken om sites te maken. Het gaat erom dat standaarden duidelijk zijn, niet dat de gebruiker alles goed moet doen. Standaarden zijn handig, niet heilig. Google moet hier helemaal met z'n poten afblijven, dan gaat google voor ons bepalen wat een 'goede' site is.

[JeroenB]

Regels opstellen voor de verwerking van malformed html is toch eigenlijk een vorm van symptomen bestrijden? Ik bedoel, het probleem is dat de html door veel producenten malformed wordt aangeleverd, niet dat de regels over hoe het moet worden afgehandeld niet bestaan.

Ik begrijp best dat de realiteit nou eenmaal is dat mensen malformed html aanleveren, maar daar is dit ook geen oplossing voor: waarschijnlijk gaan ze bij MS (of ergens anders) die regels dan weer met verschillende nuances of prioriteiten implementeren, waardoor je weer terug bij af bent.

En wat gaan we dan doen? Een standaard verzinnen om te definieren hoe het incorrect toepassen van regels bij incorrecte html moet worden afgehandeld? Dat is een gebed zonder einde.

[Little Penguin]

Aangezien het web nu eenmaal veel non-standaard HTML sites heeft - met brakke HTML code, is het nu eenmaal noodzakelijk om lenient op te gaan met het parsen van de HTML van die sites.

Door duidelijk te definieren hoe een user-agent deze rommel moet parsen ziet het er in elk geval overal hetzelfde uit.

Dat wil niet zeggen dat je er een rommeltje van moet maken, maar je kunt nu eenmaal niet alle bestaande sites naar een 100% valid SGML/XML parsing model dwingen - helaas...

[Lukse]

maar je kunt nu eenmaal niet alle bestaande sites naar een 100% valid SGML/XML parsing model dwingen - helaas...

Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?

[user109731]

Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?

Er is wel verschil tussen een programmeertaal en een markup-taal. Een foutje in een programmeertaal door de compiler laten rechtzetten kan ernstige gevolgen hebben, maar html word enkel geparst en direct weergegeven, daar is error correctie prima mogelijk

Omdat er ergens een klein foutje zit (entity vergeten te encoden bijvoorbeeld) zou je een website uren onbereikbaar kunnen maken. Of stel dat er op een blog iemand iets malformed html kan zetten dan is dat hele artikel niet meer te lezen, dat wil je niet. Dan kun je denk ik beter goed definieren wat er in dat geval moet gebeuren dan domweg de toegang tot alles ontzeggen.

[Roland684]

Vanuit browser-oogpunt wil je dat eigenlijk wel doen, om daarmee developers te dwingen iets te maken dat aan de standaard voldoet, zodat iedere browser er mee overweg kan., maar de eerste browser die sites met brakke html niet laat zien, maar de bezoeker confronteert met een "deze pagina kan niet worden weergegeven"-melding, raakt zijn gebruikers kwijt.

Er is nu eenmaal veel slechte html op het web te vinden en daar zul je mee om moeten gaan.
En door dat allemaal op dezelfde manier te doen, voorkom je dat je gebruikers weglopen naar een browser die de 'rotzooi' beter weergeeft.
Blijft de vraag hoe je gaat zorgen dat devellopers nette html gaan schrijven ipv dat ze de error-handling als valide html gaan gebruiken. Als je sluittags kunt weglaten omdat het toch wel acceptabel afgehandeld wordt, moet je dan nog wel sluittags gebruiken?

[arendjr]

@berend_engelbrecht:
Volgens mij heb je niet helemaal begrepen wat backward compatibiliteit hier inhoudt.
Dat XHTML niet backward compatible is met HTML betekent dat een geldige HTML-pagina niet automatisch ook een geldige XHTML-pagina is. Maar dat wil natuurlijk helemaal niet zeggen dat een browser die XHTML ondersteunt geen HTML-pagina's meer zou kunnen ondersteunen. Het een hoeft het ander niet uit te sluiten. Want natuurlijk kan een browser die XHTML ondersteunt (zoals Mozilla of Opera) gewoon pagina's in normaal HTML van 10 jaar geleden weergeven.

[alex3305]

Iedereen (die een webbrowser) schrijft zou zich dus aan deze regels moeten houden. Gecko (Mozilla), KHTML/Webcore (Apple), Presto (Opera) en alle opensource browsers zullen zich hieraan willen houden. Alleen zal de marktleider, Microsoft, hier niet aan mee werken met hun Internet Explorer.

Microsoft kijkt te veel naar de consument en dat zouden ze niet moeten doen, daarmee bedoel ik dat ze proberen ALLE sites voor iedereen toegankelijk te maken. Echter zouden ze beter moeten kijken naar de ontwikkelaars van websites. Deze maken wel het internet 'mogelijk' en met brakke code (lees: te veel verschillende render mogelijkheden), krijgen deze ook steeds minder zin in het maken van sites.

[berend_engelbrecht]

De reden is heel simpel:

Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer.

Je kan niet de regels veranderen en dan prompt verordonneren dat iedereen zich aan de nieuwe regels houdt. Een webpagina van 10 jaar oud moet leesbaar blijven, net zo als je kan verwachten dat je een boek dat slechts 10 jaar oud is uit de kast kan pakken en zonder problemen kan lezen.

Het feit dat er een versie van de standaard is ingevoerd die niet backward compatible is was een heel domme en ondeskundige move van de W3C destijds, waar we nu de wrange vruchten van plukken. We hebben hier met documenten van doen en daarvoor horen de principes van documentaire duurzaamheid te gelden: een nieuwe versie van een reader hoort altijd zonder problemen documenten die voor een vorige versie gemaakt zijn kunnen lezen, in principe tot in de eeuwigheid. Jammer voor mensen die alles "mooier" willen maken, maar zo werkt het dus niet. En voor als je eeuwig wat lang vindt: begin dan in elk geval maar eens met een periode van 80 jaar te hanteren, dat is heel gebruikelijk in de archiefwereld.

[Little Penguin]

Waarom niet? Valid (X)HTML afdwingen vind ik wel kunnen. Als ik in PHP, ASP, JAVA, ... geen valid code schrijf, werkt mijn programma ook niet. Waarom zou hetzelfde niet voor een website mogen gelden?

Het probleem is dat je dat afdwingen vanuit de browser moet doen - zoals al aangegeven is, is dat geen optie - zie eerdere reacties.

Het enige dat wel zou kunnen helpen om XHTML (dus ook "XHTML 5") een duwtje te geven is dat browsers die XHTML strict renderen dit sneller doen dan HTML-tagsoup.

Ik weet niet in hoeverre dit technisch mogelijk is, maar door de pagina seconden sneller te renderen als XHTML zou kunnen helpen om XHTML populairder te maken.

Ik weet echter niet in hoeverre het parsen van XHTML efficienter is dan het parsen van HTML - het verschil is waarschijnlijk te klein.

[7.01D]

@berend_engelbrecht

Het feit dat er een versie van de standaard is ingevoerd die niet backward compatible is was een heel domme en ondeskundige move van de W3C destijds, waar we nu de wrange vruchten van plukken

Daarom hebben ze de naam ook veranderd naar XHTML, om aan te geven dat het niet zomaar een nieuwe versie van dezelfde taal is.

[Milt]

@berend_engelbrecht:
Het feit dat XHTML er is en browser het correct gaan ondersteunen wil niet zeggen dat oude en brakke HTML pagina's ineens niet meer weergegeven kunnen worden. Dankzij DOCTYPE declaraties en content types kan een goed geimplementeerde browser het verschil zien tussen XHTML en HTML dus kan hij beide goed weergeven (of in ieder geval in het geval van HTML het beste ervan maken).

[JeromeB]

arendjr, zo 'natuurlijk' vind ik dat eigenlijk niet. Het is misschien natuurlijk dat bekende browsers zoals Mozilla en Opera zowel XHTML als HTML ondersteunen, maar dat geld niet voor alle applicaties. Beide formaten worden namelijk op verschillende wijzes geparst. HTML wordt geparst door een SGML-parser. XHTML wordt geparst door een XML-parser. Dat kan nog wel eens een probleem worden met minder bekende browser of tools die wel over een XML-parser beschikken, maar niet over een SGML-parser.

[JeromeB]

Little Penguin, dat vind ik eigenlijk nogal krom. Waarom zou een browser XHTML moeten pushen ten nadele HTML? Het is dan net alsof je XHTML door de strot van webdevelopers wil drukken. Ik zou dit geen goede ontwikkeling vinden. Ik heb als webdeveloper helemaal geen interesse in XHTML. HTML voldoet prima en is iets flexibeler (mbt tags en error-afhandeling) dan XHTML.

[KoKro]

Probleem van die error correctie is dat die ook niet gestandaardiseerd is en dus onvoorspelbaar resultaat geeft. Dat kan net zo funest zijn als een pagina helemaal niet rendert.

Als je een website goed opzet, dan zorg je voor een goede test en productieomgeving. Door een eenduidige standaard is het mogelijk om correctheid te bewijzen en dan pas over te gaan naar productie.

Voor dynamische pagina's zijn voldoende tools aanwezig om correcte output te blijven genereren.

Volgens mij is het toch echt gewenst dat een pagina volgens een vastgestelde opmaak overal dezelfde, vooraf gedefinieerde, uitvoer produceert.

[2playgames]

oplossing: laat de browsers een dikke vette balk bovenaan zetten (zoals nu de balk van een geblokte popup) met het bericht: "Deze pagina is niet geldig opgemaakt. Het weergegeven resultaat is wellicht niet wat de auteur bedoeld heeft" (of iets dergelijks). Developers worden dan gemotiveerd om correcte HTML te schrijven, maar gebruikers kunnen de pagina nog steeds bekijken.

Oh, en belangrijk detail: Niet alle oude pagina's zouden meteen kapot gaan. Alleen pagina's met een HTML 5 DTD zouden volgens deze regels behandeld worden

[denkster]

Iedereen (die een webbrowser) schrijft zou zich dus aan deze regels moeten houden.

Helemaal mee eens. Geldt voor schrijvers van browsers, websites, automobilisten, monopolisten...
Feit is dat regels toch vaak, bewust of onbewust, worden overtreden. Daar moeten we een houding tegenover stellen, maatregelen nemen. Waarom? omdat de consumenten de dupe worden. Zij worden geconfronteerd met onvindbaarheid of onleesbaarheid van informatie, idiote foutmeldingen, blanco pagina's, crashes, malware brakke browser, enzovoort, terwijl ze daar vrijwel niets aan kunnen doen, bij gebrek aan kennis en macht.
Dus met:

kijkt te veel naar de consument

ben ik het helemaal oneens.
Laten we iets bedenken waardoor de narigheid van het gebrek aan standaards en het overtreden van regels bij de producent van de narigheid komt te liggen.
Als eerste afspraak stel ik voor: als een gebruiker een pagina probeert openen die niet valide is voor die browser krijgt de server van de pagina een technische foutmelding en de gebruiker een excuus en een advies.
De bouwers van invalide websites zullen snel overspoeld raken met meldingen, dat zal ze leren.
Valide websites bouwen kan namelijk best, zie Rabobank (f.y.i.: ik heb daar geen belangen)

[_JGC_]

Ik zie het op mijn werk echt heel vaak gebeuren: "Oh shit, het werkt niet helemaal 100% met XHTML, als ik nou gewoon de doctype weghaal en IE in quirksmode zet werkt het wel"
En vervolgens heb je een rotzooisite vol met tabellen omdat ze niet weten hoe het in IE6 goed te krijgen is. Vooral sites met 100% hoogte is in IE6 een ramp als je IE6 in standards compliance mode zet (ja het kan, vraag niet hoe )

HTML5 is leuk en aardig allemaal, maar zolang webdevvers allemaal nog gewoon terugvallen op een oudere standaard als het even tegenzit, heeft het forceren van goede code geen zin. Verder heb je ook nog zoiets als een doelgroep van je website. Als je doelgroep IE6 en IE7 is (grote kans, je kunt het niet maken om deze twee browsers uit te sluiten), is HTML 5.0 dus al waardeloos omdat die browsers het toch niet snappen.

[Verwijderd]

Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer.

Ow... dus... we hebben een standaard... MS weigert hem te volgen of implementeren... dus beginnen we aan maar aan een nieuwe versie...

[Roland684]

Het is kiezen tussen een standaard die niet werkt op internet explorer en dus vrijwel kansloos is, of een die nog wel iets laat zien op internet explorer.

[Verwijderd]

Mijn eigen website die met volledig geldige xhtml 1.1 en css is opgemaakt, wordt nogthans ook in IE6 en IE7 goed weergegeven. Of hij deze rendert met html-rendering weet ik niet, maar 't k heb er toch geen problemen mee.

Meer zelfs, ik ben voorstander van xhtml tov html, net omdat het stricter is. Ik vind foute code afhandelen zowieso al niet de taak van een browser. Ik heb liever dat ze eerst de standaarden volledig werkend implementeren alvorens ze zich gaan bezig houden met onnodige zaken. Wat mij betreft moet foutieve broncode gewoon genegeerd worden, zodat de andere code van die pagina wel nog getoond wordt. Als dat het enige regeltje is, dan is het voor iedereen duidelijk en kan je bij het plaatsen van een artikel ervoor zorgen dat het wel compliant is, zodat als iemand dan toch foutieve code kan posten je site niet om zeep helpt, omdat enkel zijn/haar post niet getoond wordt.

Google kan bij het zoeken naar informatie dan dezelfde regel toepassen, want als je de site bezoekt, krijg je het toch niet te zien.

Dat niet backwards compatible zijn is eigenlijk enkel een probleem als je site vroeger in html was en je die nu naar xhtml wil omzetten, omdat je dan ook alle image-tags e.d. van een sluittag moet voorzien en je sluittags correct genest moeten staan. Als je tevreden bent met je site in HTML moet je deze echter niet naar XHTML gaan omzetten, dus ik vind het een relatief zwak argument, die backwards compatibiliteit.

En dat IE xhtml niet ondersteunt is ook geen nadeel, want zaken die in html 5 nieuw zijn tov versie 4 zullen ook niet in IE ondersteund worden...

< sarcastic-mode>
Trouwens MS kennende zullen ze naast xhtml2 en html5 wel met een eigen formaat komen dat ze dan via een speed-procedure willen gestandardiseerd krijgen, maar dat het zodanig opgesteld is dat Firefox, Opera en apple het nooit volledig kunnen implementeren omdat het zich een stuk baseert op closed source binnaire drm-componenten.
< /sarcastic-mode>

[Nijn]

Dat is nou precies de strategie van MS. Ze wachten af tot er een standaard komt, om vervolgens een aantal punten aan te passen. Aangezien zij de marktleider zijn gaan veel mensen niet eens de moeite nemen om hun site correct te maken, als ie maar werkt in IE. Dus, Mozilla geeft foutmeldingen op een site die met IE prima werkt. Wat doet de consument? Precies...

[SirBlade]

Het zou makkelijker zijn om aan MS te vragen hoe de volgende standaard er uit moet zien en die dan door de rest van de browser-maker te laten implementeren. Maar dat is natuurlijk op z'n minst niet politiek-correct en voor velen heiligschennis.

[Roland684]

Een groot probleem daarbij is dat Microsoft zijn Internet Explorer erg graag integreert met het windows OS. Dan kunnen ze met betrekkelijk weinig werk hele krachtige dingen doen, door gebruik te maken van ActiveX, VBA en .Net, maar behalve dat dat veel beveiligingsgaten oplevert omdat dat diep in het OS integreert, kun je geen browser meer maken zonder gelijk half Windows te moeten emuleren.
En dat zie ik nog niet zo snel gebeuren op Linux, Mac en andere non-windows-systemen (zoals settop boxen en de b.v. de PS3 in de woonkamer, mobiele telefoons, etc.) Als het aan Microsoft ligt, kun je straks geen fatsoenlijke webbrowser meer bouwen zonder Windows OS.
En er zijn diverse redenen waarom je dat geen goede ontwikkeling is, als was het maar dat mijn telefoon geen windowsXP kan draaien.

[ytsmabeer]

Microsoft wacht eerst af wat anderen als standaard willen zodat ze precies het tegenovergestelde kunnen doen.

[alex3305]

Dit zou een goede ontwikkeling zijn ten behoeven van het programmeren of scripten in 'internettalen'.

Het grote nadeel is nu, als door het artikel al wordt aangegeven, dat XHTML niet goed verwerkt wordt door Internet Explorer. Als je die namelijk puur XHTML aanleverd, gaat deze een foutmelding geven, terwijl de pagina het wel goed doet in andere browsers.

Je zou kunnen zeggen dat je dan IE kunt buitensluiten, maar echter is dit geen reële oplossing. IE gebruikers stappen namelijk vaak niet over vanwege het gemak en veel mensen haken daardoor af en zullen je site niet bezoeken.

Het is dus goed dat er nu een goede standaard wordt opgesteld, en ik denk ook dat het W3C hier binnen niet al te lange tijd een positief besluit over moet maken!

[tjerkw]

Jij snapt het echt dus volkomen niet..

Ook wat er in het artikel staat klopt niet, ik citeer:


Xhtml kent een aantal grote nadelen; zo is de taal niet volledig backwards compatibel en wordt xhtml niet ondersteund door Internet Explorer


Dus een nadeel van XHTML is dat het niet wordt ondersteunt door Internet Explorer.... Sorry maar WTF!!
Dat is geen nadeel van XHTML, dat is een nadeel van Internet Explorer:
Internet Explorer ondersteunt XHTML niet, en niet andersom. XHTML is namelijk een specificatie waarin de browser-implementaties moeten voldoen...

Trouwens ik ben tegen HTML 5.0. XHTML is een zeer goede specificatie en heel duidelijk. Ook XML als basis geeft vele voordelen.. (bv XML Databases, XSL etc etfc)

Serieus de meeste mensen weten niet waar ze het over hebben

[Stijn]

Ja, dat is natuurlijk een nadeel van Internet Explorer, maar in de realiteit zitten we er mooi mee omdat nog steeds het overgrote deel van de mensen IE gebruikt. Dan moet je pragmatisch denken en niet religieus vasthouden aan een standaard die niet ondersteund wordt omdat je daarmee toch geen stap verder komt.

Wist je trouwens dat de WHATWG ook XHTML 5 ontwikkelt? Precies hetzelfde als HTML 5, maar dan met XML-syntax. Fijn, hè Als je gaat beweren dat mensen niet weten waar ze het over hebben is het altijd handig je eerst even in te lezen.

[tjerkw]

Ok ik kwam er iets later achter dat ze ook XML omarmen, maar dan nog: Waarom nog een standaard. XHTML 2.0 moet de toekomst worden.

Dit alles is niet echt goed voor het web.

Ik zeg: we moeten een offensief tegen MSIE beginnen. die MSIE 7.0 is ook zo brak als het maar kan.

Wat ik heb gehoord (op slashdot.org gelezen) is dat MSIE wordt gebruikt in veel MS applicaties als bijvoorbeeld Explorer. Als je daar bijvoorbeeld op een map klikt wordt er eigenlijk gewoon een DOM gegenereerd en rechts weergegeven in een MSIE engine.

Dus MSIE zit gewoon gebakken in de OS; MS KAN gewoon MSIE neit aanpassen omdat veel applicaties dan niet meer werken (Outlook, Verkenner, en ja volgens mij zelfs je bureaublad)

[2playgames]

vergeet het startmenu niet

[Rvanlaak]

Uh.. Outlook maakt gebruik van de Word engine! Ik weet het, ik ben er ook niet blij mee

[Laurens-R]

Dat kan je ook van jou zeggen?

Je onderschat wellicht het aantal gebruikers dat IE nog steeds heeft. Niet iedereen gebruikt Firefox, Opera of Safari. Samen met IE sluit je tegelijkertijd een enorme groep potentiele visitors uit, wat niet echt handig is vanuit een 'bezoekers-aantal-technisch' oogpunt.

[tjerkw]

Nee ik weet heel goed dat er veel gebruikers met IE zijn, maar er moet gewoon druk op MS worden uitgeoefend zodat ze ook voldoen aan de standaard.

Ik erger me nu gewoon dood aan MSIE.

[Punkie]

Vandale:
stan·daard2 (bn.)
1 als regel, normaal => gewoon

Xhtml wordt niet ondersteunt door IE en is dus niet gewoon, de regel en is dus geen standaard. Hoe goed het verder ook mag zijn, het grote nadeel is een groot nadeel dat het niet de standaard is.

Dat html5 WEL ondersteunt zal worden in IE heeft een betere kans en dat zou tot gevolg hebben dat alle browsers WEL gelijkvormiger worden wat dan weer positief is voor de consumenten.

[mae-t.net]

Even wat doorgeredeneerd op de betekenis van gewoon: dit betekent dat het door de meerderheid van browsers wordt ondersteund. (vergelijk Engels: common -> in common). Dat is met XHTML natuurlijk gewoon zo. IE is maar 1 browser, en de browsers die het wel ondersteunen zijn in de meerderheid. Dat ze niet het grootste marktaandeel hebben is een ander verhaal.

[CH4OS]

Trouwens ik ben tegen HTML 5.0. XHTML is een zeer goede specificatie en heel duidelijk. Ook XML als basis geeft vele voordelen.. (bv XML Databases, XSL etc etfc)

Niemand zal je dan ook verplichten om HTML5 te gaan gebruiken...

Xhtml wordt niet ondersteunt door IE en is dus niet gewoon, de regel en is dus geen standaard. Hoe goed het verder ook mag zijn, het grote nadeel is een groot nadeel dat het niet de standaard is.

Wel een beetje raar, om te zeggen dat omdat IE het niet ondersteund, dat het dan geen 'standaard' meer is.

Dat is hetzelfde als een diesel auto hebben, iets anders tanken en verwachten dat je auto gewoon rijd...

Dat html5 WEL ondersteunt zal worden in IE heeft een betere kans en dat zou tot gevolg hebben dat alle browsers WEL gelijkvormiger worden wat dan weer positief is voor de consumenten.

Voor zover ik weet, is HTML5 een soort mix tussen xHTML en HTML 4.1, maar ook hier kan ik er naast liggen, dus ik ga er eigenlijk vanuit dat het niet (goed) zal werken in IE.

[tjerkw]

Een standaard op het gebied van de informatica is niet wat jij beweert dat het is. Ik doel op specificaties opgericht door bedrijven / instellingen om er zo voor te zorgen dat iedereen weet wat hij kan verwachten / moet doen.

Dat is een standaard. Dus nee niet wat normaal is. (meestal wordt een standaard door veel bedrijven omarmt.. maarja Micro$oft is weer het buitenbeentje)

[CH4OS]

Een standaard op het gebied van de informatica is niet wat jij beweert dat het is. Ik doel op specificaties opgericht door bedrijven / instellingen om er zo voor te zorgen dat iedereen weet wat hij kan verwachten / moet doen.

Dus omdat Microsoft niet meedoet met de (x)HTML 'standaard', is (x)HTML geen standaard, want zij hebben geen afspraken hieromtrent gemaakt?

Dat is mijns inziens ook wel te voorbarig.
Volgens Wikipedia is een standaard (ook) een synoniem voor norm, klopt ook wel, want hoe een standaard / norm 'gemaakt' word maakt natuurlijk niet uit, of het door een instelling is, of door bedrijven, of een combinatie hiervan.

Belangrijkste punt blijft gewoon, dat als er een 'standaard' is (voor zover je hierover kan spreken bij (x)HTML) kan je die toch wel implementeren...

Je kan dus ook als je wil je eigen HTML 'standaard' maken, door zelf een DTD (Doc Type Definition) aan te maken...

[2playgames]

maar zoals tjerkw zegt, het gaat hier over een informatica-standaard. dit is een vastgelegde specificatie van hoe, in dit geval een webpagina, beschreven moet worden. net als een protocol dus

[denkster]

Vandale:
stan·daard2 (bn.)
1 als regel, normaal => gewoon

Xhtml wordt niet ondersteund door IE en is dus niet gewoon,

Taal en lezen is niet je sterkste kant, hoop ik? Er staan meer betekenissen in Van Dale. Bij die andere betekenissen is er tenminste één belangrijker in dit verband. Zo werkt een woordenboek, snap je?

[Verwijderd]

Ja joepie.. weer een nieuwe standaard waar slechts een deel van de markt zich aan gaat houden.

Wij zijn hier eindelijk zover dat we alle website via XHTML en CSS er hetzelfde kunnen laten uitzien in zowel IE, FF en Opera en ook Valid zijn. Ik hoef geen nieuwe standaard!

Ik hoop wel gewoon dat de huidige vorm van XHTML-parsing blijft bestaan.

[CH4OS]

Ja joepie.. weer een nieuwe standaard waar slechts een deel van de markt zich aan gaat houden.

Wij zijn hier eindelijk zover dat we alle website via XHTML en CSS er hetzelfde kunnen laten uitzien in zowel IE, FF en Opera en ook Valid zijn. Ik hoef geen nieuwe standaard!

Ik hoop wel gewoon dat de huidige vorm van XHTML-parsing blijft bestaan.

Dit heet technologische vooruitgang en is doodnormaal.
Mede door dingen als dit, word het steeds makkelijker om een website in verschillende browsers toch hetzelfde eruit te laten zien mogelijk.

Of werk je nog liever op een 286?

[bavanandel]

Het is dus goed dat er nu een goede standaard wordt opgesteld, en ik denk ook dat het W3C hier binnen niet al te lange tijd een positief besluit over moet maken!

En deed het W3C dat in het verleden al niet? (X)HTML en CSS 1/2/3 zijn ook webstandaarden, waar helaas verschillende browsers anders mee omspringen (met name IE lapt nogal wat aan z'n laars).

Zo'n nieuwe standaard is een leuk idee, maar je zit nog steeds met hetzelfde probleem dat browserbouwers er zich ook aan zullen gaan moeten houden, doen ze dat niet, dan ben je nog steeds op hetzelfde punt als waar we nu al zijn.

[alex3305]

Het voordeel nu is echter dat Mozilla, Opera en Apple (Safari, KHTML) samenwerken, waardus eerder een goede standaard voor ontwikkeld kan worden.

Dat Microsoft deze regels niet altijd naleefd weten we gewoon, hier kunnen we echter ook bar weinig aan doen IMHO.

EDIT:
Overigens moeten de CSS standaarden ook een keer goed nagekeken worden, niet alleen IE lapt hier veel aan zijn laars, maar ook Mozilla, Opera en Apple doen dit...

[FuzzyLogic66]

Nou, ik denk het niet. Want Opera, Apple en Mozilla hebben minder dan 30% van de markt, dus betekent het dat ruim 70% van de markt voor Microsoft is. En als Microsoft zich niets om de afspraken geeft, dan kun je het fluiten met die nieuwe afspraken.

Je kunt wel een nieuwe standaard maken, maar als vervolgens 70% van de markt je site daarom niet goed kan bekijken dan ga je het natuurlijk niet gebruiken...

[dtech]

Mozilla doet dit idd ook, maar dat moet opgelost zijn met Firefox 3. Apple (Safari) en Opera houden zich al een tijd verregaand aan de standaard, getuige de ACID2 test. Deze test vereis een bijna 100% naleving van de CSS2 standaard (inc foutafhandeling in ingewikkelde situaties). Opera slaagt sinds versie 9 voor de test, Safari slaagt al iets langer (op een scrollbalkje na geloof ik)

[Not Pingu]

En als Microsoft zich niets om de afspraken geeft, dan kun je het fluiten met die nieuwe afspraken.

Maar Microsoft heeft de laatste jaren veel meer oog voor standaarden en goede implementatie daarvan. Hun goede bedoelingen worden op het gebied van reeds in gebruik zijnde HTML smaken dan lang niet altijd waargemaakt (zie ook het lopende topic op GoT) maar een volgende HTML versie zou voor Microsoft een uitgelezen kans zijn om als het ware met een schone lei te beginnen zonder de backwards compatibility te verliezen.

[humbug]

Alleen jammer dat Microsoft zich (nog?) niet heeft aangesloten bij dit initiatief. Elke poging om tot een goede webstandaard te komen lijkt te stranden op het feit dat Microsoft steeds de grote afwezige is bij het tot stand komen van de standaard. Ook nu dus weer.

Blijkbaar ziet Microsoft er niets in, of wordt Microsoft bewust buiten de ontwikkeling gehouden. In beide situaties kun je niet verwachten dat Microsoft HTML 5 gewoon zonder wijzigingen gaat invoeren.

[Splorky]

het wordt tijd dat er een nieuwe html versie komt. en ik ben een fan van IE, maar het lijkt mij verstandig om microsoft geen rol te laten spelen in de ontwikkeling van html5.

laat eerst de rest het eens worden over hoe de code ' gerenderd' moet worden ik weet niet of het renderen heet, maar het zou fijn zijn als alle html5 op alle brouwers het er hetzelfde uit komt te zien, wat dus ook de bedoelling is. als die standaard er is dan kan microsoft IE aanpassen zodat deze de code het zelfde weergeeft als de andere brouwsers.

maar waarschijnlijk zal microsoft wel een eigen draai aan html5 geven, helaas.

[Superdeboer]

FYI, Chris Wilson, de chef Internet Explorer bij Microsoft zegmaar, is enkele dagen geleden vice-voorzitter van de HTML WG geworden. En maar goed ook, ik ben dan géén fan van IE, maar zonder medewerking van Microsoft en zonder input van IE devvers heb je volgens mij echt een loze specificatie. Ik ben blij dat de ontwikkeling van de opvolger van HTML 4.01 vanaf het begin meteen door zo'n breed platform ontwikkeld wordt.

Natuurlijk leidt een en ander nu al tot uitgebreide discussie over hoe zaken aangepakt moeten worden. Zo is Chris Wilson voorstander van versioning: versienummers voor elke nieuwe HTML-specificatie, zodat een web author per document aan kan geven op welke wijze de browser dat moet behandelen. Het voorgestelde <!DOCTYPE html> voor HTML5, zonder versienummer, lijkt hem dus niks.

Wilson betoogt, dat versioning nodig is voor IE, om compatible te blijven met alles wat er nu aan webcontent bestaat. Wilson geeft aan dat ze er bij de ontwikkeling van IE constant tegen aan lopen/liepen, dat ze het gedrag van de browser niet zonder meer kunnen verbeteren naar standards conformant gedrag, omdat ze anders miljoenen bestaande websites vernielen die gebouwd zijn, uitgaande van de manier waarop IE het *fout* (gezien de spec) deed.

In IE6 en IE7 wordt op basis van het doctype geswitcht tussen quirks mode en standards mode: de webdeveloper moet min of meer zelf kiezen voor een behandeling volgens de standaard, door gebruik van het juiste doctype. De default rendering is dus echter: lelijk en met fouten... om het huidige web niet te breken (want alle oude websites hebben natuurlijk ook geen HTML 4.01 doctype en die worden vandaag de dag net zo gerenderd met de debiele bugs zoals die vijf jaar geleden ook al in IE zaten).

Wilson wil dit switchen (en dus anders behandelen) per HTML-versie kunnen blijven doen, ook bij de toekomstige HTML-versies. Eén van de participanten uit de HTML WG zegt het volgende:

"We should be willing (when provided good reasons to do so) to define things that would require even the market leader to break compatibility."

Wilson zegt: we zijn wel marktleider en het merendeel van de bestaande websites is op ons als marktleider geoptimaliseerd. Daarbij is veelvuldig rekening gehouden mét onze bugs."
Als voor een nieuwe HTML-spec die bugs opgelost worden omdat er naar aanleiding van goede testcases een correcte implementatie volgens die nieuwe spec komt, dan kun je die implementatie niet zonder meer op oude sites toepassen, want die webdevvers gingen er vanuit dat IE juist géén implementatie van een goeie specificatie zou hebben. Dus zelfs al is je nieuwe HTML specificatie backwards compatible met de vorige versie van HTML: het feit dat er zoveel websites stuk gaan als IE (met 80 procent marktaandeel) die juiste implementatie op oude sites toepast, zorgt ervoor dat ze dat niet zullen doen.

Kortom: Microsoft wil bést een standards compliant rendering en ze willen heel graag een bugvrije implementatie van een nieuwe HTML-specificatie, maar ze kunnen die niet zomaar op alle bestaande content toepassen (zelfs dus als de HTML-spec volledig backwards compatible is), omdat de meeste (?) websites gebouwd zijn voor oudere versies van IE die het niet nauw namen met standaarden. De enige oplossing daarvoor lijkt voor Wilson dus versioning: elke content kunnen blijven behandelen volgens de rendermethode die gebruikt werd ten tijde dat de website gemaakt werd.

Chris Wilson maakt wel een sterk punt in zijn essay waar ik net naar linkte. De HTML WG heeft als uitgangspunten onder meer: 'Don't Reinvent The Wheel', 'Pave The Cowpaths' en 'Evolution Not Revolution'. Anders gezegd: bestaande implementaties of veel gebruikte praktijken moeten in beginsel op die wijze gespecificeerd en gestandaardiseerd worden, in plaats van ze te verbieden en te menen een beter alternatief te moeten introduceren. Daar is de ontwikkeling van XHTML2 juist misgelopen: bestaande praktijken worden 'verboden' en er wordt een zogenaamd 'beter' alternatief voor in de plaats gezet. Zo kun je de webdevelopers community dus niet sturen, zo blijkt na zoveel jaar. Standaarden moeten (goede) bestaande praktijken beschrijven om tot een eenheid te komen. Door het verbieden van een veelgebruikte praktijk en het bieden van een kunstmatig alternatief bevorder je geen eenheid.
Met dat in het achterhoofd zegt Wilson:

"This DOES NOT (in my opinion) give us (the WG) the license to break compatibility with current standards like HTML 4.01 - like XHTML 2 did, or even like XHTML 1.1 - unless that standard does not represent current practice in browsers, in which case we have a decision to make."

Met zoveel marktaandeel (hoe weinig fan ik ook ben van IE) moet je toch zo eerlijk zijn om toe te geven dat IE de de facto standaarden bepaalt op dit moment: IE is de current practice over de afgelopen tien jaar geweest. Voor de toekomst kan dat natuurlijk allemaal veel mooier en beter, als IE ook een standards compliant implementatie heeft... maar dat moet dan alleen op nieuwe documenten toegepast worden, die onder de nieuwe specificatie gemaakt zijn. Een vorm van versioning lijkt dan inderdaad onontbeerlijk om het dilemma van Microsoft op te lossen. Wat alleen dramatisch wordt, is dat je dan voor elke HTML-periode een gelockte rendermethode krijgt... waarin de op dat moment bestaande bugs of implementatiefouten van IE bevroren worden en de komende honderd jaar in die browser ingebakken moeten worden voor documenten uit die periode, omdat die documenten anders lelijk weergegeven worden.

Juist echter vanwege dit soort buitengewoon belangrijke praktijkkwesties is het dus onontkomelijk en juist alleen maar goed dat ook Microsoft meewerkt aan de specificatie. Een specificatie die zonder de medewerking van een vertegenwoordiger van het IE-team door een stel uiterst theoretische standards advocates wordt geschreven en daarbij niet de praktische implicaties in het oog houdt, zou door Microsoft (terecht) meteen ter zijde geschoven worden. Dan heb je een hoop werk verzet en helemaal geen resultaat (of net zo weinig als met XHTML... dus verwaarloosbaar). Ik ben juist blij dat de ontwikkeling zo breed gedragen wordt in de industrie.

[Justice]

Waarom wordt er dan niet gekeken naar methodes om brakke html om te zetten in betere html (perfect zal het nooit worden) in plaats van de brakke html te blijven ondersteunen.

[Superdeboer]

Ik weet niet of je het probleem van Microsoft helemaal ziet. Microsoft heeft een marktaandeel van 80%, dat in de afgelopen tien jaar nog stukken hoger heeft gelegen. De meeste sites die gedurende die tijd zijn geschreven, zijn (daarom) uitgegaan van de implementatie in IE.

Sites worden niet geschreven puur volgens de specificatie. Sites worden geschreven naar de implementatie(s) van de browser(s). Simpelweg: je pielt net zo lang totdat je in een specifieke browser die layout hebt die je beoogde - je stopt niet zodra je document valideert volgens de spec!

Verreweg het merendeel van de bestaande webcontent is dus ontwikkeld zodat het er goed uitziet in IE, óndanks dat IE rare bugs heeft en niet overal de bestaande HTML-specificaties volgt. Vanaf IE6 probeert Microsoft standards compliant te renderen. Laten ze echter die standards compliant rendering los op *alle* oude content, die er juist van uitgaat dat IE niet standards compliant is, dan vernielen ze dus die sites voor iedereen die die content met die browser bekijkt. Juist om die reden is standards compliant rendering in IE een opt-in geworden: het gebeurt pas als de webdevver door gebruikmaking van het HTML 4.01 doctype aangeeft dat IE die pagina volgens de standaard moet renderen. De webdevver zegt tegen IE: "ik vertrouw erop dat jij, IE6/7, deze pagina conform de HTML 4.01 spec afhandelt en omdat ik dat per se wil, gebruik ik dat doctype". Wordt dát doctype niet gebruikt (sowieso alle legacy content van vóór HTML 4.01), dan wordt standaard volgens de oude methode (quirks mode) gerenderd.

De working draft voor HTML5 van de WHATWG, zoals die nu als uitgangspunt voor de HTML WG wordt genomen, gaat uit van een nieuw doctype <!DOCTYPE html>, waarbij dus niet zoals vroeger een versienummer wordt gebruikt. Dit doctype triggert de huidige standards mode in IE. Als Microsoft de HTML5 spec precies juist implementeert, wordt die rendering dus automatisch toegepast op de content die voor de huidige standards mode van IE (met o.a. zijn floatbugs en andere ongein) is geschreven. Als HTML5 dan ook maar iets afwijkt van de huidige implementatie van HTML4 in IE, wordt er dus oude content gesloopt, iets dat Microsoft zich niet kan veroorloven met zo'n ontzettend groot aantal gebruikers.

Jouw voorstel is dus niet uitvoerbaar, als ik je tenminste goed begrijp. Brakke HTML in legacy content blijft brakke HTML: die content verandert nooit meer.
De enige manier om die oude, brakke HTML, die is geschreven met de brakke implementatie van IE in het achterhoofd, goed te renderen, is op de brakke manier waarop IE het altijd heeft gedaan, waar de webdevvers van uitgingen bij het maken van de site. Dan moet IE dus een onderscheid kunnen maken tussen de verschillende HTML-versies. Voor nieuwe HTML kunnen ze natuurlijk de juiste rendering gebruiken als ze de HTML5 spec goed geïmplementeerd hebben, maar als die spec dus afwijkt van de oude implementatie dan kunnen ze de nieuwe rendering niet op oude content toepassen.

Ian Hickson, de editor van de HTML5 working draft van de WHATWG, stelt hier simpelweg tegenover dat er dus net zo lang aan de HTML5 spec geknutseld dient te worden, tot een juiste implementatie van die spec, toegepast op oude content, geen gebroken websites oplevert. De enige manier is dus volgens hem: spec maken, implementeren, spec aanpassen en implementatie aanpassen (iteratief). Als dát goed lukt, dan kan de implementatie van HTML5 natuurlijk zonder meer over de oude content heen gerausd worden. In dat geval heb je geen versioning nodig, want dan is de HTML5 spec zélf compatible (genoeg - zal nooit 100% zijn) met oude content die voor IE is geoptimaliseerd. Als een opvolger van HTML5 dan volstrekt back compat is met HTML5, kun je óók dan weer van <!DOCTYPE html> gebruik maken, zonder dat je van rendering hoeft te switchen op basis van een versienummer om gebroken pagina's te voorkomen...

Het schijnt mij toe dat Chris Wilson (van Microsoft) dat niet helemaal ziet gebeuren in de praktijk en voor de zekerheid kiest waarbij in de IE implementatie zelf op basis van een HTML-versie de soort rendering kan worden gekozen. Elke HTML-versie zijn eigen rendering dus. Dit is een fundamenteel verschil van opvatting denk ik. Wilson denkt (begrijpelijkerwijs) heel praktisch, vanuit het standpunt van IE als oudste browser met verreweg het grootste aantal gebruikers. Ian Hickson denkt vanuit het standpunt van de spec-editor. Ik kan nog niet goed beoordelen of het ideaal van Hickson in de praktijk haalbaar is, maar puur theoretisch is dat uiteraard verreweg de meest verkieslijke optie. Die vaststelling maakt echter het standpunt van Microsoft in zijn situatie niet minder begrijpelijk.

[Daenney]

Klinkt goed, vooral het standardiseren van het afhandelen van niet valide code is iets waar ik al jaren zit op te wachten,. dan ziet een bogus pagina er tenminste overal bogus uit en niet bogus in FF etc en wel correct in IE, zoiets zou webdevvers ook een stuk bewuster moeten maken.
Als iedereen nu nog eens eenzelfde implementatie van CSS3 zou willen bouwen ben ik helemaal blij.
Verder vind ik XHTML opzich wel prettig, de koppeling met XML stelt je wel in staat veel te doen met dynamische generatie en weergave van feeds e.d en bij XHTML was tenminste duidelijk wat wel en niet mocht, HTML4.01 is een grote soep waar iedereen tussendoor ook nog even zijn eigen tags uitvond of nieuwe arguments bij bestaande tags die de rest van de browsers dan weer niet snapten...
Het W3C moet hier wel even mee gaan opschieten, dan kan iedereen tenminste even opgelucht ademhalen en verder is het gewoon belangrijk dat HTML met de tijd mee evolueert.
Dat IE moeite heeft met XHTML vind ik meer een fout van Microsoft dan van het W3C, MS mag ook eens wat meer tijd in hun browser steken.

[Little Penguin]

De WHATWG probeert wel te voorkomen dat iedereen zijn eigen tags gaat uitvinden - niet helemaal gelukt als je naar 'canvas' kijkt, maar goed.

Het doel van de WHATWG is juist het opstellen van specificaites die daarna door de browser-fabrikanten geimplementeerd kunnen worden, waarbij backwards compatibiliteit erg belangrijk is - iets dat in de XHTML standaard nooit aanwezig geweest is.

Vanwege de non-support van MS voor XHTML is die backwards compatibiliteit (of beter het ontbreken ervan) het grote struikelblok van XHTML - verder had het idd alleen maar voordelen, omdat XHTML een stuk strakker gespecificeerd was.

Waaruit maar weer blijkt dat het slechts is als een partij een monopolie heeft, de innovatie is er namelijk door afgeremt!!!

[Blaise]

Ook Apple heeft aangegeven XHTML2 niet te willen steunen:

We declined to participate in the HTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.

[Verwijderd]

@Blaise: Heb je hier toevallig een link van naar de pagina waar dit staat? Lijkt me wel interessant om te lezen waarom ze geen XHTML2 willen ondersteunen namelijk.

edit:

hmm, ik had natuurlijk ook Google kunnen gebruiken
http://www.digital-web.co...nd_the_future_of_the_web/

[Verwijderd]

Er moet eigenlijk een keep-alive HTTP protocol komen dat veranderingen doorgeeft waardoor je active sites kan krijgen, dus niet met PHP+AJAX maar dat je echt met een instandhoudende connectie werkt. Dat zou waanzinnig veel verbetering op het internet kunnen betekenen. Een daarbij passende Markup Language moet dan uiteraard ook worden gemaakt.

Overigens wel relaxt dat W3C een standaard hanteerd en een eigen check-systeem heeft!

[Roland684]

Dat kan al hoor, als je voor lief neemt dat je browser-ikoontje blijft draaien (en terecht, want de pagina is nooit klaar met laden). Je kunt bijvoorbeeld gewoon javascript blijven sturen en zo de pagina blijven updaten.
En als er geen verandering is, geeft een revisit van een pagina door aan je browser dat hij de site in zijn cache moet gebruiken, dus elke 5 seconden refreshen hoeft nauwelijks dataverkeer tot gevolg te hebben.

Maar een probleem dat optreedt als je van alle pagina's streams zou gaan maken, is dat de server dan heel erg veel connecties moet gaan bijhouden en het beschikbaar aantal poorten is gewoon beperkt (al zul je eerder door je geheugen heen zijn)

Maar ik heb het idee dat jij een oplossing zoekt voor een heel specifiek probleem, ik kan me weinig toepassingen voorstellen waarbij iets dergelijks nuttig is.

[flowerp]

Maar ik heb het idee dat jij een oplossing zoekt voor een heel specifiek probleem, ik kan me weinig toepassingen voorstellen waarbij iets dergelijks nuttig is.

Ik heb het idee dat jij niet zo veel verstand van developpen hebt.

Wat we tegenwoordig steeds meer doen is applicaties remote draaien via het web. Vele "web sites' zijn eigenlijk "web applicaties".

HTML en HTTP zijn oorspronkelijk bedoeld voor simpele information browsing sites. Niet voor statefull & rich applications. Als programmeur moet je je dus nu in zeer veel bochten wringen om web applicaties te realiseren. Solide frameworks als Java EE en ASP.NET (among others) helpen wel een eind om de pijn te verzachten, maar feit blijft dat zelfs antieke frameworks/widget sets als MFC en Motif een 10x zo rijk programmeermodel hebben als de huidige web frameworks kunnen bieden.

[daank]

Auch, lekker als er 1000 concurrent connections zijn met een website.. wil alleen al niet weten wat dit dan server-side doet..

[Larsie]

Dat is dus een probleem voor de 'programmeur'. (zodra we zo'n standaard hebben)
Net alsof je een normaal programma niet zou schrijven omdat er mogelijk teveel mensen gebruik van gaan maken...

[Verwijderd]

Ik hoor hier alleen maar slechte commentaar? Ik vind de nieuwe specificaties best wel goed, vergeet niet dat heel veel websites gemaakt zijn door de "hobby man / vrouw" met zijn PC waar een voor geïnstalleerde frontpage editor of dergelijke op zat en ze nu pas verder kijken dan de wysiwyg omgeving door dat men het boek "html voor dummies" gekocht heeft of dergelijke ... XHTML is voor veel "dummies" al onmiddellijk een grote stap omdat ze vaak amper weten wat nog maar een <meta> tag is of laat staan een <object> ... ik vind HTML 5 duidelijker, omdat er meer specifieke tags bestaan zoals <video></video>, <audio></audio>, <code></code>, <dialog> ... etc, waar ik wel akkoord mee ben is dat er eindelijks gewerkt gaat moeten worden aan CSS

[g4wx3]

Ik had juist liever gehad, dat alles was omvat in <object>
MEt een javascripte, zou het dan makkelijker zijn geweest, om te swichten tussen audio/video/flash/afbeelding.

BTW: Ik had ook graag de toevoeging gehad aan de audio, om een visual toe te voegen.

[2playgames]

je kunt altijd de inhoud in een div zetten, en daar de innerHtml van aanpassen

maar iid, <object> is beter. dan kun je ook makkelijker "onbekende" objecten zoals b.v. een flash animatie of java applet invoegen

[nAFutro]

Een ander probleem volgt uit het feit dat de verwerking van xml stokt zodra er een fout in de syntaxis voorkomt.

Dit kan een begin zijn van hele veilige pagina's, designers zien vaak de gaten over het hoofd omdat het eindresultaat er uit ziet zoals zij het wensen. Dat het onder water allemaal rechtgetrokken word door de browser helpt niet in dat soort gevallen en als een deel van de pagina niet zichtbaar is omdat je niet aan de specs hebt voldaan merk je dat heel snel als designer.

[Blaise]

Dan haal je het door de W3C validator.

Ik zit er niet echt op te wachten dat allemaal webpagina's het niet doen omdat de webmaster ergens een element vergat af te sluiten.

[Verwijderd]

Gelukkig geven ze het goede voorbeeld:
http://validator.w3.org/c...tically%29&doctype=Inline

[user109731]

Je gebruikt een xhtml/html4 validator om een html5 pagina te valideren? Misschien dat die pagina zelf al de daarin beschreven regels volgt? Dat is wel zo leuk

@Bob_: waarom zou je het niet mogen gebruiken als er nog geen implementatie is?

[Verwijderd]

HTML 5 is een draft die door nog geen enkele browser wordt ondersteund. Dus nee het is geen html5.

Het blijkt HTML 4.01 strict te zijn maar dan moet er _wel_ een doctype gespecificeerd zijn.

[dmantione]

Apple, Opera en Mozilla zijn al lang bezig met het implementeren van HTML5. Ook KDE is er mee begonnen. Probeer maar eens hoeveel HTML5 je huidige browser al slikt, je zult versteld staan, mits het een beetje recente browser is en het niet om IE of Links gaat.

[Jero]

Ze geven zeker het goede voorbeeld. Het enige wat de WHATWG "verkeerd" heeft gedaan in dit document is dat ze niet een DOCTYPE hebben gebruikt die in één van de voorgaande HTML specificaties is verplicht. Dit is met opzet gedaan omdat de WHATWG tegen het gebruik van een DOCTYPE is. Een DOCTYPE stamt immers af uit de afkomst van HTML, namelijk SGML. De WHATWG heeft echter de conclusie getrokken dat HTML niet meer als SGML applicatie gezien kan worden omdat HTML een eigen leven is gaan leiden. Dit is voor hen dus de reden om zoveel mogelijk afstand te doen van een DOCTYPE. De enige reden om niet helemaal afstand ervan te doen is voor backward compatibility.

Voor de rest is de pagina echter valide HTML 4.01. Dit kan je checken door de validator in te stellen met een HTML 4.01 Strict DOCTYPE:
http://validator.w3.org/c...TML+4.01+Strict&verbose=1

[_Thanatos_]

Maar leggen ze dan ook uit hoe je dan moet zien of je te maken hebt met HTML2, HTML3, HTML4, XHTML of HTML5?

[Jero]

Het is niet echt relevant welke versie van HTML gebruikt wordt. Elke versie van HTML is immers backward compatible. Dus als enkel de laatste versie van HTML wordt ondersteunt, dan ondersteun je dus in feite alle versies van HTML.

Bij XHTML wordt er gekeken naar het internet media type. XHTML en HTML zijn twee verschillende talen en hebben daarom hun eigen internet media type waaraan je kan zien welke taal voor de opbouw wordt gebruikt. Wordt XHTML verstuurd met het media type van HTML, dan wordt er gedaan alsof de pagina is opgebouwd in HTML 4.01.

[_Thanatos_]

Dus je kunt niet meer aangeven hoe een document gevalideerd moet worden, nog hoe het geparst dient te worden. Dat legt toch wel een beperking op, omdat browsers wel degelijk hun rendering kunnen aanpassen aan de versie van het documenttype. Immers, de regels die specifieren hoe e.e.a. gerenderd dient te worden, kunnen verschillen per HTML-versie.

Maar validatie ook; als je een HTML4 document moet maken, moet je daar niet HTML5 dingen in gaan stoppen. Doe je dat wel, dan werken er dingen niet, terwijl de validator het allemaal prima vindt. Wat is er dan fout? Zoek het maar uit... en dat probleem wordt erger bij meer nieuwere versies van HTML.