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

On 2014/11/14 2:08, Amelia Bellamy-Royds wrote:
> ...
> In summary, if the above resolutions are adopted, there will be four
> different error situations for filters:
>
>  1. If there is a syntax error or unsupported value in a CSS shorthand
>     filter function, the filter property declaration will be invalid,
>     and any filter specified earlier in the CSS cascade will apply.
>     This behaviour is defined by CSS error handling rules and can't be
>     changed.
>
>  2. If a URL reference in a filter property points to an inaccessible
>     resource, or a resource that isn't a <filter> element, then the
>     graphic will be rendered as if it had `filter: none` (In particular,
>     it *won't* fallback to previous filter declarations).  This
>     behaviour is defined in the new Filter Effects spec.
>
>  3. If an SVG filter points to an inaccessible resource via an <feImage>
>     primitive, work around it as best as possible (new resolution,
>     sounds good to me).
>
>  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'

Best regards,

Brian

Received on Friday, 14 November 2014 00:35:17 UTC