W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Re: Point of Extensibility

From: Doug Schepers <schepers@w3.org>
Date: Thu, 03 Apr 2008 10:32:28 -0400
Message-ID: <47F4EA7C.80006@w3.org>
To: public-html@w3.org

Hi, Hallvord-

Hallvord R. M. Steen wrote (on 4/3/08 8:00 AM):
> Certainly, but for a nugget of implementor experience to back up what 
> Philip is saying: Opera at some point had some "support" for xmlns in 
> text/html. It was removed because it broke pages when random sections or 
> elements were no longer considered HTML markup. (I know without offering 
> more hard facts like what exactly we "supported", how many pages we 
> noticed breaking this is semi-anectdotal - I could look up those bugs if 
> required).

Perhaps not required, but it would be very nice.  Hixie might consider 
it required, as he is unconvinced that we can usefully and safely use 

> So we really can't imply <ext> when we see some xmlns - or at least not 
> without extra magic that would "fall back" to un-implying <ext> if the 
> "unknown" content looked like HTML after all (naturally, nobody wants to 
> go down this route).

Unsurprisingly, a known namespace declaration that matches the known 
root element is the clearest way forward for this.

root: <svg>, namespace: "http://www.w3.org/2000/svg"
root: <math>, namespace: "http://www.w3.org/1998/Math/MathML"

Should we consider RDF on this short list?  Metadata is also core 
functionality, in addition to text, math, and graphics.

I don't *like* implied elements (they would be confusing to even 
moderately sophisticated authors when walking the tree), but I don't 
have strong objections to Erik's idea that the following 2 snippets 
would both result in the same DOM tree:

1) Explicit:
   <svg xmlns="http://www.w3.org/2000/svg">
    <circle />

2) Implied:
  <svg xmlns="http://www.w3.org/2000/svg">
   <circle />

      |svg xmlns="http://www.w3.org/2000/svg"

Two advantages to explicitly using <ext>, however:

* Compatible with Henri's general solution, but with the added benefit 
of the ability to supply a rich fallback.

* Incredibly unlikely to break any content... there may be content out 
there like #2, but unlikely to be any like #1; you could think of the 
<ext> as a sort of "early warning" to browsers that a known "insertion 
mode" is about to follow.

-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
Received on Thursday, 3 April 2008 14:33:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:32 UTC