RE: Interim strategies for no SMIL (and other?) support in IE9

Patrick Dengler:
>We are working on coming up with clear strategies for Internet Explorer and 
>hope to update developers on that soon.  I would, however, suggest that you 
>avoid UA string detection and leverage the built in hasFeature in the DOM to 
>detect SVG support, as well as more granular hasFeature in SVGDOM, and 
>declarative <switch>.

What about the HTTP_ACCEPT string to get a rough impression about
an overall interpretation of SVG? 
(can be problematic as well, if not all user-agents with SVG capabilities
or active SVG plugins indicate this within this string ...)

The problem with switch and requiredFeatures is often, that the feature
strings are not precise enough. 
Therefore and often for other reasons the reaction of the viewer is not 
precise enough.
Cautious viewers will too often use the alternative.
Careless viewers will too often claim to interprete something correctly.
Another problem is, that older viewers do not know newer feature
strings. In many cases their presentation would be nevertheless 
acceptable.
Theoretically requiredFeatures is a nice concept, practically it
is hard to use with the current diversity of viewers and their
individual behaviour and interpretation of this feature.

For example should currently really any viewer switch for
'http://www.w3.org/TR/SVG11/feature#Animation' properly?
- all have bugs and gaps concerning animation, therefore
a conditional processing should be never true theoretically.
On the other hand, for a more or less large subset the
interpretation in several viewers meanwhile is correct
and usable (Opera, Bitflash, Batik/Squiggle, WebKit, Adobe plugin,
current Firefox preview etc). Therefore practially the processing 
of this string is not very informative.

The behaviour for requiredExtensions is even harder to predict.
Currently I did some tests with foreignObject. And it turned out
for example with a simple poem marked up with DAISY 
and styled with CSS, it is better not to use requiredExtensions 
for Geckos, just because they manage to display the styled text 
in an acceptable way. Opera on the other hand does not provide
a useful result. This should apply for arbitrary XML styled with CSS
as well.
For XHTML with some functionality in foreignObject Opera tries to 
present something, but it is useless - the alternative would have been better.
Presentation with a Gecko is much better, but the function
does not work, again to present the alternative would have been
better. With WebKit in Arora neither the XHTML nor the SVG
alternative is presented.
With some simple MathML presentation in Geckos
was nice, with Opera questionable. Opera should have presented
the alternative for a better result. 
With WebKit in Arora neither the MathML nor the SVG alternative is 
presented.
Just from these few tests I got the impression, that an average
author will be overstrained by switch and requiredExtensions.

The new requiredFormats has problems in some viewers
as well. For example in Opera one has the problem, that
this with a value like 'application/ecmascript' does not switch 
to a scriptless alternative, if the user only switched off script
interpretation. And older viewers not knowing the attribute
of course ignore it anyway. Similar applies for the related
feature string for scripting.

Because some viewers can have different methods to
present SVG content (for example Konqueror 4 can use
the build in KSVG, WebKit or a plugin like that from adobe),
the information within the user-agent-string indeed is not very
useful. Additionally due to some bad history it is often faked
to indicate Netscape 4 or an MSIE that claims to be
Netscape 4 ;o)
However due to the problem of previous MSIE versions
with XHTML many authors are already used to sniff for 
problematic user-agents. Hopefully many of these algorithms
are optimistic for newer versions and unkown user-agents not
faking other user-agents...
(and it could be a good idea of course to not longer claim
that a newer MSIE version is only compatible with Netscape 4
with almost no CSS capabilities and no SVG capabilities ;o)

Therefore currently I can see no simple strategy for authors
to work around gaps and bugs in different viewers. The only 
more or less useful approach is to provide a text alternative 
with title and desc elements. With this at least the audience 
has an indication for the quality of the presentation of the 
currently used viewer.


Olaf

Received on Tuesday, 4 May 2010 09:40:08 UTC