Feature Strings and Fallback for SVG (was: [svg-developers] Re: Forcing browsers to render SVG in text/html context)

Hi, Brad-

Ian Hickson wrote (on 7/23/09 8:38 PM):
> On Thu, Jul 23, 2009 at 08:31, Bradley Neuberg<bradneuberg@gmail.com>  wrote:
>>  A feature string on would be *great*. There might be two: whether SVG
>>  in HTML is *parsed*, and whether SVG in HTML is *displayed*. There are
>>  none presently; that would be a great thing for Doug Schepers or Ian
>>  Hickson to propose. Added them to this thread.
>
> Please send feedback to one of the HTML lists. :-)
>
> Generally speaking, I'm not a fan of feature strings, more a fan of
> feature detection. You can easily detect SVG parsing ability (just
> check to see what namespace the<svg>  node is in after doing
> div.innerHTML = '<svg></svg>' on some div you just created), and you
> can easily detect SVG rendering ability (just poke at the SVG DOM and
> see if it is present), so it seems this use case is already covered.

I suppose you mean something like getting the bounding box of an 
element?  Or maybe you could expand on how you can detect if SVG has 
been rendered?

How would this apply to MathML, or to some other language?

How would it work if script isn't available?


> (Feature strings tend to be very unreliable.)

That seems like a pretty broad statement.  Can you say in what way they 
are unreliable?  HTML5 has specified many things to a greater degree of 
precision, to promote interop, which is good, and introduced many useful 
new features; why can't you simply introduce or refine a feature-string 
mechanism that *is* reliable.  This could also be the chance to 
introduce a generic and simple declarative fallback mechanism that works 
across modern browsers.


Regards-
-Doug

Received on Friday, 24 July 2009 02:49:49 UTC