- From: John Cowan <cowan@mercury.ccil.org>
- Date: Sat, 1 Jan 2011 20:37:13 -0500
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Norman Walsh <ndw@nwalsh.com>, public-html-xml@w3.org
Benjamin Hawkes-Lewis scripsit:
> That is, how might it happen without the web's client software being
> updated to build interfaces on top of the semantics expressed by those
> namespaced vocabularies?
The whole point of JavaScript is to make the web's client
software dynamically updatable. (Of course, not all clients are
JavaScript-capable.)
> My argument is: using arbitrary vocabularies to express renderable
> content, rather than merely annotate it with metadata, will break
> those interfaces, and namespaces do *nothing* to help with this
> situation. How could they?
Some convention must exist to determine which part of a
dynamically-updated client is to process what. For SVG-in-HTML5 and
MathML-in-HTML5 (as distinct from SVG and MathML as XML vocabularies)
that's the special root elements "svg" and "math". That convention is
no more and no less problematic than the namespace convention, except
that it's simpler because it is more direct (and by the same token
less extensible).
> <foo:whizzbangbutton foo:quux="Do something"></foo>
>
> is /just/ gobbledygook. This is bad HTML because the button has not
> been marked up with an appropriate element, so it cannot be recognized
> in the uniform interface.
That doesn't work (and only doesn't work) because there is no standard
declarative way to specify the behavior of an element in the way that
CSS specifies its appearance. In a hypothetical CBS, you could write
"foo|whizzbangbutton { button }" and get interoperability.
--
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
John Cowan <cowan@ccil.org>
Received on Sunday, 2 January 2011 01:37:44 UTC