- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 6 Oct 2009 14:46:27 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Henri Sivonen <hsivonen@iki.fi>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Brendan Eich <brendan@mozilla.org>
On Tue, Oct 6, 2009 at 4:33 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Jonas Sicking wrote:
>> We already have one simpler thing, which is what HTML uses, where a
>> nodes meaning is derived from its nodeName alone.
>> ...
>
> Yes, but sometimes simple is too simple.
I don't normally pitch in on these namespace discussions, because they
go in circles. But I'm really not clear on something here. What is
the practical advantage of requiring a namespace declaration that
causes "foo:bar" to be treated as "{http://something-or-other}bar",
over just treating "foo:bar" (or for that matter "foo_bar" or
whatever) as an opaque string, as with CSS vendor-specific extensions?
After reading numerous lengthy arguments over the matter, I can only
think of about two reasons:
1) It prevents inadvertent prefix collisions.
2) It's widely used already.
The risk of prefix collisions (1) seems minimal. Allowing extensions
to use a global namespace and trusting implementers to not choose
names that are likely to conflict tends to work fairly well. CSS
vendor extensions are one good example. HTTP and e-mail X-* headers
(one namespace for all extensions) also haven't caused major problems
in practice. Problems would only have to arise, anyway, if both the
prefix *and* the tag name (or attribute, etc.) were the same in two
different extensions, *and* someone wanted to use both extensions in
the same document. This benefit therefore seems minor at best.
(2) might be true in a generic sense, but not in the specific case of
HTML, and particularly not in text/html. To the contrary, supporting
XML-style namespaces in text/html would apparently cause significant
interoperability problems with existing content. At best, widespread
use in other standards is a very weak argument from a practical point
of view.
What exactly is too simple about relying only on nodeName?
Received on Tuesday, 6 October 2009 18:47:00 UTC