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

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!

[1]:
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-felem-01-b.html

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
   filter:none)?

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