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)

[Franksijbom]

Ik begrijp het niet echt? Wat bedoelen ze precies met last call? Er staat dat ze tot 2014 de tijd hebben?

[Verwijderd]

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.

[Xirt]

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.

[ADT_Phantom]

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.

[Verwijderd]

2014 definitief zijn afgerond? Ondertussen gebruikt iedereen het al volop. Die jongens gunnen zichzelf teveel tijd. Opschieten, luiwammeses!

[phoenix]

Liever een standaard waar goed over is nagedacht dan dat je als webdeveloper voor 10 verschillende browsers moet testen...

[LOTG]

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?

[ZpAz]

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.

[prutsger]

Tip: http://www.alistapart.com...ngprogressiveenhancement/

Lees ook eens zijn twwe opvolgende artikelen, interessant voer!

[ZpAz]

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.

[ashemedai]

Je bedoelt waarschijnlijk graceful degradation, iets wat je makkelijk kan implementeren met behulp van feature detection libraries zoals Modernizr.

[Xthemes.us]

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.

[avdg-BE]

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).

[Cronax]

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...

[Xirt]

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.

[Thunderhawk0024]

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.

[OddesE]

In de toekomst ga je dus niet meer weten over welke features het gaat als men het heeft over "HTML"

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).

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).

[Aham brahmasmi]

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).

[Verwijderd]

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.

[.oisyn]

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.

Het probleem met (X)HTML was weldegelijk de standaard, die was gewoon ambigu opgezet en had tal van layoutproblemen die niet eenduidig interpreteerbaar waren.

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 23 juli 2024 15:08]

[OddesE]

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).

[Verwijderd]

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.

[curry684]

Wat dacht je van 'iedere XML specific extension zoals CDATA e.d.'? Dat is in HTML4 gewoon 'text'.

[crisp]

Zelfs zaken als <br /> leveren je een warning op in HTML:

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.

Verder kan de DOM verschillen tussen XHTML en HTML wat issues in scripting en CSS kan opleveren.

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

[mashell]

dan dat je als webdeveloper voor 10 verschillende browsers moet testen...

De webdeveloper is dus nog luier dan de standaardopsteller 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.

[Verwijderd]

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.

[Aham brahmasmi]

[...]

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.

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.

[Ramon]

huh? dan zouden ze gewoon meer sites er uit kunnen stampen en juist meer verdienen!

[ADT_Phantom]

Dat moet je sowieso gaan doen, aangezien ze allemaal de standaard anders implementeren (al verschilt het bij sommige zeer weinig)

[Timo002]

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.

[Reactie gewijzigd door Timo002 op 23 juli 2024 15:08]

[rickiii]

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.

[Verwijderd]

inderdaad.. teveel porno, gekloot met hacks en games tijdens het werk

gewoon eind 2012 hoogstens.. anders hebben we er uberhaupt niks meer aan

[TDeK]

Opschieten, luiwammeses!

Dat dacht Microsoft destijds ook, met IE5 en IE6 als gevolg. Ik denk dat dat genoeg zegt.

[Echron]

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...

[kikker81]

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...

[Rub3s]

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.

[brinkdinges]

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.

[kikker81]

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.

[mashell]

Moesten browsermakers verplicht worden om zich aan de standaarden te houden

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!

[OddesE]

Een levende standaard waar elke browser zijn eigen versie van heeft, wat heeft het dan voor nut om een standaard te hebben?

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.

[Wolfos]

Helaas dat we nu weer zien dat Microsoft er zich niet aan gaat houden. Met name met WebGL.

[madcow22]

Niks jammer mee te maken WebGL is geen HTML 5 is een standaard die er buiten gemaakt wordt door een totaal ander bedrijf.

[Martinspire]

Dus? Flash/Silverlight of zelfs javascript is toch ook geen HTML?

[Reactie gewijzigd door Martinspire op 23 juli 2024 15:08]

[Verwijderd]

flash/silverlight heeft niks met html 5 te maken
javascript wel en is onderdeel van html 5

[Dreamvoid]

JavaScript is geen HTML, het genereert HTML.

[ZpAz]

Als de aanroepende API hetzelfde is maakt het niet zoveel uit of op de achtergrond nu OpenGL of DirectX wordt gebruikt. Helemaal omdat IE het Windows platform toch niet verlaat.

[Verwijderd]

lijkt me onduidelijk hoe je voortaan, met zo'n levende standaard, aangeeft welke browser welke html tags ondersteunen. dan krijg je vast van die ellende van 'IE12 ondersteund de HTML-standaard van rond 2013' en dan moet je er maar bij verzinnen welke tags daar alweer bij hoorden.

[Verwijderd]

Alle browsers zullen in de toekomst ook geen versie meer hebben, zoals Chrome dat nu al heeft en vanaf Firefox 4 worden de versienummers ook minder belangrijk.
Als je een IDE gebruikt zoals Aptana krijg je direct te zien welke browsers het ondersteunen als je een tag wilt openen.
Veel technologieën kun je vinden op http://caniuse.com/.

[SuperDre]

Maar chrome heeft onderliggend wel degelijk een versienummer hoor.. dat het naar buiten toe in naam geen versienummer heeft wil nog niet zeggen dat het deze daadwerkelijk niet heeft.. Het is natuurlijk ook altijd nodig..

[Verwijderd]

Alle? Denk niet dat Opera snel van hun huidige systeem, wat ze nu met Opera Next nog extra aandacht geven, gaat veranderen.

[tes_shavon]

Volgens het huidige tijdsschema van de W3C moet de standaard in 2014 definitief zijn afgerond.?

Begin 2014 of eind 2014 ... maakt ook nogal uit...

[Reactie gewijzigd door tes_shavon op 23 juli 2024 15:08]

[Henridv]

Dat zal waarschijnlijk in de loop van volgend jaar beter gespecifiëerd worden, wanneer de grootte van eventuele problemen duidelijk wordt.

[PolarBear]

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.

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.

[kikker81]

Per feature kijken is de enige betrouwbare manier (nu al) om te kijken of een browser iets ondersteund.

[OddesE]

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.

[EvilWhiteDragon]

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.

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.
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.

[ashemedai]

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.

[jj71]

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.

Klopt dat nog steeds?

[Xirt]

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.

[Blokker_1999]

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.

[Maurits van Baerle]

[...]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.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 15:08]

[Martinspire]

Ik hoop dat de integratie van functionaliteiten en compatibiliteit tussen HTML5 en CSS3 nog wat verbeterd gaat worden. Zoiezo is de aandacht voor CSS3 nog wat laag, ik had hier graag nog wat meer mogelijkheden gezien. Er zijn nu nog steeds een hoop zaken waar je javascript voor nodig hebt, die eigenlijk geen script nodig zouden moeten hebben (vind ik). Zaken als content-vakken die sliden/faden/verplaatsen e.d. zouden gewoon met CSS3 geregeld moeten kunnen worden. Worden een hoop sites sneller van. Maakt het geheel ook wat dynamischer

[ZpAz]

In ieder geval in Webkit is het mogelijk om faden en sliden / verplaatsen om met enkel CSS zulke animaties te doen.