Re: Possible Conservative Proposal : no prefixes, but allow xmlns on a root element

On Mon, Mar 22, 2010 at 2:22 PM, Ennals, Robert <robert.ennals@intel.com> wrote:
> ·         Define a root element (like math or svg) that content for your new
> extension can be included under.
>
> ·         If the extension is not yet part of HTML, the root element MUST
> contain an xmlns.
>
> ·         Such a root element MUST NOT be an existing HTML5 tag
>
> ·         If the extension is part of HTML, then the parser will infer the
> xmlns based on the name if no xmlns is currently present
>
> ·         If the browser encounters an unknown element with a default
> namespace declaration, then it should apply that namespace to all descendent
> nodes.
>
> ·         Use a registry to help spec authors ensure that these root
> elements, and ideally also the other elements, are unique. Also strongly
> encourage creators of such extensions to talk to the HTML WG. However the
> registry has no normative function, but is merely a recommended tool to help
> groups coordinate better.

This sounds fine except for the xmlns stuff.  Why not simply drop
that?  Old browsers will assign an HTML namespace to the content --
but who cares?  They won't support the features anyway.  Likewise, if
you use <svg> right now, all browsers except IE9 and Firefox with
html5.enable will treat it as an unknown HTML element, but that causes
no actual problems.  When inline SVG support is added, the elements
will be assigned a different namespace than they are now.

The extension procedure for things like this should, IMO, just be to
define a top-level root element, then do whatever you want under that,
provided you don't use any tag or attribute names that conflict with
HTML (because those will usually result in incorrect behavior in UAs
that don't know about your feature).  If your spec is small, it's
possible that name conflicts will be introduced by elements in new
HTML versions, but those are likely to be manageable.  Better to take
that small risk than to burden authors with additional boilerplate on
millions of pages.

Received on Wednesday, 24 March 2010 19:10:01 UTC