Re: script tags fire in a switch element

Miles Elam:

>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.
Of course, this depends on the example and the current working load of
the CPU maybe, but I think, often one could write precision tests to see
a difference, because the concepts are quite different.
Currently it is not even a big problem to write tests to indicate, that
the precision of some viewers for some issues does not even fit
to the low requirements of SVG tiny for rendering precision -
would be surprising, if a scripted simulation of a declarative animation
is always more accurate ;o)

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

Just to clarify this - I'm not a member of the working group (any more),
therefore we will see, if there is a response from a working group
member or an official response. But if you can provide a detailed
suggestion, it might be more efficient to discuss and you might get
more people interested in this.
I just tried to explain what works currently (finally if something is
not implemented, related parts of documents will not be presented,
in some cases maybe only alternatives).
How I understand your problem: MSIE has the bug not to present
animated SVG, other viewers have the bug, that they may start
script interpretation within a switch alternative, that is not to
be presented.
Clearly MSIE should switch due to the feature string to the 
non-animation-alternative - if it does, it has still the big gap or bug
not to interprete declarative animation, but the feature string behaviour 
is correct.
The others have a bug in the interpretation of switch alternatives,
they should have an indication with a feature string for switch/conditional
processing (amazing, that you can test in theory that conditional processing
is not implemented with conditional processing ;o). If they have not, they 
have already two bugs concerning this -
wrong implementation and wrong feature string indication.
But if the conditional processing feature is not implemented properly,
one cannot expect, that this already specified method is reliable -
a disaster, if there is a bug in the method to work around bugs itself ;o)
Taking this together, these are too much and too different bugs in
different viewers, that authors can make efficient use of already
existing methods of SVG to help to work around gaps.

Do you really want a new method to work around bugs in implementations
of the existing method to work around bugs? Should we have yet another
work around specific in case, there are bugs in the implementation of this
new method? At which level it is time to give up? 
What do you expect, what could be specified in general for a situation,
where different bugs in different viewer block to provide efficient
alternatives for all viewers? 
Because switch, declarative animation and scripting are not much
related in general, this problem looks pretty specific, therefore
one might have to look for a more general solution for similar
complex problems, if there is one - but this can result in an infinite
recursion, if one needs a new method to work around bugs in
the lower level method to work around bugs.

Obviously it is annoying for authors, that viewers have lots of
gaps and bugs, but on the other hand, I think, in practice there are not 
much more options than to report bugs and gaps in format interpretation
in specific viewers. That this does not necessarily work and is frustrating
authors, cannot just be seen by the behaviour of microsoft, this is present 
by Mozilla, WebKit, Opera as well for some features - but microsoft
strategies against standards are still more prominent ;o)

About:
>As of Internet Explorer 10, conditional comments no longer work.
Well, these conditional comments were not perfect anyway.
However if it works up to version 9, you still have an option at
least for a subset of MSIE users.
Now they suggest 'feature detection' with scripting - this mixing of
different technologies to indicate or test with scripting, whether declarative
methods work, is surely a confused or hocus concept -  if there is
a DOM equivalent for something, does not indicate, that this
feature really works as specified declaratively, it only indicates, that
the implementor assumes, that there is some DOM feature available.
And this does not really help, if the author or viewer uses no scripting 
at all, just accessible and declarative methods, therefore as
conditional comments still no generally applicable method - looks
more like a regression concerning MSIE ;o)

What is needed, is a declarative method to test features, but
the current SVG method with feature strings does often not work
in practice as well - often viewers claim that a feature is 
interpreted, but indeed it has too many bugs and gaps in relation
to this feature, that this information is of any use for the author ;o)

What I suggested is the better approach, to use the same method
to prevent that the alternative is presented, if the method works,
what is applicable at least for some animated documents.
If one assumes, that scripting is interpreted (I have this always
switched off for unkown content - and if it does not work without
scripting, it will remain unkown for me ;o) - one can try similar
things with scripting - if one believes in this 'feature detection' -
is it possible to detect in Mozilla/Opera/WebKit, that declarative
animation is available and not for MSIE? If yes, one may have
a method to provide some 'script alternative' for MSIE with
script interpretation on. But if such a script has a size of a
few hundred kByte, it is understandable, that this will be no
useful alternative as well. Maybe you need a method that
a script with 'feature detection' loads only on demand more
scripts fragments, if they are needed - seems to be
more a task or feature for the scripting language, not for
SVG or (X)HTML as languages, the scripts are applied to.

What do you suggest, what could be specified to help authors
working around bugs and gaps of user agents with an efficient 
declarative method that really works or better than conditional 
processing without implementation bugs? Or concerning the 
already existing method with feature strings, how to have a 
reliable method to find out, if a bug or gap in one feature 
matters for the current document, if there is only a partial 
support of this feature? 
Obviously if the implementor does not know about a problem
or does not want to propagate the fact, there is still a low 
chance to get automatically information about this, but if
we care only about problems, implementors know and want
to propagate for one viewer version - how to give detailed enough
information about this to help authors?
Feature strings could be more detailled, but this will not help
for your problem, that viewers have bugs in conditional processing
itself.

Olaf

Received on Saturday, 18 January 2014 13:05:29 UTC