Prototyperen, XHTML, client- en serverside problemen

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 10:46:
[...]
Het leek ons handig om een standaard te kiezen waarbij men geforceerd nette HTML moet schrijven, en zichzelf kunnen controleren door gewoon die validator erbij te pakken. Die zegt dan vanzelf wel: "attribuut niet in orde", "tag niet afgesloten", etc.

En dat kan je niet regelen met algemeen html? En waarom zou iemand ooit zijn code gaan herschijven "als het toch gewoon werkt"

Je probleem word niet opgelost door een ander doctype te werken. Je mensen moeten gewoon netjes werken.

Je zou sowieso voor HTML moeten kijken naar de SGML specificatie

Leesvoeier: http://www.rikkertkoppes.com/thoughts/2005/01/27/

RobIII wijzigde dit bericht 01-08-2008 10:54 (32%)

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 10:46:
[...]
Het leek ons handig om een standaard te kiezen waarbij men geforceerd nette HTML moet schrijven, en zichzelf kunnen controleren door gewoon die validator erbij te pakken. Die zegt dan vanzelf wel: "attribuut niet in orde", "tag niet afgesloten", etc.

Een 'reguliere' HTML/SGML parser/validator doet dat ook. Heb je geen XHTML voor nodig.

quote:

Edit 2: Gewoon HTML 4 is geen optie omdat deze juist netjes werken niet promoot. Het slikt alles, so to speak. Ik wil dat frontenders -en- programmeurs allemaal hetzelfde taaltje praten qua HTML, en dat het prototype in een applicatie omgeving niet ineens iets heel anders gaat doen.

Onzin. Schop een developer voor z'n ballen als het fout gaat. Ook in XHTML kan je er een rommeltje van maken. Je validator (hetzij SGML hetzij XHTML) zal vanzelf gaan jengelen als er iets fout gaat. Nu zoek je de problemen op.

quote:

disjfa schreef op vrijdag 01 augustus 2008 @ 10:50:
[...]
Je probleem word niet opgelost door een ander doctype te werken. Je mensen moeten gewoon netjes werken.

Verkeersborden helpen niet, mensen moeten zich gewoon veilig gedragen in het verkeer.

Ik denk dat de TS heel goed het belang van standaarden begrijpt. Als je wilt kiezen tussen HTML en XHTML zal afhangen van factoren als hoe de rest van je applicatie eruit ziet, welke techniek mensen gewend zijn te gebruiken, toekomstperspectief, comptibiliteit etc. Persoonlijk vind ik XHTML (zeker 2.0) daarin veel sterker, maar ik heb niet het idee dat daarmee het probleem van de TS opgelost wordt.

Draaien er nog meer applicaties op de server? Anders kun je natuurlijk op de server instellen alles als application/xml+xhtml in te stellen. Of gaat het geheel door een centraal document? Een template-parser ofzo? Daar zou je prima dit soort dingen kunnen aanpassen (en evt. valideren).

Paar pro's ten opzicht van HTML is dat het consistent is.

XHTML verwacht dat alle tags afgesloten worden, danwel door een sluitings-element van hetzelfde soort of een /> voor een lege tag. HTML heeft als syntax dat alle tags afgesloten worden, behalve sommige... dat vind ik niet handig om als standaard op te zetten.

XHTML is parsable. De structuur van HTML leent zich daar minder voor, omdat een heel document door gezocht moeten worden of een tag een sluit-element heeft of dat het een 'open'-tag is. Bijvoorbeeld handig als er zoals de topicstart zegt met AJAX gewerkt moet worden.

XHTML zal meer geschikt zijn om met XML gebasseerde applicaties te communiceren. HTML zal eerst omgezet moeten worden naar een XML-wellformed document (almost XHTML).

r0bert wijzigde dit bericht 01-08-2008 11:15 (27%)

Los van dat ik de motivaties van de TS wel begrijp en deels onderschrijf is XHTML code + mimetype niet een oplossing voor dit probleem. Niet als de prototypes ook in IE moeten werken in ieder geval. Dat gaat never nooit niet werken.

Wat is dan wel een oplossing? Leg coding standards vast en zorg dat alle code peer-reviewed wordt.

quote:

Blues schreef op vrijdag 01 augustus 2008 @ 11:15:
Wat is dan wel een oplossing? Leg coding standards vast en zorg dat alle code peer-reviewed wordt.

Als je daar de capaciteiten voor hebt is dat wel het mooist, in combinatie met een validator. Want niets is irritanter dan opening en closing tags handmatig controleren. En uit efficientie-oogpunt is iedere controle verlies, dus als je het kunt automatiseren verdien je makkelijk geld

Goed, dus.. om consistentie en compatibiliteit met de applicatie te waarborgen, en de demo gelijk te laten zijn met de uiteindelijke applicatie, kiezen we intern voor de volgende stappen:

1. Zet coding standards op bedrijfs-wiki
2. Stuur iedere ontwikkelaar een memo hierover
3. Plan per project team een uur interne training in
4. De frontender per project-team is verantwoordelijk voor de HTML
5. We gebruiken een XHTML 1.1 doctype
6. De MIME type blijft text/html (toegestaan door de W3C specs)
7. Ontwikkelaars die fouten maken worden daar actief op gewezen

Voila, nieuwe manier van ontwikkelen. Geen XHTML doctypes met HTML4 content meer, geen "vergeten doctypes", geen rotzooi.

En dat op een vrijdag ochtend

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 11:35:
• We gebruiken een XHTML 1.1 doctype
• De MIME type blijft text/html (toegestaan door de W3C specs)

Nee, text/html mimetype is toegestaan* voor XHTML 1.0, niet voor 1.1 en dan zelfs nog met een hoop mitsen en maren (appendix C, welke niet normatief of volledig is)

* de specificatie gebruikt "SHOULD be served with an XHTML mimetype" (en voor XHTML1.1 is dat MUST)

XHTML1.x is niet stricter dan zeg HTML4.01 Strict, het is immers puur de XML serialisatie van HTML4, niets meer en niets minder...

Verder zijn zaken als toegankelijkheid veel belangrijker dan pure syntax validatie. Het is daarom beter om in eerste instantie te werken volgens bijvoorbeeld de webrichtlijnen en daarbij validatie te gebruiken als een tool, niet als een doel an sich.

crisp wijzigde dit bericht 01-08-2008 11:53 (21%)

quote:

crisp schreef op vrijdag 01 augustus 2008 @ 11:51:
[...]

Nee, text/html mimetype is toegestaan* voor XHTML 1.0, niet voor 1.1 en dan zelfs nog met een hoop mitsen en maren (appendix C, welke niet normatief of volledig is)

* de specificatie gebruikt "SHOULD be served with an XHTML mimetype" (en voor XHTML1.1 is dat MUST)

XHTML1.x is niet stricter dan zeg HTML4.01 Strict, het is immers puur de XML serialisatie van HTML4, niets meer en niets minder...

Verder zijn zaken als toegankelijkheid veel belangrijker dan pure syntax validatie. Het is daarom beter om in eerste instantie te werken volgens bijvoorbeeld de webrichtlijnen en daarbij validatie te gebruiken als een tool, niet als een doel an sich.

Ik geloof je op je woord, maar staat het dan verkeerd aangegeven op deze pagina?

quote:

Pagina: http://www.w3.org/TR/xhtml11/conformance.html

XHTML 1.1 documents SHOULD be labeled with the Internet Media Type text/html as defined in [RFC2854] or application/xhtml+xml as defined in [RFC3236]. For further information on using media types with XHTML, see the informative note [XHTMLMIME].

Dat zegt volgens mij: "XHTML1.1 documenten zouden gelabeled moeten zijn met het Internet Media Type text/html OF application/xhtml-xml .. "

Nogmaals, ik trek jou niet in twijfel, ik vind het W3C gewoon verwarrend.

In dat geval zou ik dus gewoon HTML4.01 kunnen gebruiken, met onze eigen opmaak standaarden (tags sluiten, etc.).

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 12:05:
[...]

Ik geloof je op je woord, maar staat het dan verkeerd aangegeven op deze pagina?

[...]


Dat zegt volgens mij: "XHTML1.1 documenten zouden gelabeled moeten zijn met het Internet Media Type text/html OF application/xhtml-xml .. "

Nogmaals, ik trek jou niet in twijfel, ik vind het W3C gewoon verwarrend.

Hmmz, dat is zo te zien een toevoeging van de revisie uit 2007

XHTML Media Types benoemt nog enkel XHTML1 dus daar heb je verder ook niet veel aan, behalve dat daar impliciet wordt gezegd dat voor andere XML-families text/html niet is toegestaan. W3C is in deze inderdaad niet bepaald consequent (of consequent gebleven) wat wel weer iets zegt over de onmogelijke positie van XHTML op het web...

quote:

In dat geval zou ik dus gewoon HTML4.01 kunnen gebruiken, met onze eigen opmaak standaarden (tags sluiten, etc.).

jep, XHTML heeft geen enkele meerwaarde boven HTML4.01 indien je toch als text/html moet serveren en het gebruik van XHTML levert enkel verwarringen op (mensen die denken dat <script src="foo.js" /> ineens kan enzo).

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 10:39:
Ik prototype web-applicaties, noodgedwongen, in platte HTML bestanden op het filesystem. Deze kunnen niet de mime-type application/xhtml-xml krijgen.

Waarom installeer je niet gewoon lokaal een webserver? Dan zit je voor de browser niet meer lokaal te werken en heb je ook geen last meer van bepaalde restricties met betrekking tot communicatie in JavaScript en kan je ook meteen server-side code prototypen.

quote:

Johnny schreef op vrijdag 01 augustus 2008 @ 13:11:
[...]


Waarom installeer je niet gewoon lokaal een webserver? Dan zit je voor de browser niet meer lokaal te werken en heb je ook geen last meer van bepaalde restricties met betrekking tot communicatie in JavaScript en kan je ook meteen server-side code prototypen.

Een aantal redenen:

1. Legacy prototypes, niet door mij gemaakt - ik pak nieuwe prototypes door mijzelf gemaakt heel anders aan;
2. De boel moet zonder server kunnen functioneren zodat verkopers het kunnen tonen bij een klant zonder "moeilijke" servers te hoeven installeren;
3. Het idee van prototypes binnen dit bedrijf is: "keep it simple", er hoeft geen logica in of zelfs waarschijnlijke data, het is een veredelde sfeerimpressie met een paar suggestieve functionele uitingen.

In een nog verder uit te werken opzet werk ik zelf met XSL/XML. Voordelen zijn: nette code, je herhaalt jezelf niet (menu's enzo), je kan door een set fake-data loopen (xml-files) en je kan wel enige logica inbouwen waar wenselijk.

Daarnaast heb ik een .NET applicatie gebouwd welke door een map met daarin een prototype loopt, en van de XML files de bijhorende XSL file opzoekt, deze twee merged en een HTML-file output in het formaat aangegeven door de <XSL:output>-tag.

Het voldoet aan alle eisen, en bied nog een hele lading extra's Maar dan moet ik wel de overige collega's zo ver zien te krijgen dit als asset te zien, niet als liability en aanval op hun huidige manier van werken.

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 10:46:
[...]

Edit 2: Gewoon HTML 4 is geen optie omdat deze juist netjes werken niet promoot. Het slikt alles, so to speak. Ik wil dat frontenders -en- programmeurs allemaal hetzelfde taaltje praten qua HTML, en dat het prototype in een applicatie omgeving niet ineens iets heel anders gaat doen.

Wat is dat nou weer voor onzin Als ze allemaal HTML 4 praten praten ze toch ook hetzelfde praatje? Uiteraard moet je wel kiezen voor een strict doctype, dit is veel essentieler dan de keuze tussen html of xhtml. Het enige verschil is het afsluiten van tags in xml stijl, maar of je dat dan per definitie 'netter' moet noemen is natuurlijk de vraag.

Persoonlijk vind ik het netter een standaard te kiezen die in ieder geval alle browsers ondersteunen. En aangezien IE nog steeds niet correct XHTML ondersteunt (zelfs IE8 beta niet), lijkt me de keuze voor HTML4 Strict hierin me een stuk logischer.

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 14:14:
[...]
In een nog verder uit te werken opzet werk ik zelf met XSL/XML. Voordelen zijn: nette code, je herhaalt jezelf niet (menu's enzo), je kan door een set fake-data loopen (xml-files) en je kan wel enige logica inbouwen waar wenselijk.

Wat is er verschillend dan als je nette html maakt. Herhaal je dan wel Zit daar geen logica in

Wat voegt xml/xsl toe anders dan een normale html pagina met datdabase/html en css opmaak. Uiteindelijk precies hetzelfde.

quote:

Bosmonster schreef op vrijdag 01 augustus 2008 @ 15:04:
[...]


Wat is dat nou weer voor onzin Als ze allemaal HTML 4 praten praten ze toch ook hetzelfde praatje? Uiteraard moet je wel kiezen voor een strict doctype, dit is veel essentieler dan de keuze tussen html of xhtml. Het enige verschil is het afsluiten van tags in xml stijl, maar of je dat dan per definitie 'netter' moet noemen is natuurlijk de vraag.

Persoonlijk vind ik het netter een standaard te kiezen die in ieder geval alle browsers ondersteunen. En aangezien IE nog steeds niet correct XHTML ondersteunt (zelfs IE8 beta niet), lijkt me de keuze voor HTML4 Strict hierin me een stuk logischer.

Ik was inmiddels op die uitspraak terug gekomen Op het moment van schrijven was het nog geen optie om alle ontwikkelaars op te voeden qua HTML gebruik. Nu wel.

Ik heb niks tegen HTML4, zeker niet met onze eigen best-practice eisen, maar het staat wel toe dat tags niet worden afgesloten. Op zich geen probleem.. ware het niet dat onze back-end omgeving (java/wicket) een klein beetje van well-formed HTML uit gaat.

Dus we gaan nu mensen trainen

quote:

disjfa schreef op vrijdag 01 augustus 2008 @ 15:08:
[...]

Wat is er verschillend dan als je nette html maakt. Herhaal je dan wel Zit daar geen logica in

Stel je voor, je hebt een prototype, een demo dus, met 40 pagina's. Iedere pagina heeft een menu. Dat menu komt op iedere pagina terug, maar heeft steeds een ander highlighted menu item.

Stel je nu eens voor dat je wijzigingen moet aanbrengen en dat het ene bestand tabs gebruikt als indenter, en een ander bestand 4 spaties. Of dat men uitzonderingen binnen het menu heeft ingebakken.

Dan moet je dus een heel goede search & replace uitvoeren met alle mogelijke gevolgen van dien.

XSL biedt de mogelijkheid het menu 1 keer in een XSL template te duwen waaraan je parameters kan meesturen. Een wijziging is dan een kleine moeite, en vereist een wijziging in 1 bestand, niet alle 40 pagina's.

quote:

Wat voegt xml/xsl toe anders dan een normale html pagina met datdabase/html en css opmaak. Uiteindelijk precies hetzelfde.

Niet al onze HTML-ers kunnen met PHP/ASP/Java werken, laat staan een database inrichten, laat staan een server opzetten. Daarnaast kunnen we niet van een verkoper eisen dat hij dat ook eventjes instelt als hij naar een klant gaat met onze demo.

Daarom: XSL/XML.

Blue-eagle wijzigde dit bericht 01-08-2008 15:14 (35%)

offtopic:
Kan de verkoper z'n app's niet verkopen adhv een app op z'n laptop (waar dan een server op draait).

quote:

Blue-eagle schreef op vrijdag 01 augustus 2008 @ 15:10:
Niet al onze HTML-ers kunnen met PHP/ASP/Java werken, laat staan een database inrichten, laat staan een server opzetten. Daarnaast kunnen we niet van een verkoper eisen dat hij dat ook eventjes instelt als hij naar een klant gaat met onze demo.

En ze kunnen dan wel even xml EN xsl erbij leren. Maar een database maken is dan te ingewikkeld.

quote:

disjfa schreef op vrijdag 01 augustus 2008 @ 15:41:
[...]

En ze kunnen dan wel even xml EN xsl erbij leren. Maar een database maken is dan te ingewikkeld.

Want simpele Xml begrijpen en 3 Xsl-tags leren is zo ontzettend complex.

Ja, dan laat ik ze liever een MySql database inrichten, leer ik ze Sql en while at it doen we ook nog eventjes Php. Een Apache servertje configureren (was dat ook niet in XML?) et voila!

quote:

moozzuzz schreef op vrijdag 01 augustus 2008 @ 15:38:

offtopic:
Kan de verkoper z'n app's niet verkopen adhv een app op z'n laptop (waar dan een server op draait).

Als het altijd zo voorspelbaar was.. Gisteren moest ik een prototype in alle haast opsturen naar een opdrachtgever zodat hij het aan een mogelijk nieuwe klant kon tonen. Dus: inzippen, e-mailen.

Dan zeg je nu: Dan zet je het toch online? Dat kan als men overal internet heeft. Wat helaas niet altijd het geval is, zeker niet in het segment waarin wij zaken doen - veel (overdreven) beveiligingen enzo.

Maar we gaan nu wel heel snel offtopic

Als jullie het prototyping proces willen bespreken, maak er dan even een nieuw topic voor aan aub. Dan kunnen we daar verder praten over de gangbare of niet gangbare technieken.

quote:

Mag je een div-tag zo afsluiten? <div class="container" />
Of moet je hem altijd afsluiten als <div class="container"></div>
Ik kan deze regel zo snel niet terugvinden in W3C documenten..

Deze pagina heb ik zelf eens opgegoogled.. toen hadden we hier een discussie over het wel of niet shorthand afsluiten van de script tag met een src verwijzing. Deze tag kan je al helemaal niet als shorthand schrijven en dat terwijl het nooit inner html bevat.
http://justinsomnia.org/2...0-legal-xhtml-empty-tags/

Ik mis XHTML 2.0, XPath, XQuery, XPointer en XForms als argument vóór Xhtml

De semantiek van XHTML 2.0 vind ik veel ergernis wegnemen - als voorbeeld de <h>-tag. Waar deze in HTML nog het niveau handmatig aan moet geven d.m.v. <H1>, <H2> .. <H5> wordt in XHTML 2.0 deze nesting automatisch gedaan en is dus alleen <h>-tag nog nodig (eventueel natuurlijk naar een eigen level te forceren). Zo zijn er nog een aantal dingen die ik veelbelovend vind. Een overstap naar XHTML 2.0 is natuurlijk veel makkelijker van XHTML 1.1 dan van HTML 4.01.

Daarbij vind ik dat XPath en XQuery enorm veel flexibiliteit bieden. Zoals de topicstarter ook al even XSL erbij betrok, maar ook eigen applicaties die door middel van deze twee talen documenten kunnen manipuleren of doorzoeken. Paralel hieraan lopen natuurlijk de DOM functionaliteiten - maar die kun je in principe ook met HTML bereiken.

Dan is XPointer een mooie toevoeging in de huidige manier van linken, al lijkt het me logisch dat dit ook voor HTML beschikbaar wordt.

En forms zijn voor mij persoonlijk altijd een ergernis geweest die veelste veel tijd leek te kosten. Ik vind dat XForms er een stuk handiger mee om gaat, hoewel ik bij sommige syntax-elementen nog wel een paar vraagtekens heb, aangezien ze niet erg consistent zijn met andere XML-gerelateerde talen (XSD p.e.).

edit:
Voor HTML (en XHTML) zag ik op rikkertkoppes website iets over http://www.whatwg.org/specs/web-forms/current-work/, ook veelbelovend, hoewel XForms net een stap verder gaat dan syntax-wijzigingen.

quote:

This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.

XForms 1.0 is well suited for describing business logic and data constraints. Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on HTML Web browsers that do not support XForms.

Ik hoop dat de TS mee kan nemen welke argumenten voor hem tellen en zo ook in toekomstige perspectief een goede keus kan maken

r0bert wijzigde dit bericht 02-08-2008 12:13 (15%)

quote:

r0bert schreef op vrijdag 01 augustus 2008 @ 17:28:
Ik mis XHTML 2.0, XPath, XQuery, XPointer en XForms als argument vóór Xhtml

[heel verhaal]

Niemand zegt ook dat XHTML niet goed is. Alleen als je GEEN gebruik maakt van de XML-capaciteiten, zoals XSL en alle andere X-shizzle die je al noemt, heeft het weinig zin.

XHTML gebruiken puur omdat het de tags zo mooi afsluit is niet echt een goede reden. Als je bijvoorbeeld met PHP werkt en een template engine als Smarty, heeft XHTML gebruiken geen enkele toegevoegde waarde en wil je eigenlijk alleen een HTML standaard hebben die IE in de juist modus forceert (daarom is strict zo belangrijk) en die volledig ondersteund wordt en je niet teveel onnodige beperkingen oplegt.

Daarom wordt, als je geen XML-capaciteitein gebruikt, html4 strict aangeraden.

Bosmonster wijzigde dit bericht 03-08-2008 13:07 (11%)

Akkoord, wat dat betreft kan ik inderdaad daarin meegaan.

Persoonlijk ervaar ik HTML altijd als"
code:

if (statement
{
   execute();

   if (statement)
   {
   elsif
   {
   }
   else
   {
}

Oftewel, een taal waar de syntax-structuur niet klopt. Het lijkt me verwarrend om met een programmeur af te spreken dat hij sommige statements wel af moet sluiten en andere niet. In XHTML wordt hier meer één regel voor gebruikt, helaas dat sommige elementen als <script /> nog eisen stellen (maar dat is misschien meer vanuit de browsers). Daarmee vind ik XHTML meer potentie voor een standaard hebben. Maar als een ieder HTML blijft gebruiken, omdat XHTML nog niet goed ondersteund wordt, denk ik dat het lang zal kunnen duren totdat browsers XHTML juist gaan ondersteunen? Terwijl indirect iedereen juist zo graag een overeenkoepelende standaard wil voor alle browsers zonder uitzonderingen.

Sterker nog, de ontwikkeling van XHTML is door het W3C op een laag pitje gezet. De voornaamste focus ligt momenteel bij HTML5.

Nu moet ik er wel bijzeggen dat ook HTML5 in XML uitgedrukt kan worden en je dan dus de vrije keus krijgt. De koppeling met X-standaarden is echter niet zo geforceerd als met de huidige XHTML standaarden en de standaard in zn geheel is meer gericht op bruikbaarheid.

Bosmonster wijzigde dit bericht 04-08-2008 12:00 (97%)

quote:

dat ook HTML5 in XML uitgedrukt kan worden

Over een paar jaar zijn XHTML en HTML weer vriendjes

quote:

r0bert schreef op maandag 04 augustus 2008 @ 16:53:
[...]

Over een paar jaar zijn XHTML en HTML weer vriendjes

Waarschijnlijk niet; XHTML2 heeft zich dusdanig van het web vervreemd dat er gewoonweg geen animo voor is binnen de webcommunitie (zowel authors als browservendors, maar dat is natuurlijk ook een beetje kip-ei).

Feit is dat HTML als 'dialect' (en dan praat ik niet over HTML als SGML implementatie, want dat is het in de praktijk nooit geworden) succesvol is gebleken, mede dankzij het vergevende karakter van parsers mbt syntax-fouten. Op het moment dat je die vergevingsgezindheid ook vat in stricte regels voor parsers heb je op dat punt ook interoperabiliteit, behoudt je een groot stuk backwards-compatibility, en kan je vanuit daar de 'taal' extenden. En dat is wat HTML5 placht te doen, met daarnaast een XML-serialisatie (gelijk aan HTML4.x vs XHTML1.x) voor wanneer de markup met XML tools moet kunnen worden bewerkt.

Er wordt ook veel werk gestoken om technologieën waarvoor XHTML tot nu toe verplicht was ook te laten werken in een text/html geserveerd document; denk aan SVG en MathML.

Als tegenhanger van XForms kent HTML5 WebForms2 (al geimplementeerd in Opera o.a.), waarvan ook javascript-based implementaties zijn voor andere browsers.

XHTML2 is een compleet nieuwe taal en daarmee niet backwards compatible met huidige (X)HTML pagina's op het web. Ik durf dus wel te stellen dat de overstap naar XHTML2 (als browers daar ooit support voor zouden bieden, en dat is een hele grote 'als' ) vanuit XHTML1.x vele malen groter is dan naar (X)HTML5, en dat uiteindelijk (X)HTML5 praktisch hetzelfde te bieden zal hebben.