W3C drukt last call-stempel op html 5
Het World Wide Web Consortium heeft de last call voor de html 5-standaard uitgegeven. Deelnemers krijgen tot 3 augustus de tijd om hun laatste op- en aanmerkingen op de nieuwe webstandaard kenbaar te maken.
De html 5-specificatie is opgesteld door de HTML Working Group waarin vijftig W3C-leden en meer dan tweehonderd deskundigen zitting hebben. Met het uitroepen van de last call krijgen derden nog kans om mogelijke problemen in de webstandaard aan te kaarten, zodat deze verholpen kunnen worden. Zo spelen er nog enkele kwesties over de vraag of html 5 voldoet aan de normen voor toegankelijkheid.
Naast html 5 zijn er ook vijf gerelateerde specificaties die de last call draft-status hebben gekregen: HTML+RDFa 1.1, HTML Microdata, HTML Canvas 2D Context, Polyglot Markup en HTML 5: Techniques for providing useful text alternatives. Ook heeft de W3C drie aanvullende documenten als ontwerp gepubliceerd. Deze hebben echter nog niet de last call-status gekregen.
Volgens het huidige tijdsschema van de W3C moet de standaard in 2014 definitief zijn afgerond. Toekomstige versies van de html-standaard krijgen mogelijk geen versienummer meer, als het aan de WhatWG-werkgroep ligt die met de W3C heeft samengewerkt voor het bouwen van html5. Volgens hen is het de bedoeling dat html een 'levende standaard' wordt, die continu evolueert. De standaard zou dan ook gewoon 'html' moeten gaan heten.
Reacties (78)
2014 definitief zijn afgerond? Ondertussen gebruikt iedereen het al volop. Die jongens gunnen zichzelf teveel tijd. Opschieten, luiwammeses!
Ik denk ook wel eens, waarom moet dat zo lang duren!
Maar om ze nou luiwammesen te noemen! Ga zelf eens aan een project werken wat wereldwijd invloed heeft. Ben je met een paar jaar niet klaar mee! Ik werk momenteel aan een project waar slechts 4 man actief in zit en in totaal 16 man. Ben er niet fulltime mee bezig maar je bent al snel een jaar verder voordat specificaties goed op papier staan. En dan gaat het nog om een veel simpeler en kleiner project dan een HTML 5 standaard.
Maar om ze nou luiwammesen te noemen! Ga zelf eens aan een project werken wat wereldwijd invloed heeft. Ben je met een paar jaar niet klaar mee! Ik werk momenteel aan een project waar slechts 4 man actief in zit en in totaal 16 man. Ben er niet fulltime mee bezig maar je bent al snel een jaar verder voordat specificaties goed op papier staan. En dan gaat het nog om een veel simpeler en kleiner project dan een HTML 5 standaard.
[Reactie gewijzigd door Timo002 op donderdag 26 mei 2011 15:36]
Zoals W3C dit nu doet is wel netjes. In plaats van pas in 2014 te komen met een document, wordt deze nog steeds bijgewerkt op basis van commentaar op werkelijke tussentijdse implementaties.
Het is in deze tijd niet verstanding om een jaar lang alleen maar specificaties op te stellen en daarna te beginnen met implementeren.
Beter kun je high level requirements opstellen... vervolgens opslitsen in onderdelen die je maandelijks kunt specificeren en tot een echte werkende oplevering brengen, zodat je op tijd feedback kunt krijgen en kunt bijsturen.
Tenzij je iets bouwt dat gemaakt wordt om echt tientallen jaren te functioneren, kun je beter interatief werken dan incrementeel.
Het is in deze tijd niet verstanding om een jaar lang alleen maar specificaties op te stellen en daarna te beginnen met implementeren.
Beter kun je high level requirements opstellen... vervolgens opslitsen in onderdelen die je maandelijks kunt specificeren en tot een echte werkende oplevering brengen, zodat je op tijd feedback kunt krijgen en kunt bijsturen.
Tenzij je iets bouwt dat gemaakt wordt om echt tientallen jaren te functioneren, kun je beter interatief werken dan incrementeel.
Liever een standaard waar goed over is nagedacht dan dat je als webdeveloper voor 10 verschillende browsers moet testen...
Het probleem is over het algemeen niet de standaard, maar de developers van de browsers. Er is al jaren een standaard voor (X)HTML, maar pas recentelijk kan Internet Explorer (één van de grotere spelers op de markt) een 'valide' pagina correct weergeven. Er kan dus nu wel goed over de standaard nagedacht worden, maar dat is slechts de helft van het verhaal.
Het probleem met (X)HTML was weldegelijk de standaard, die was gewoon ambigu opgezet en had tal van layoutproblemen die niet eenduidig interpreteerbaar waren.Het probleem is over het algemeen niet de standaard, maar de developers van de browsers. Er is al jaren een standaard voor (X)HTML, maar pas recentelijk kan Internet Explorer (één van de grotere spelers op de markt) een 'valide' pagina correct weergeven.
Dit staat natuurlijk los van het feit dat IE (En andere browsers net zo goed overigens) sowieso een eigen draai aan dingen gaf, maar ookal hield iedereen zich aan de standaard dan nog kon het verschillend zijn.
[Reactie gewijzigd door .oisyn op donderdag 26 mei 2011 17:39]
De X tussen haakjes is in deze niet echt terecht want HTML (4.01, want dat is dé versie die iedereen gebruikt) en XHTML zijn toch wel wezenlijk verschillend. Ze zijn ook incompatible van elkaar waardoor een fragment markup eigenlijk vrijwel niet tegelijk XHTML compliant kan zijn en HTML compliant.
imho is XHTML een beetje geflopt. Met HTML5 wil men gelukkig de incompatibiliteit de wereld uitdrukken waardoor je HTML5 gewoon kunt uitdrukken als XML document (wat eigenlijk is wat je wil). Intussen wordt het hele XHTML modularization gebeuren door iedereen straal genegeerd (en terecht want wat heb je er aan. Geef ons nou maar gewoon die video en canvas tags waar we al jaren op wachten).
imho is XHTML een beetje geflopt. Met HTML5 wil men gelukkig de incompatibiliteit de wereld uitdrukken waardoor je HTML5 gewoon kunt uitdrukken als XML document (wat eigenlijk is wat je wil). Intussen wordt het hele XHTML modularization gebeuren door iedereen straal genegeerd (en terecht want wat heb je er aan. Geef ons nou maar gewoon die video en canvas tags waar we al jaren op wachten).
Dit klopt niet helemaal: xhtml is, na verandering van de doctype, zo goed als altijd geldige html. Xhtml is, heel kort door de bocht, html waarbij je gedwongen wordt om alles goed af te sluiten, en bepaalde attributen altijd in te vullen. Ik kan me niet heel snel iets voor de geest halen uit xhtml wat niet geldig is in html.
Wat dacht je van 'iedere XML specific extension zoals CDATA e.d.'? Dat is in HTML4 gewoon 'text'.
Zelfs zaken als <br /> leveren je een warning op in HTML:
Maar deze discussie is over het algemeen academisch aangezien 99% van de documenten op het web met een XHTML doctype toch gewoon als text/html geserveerd worden en daarmee door elke browser als HTML worden behandeld. Daarbij is het overgrote deel van die betreffende documenten niet eens valide XHTML en zou het parsing door een XML parser niet overleven
Verder kan de DOM verschillen tussen XHTML en HTML wat issues in scripting en CSS kan opleveren.The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML.
Maar deze discussie is over het algemeen academisch aangezien 99% van de documenten op het web met een XHTML doctype toch gewoon als text/html geserveerd worden en daarmee door elke browser als HTML worden behandeld. Daarbij is het overgrote deel van die betreffende documenten niet eens valide XHTML en zou het parsing door een XML parser niet overleven
En dat wordt nu alleen maar erger dus. Doordat er geen versienummering zal zijn, ga je dus niet meer weten wat de browser nu eigenlijk ondersteund. Voorheen was het eenvoudiger: IE ondersteunde gewoon geen HTML 5 bv. In de toekomst ga je dus niet meer weten over welke features het gaat als men het heeft over "HTML"...
Zoiets als een levende standaard kan alleen maar als browsermakers altijd kort op de bal spelen. In het verleden is al genoeg gebleken dat dit louter wishful thinking is.
Zoiets als een levende standaard kan alleen maar als browsermakers altijd kort op de bal spelen. In het verleden is al genoeg gebleken dat dit louter wishful thinking is.
Misschien dat dit wel mee gaat vallen. In het verleden was de ontwikkeling van browsers lang niet zo levend als nu (en het aandeel IE onder de internetgebruikers) is toch behoorlijk geslonken).Zoiets als een levende standaard kan alleen maar als browsermakers altijd kort op de bal spelen. In het verleden is al genoeg gebleken dat dit louter wishful thinking is.
Je vergeet dat HTML oorspronkelijk is bedoeld als levende standaard. De versienummering is later pas toegevoegd maar heeft eigenlijk nooit goed gewerkt. De meest recente versie van HTML bijvoorbeeld, HTML 4.01 stamt alweer uit 1999 en is toch pas een paar jaar echt goed ondersteund. Al die tijd kon je wel gebruik maken van de meeste features en zelfs ook van nieuwere features, met hier en daar een workaround (alternatieve elementen, browser detectie, plugins).In de toekomst ga je dus niet meer weten over welke features het gaat als men het heeft over "HTML"
Zolang je nieuwe features kunt detecteren en effectief alternatieven aan kunt bieden heeft een fijnmazige variant veel voordelen t.o.v. de hele standaard ineens naar een volgende versie te gooien. Anders gaat het steeds jaren en jaren duren, niet alleen om de standaard te ontwikkelen maar ook voordat alle browsers hem volledig ondersteunen. Persoonlijk geloof ik wel in de aanpak van HTML5. Het is vooral een hele pragmatische en no-nonsense standaard en dat is wat het web nodig heeft want er zijn gewoon te veel spelers (browsers, platforms, bestaande pagina's) om hele ambitieuze dingen te doen.
Zulke ambitieuze plannen heeft het W3C wel gehad maar zijn eigenlijk over de hele linie gefaald: XHTML, XFORMS, OWL , allemaal hebben ze geprobeerd iets bestaands radicaal te veranderen en geen van allen zijn echt doorgebroken. (Om een voorbeeld te geven van het ambitie niveau van W3C, als je kijkt naar het adres onder de XHTML link dan zie je dat in de ogen van W3C XHTML dé HTML standaard is. Een de praktijk is HTML 4.01 die echter nog steeds en het ziet er niet naar uit dat het XHTML gaat worden voorlopig, maar eerder HTML 5).
Dit is nu juist het sterke punt in html5.
Het is dus ook de bedoeling dat je niet meer gaat bijhouden wat welke browser ondersteund.
Maar alles wat je maakt eerst even aan de browser vraagt "he kan jij dit?" zoniet los je het anders op of laat je het voor die browser weg. "
bv ie6 kan ook een html 5 pagina laten zien geen probleem.
Alleen is het aan de maker van de pagina om te zorgen dat het goed word weer gegeven. En dat doe je niet meer door te vragen "he ben jij ie6 maar door he kan jij dit?""
Er zjin al tools voor die je dit makkelijk maken Modenizer.js.
Uiteindelijk maak het dus niet meer uit welke browser er wordt gebruikt en wat deze ondersteund, omdat onderdeel van de standaard is dat je altijd checked of de browser het aan kan.
Het is dus ook de bedoeling dat je niet meer gaat bijhouden wat welke browser ondersteund.
Maar alles wat je maakt eerst even aan de browser vraagt "he kan jij dit?" zoniet los je het anders op of laat je het voor die browser weg. "
bv ie6 kan ook een html 5 pagina laten zien geen probleem.
Alleen is het aan de maker van de pagina om te zorgen dat het goed word weer gegeven. En dat doe je niet meer door te vragen "he ben jij ie6 maar door he kan jij dit?""
Er zjin al tools voor die je dit makkelijk maken Modenizer.js.
Uiteindelijk maak het dus niet meer uit welke browser er wordt gebruikt en wat deze ondersteund, omdat onderdeel van de standaard is dat je altijd checked of de browser het aan kan.
Dat moet je sowieso gaan doen, aangezien ze allemaal de standaard anders implementeren (al verschilt het bij sommige zeer weinig)
Werkt eerder andersom, die webdeveloper test toch niet in 10 browsers want dat kost tijd en tijd = geld. Met een goede standaard en implementatie daarvan hoeft dat ook niet want dan werkt het wel.
Om een voorbeeld te noemen, google is constant druk bezig om het testen makkelijker te maken. Voor diegene die iets meer technische kennis hebben kan dit filmpje interessant zijn (vooral voor publiek gericht die iets kennen van unit testing, maar bevat ook informatie over hoe google probeert het testen te schalen).
Was het maar zo, als webdev kan je je niet veroorloven dat je werk het in een browser niet doet...als je klant ineens een telefoontje heeft gekregen van een bedrijf waar ze nog in IE6 werken dat de website daar niet werkt of iets vreemds doet krijg je dat gewoon over je heen, kan je het lekker aan gaan passen...
Dat laatste zullen we voorlopig toch wel houden omdat iedere browser wel weer zijn eigen dingen doet.
2014 is nog een lange tijd weg, en als je ziet hoe snel web development groeit vraag ik mij af of het tegen die tijd al niet weer een beetje zal worden voorbij gestreefd door allemaal extra's.
We hebben nu eindelijk een canvas tag, maar is dat over 3 jaar nog wel toereikend? Wie is de eerste browser maker die het uitbreid met weer eigen implementaties?
Ook denk ik dat silverlight/flash achtige plugins tegen die tijd weer in opkomst zullen zijn om te kunnen voldoen aan de eisen van de gebruikers.
HTML 5 had al lang klaar moeten zijn. En die levende standaard, hoe ga je dat handhaven als webdeveloper?
2014 is nog een lange tijd weg, en als je ziet hoe snel web development groeit vraag ik mij af of het tegen die tijd al niet weer een beetje zal worden voorbij gestreefd door allemaal extra's.
We hebben nu eindelijk een canvas tag, maar is dat over 3 jaar nog wel toereikend? Wie is de eerste browser maker die het uitbreid met weer eigen implementaties?
Ook denk ik dat silverlight/flash achtige plugins tegen die tijd weer in opkomst zullen zijn om te kunnen voldoen aan de eisen van de gebruikers.
HTML 5 had al lang klaar moeten zijn. En die levende standaard, hoe ga je dat handhaven als webdeveloper?
Gracefull degration, je implementeerd het, werkt het niet, val je terug op iets wat simpeler is e.d.HTML 5 had al lang klaar moeten zijn. En die levende standaard, hoe ga je dat handhaven als webdeveloper?
Tip: http://www.alistapart.com...ngprogressiveenhancement/
Lees ook eens zijn twwe opvolgende artikelen, interessant voer!
Lees ook eens zijn twwe opvolgende artikelen, interessant voer!
Is ook mogelijk inderdaad, beide idee-en komen op hetzelfde neer, de browsers die het ondersteunen krijgen mooiere en luxere dingen voorgeschoteld, in browsers waar het niet werkt is het wat minder fancy.
Je bedoelt waarschijnlijk graceful degradation, iets wat je makkelijk kan implementeren met behulp van feature detection libraries zoals Modernizr.
De webdeveloper is dus nog luier dan de standaardopstellerdan dat je als webdeveloper voor 10 verschillende browsers moet testen...
Vergeet niet als er goede eenduididge web standaarden zouden zijn, zouden webdevelopers veel minder werk hebben, veel minder expertise nodig hebben en dus ook minder verdienen.En zich veel meer kunnen bezig houden met de kern van hun taak in plaats van andermans fouten op te lossen. Een webdeveloper/designer heeft normaal gezien geen baat bij deze fouten, integendeel.
huh? dan zouden ze gewoon meer sites er uit kunnen stampen en juist meer verdienen!
Nonsens. Webdevelopers zullen zich kunnen concentreren op het daadwerkelijke developen en dus creatiever zijn, en tijd hebben voor meer opdrachten. Opdrachtgevers zullen minder hoeven te betalen voor onzin als ondersteuning voor verschillende browsers en dus makkelijker een goeie webdeveloper kunnen betalen. Win-win dus.[...]
Vergeet niet als er goede eenduididge web standaarden zouden zijn, zouden webdevelopers veel minder werk hebben, veel minder expertise nodig hebben en dus ook minder verdienen.
inderdaad.. teveel porno, gekloot met hacks en games tijdens het werk 
gewoon eind 2012 hoogstens.. anders hebben we er uberhaupt niks meer aan
gewoon eind 2012 hoogstens.. anders hebben we er uberhaupt niks meer aan
Dat dacht Microsoft destijds ook, met IE5 en IE6 als gevolg. Ik denk dat dat genoeg zegt.Opschieten, luiwammeses!
Ik begrijp het niet echt? Wat bedoelen ze precies met last call? Er staat dat ze tot 2014 de tijd hebben?
Daarmee wordt bedoeld dat men nog éénmaal op- en aanmerkingen kan geven:
Deelnemers krijgen tot 3 augustus de tijd om hun laatste op- en aanmerkingen op de nieuwe webstandaard kenbaar te maken.
Met last-call wordt bedoeld dat de blauwdruk van de standaard eigenlijk gewoon af is en dat ze die gaan publiceren zoals die nu is, tenzij een van de deelnemers aan de discussie er nu nog achter komt dat er toch iets verandert moet worden.
Dat betekent niet dat je nu nog aan kan komen met een opmerking als: Die of die functionaliteit wil ik er nog bij of die functionaliteit moet er nog uit.
Wat kan je nog wel voor elkaar krijgen: Deze of die zin moeten we toch wat anders formuleren. Bijvoorbeeld omdat bij nader inzien een bepaalde zin toch dubbelzinnig kan worden uitgelegd.
Dat betekent niet dat je nu nog aan kan komen met een opmerking als: Die of die functionaliteit wil ik er nog bij of die functionaliteit moet er nog uit.
Wat kan je nog wel voor elkaar krijgen: Deze of die zin moeten we toch wat anders formuleren. Bijvoorbeeld omdat bij nader inzien een bepaalde zin toch dubbelzinnig kan worden uitgelegd.
Tot 3 augustus mogen mensen nog aan/opmerkingen geven. Daarna hebben ze (W3C) tot 2014 om dit allemaal nog aan te passen aan de standaard.
Begin 2014 of eind 2014 ... maakt ook nogal uit...Volgens het huidige tijdsschema van de W3C moet de standaard in 2014 definitief zijn afgerond.?
[Reactie gewijzigd door tes_shavon op donderdag 26 mei 2011 15:34]
Dat zal waarschijnlijk in de loop van volgend jaar beter gespecifiëerd worden, wanneer de grootte van eventuele problemen duidelijk wordt.
Maar ja hoe weet je dan of een bepaald device of een browser iets ondersteund? Dan moet je per feature gaan kijken. Een bepaalde releasenummering is toch best handig lijkt mij.Toekomstige versies van de html-standaard krijgen geen versienummer meer; het is de bedoeling dat html een 'levende standaard' wordt, die continu evolueert. De standaard zal dan ook gewoon 'html' gaan heten.
Per feature kijken is de enige betrouwbare manier (nu al) om te kijken of een browser iets ondersteund.
Inderdaad. Theoretisch is die 'release nummering' prachtig, maar in de praktijk zijn er teveel verschillende browsers die allemaal hun eigen tijdpad hebben en die het allemaal volledig moeten implementeren. Dus of je moet tien jaar wachten totdat elke browser de 'game' tag ondersteunt (hypothetisch voorbeeld), of je moet hem gaan detecteren en diegene die hem nog niet ondersteunen een flash game alternatief aanbieden bijvoorbeeld.
Die 10 jaar is natuurlijk geen kattepis en lijkt echt niet zo overdreven als je ziet dat HTML 4 al 13 jaar bestaat en eigenlijk pas zo'n jaar of 2 volledig en correct wordt ondersteund. Zelfs nu ondersteunen velen nog IE6, die HTML 4.01 (en de bijbehorende CSS standaarden) maar met moeite onvolledig en met veel bugs ondersteunt.
Die 10 jaar is natuurlijk geen kattepis en lijkt echt niet zo overdreven als je ziet dat HTML 4 al 13 jaar bestaat en eigenlijk pas zo'n jaar of 2 volledig en correct wordt ondersteund. Zelfs nu ondersteunen velen nog IE6, die HTML 4.01 (en de bijbehorende CSS standaarden) maar met moeite onvolledig en met veel bugs ondersteunt.
Idd beter wat later en goed dan te snel en bagger. en dat laatste gebeurt nog al regelmatig.
Een levende standaard waar elke browser zijn eigen versie van heeft, wat heeft het dan voor nut om een standaard te hebben?
Moesten browsermakers verplicht worden om zich aan de standaarden te houden alvorens ze zich "browser" mogen noemen zou ik voor html 5 zijn. Maar nu is het al een ramp om crossbrowser te ontwikkelen, wat zal dat niet gaan geven als er nog meer tags/implementaties bijkomen.
Het voordeel aan de levende standaard is dat er misschien sneller ontwikkeld zal worden aan html waardoor browsers niet meer hoeven te komen met eigen implementaties.
Ik ben benieuwd wat het zal geven...
Moesten browsermakers verplicht worden om zich aan de standaarden te houden alvorens ze zich "browser" mogen noemen zou ik voor html 5 zijn. Maar nu is het al een ramp om crossbrowser te ontwikkelen, wat zal dat niet gaan geven als er nog meer tags/implementaties bijkomen.
Het voordeel aan de levende standaard is dat er misschien sneller ontwikkeld zal worden aan html waardoor browsers niet meer hoeven te komen met eigen implementaties.
Ik ben benieuwd wat het zal geven...
Ben benieuwd hoe jij websites maakt.
Ik bouw websites al een tijdje volgens de HTML5 standaard, gaat gewoon prima in elke browser hoor, tuurlijk IE8 en lager hebben zo hun bugs en beperkingen, maar die weet je vooraf...
Ik bouw websites al een tijdje volgens de HTML5 standaard, gaat gewoon prima in elke browser hoor, tuurlijk IE8 en lager hebben zo hun bugs en beperkingen, maar die weet je vooraf...
Er zijn nog zoveel mensen met browsers die niet (goed) html5 ondersteunen, dat je die doelgroep niet kan vergeten.
Bovendien zijn er zoveel html5 onderdelen die niet met elke browser gelijk zijn, dat je het toch nog vooral bij html4 moet houden (al heeft html5 bijvoorbeeld zulke coole input types)
Eigenlijk zou een browser gewoon een houdbaarheidsdatum moeten hebben. Als de browser die datum passeert, de browser gewoon self-destruct doet...... zooo, zijn we daar ook weer van af.
Bovendien zijn er zoveel html5 onderdelen die niet met elke browser gelijk zijn, dat je het toch nog vooral bij html4 moet houden (al heeft html5 bijvoorbeeld zulke coole input types)
Eigenlijk zou een browser gewoon een houdbaarheidsdatum moeten hebben. Als de browser die datum passeert, de browser gewoon self-destruct doet...... zooo, zijn we daar ook weer van af.
Afgezien van de haalbaarheid vind ik de houdbaarheid wel een goed idee voor dit soort software. Dan weet je tenminste zeker dat de software die je gebruikt goed werkt heden ten dage.
De meeste websites die ik maak ondersteunen IE6 nog, gewoon HTML5 hoor.
Je mist wat features, maar die had je anders toch niet gehad. En voor triviale zaken is er javascript om één en ander op te vangen.
En over een houdebaarheidsdatum, wat dacht je van geforceerde updates?
Mijn chrome is altijd up to date, zie dat ding alleen nooit updaten.
Je mist wat features, maar die had je anders toch niet gehad. En voor triviale zaken is er javascript om één en ander op te vangen.
En over een houdebaarheidsdatum, wat dacht je van geforceerde updates?
Mijn chrome is altijd up to date, zie dat ding alleen nooit updaten.
Niet de browsers moeten zich aan de standaarden houden, de sites moeten zich aan de standaarden houden. De browsers moeten elke site zo goed mogelijk weergeven, de sites die aan de standaarden voldoen maar ook de sites die er niet aan voldoen. Natuurlijk is het zo dat een browser de standaard goed moet kunnen verwerken, maar daar houdt het dus niet op!Moesten browsermakers verplicht worden om zich aan de standaarden te houden
Features zijn op zichzelf gewoon strak gestandaardiseerd, alleen ondersteunt niet elke browser elke feature. Dat is geen probleem mits je dat maar kunt detecteren en er goede alternatieven voor aan kunt bieden. Zo ontstaat een simpele en pragmatische vorm van modulariteit die heel nuttig kan zijn. Tablets kunnen bijvoorbeeld een touch subsysteem ondersteunen terwijl deze ondersteuning er op de desktop niet is. Daar zal je applicatie dus rekening mee moeten houden door daar terug te vallen op de muis. Het web is gewoon te groot en log om rigide versies van standaarden te gebruiken. Het werkt gewoon niet.Een levende standaard waar elke browser zijn eigen versie van heeft, wat heeft het dan voor nut om een standaard te hebben?
Zijn we eindelijk zover dat browsers wat doen met de W3C standaarden zoals die met naam, toenaam en versie genoemt worden in je HTML document, gaan we de versienummering van de standaard weg werken.Volgens het huidige tijdsschema van de W3C moet de standaard in 2014 definitief zijn afgerond. Toekomstige versies van de html-standaard krijgen geen versienummer meer; het is de bedoeling dat html een 'levende standaard' wordt, die continu evolueert. De standaard zal dan ook gewoon 'html' gaan heten.
Wat is daar het nut van, het wordt zo vrijwel onmogelijk om functies aan te passen ook al zijn ze aantoonbaar fout of om andere redenen niet meer gewenst. Ook zal voor iedere nieuwe eigenschap van een bestaande functie een nieuwe naam of tag worden meegegeven, wat mij niet echt prettig werken lijkt.
Erg slim juist om die versienummers weg te halen, het toverwoord is: feature detection.
Nu schrijf je gewoon je webpagina's en de ondersteunende code en je test voor welke features de bezoekende UA (User Agent) ondersteunt. Heeft UA #1 dat niet, val je terug naar andersoortig support. Veel makkelijker en meer resultaat gericht.
Tevens zorgt het er voor dat het juist makkelijker wordt om voor specifieke features van een bepaalde versie van een UA workarounds in te bouwen.
Nu schrijf je gewoon je webpagina's en de ondersteunende code en je test voor welke features de bezoekende UA (User Agent) ondersteunt. Heeft UA #1 dat niet, val je terug naar andersoortig support. Veel makkelijker en meer resultaat gericht.
Tevens zorgt het er voor dat het juist makkelijker wordt om voor specifieke features van een bepaalde versie van een UA workarounds in te bouwen.
Ik heb wel eens een nog veel belachelijker tijdsschema voor HTML5 gezien, waarin het pas in 2022 (ja, twintigtweeëntwintig, over elf jaar!) een "Proposed Recommendation" zou zijn. Zie hier:
- First W3C Working Draft in October 2007.
- Last Call Working Draft in October 2009.
- Call for contributions for the test suite in 2011.
- Candidate Recommendation in 2012.
- First draft of test suite in 2012.
- Second draft of test suite in 2015.
- Final version of test suite in 2019.
- Reissued Last Call Working Draft in 2020.
- Proposed Recommendation in 2022.
Nee, want op de huidige pagina staat bijvoorbeeld al:
W3C also reconfirmed today that, as announced, these specifications are on track to become stable standards in 2014.
Zoals je kan zien lopen we zelfs achter op schema. Daar staat de last call in 2009 en we zijn reeds 2011.
De standaard op zich is zo goed als geschreven en veel zal er niet meer aan veranderen. De laatste status, die je dus in 2022 ziet staan is een status die pas behaald word wanneer alle test suites gebouwd zijn en wanneer er 2 verschillende browsers zijn die een volledige implementatie van de standaard hebben.
De standaard op zich is zo goed als geschreven en veel zal er niet meer aan veranderen. De laatste status, die je dus in 2022 ziet staan is een status die pas behaald word wanneer alle test suites gebouwd zijn en wanneer er 2 verschillende browsers zijn die een volledige implementatie van de standaard hebben.
Klopt, het is op dit moment zelfs ook nog onduidelijk wanneer HTML4 die status zal bereiken.[...]wanneer er 2 verschillende browsers zijn die een volledige implementatie van de standaard hebben.
[Reactie gewijzigd door Maurits van Baerle op donderdag 26 mei 2011 19:47]
Wat ik erg vind is dat er zoveel webdesigners zijn die nog nooit blijkbaar van de W3C validator hebben gehoord. Schande dat de meest grote websites verschrikkelijk veel fouten in hun codes hebben zitten. Een site controlleren op fouten is zo gedaan, en elke webdesigner moet dat weten.
Ik zou html 5 ook maar niet valideren in de W3C validator. Die is daar nog niet klaar voor.
Klopt, maar de validator is wel een zeurpiet en staat je regelmatig niet toe bepaalde constructies te gebruiken die in de praktijk gewoon goed werken. Verder gebruikt elke browser in principe maar één rendering engine voor alle versies van de standaarden. Dus dezelfde rendering engine rendert XHTML, HTML 4.01 en HTML5.
Sommige browsers gebruiken wel meerdere rendering engines maar dit is niet gekoppeld aan de versies van de standaarden maar aan de versies van de browser zelf. Internet Explorer 9 heeft bijvoorbeeld gewoon een IE7 en IE8 aan boord, maar als je document helemaal valid is wordt zowel HTML 4.01 als HTML 5 gewoon in de IE9 engine gerendered.
Bottom line: We hebben die versies 15 jaar lang geprobeerd, het werkt niet. Het is een theoretische ivoren-toren discussie. In de praktijk komt er niets van terecht.
Sommige browsers gebruiken wel meerdere rendering engines maar dit is niet gekoppeld aan de versies van de standaarden maar aan de versies van de browser zelf. Internet Explorer 9 heeft bijvoorbeeld gewoon een IE7 en IE8 aan boord, maar als je document helemaal valid is wordt zowel HTML 4.01 als HTML 5 gewoon in de IE9 engine gerendered.
Bottom line: We hebben die versies 15 jaar lang geprobeerd, het werkt niet. Het is een theoretische ivoren-toren discussie. In de praktijk komt er niets van terecht.
Fouten in codes komt over het algemeen omdat je met een scripttaal of programmeertaal (zoals PHP) gaat werken, waardoor je het overzicht langzamerhand kwijtraakt. Bovendien kun je altijd hebben dat je ergens een (sluit-)tag bent vergeten, maar dat het wel gewoon goed werkt. Bovendien hangt het maar net af of de browsers het goed ondersteunen, waardoor je soms moet (of moest) werken met een code die niet gevalideerd wordt, maar wel zo werkt. Ook heb je soms dat je bepaalde waardes aan een veld moet geven om er functionaliteit aan te geven (zoals dus bij javascript vaak het geval is), maar waar dus geen correct gebruik is.
Soms is het sneller om een stukje niet-gevalideerde code te gebruiken die werkt, dan te gaan zoeken naar een gevalideerde code, omdat als je dat doet de functionaliteit weer niet werkt.
Verder doen die validators ook niet altijd goed en zit je met een custom taal altijd te hannessen met een niet gevalideerde website.
Overigens geeft hij ook vaak zaken aan die er helemaal niet toe doen. Boeiend dat een plaatje geen alt-tag heeft als het niet gebruikt wordt als content-afbeelding maar opmaak/reclame/achtergrond.
Soms is het sneller om een stukje niet-gevalideerde code te gebruiken die werkt, dan te gaan zoeken naar een gevalideerde code, omdat als je dat doet de functionaliteit weer niet werkt.
Verder doen die validators ook niet altijd goed en zit je met een custom taal altijd te hannessen met een niet gevalideerde website.
Overigens geeft hij ook vaak zaken aan die er helemaal niet toe doen. Boeiend dat een plaatje geen alt-tag heeft als het niet gebruikt wordt als content-afbeelding maar opmaak/reclame/achtergrond.
validate ik t.net dan geeft w3c nog wel wat foutjes aan.
allen in de volgende strekking.
Line 391, Column 54: The cellspacing attribute on the table element is obsolete. Use CSS instead.
<table class="nextPrevious ellipsis" cellspacing=0>
✉
Line 393, Column 19: The width attribute on the col element is obsolete. Use CSS instead.
allen in de volgende strekking.
Line 391, Column 54: The cellspacing attribute on the table element is obsolete. Use CSS instead.
<table class="nextPrevious ellipsis" cellspacing=0>
✉
Line 393, Column 19: The width attribute on the col element is obsolete. Use CSS instead.
[Reactie gewijzigd door gp500 op donderdag 26 mei 2011 16:47]
Lekker belangrijk, je kunt niet eerder van sites verwachten dat ze w3c valideren dan dat er geen browsers meer zijn die niet aan de standaard voldoen.
cellspacing is anders prima op te vangen met CSS (zoals de foutmelding ook aangeeft). Dat is niet een functie die lastig op te lossen is. Dat kan zowel in de externe CSS als in de html zelf door gewoon een "style=..." toe te voegen ipv cellspacing.
[Reactie gewijzigd door Martinspire op vrijdag 27 mei 2011 02:10]
Het equivalent voor cellspacing in CSS is border-spacing, echter wordt dat niet ondersteund door o.a. IE < 8. Aangezien we nog IE7 moeten supporten is er geen andere workaround (table-collapse: collapse is ook niet altijd wenselijk)
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
