- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Thu, 13 Nov 2014 10:08:10 -0700
- To: www-svg <www-svg@w3.org>, public-fx@w3.org
- Message-ID: <CAFDDJ7xbpg7MBRV-Ub5T0wq7M5QWoRgPaX6YvSNtmfoEJ7Q_hw@mail.gmail.com>
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: 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 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!
Received on Thursday, 13 November 2014 17:08:39 UTC