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

On Thu, 23 Jul 2009, Doug Schepers wrote:
> > 
> > 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?

You could use getComputedStyle() to see if some relevant SVG-specific 
feature has been translated to the cascade, or you could check to see if 
using createElemenNS() to create an SVG element results in an element with 
appropriate DOM attributes, etc. Basically anything to test whether the 
implementation supports SVG. (I presume if the implementation supports the 
SVG DOM, it'll have no problem rendering it.)


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

It would apply in the same way, just using the MathML DOM instead.


> How would it work if script isn't available?

No. Aren't feature strings a DOM-specific feature? I'm assuming we're 
talking about the DOM hasFeature() here.


> > (Feature strings tend to be very unreliable.)
> 
> That seems like a pretty broad statement.  Can you say in what way they 
> are unreliable?

A feature's implementation will go through several stages:

 - non-existent
 - incomplete and buggy
 - somewhat complete and buggy
 - somewhat complete and a bit buggy
 - more complete and less buggy

Each implementation will reach a slightly different level of "complete" 
and a slightly different version of "buggy". However, feature strings are 
booleans: the entire range of the "complete"/"buggy" phase space gets 
collapsed into one bit of data: is the feature supported?

Implementors tend to be responsible, so they'll avoid setting the bit to 
"true" when they're at the "incomplete and buggy" stage. But when should 
they decide that they're complete enough to change their mind? Some 
implementors are eager to advertise support, and so set the feature 
strings to "true" early in the process, e.g. at "somewhat complete and 
buggy". Others may be perfectionists, and not set it until their version 
of "more complete and less buggy". Yet others might forget about the 
feature strings altogether, or might be so eager than they copy entire 
blocks of feature strings into their implementations and have some of them 
return true even though in practice they're still at the "non-existent" 
stage.


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

What HTML5 specifies will be implemented buggily. Hopefully 
implementations and the specification will converge; however, that doesn't 
change the fundamental fact of life, that the implementations will be 
buggy. That's not ideal, but it's generally fine for most features, 
because people can work around the problems during the growing pains. The 
features don't actually have to be fully reliable to be usable.

Feature strings, however, are the exact opposite. They have only one 
purpose: finding out if a feature is usable. If they aren't reliable, then 
they aren't usable. They fundamentally rely on implementations skipping 
the "buggy" stage and going straight to the "complete" stage.

What's more, they are _only_ useful during the growing pains. Once 
everything is implemented correctly everywhere, feature strings aren't 
useful anymore, because they'll always return true. So unlike other 
features, where the reliability can improve over time, thus making them 
even more useful, the reliability of feature strings is in fact inversely 
proportional to their usefulness. When they're all always false, they're 
reliably, but not useful. When they're all always true, they're reliable, 
but not useful. When they're in the middle, they're intrinsicly 
unreliable, and thus not useful.


> This could also be the chance to introduce a generic and simple 
> declarative fallback mechanism that works across modern browsers.

This concept has been proposed many times over the past few years, but it 
suffers from the same problem. It would need to be always reliable, and 
never buggy, to be usable.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 24 July 2009 03:34:20 UTC