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

I feel that there should be two different behaviours for each of the error
cases:

(1) a syntax error in the filter definition such as invalid input reference
or number out of range.
(2) a missing/unavailable external resource (but not a missing *internal*
resource)

#2 should be a special case because it is often not under the control of
the developer.

In the case of #1, it would be most appropriate to assist debugging by
processing up to the filter primitive that is in error.

Case #2 should allow graceful fallback, so I kind of like Amelia's
suggestion.

Paul


On 14 November 2014 14:35, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> [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/
>