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

[response follows]
On 13 November 2014 17:35, Brian Birtles <bbirtles@mozilla.com> wrote:
>
>  4. If an SVG filter has any other error, cause the filtered graphic to
>>     disappear (new resolution, justified as being consistent with
>>     current implementations, but not particularly useful otherwise).
>>
>
> I think 4 is problematic. As I noted in the meeting I would prefer we have
> nicer fallback in that case.
>
> I was persuaded to keep 4 given that it is interoperable but I think your
> point about progressive enhancement is important.
>
> What do you propose we do in that case? Some possibilities might be:
>
> a) Make the output of that filter primitive transparent black (I wonder if
> that works in all cases)
> b) Make the result of the whole filter chain equivalent to 'filter: none'
>

I had suggested in my first note [1] that an error in a filter primitive
could break the filter chain, returning the result from the previous
primitive.  The main benefit of this would be easy debugging.  The downside
is that the output could be quite unrelated to the intended final product
of the filter.  Authors would have to carefully calculate the design of
their filters if they wanted to use filter features with inconsistent
browser support and still always have acceptable output.

Making the output of an error-state filter primitive transparent black
would, in many filters, have the same effect of causing the filtered
graphic to disappear.  In other filters you'd get pieces of the intended
result, depending on how different layers are composited.  I don't think
this would be useful for debugging, and it would have the same problem with
getting arbitrary unintended output.

Responding to a filter error by rendering the graphic with `filter:none`
doesn't help with debugging, but it will usually be an acceptable fallback
result.  It is the approach the draft spec currently recommends for invalid
URL references.  It is also consistent with the way errors in other style
properties (e.g., mask, clip-path, or even fill or stroke) are treated --
the style isn't applied, by the graphic is still rendered.

However, there would still be an inconsistency between the `filter:none`
error handling on SVG filters, versus error handling for syntax errors in
the filter declaration, which cause the declaration to be ignored and
fallback filters to be applied.  It also means that you can't declare
fallback filter options for errors in SVG filters.

If there are no practical obstacles, therefore,* I think the ideal solution
would be to respond to *any* error in a filter sequence by invalidating the
entire filter declaration and falling back through the CSS cascade*.  There
are two main benefits:

   - All errors would be treated the same, regardless of whether the error
   is in the SVG code, the URL reference, or the CSS syntax.

   - Authors could use the standard CSS approach to progressive
   enhancement, by including a series of filter declarations on the same
   element, each designed to return acceptable results, in order from least to
   most preferred.

This is a question for implementers: how complicated would it be to respond
to an error in a SVG filter code (or URL reference) by making the
corresponding CSS declaration invalid, and therefore falling back to
filters specified earlier in the cascade?

Based on the quick fiddle I put together [2], it looks like that already
happens in at least some cases.  Can it be made consistent?

If there are performance reasons to not want to fallback, then the next
best approach, from my perspective, is to remove all filters.

Amelia BR

[1]: http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0066.html
[2]: http://fiddle.jshell.net/ev10jtmp/1/