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

Re: script tags fire in a switch element

From: Miles Elam <mcelam@google.com>
Date: Fri, 17 Jan 2014 07:19:23 -0800
Message-ID: <CAGYSi7Ep8dzFaGv5U9gC-2CFcvRux8-XfhJKEuP9dEimjAT8Pw@mail.gmail.com>
To: www-svg@w3.org
In this case it's for a loading spinner animation. The rectangle was merely
to show an easily understandable test case. Yes, I can put the script
element inside a g to make sure the document validates, but that misses the
issue where the nested script still executes.

I already have graphical fallbacks to raster graphics if SVG is not
supported. 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,
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.

The accessibility provisions do not apply here as the SVG already has
alternate text. 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.


Cheers,

Miles Elam

On Friday, January 17, 2014, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:

> Hello,
>
> if you put your script element into a g element, you do not have
> to worry about validation and the g does not change the switching
> behaviour and if required you can put more elements into the g.
>
> Concerning the lack of animation capabilities in MSIE or maybe some
> other browsers you have several options.
> However you should always have a good text alternative in title and desc
> of the root svg element. Reading this, the audience can always understand,
> what is intended.
>
> And if animation matters and there is no graphical alternative without,
> you can add some text to the file, explaining that animation support is
> required for understanding, due to a bug or gaps this seems not to be
> available in the used viewer, but one can read title and desc to get
> a text alternative. With a set or animate element you can remove this,
> in case animation works. This is a more advanced feature selection
> than switch, because you use the same feature to remove the hint or
> warning as is required for your content.
>
> Or you can put all your animation related content into one g element
> and a hint about no animation into another and both into the switch
> with the required feature.
>
> With tref you can reuse text from title and desc to display this directly
> with graphical text elements as an alternative for the animated content
> (but you have to ensure, that related viewers not interpreting animation
> interprete tref for this approach). Doing this, the audience does not
> have to switch to the alternative text view manually in case of bugs and
> gaps of the viewer.
>
> Obviously, if you embed the SVG or reference it from other files, you
> can provide a hint as well, that interpretation of animation is required
> for the file - and if you like, you can add a collection of viewers, that
> do
> the job properly, to facilitate the audience to find and install better
> software than they currently use.
>
> But your test file only contains a static red square, no animation at all,
> therefore it is not obvious, what you want to do with it and if there
> is a way without animation - respectively I can see the red rectangle
> with and without animation capabilities, it simply does nothing else -
> why to require the animation feature for this?
>
> Olaf
>
Received on Friday, 17 January 2014 15:19:52 UTC

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