- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 27 Aug 2013 00:53:32 -0700
- To: Stephen White <senorblanco@chromium.org>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
On Jul 25, 2013, at 2:13 PM, Stephen White <senorblanco@chromium.org> wrote: > 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 behavior. Even if not pleasant, I think this is the better behavior. Imagine you have two SVG Filter references in a chain filter: url(#invalid) url(#valid); Given that #invalid does not reference an SVG Filter and #valid does, then the first reference would produce a 'null filter' which is the input of the second filter reference. This would proceed as normal but with a transparent black image a SourceGraphic. I think in this case you would prefer the unfiltered object as input of the second filter reference instead. Therefore, I suggest changing the current behavior and make invalid filter reference a pass trough instead of a null filter. Greetings, Dirk > > 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 > > > > >
Received on Tuesday, 27 August 2013 07:54:01 UTC