W3C home > Mailing lists > Public > public-html@w3.org > March 2010

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 22 Mar 2010 15:46:52 -0700
Message-ID: <dd0fbad1003221546v7dc8d4f1ha942c266db83a717@mail.gmail.com>
To: "Ennals, Robert" <robert.ennals@intel.com>
Cc: "public-html@w3.org WG" <public-html@w3.org>, "Carr, Wayne" <wayne.carr@intel.com>
On Mon, Mar 22, 2010 at 11:22 AM, Ennals, Robert
<robert.ennals@intel.com> wrote:
> If you want to introduce an extension, and call your HTML documents
> “extended HTML” then you must introduce your extension in the same manner
> that SVG and MathML have been integrated into HTML5. That is:
> ·         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.

What specific use-cases is this designed to address?  I see that you
say it's supposed to allow extension like how SVG was developed.  SVG
*has* a spec, though.  It's a widely accepted standard, so it should
be possible to put it straight into HTML without further problems via
the "relevant specifications" clause (we call it out specially mainly
to handle the annoying namespaces that it comes with).

If this is meant for more experimental, not-yet-widely-accepted
extensions, how does this address the already brought up issues with
element-name extensibility wrt experimental browser implementations?

*Is* this even supposed to do anything special for browsers?  That is,
should extensions done through this mechanism have (or eventually
obtain) actual browser behavior based on it?  Or is meant just for
private stuff that, while it may be meant to be shared across the web,
shouldn't be treated specially by browsers?

Received on Monday, 22 March 2010 22:47:46 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC