Re: script tags fire in a switch element

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

Irrelevant. I can work around browser implementation quirks. I can't
work around a browser vendor's refusal to implement a major feature.

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

I understand your theoretical point of view, but in practice it is
wrong. The script traverses the DOM to find the animation description
tags and implements JavaScript equivalents. As with most things on the
internet, while the pure case is obviously preferable, the pragmatic
case is equally correct if (and only if) the viewer cannot tell the
difference.

If I have two PNGs side by side, one with a restricted-size palette
and the other a 32-bit version, there is no difference to the viewer
if they cannot see the difference even though they have markedly
different sizes and therefore latency performance. If I have two SVGs,
one driven by declarative animation and the other driven by JavaScript
and event loops, there is no difference to the viewer if they cannot
see the difference. On the other hand there would be a marked
difference if the latter were replaced by text, a raster graphic, or a
static vector.

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

And yet the declarative animation structure is still there in the DOM.
It is what is driving the behavior of the script. It does matter.
There is an alternative. It is not perfect, but there is relatively
smooth graceful degradation. This is far, far better in practice that
a simple binary works/doesn't work.

More to the point, yes, a user or agent could turn off scripting and
be left with something non-optimal. That is theoretically possible. In
practice it is so highly unlikely that an IE9, IE10, or IE11 would
browse the web with JavaScript disabled, it is not a reasonable
concern. Were a user sufficiently savvy to disable it in this case,
they would most likely be doing so for security reasons and not be
using Internet Explorer in the first place. Were Internet Explorer to
disable scripting in SVG, they would be killing a non-trivial number
of sites geared toward that browser with no alternative method
available to developers–quite unlike traditional Microsoft behavior. I
cannot simply ignore a huge swath of viewers for the sake of a
theoretical 0.0001%.

The fact remains that SVG currently affords no mechanism to solve this
issue. To hand wave away the problem with statements like "there is no
win" or "there is no way to work around the gap" ignores both the
problem and the fact that people are indeed working around the gap. I
didn't mention this problem because I expect this working group to fix
every browser in production today. I had merely hoped that someone
would recognize that this class of problem exists and that the specs
currently give no advice whatsoever as to what to do about it.

> Note that according to the draft about 'integration'
> https://svgwg.org/specs/integration/#static_mode
> 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)

I had not seen this before. It is also an error in judgement for
someone to have proposed it unless their goal was to ensure SVG is
never adopted in the large. It would not surprise me if user agents
ignored this provision en masse or at the very least opted instead for
"animated mode". While on (virtual) paper it may seem reasonable, the
end result will be that developers will use animated GIFs, animated
WebPs when available, draw to HTML5 canvases used as backgrounds, and
the like. Once again cutting off the nose to spite the face as they
could not use SVG at all in this case. The likely developer response
must be considered.

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

As of Internet Explorer 10, conditional comments no longer work.
http://msdn.microsoft.com/en-us/library/ms537512.ASPX


Cheers,

Miles Elam

Received on Friday, 17 January 2014 18:14:09 UTC