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

Regarding rendering filtered objects,

I totally agree with Amelia, that for authors it will be a hell of a lot  
of work to figure out where things go wrong if nothing is rendered. Would  
it be feasible to instead display some type of error message or colour  
coded image instead? Like often happens when image references are faulty  
(image replaced by red cross). If this case the four types of errors could  
get their own colour code to indicate where the shit hits the fan. It  
should be fairly straightforward to insert two scaled lines with a red  
cross and a coloured box by the render engine when it gets an error in the  
chain. So authors can figure out whether if crapped up in the CSS, faulty  
URL, inaccessable resource, etc.

The graphic the filter applies to however should always be rendered, just  
discarding the filter. Having nothing display makes figuring out where to  
look for the problem a tad problematic. If I read it correctly, nothing  
gets rendered, not even the object that the filter applies to? That sounds  
a bit harsh to me. What if filters are not supported (yet)?

Jelle Mulder


On Fri, 14 Nov 2014 01:08:10 +0800, Amelia Bellamy-Royds  
<amelia.bellamy.royds@gmail.com> wrote:

> Regarding the following resolutions from the SVG WG telcon this morning:
>
>>   RESOLUTION: If feImage refers to a missing resource, it should
>>   produce transparent black such that it fills the filter
>>   primitive subregion
>>   krit: and note that authoring tools may differ by indicating
>>   that the resource is missing
>
>>
>>   RESOLUTION: If there are broken references within the filter
>>   chain, the filtered element must not be rendered
>[http://lists.w3.org/Archives/Public/www-svg/2014Nov/0034.html]
> I sent a note on filter error handling to the FX list when I saw this on  
> the agenda yesterday, but I don't think it got through before the  
> >meeting. 
> [http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0066.html]
>
> In summary, if the above resolutions are adopted, there will be four  
> different error situations for filters:
> 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.
>
> 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.
>
> 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).
>
> 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 put together a quick test of current implementations, and found a  
> number of inconsistencies.  Follow along with  
> http://fiddle.jshell.net/>ev10jtmp/1/
> There are three rows of circles:the first row have filters with errors,  
> applied via CSS;
> the second row have the same filters (with errors) applied via CSS, but  
> also have fallback (valid) filters defined as presentation >attributes;
>
> the third row has the error-prone filter declarations as presentation  
> attributes.
> 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, all the browsers ignore the filter declaration for >filters  
> declared in CSS, but FF and IE treat it as a filter error (and don't  
> render the graphic) if it is declared via presentation >attribute.
> The third column in the fiddle is a straight syntax error, all browsers  
> tested ignore the declaration and render the graphic.
>
> The fourth column contains a URL reference to a valid filter element  
> that contains an error in a primitive, all three browsers >ignore the  
> filter declaration if it is applied in CSS (i.e., they fall back to a  
> filter higher in the cascade), but cause the graphic to >disappear if  
> the filter is declared as a presentation attribute.
> Given these inconsistencies, I strongly argue against a "pave the  
> cowpath" argument that we should declare that the proper error >handling  
> result is to not render the filtered graphic.  That does not provide  
> helpful feedback to authors, it does not support progressive  
> >enhancement, and it is not consistent with current implementations when  
> filters are declared via CSS.
>
> Amelia BR
>
> P.S.  If this gets carried over into next week's telcon agenda, and if  
> the telcon does get switched to the later time, I'd be happy to call in  
> >and help hash out a solution.  But I wasn't quite passionate enough to  
> drag myself out of bed early this morning to talk about it!