W3C home > Mailing lists > Public > www-svg@w3.org > January 2014

Re: script tags fire in a switch element

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 17 Jan 2014 17:53:33 +0100
To: www-svg@w3.org, mcelam@google.com
Message-Id: <201401171753.34143.Dr.O.Hoffmann@gmx.de>
Miles Elam:

>I already have graphical fallbacks to raster graphics if SVG is not

I think, you do not need to do this, if you have alternative text for those
SVG documents, that are not only decorative.
And if the graphics are only decoration, you need no alternative text
both for SVG and for raster images and you do not have to worry about
wrong or incomplete display or no display at all ...

>The issue at hand is that IE9 and above indeed support SVG; they 
>simply don't support SMIL. Rather than burden every SVG-capable browser
>with 6KB of JavaScript when the original SMIL asset is just over 500 bytes,

Well, other viewers have major bugs and gaps as well - unfortunately.
It would be already a big progress, if only one viewer had major bugs and 
gaps ;o)
To get replacements for some of them for static files you may get 
an increase of the file size of some orders of magnitude ...
However you should note, that java-script is no alternative or
replacement for declarative animation.
If script interpretation is switched off, such scripts will not matter
for the presentation and they do not matter for content anyway. 
The script does not really change the meaning of the
document, only the appearance. This differs from declarative
animation - this really matters for content ;o)
As you can see, their is no win in using scripts as an alternative,
because it is no alternative.
If a viewer does not animate declaratively, there is no equivalent
replacement. The audience can only replace the viewer, if it needs
to see what is really going on.

>I wanted a way to conditionally load the script only when the SMIL features
>were missing. From what I'm gathering, this is not possible, and my only
>viable options are user agent detection on the server side or a stub
>loading script in the SVG.

This I understand, sounds like a bug of those viewers if their script
interpretation is switched on. Unfortunately there seems to be no
method for authors to switch script interpretation off.
Just to avoid needless discussions in bug reports to implementors 
I recommend to send documents that validate.

>The accessibility provisions do not apply here as the SVG already has
>alternate text.

Well, then everyone, at least in theory has access to the content,
no need to worry.
Because there is no way to work around the gap not to interprete
animation for authors, good alternative text seems to be the only
way to propagate the content to users of viewers with such major 
gaps and bugs.

>In addition when used as a CSS background image, alt text 
>becomes moot anyway. The crux of matter is that IE9 and above can do
>everything I require, they just require one additional asset to do it—an
>additional asset that is 10x larger than the file it acts upon—and I would
>prefer not to load in other browsers if I can avoid it. Yet falling back to
>descriptive text for all IE versions is completely out of the question as
>that would be cutting off my nose to spite my face.

Note that according to the draft about 'integration'
in the future viewers may not apply scripts or declarative animation to CSS 
background images anyway. 
Once viewers care about this, there will be no chance to
provide non static background images with CSS anyway - what is
a little bit surprising, because there are already drafts for CSS animation 
and there seem to be methods to change the style within the DOM with
scripts as well. ;o)

Microsoft introduced 'conditional comments' - this might help to provide
other stylesheets for specific versions of MSIE to hide bugs of these 
specific versions of MSIE - did you try this?

And as already mentioned - no need for text alternatives for CSS background
images - they are only decoration. You can use a simple color as alternative
to ensure that there is still enough contrast bet fore- and background.
Obviously if the viewer interpretes only parts of an SVG correctly, you may
get in trouble with contrast of background to foreground, but due to the
'integration' draft it is better not to rely on animation and scripting in 
background images anyway.

Received on Friday, 17 January 2014 16:54:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:50 UTC