W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2014

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

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


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.

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

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:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:52 UTC