Re: [filter-effects] url() as pass-through on invalid reference?

One related case is that even a valid filter with a url() could be pending
a network load. If we do a "best effort" render (render the valid parts of
the chain), then a mix of shorthand filters mixed with a url() filter, e.g.

filter: blur(4px) url(foo.svg#bar) contrast(0.5);

will render progressively. I.e., it'll render the blur and contrast, and
then re-render once the network fetch is done. This is likely how it works
in Chrome/Safari, but I'm not sure it's the best behaviour.

Stephen

On Sun, Jul 14, 2013 at 10:20 AM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jul 12, 2013, at 2:31 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>
> > On 7/12/13 5:25 PM, Robert O'Callahan wrote:
> >> I feel pretty strongly that the SVG behavior is not appropriate. I think
> >> any sort of invalid 'filter' value, including a <filter> element with a
> >> child element of unknown type, should cause the filtered element to be
> >> rendered normally (i.e. 'filter' treated as 'none'). Otherwise I think
> >> introducing new <fe> SVG element types does not get useful fallback.
> >
> > OK, should that be raised as an issue on SVG, then?  I feel like we
> > should have consistency between the case when there is only one url() in
> > 'filter' and the case when there are multiple things including a url()…
>
> I forgot to paste the link to the Filter Effects specification that allows
> multiple declarations on url() [1]. Sorry for that.
>
> 1) SVG 1.1 was not clear about what happens if the specified URL is not
> referencing an existing <filter> element. Implementations treat this case
> as if 'none' was specified.
> 2) For SVG 1.1: if one of the primitives is in an error state (which used
> to happen quite often in earlier versions of the spec.) then nothing gets
> rendered at all.
>
> I agree with you Boris that we should not treat both cases differently.
> However, I am more in favor of just not applying the filter then stop
> rendering of the filtered element entirely (suggestion from roc).
>
> With Filter Effects we have a new situation since we allow multiple filter
> functions or url()s. The reason why it changes the way to look at the topic
> is the following:
>
> A) Treat errors as "filter: none" and refuse the whole filter chain
>
> might be described similarly with
>
> B) Treat failing filter function as pass-through and still apply the other
> filter functions.
>
> Both, A) and B) just make a difference on applying multiple filter
> functions if we agree on the behavior of 1).
>
> Greetings,
> Dirk
>
> [1] http://dev.w3.org/fxtf/filters/#FilterProperty
>
>
> CCed public-fx again.
>
> >
> > -Boris
> >
>
>
>