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
