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

Tab Atkins Jr. wrote:
> On Mon, Mar 22, 2010 at 11:22 AM, Ennals, Robert
> <robert.ennals@intel.com> wrote:

[snip]

> 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).

There are several use cases.

This is primarily for extensions that do have a spec. The aim is to provide guidelines for how such a spec should be written to minimize clashes with HTML. It is not a substitute for spec authors talking to the HTML WG. However making platform extensions to HTML is likely to be easier if there are conventions about how it should be done.

That said, it does not have to be as high-profile and mature a spec as SVG. It may be a lesser known developing spec that is not yet big enough for members of the HTML WG to be able to spend lots of time helping people understand how they should make their spec play nice with HTML.

While such specs will still count as "other applicable specifications", I think it is still useful to have guidelines about how such other specifications should be written, and to give guidelines for user agents about what kind of markup they should expect to see in the wild that has been created for one of these specifications.

> 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?

The element-name extension stuff is not intended for use by browser-specific extensions. Only vendor-neutral specs should define element names.

However, in my modified variant, a browser-specific extension may use a prefixed attribute. Note that, 
although we do not change the parsing behavior of element names (since they can't be prefixed), the variant with prefixed attributes /does/ change the parsing behavior of attributes, since they may now have a prefix.

> *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?

The element type extension stuff is for "platform features" such as SVG, MathML, and future stuff along those lines. Some of these may be implemented in standard browsers. Some of these may be implemented in other user agents such as special purpose browsers.

The prefixed-attribute stuff allows for stuff like RDFa and also for vendor-specific features.


-Rob

Received on Monday, 22 March 2010 23:06:50 UTC