RE: animation and stroke: css, svg and browsers: Part II: gradients and opacity in stroke and fill

David Dailey:

>1. http://cs.sru.edu/~ddailey/GradientStroke1.svg 
>2.  http://cs.sru.edu/~ddailey/GradientStroke2.svg 

>In 1) all browsers and even old Safari/Win seem to render consistently, but
>regardless of how one tries, the gradient (applied to both fill and stroke)
>does not bleed beyond the strict edge of the original object's footprint.
>Should it? At least in some circumstances?

Try to use more attributes for the gradient.
For example:
a) gradientUnits = "userSpaceOnUse"
b) r="100%"
c) spreadMethod = "reflect" or "repeat"

About 2) - currently you use the default spreadMethod ="pad",
this is what can be seen for example in the current version of
Opera (12, there is no new stable version yet, only experimental
for few non Linux/Unix sytems).

The recommendation mentions:
"'pad', which says to use the terminal colors of the gradient to fill the 
remainder of the target region"

If there is a different behaviour in some viewers, this is probably a bug,
should be explored with more and a simpler text cases however, indicating
more clearly what is wrong or right presentation.

>BTW -- I disagree with ROC, though, that comparing old browsers is
>irrelevant. Sometimes, to this very day, only ASV and/or old Opera render
>things properly, and there have been dozens of instances in the last four or
>five years where Webkit progress in newer versions reflected in Chrome
>breaks content that still runs properly in older Safari, so the comparison
>is oftentimes valid, even though Old Opera, ASV and Safari/Win are no longer
>being maintained -- the older things represent one implementation's reaction
>to the SVG spec at one point in time. Sometimes those readings are as valid
>as someone else's, particularly about things like whether or not certain
>features are important to authors.

It depends on the question, which browser versions matter for testing.
- compare the quality of different implementations/versions
- explore which presentations users get
- determine progress and regressions in implementations, for
  example to find out approximately, at whicht point a regression
  appears (simplifies to identify the bug and to fix it, respectively
  if the bug was intended to publish dates/versions, at which points
  an implementation starts to deviate from recommendations
  intentionally)
- to care as an implementor, what other implementors currently do

Only in the last case it does not really matter, how older versions
behave ;o)

Due to my systematic test, something around Opera 10 is still the best 
implementation for SVG 1.1, but even this has a larger number or known bugs.
I think, meanwhile ASV is not so important anymore for comparison,
the few cases ASV still has a better implementation than Opera 10 are
covered by other implementations, not having the same bug or gap
as Opera 10. The average quality of the ASV implementation is comparable
with Squiggle of Firefox, but of course all of them have different bugs and 
gaps - still a long way to go to compare with Opera 10 ;o)
Another problem can be, that there are a few backwards incompatibilities in
the second edition of SVG 1.1 and as well some bug fixes, therefore the
behaviour for earlier implementations can be different for an SVG 1.1 file.
Because there is no different version indication for the second edition, there
is no way to decide, what it right or wrong in such cases.
Therefore it is still relevant for SVG 1.1 tests to care about older 
implementations as well. As we can see for the Opera example, newer
versions are not necessarily better than older - therefore for the audience
it can be of course pretty useful to have older versions installed, if newer
fail - this is even more true for the current experimental versions of Opera,
using WebKit/Blink instead of the (concerning SVG) more advanced Presto.

And another issue - if one uses package management systems for operating
systems like Debian Linux, for some programs it can take two or more years
until a new version of a program is available, meanwhile there are only bug 
fixes for the stable version available, therefore it is often of not much use
to test instable versions of programs, if one wants to explore, what the 
average audience will see.
The problem with WebKit implementations here is typically, that it is
updated quite often, but difficult to install independently from the 
package management, therefore one does not have one version for a 
longer time, therefore no defined test object, that matters at all 
- maybe this will change, if there appears a stable version of the new
Opera-WebKit/Blink variant (in a few years?).


Olaf

Received on Tuesday, 22 April 2014 10:51:16 UTC