- From: Doug Schepers <doug@schepers.cc>
- Date: Thu, 23 Jul 2009 22:49:06 -0400
- To: "public-html@w3.org" <public-html@w3.org>
- Cc: www-svg <www-svg@w3.org>
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