W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] Possible compremise for namespaces in html5

From: Rob Ennals <rob.ennals@gmail.com>
Date: Thu, 5 Nov 2009 20:16:57 -0800
Message-ID: <f3fb55dd0911052016r72699b20n305ca763963fdfdf@mail.gmail.com>
I talked to a few more people, resulting in the following additional
requirement:


"A prefixed node MUST NOT contain HTML nodes"

This is to stop people creating prefixed nodes that replace HTML
nodes, with resulting loss in universally understood semantics.
Prefixed tag names are to be used only for data. If you want to add
information to a node that contains HTML nodes, then this must either
be done with a prefixed attribute, or microdata.

This would break some existing practices, but those are arguably bad
practices and should be changed. E.g. in Lift you can write:
<lift:surround with="default" at="content">
   ... some HTML ...
</lift:surround>

But this would be better done as
<article lift:surround-with="default" lift:at="content">
   ... some HTML ...
</article>

BTW: my previous email was wrong. Ruby markup isn't proper XML - I was
confusing it with Lift.


There is some question about exactly how best to map a prefix into a
namespace. To enable polyglot files, we need to allow a user to write
an xmlns decl that specifies the same namespace that the prefix
automatically maps to, but XML does not allow a namespace to be just a
string like "fbml" or "lift". One suggestion is to have a default
mapping to something like "whatever:lift" - which would also be the
namespace used by the HTML parser. There is then the question of
whether createElementNs should accept a prefix in place of a
namespace.


Barring niggles, this version seems to have tentative buy-in from
people on both "sides" of the namespace argument.


-Rob


On Thu, Nov 5, 2009 at 4:50 PM, Rob Ennals <rob.ennals at gmail.com> wrote:
> [this is Ron Ennals from Intel, posting from gmail on my phone while at
> tpac]
>
> I've talked to a few people about the distibuted extensibility problem and
> I'd like to suggest a possible compremise:
>
> * maintain a central registry of prefixes with standard meanings - so eg fb
> always means fbml. Thus no namespace decl is needed.
> * for a prefixed node the prefix is itself the namespace - thus the user
> agent doesn't need to know what a prefix means
> * prefixes are allowed for tags and attributes
> * a web browser MUST ignore prefix tags and attributes - they are for data,
> just like microdata and data attributes, not for browser extensions
>
>
> I believe this satisfies the most important requirement for the people who
> like namespaces and the people who don't. In particular:
>
> Reasons why namespaces etc are good:
> * allow data on a page without worrying about name clashes
> * copy and paste data from existing XML files into HTML
> * support markup like fbml, rails, etc - on the client as well as server
> * allow companies to include their own XML data inside an HTML file, for
> processing with other tools
>
> Reasons why namespaces are bad:
> * copy and paste breaks
> * the meaning of a tag depends on what namespaces you have
> * the encourage incompatible extentions to the browser
> * long namespace urls are horrible
>
> I've pitched this idea about a bit and got tentative buy in from some (but
> not all) people on both sides of the namespace divide.
>
> This idea is unashamedly derived from Liam Quin's similar proposal, tweaking
> the bits some people didn't like.
>
>
> Comments/bugs/stupidities... ???
>
>
> [I'll probably post this to public-HTML too later, but I can't do that from
> gmail on my phone]
>
> -Rob
>
Received on Thursday, 5 November 2009 20:16:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC