Fwd: [filter-effects] What to do with errors in filters / Re: Minutes, 13 November 2014 SVG Telcon

On 13 November 2014 23:57, Nikos Andronikos <
nikos.andronikos@cisra.canon.com.au> wrote:
> Did you mean to put fitler instead of filter on a bunch of classes?
> Corrected here: http://fiddle.jshell.net/ev10jtmp/2/

Doh.  Well that makes me look foolish!  Thanks for catching the typo.

So, the results are not quite so inconsistent as I thought (correcting the
CSS typo gets rid of the discrepancy between CSS and presentation
attributes!), but they are still a little confusing.  Here's the correction
of the breakdown from my original email.

There are four circles in each row:

   - The first column uses a valid URL that doesn't point to anything for
   the filter value. Browsers (latest FF, Chrome, Opera and IE tested on a
   Win7 system) currently do not render the graphic at all.

   - The second column uses an invalid URL that doesn't contain a #
   character. FF and IE treat it as a filter error (and don't render the
   graphic); Chrome and Opera treat it as `filter:none`.  In particular, they
   *don't* apply the fallback blur filter.

   - The third column in the fiddle is a straight syntax error, all
   browsers tested ignore the declaration and render the graphic, with
   fallback filter where appropriate.

   - The fourth column contains a URL reference to a valid filter element
   that contains an error in a primitive, all browsers cause the graphic to

The test suite page [1] posted by Robert Longson is interesting, and a bit
frustrating, in that it is the first official source I have seen that
clearly states that the filtered graphic should not be rendered if there
are errors in the filter.  There is no such statement in the SVG1.1 specs!


If the consensus is that the testcase should not be changed, then that
doesn't leave much leeway about how to react to errors in a single SVG
filter.  However, the areas of debate would still be:

   - What should be the response to an error in one filter within a
   sequence of filters?
   - What should count as a filter error (don't render the graphic) versus
   a CSS syntax error (ignore the declaration, render with fallback filters if
   any) versus a URL access error (current draft specs say to treat as

On the more general discussion, I am very sympathetic with those of you who
want an error result that supports debugging.  Debugging has certainly been
one of my greatest frustrations when working with complex filters!
However, I think perhaps that the need for better debugging feedback could
be better addressed through developer tools error messages.  For example,
most browsers print a warning to the console when they encounter a parse
error in path data, why not something similar for filter errors?  With that
need treated separately, the primary goal for rendering should be to
support progressive enhancement.

-- Amelia BR

Received on Friday, 14 November 2014 16:23:34 UTC