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

>
> I presume if the implementation supports the  SVG DOM, it'll have no
> problem rendering it.
>

why are you ok with making this assumption, compared to the feature string
one ?
what if getComputedStyle() is buggy and doesn't return the expect value for
the test, but everything else works ?



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

Are you saying that buggy implementations in regards to the feature strings
will lead to buggy SVG rendering ?
It doesn't seem surprising.


I don't understand the difference between really testing ONE of the
features, and testing a feature string (which is also a feature of a spec).
I mean, how do I know what feature to test, and how to test it accurately ?
I don't think feature strings are ideal, but instead of requiring each
author to come up with his own new great idea to test a feature against
irresponsible and evil implementors, it would responsibalize implementors by
giving them and authors a converged focal point.

I understand that's a little bit easier (or is it?) for implementors not to
summarize their development status in feature strings. But it is really a
pain for authors to first test features for every one they plan to use. Do I
really need to attach a MyOwnAcidTest library to every web application I
develop ?

Can we have some implementors opinions ?




> Once everything is implemented correctly everywhere, feature strings aren't
> useful anymore, because they'll always return true.



> When they're all always true, they're reliable, but not useful


It seems contradictory, or I don't follow you.


It doesn't matter to know if the implementations are buggy or not. It's not
the purpose of feature strings. It is there to say "ok you can try that
feature with me". no matter how buggy.

Take the use case that is at the beginning of this thread :
I put svg in html and i want to fallback to a hack in browsers that don't
support it yet, to use their xhtml+svg support.
It doesn't matter if the html+svg or xhtml+svg implementations are buggy or
not (they probably are both).

The point is really not to know if it will render as I expect or not, nor if
the styles will be computed, nor if it will render at all.
I think the point is to know if the implementation _says_ it can deal with
svg in html.
And that you cannot test right now.


Thanks