but if you want to know what’s wrong with WC3 etc

it’s that XML-based vision
it’s like the very plague.

it’s *elegant* but it’s also *wrong*
because it’s *functional*
and not procedural
people think in procedures

and can be trained to think in objects
but the idea of applying an XPATH query, which is actually a function, to a dataset, to produce a result set – which you never see the XML of – which is rendered on the browser end by CSS in the browlser?
== madness

nobody’s ever really going to do that.
because it’ll handle special cases and exceptions like shit
and the real world is one large special case.

the other extreme is the conventional tool chain
HTML FORMS -> SQL -> ARRAYS -> ARRAY RENDERING INTO HTML -> SUB into HTML TEMPLATE -> CSS

which rather than having one data abstraction, the XML tree / DOM tree / CSS etc.
has *four*
FORMS
SQL
ARRAYS
HTML

and then uses procedural code to convert between those formats.

FORMS -> SQL -> ARRAYS -> HTML
with procedural glue code at each step.

vs.

XFORMS -> XML DATA STORE -> XPATH / XQUERY -> CSS

where there are no procedural programs which convert formats

only obscenely complicated descriptors of how to pull the data you want out of the tree using functions, which are, in the final analsysis, directly equivalent to
wait for it

REGULAR EXPRESSIONS.

but applied to a DOM-like hierarchy
rather than to a text file.

what will win, god help us all, is procedural programs which render SVG directly to the browser, probably written mainly in fat, impenetrable JavaScript libraries – like xWindows for the Browser – which will be shipped with browsers, rather than downloaded.

but nobody knows that yet.