Re: Point of Extensibility

Hi all!

This is my first post to this list, and I've just been pondering this
problem for a few hours.
So...be kind if my suggested solution turns out to be complete rubbish :)

This solution has the following characteristics:
 - Won't affect exsisting pages out there at all (big plus)
 - Generic, a UA can decide what xml languages to support and when
("decoupling" of HTML 5 and other specs like MathML and SVG)
 - Support for fallback
 - XML languages can be parsed as XML (XML in HTML)
 - No tag-name clashes
 - Easy for authors to understand, even if the syntax is a bit ugly

What I'm suggesting is:
Standardize and extend IE's conditional comments syntax, where we introduce
a new "operator" (accept), that takes a mime-type string as operand

 => Only new UAs that understand this new syntax AND has implemented native
support or knows a plug-in is installed will handle this content
 => Legacy browsers will threat this as a comment, and display the fallback
content
 => Content with an xmlns within such a conditional comment should be parsed
as XML
 => An informative in-line error message should be displayed if not valid
xml (to help/force authors to behave)
 => It is another issue/discussion if the "browser sniffing part" of
conditional comments should be standardized

Here's an example:

<div id="myMathFallback">2x</div>
<!--[if accept text/mathml]>
  <math xmlns="http://www.w3.org/1998/Math/MathML">
     <mn>2</mn>
     <mi>x</mi>
  </math>

  <script type="text/javascript">
     document.getElementById('myMathFallback').style.display = 'none';
  </script>
<![endif]-->


It could also be possible to mix namespaces, and combine for instance MathML
and SVG like this:

<div id="myMathAndSVGFallback">
  <img src="http://www.example.com/images/2xWithEllipse.png" alt="2x">
</div>
<!--[if (accept text/mathml) & (accept image/svg+xml)]>
  <svg version="1.1" xmlns="http://www.w3.org/2000/svg">
     <ellipse cx="300" cy="150" rx="200" ry="80"
style="fill:rgb(200,100,50);"/>
  </svg>

  <math xmlns="http://www.w3.org/1998/Math/MathML">
     <mn>2</mn>
     <mi>x</mi>
  </math>

  <script type="text/javascript">
     document.getElementById('myMathAndSVGFallback').style.display = 'none';
  </script>
<![endif]-->


Regards
Eirik Mikkelsen


On 4/3/08, Hallvord R. M. Steen <hallvord@opera.com> wrote:
>
>
> On Tue, 01 Apr 2008 21:33:33 +0200, Julian Reschke <julian.reschke@gmx.de>
> wrote:
>
>  How about stating that any element with an attribute "xmlns", being set
> > > > to something different from "" or the XHTML namespace name, implies <ext>?
> > > >
> > >
>   Lots of existing content uses attributes named "xmlns" -- see e.g. <
> > > http://philip.html5.org/data/xmlns.txt>. (Only 45 pages in the data
> > > set had XML content-types, so this is pretty much all text/html). It seems
> > > that compatibility requirements will make it impossible to base anything on
> > > the "xmlns" attribute.
> > >
> >
>  Well, a similar argument can probably applied to *any* change in the
> > language, such as adding new elements.
> >
>
> 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).
>
> 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).
>
> --
> Hallvord R. M. Steen
> Core QA JavaScript tester, Opera Software
> http://www.opera.com/
> Opera - simply the best Internet experience
>
>