Re: Updated filters specification

On Tue, Apr 26, 2011 at 8:37 AM, Chris Lilley <chris@w3.org> wrote:

> On Tuesday, April 26, 2011, 4:10:25 AM, Robert wrote:
>
> ROC> On Tue, Apr 26, 2011 at 12:50 PM, Dean Jackson <dino@apple.com>
> wrote:
> ROC>
> ROC> What does this mean for existing content that uses
> ROC> 'enable-background'? I doubt there is much of it, but still,
> ROC> there are a couple of existing recommendations that define it.
> ROC> Typically things get deprecated before being removed.
> ROC>
>
> ROC> That content would only have worked in Opera or possibly some
> ROC> standalone SVG viewer
>
> Some standalone viewer, like the Adobe one, which one or two people may
> have used.
>
> The attribute also gets written fairly frequently by SVG exported from
> Adobe Illustrator (current and previous versions) which again, one or two
> people may use to generate content, possibly even putting that content on
> websites.
>

Yes, but that is in the context of blending, not filters. I didn't realize
that the same keyword was affecting both filters and compositing.
http://www.w3.org/TR/SVGCompositing/#enable-background-property

It makes a lot of sense to have the 'enable-background' keyword when you're
applying blend modes.
See this article for an example:
http://layersmagazine.com/the-joys-of-isolation-blending.html.
('enable-background' is called 'isolate blending' in Adobe's model.)

Filters should just apply a pixel transform on the SVG/HTML container and
produce a bitmap. This bitmap is then composited with the normal SVG/HTML
rules.

So, I think 'enable-background' should be removed from the CSS filters spec
but it should stay in the SVG compositing spec.
If we start working on a CSS blending document, we can decide if the keyword
makes sense in the HTML world.

Rik



>
> ROC> --- i.e., probably not public Web content.
>
> Your conclusion does not follow from your data.
>
> ROC> It's up to those vendors to decide whether and when to remove
> ROC> enable-background support, I don't think it matters much for the Web.
>
> I agree with Dean, this is a deprecation and needs to be signalled as such.
>
> To be clear, I am not against deprecating the feature. But pretending it
> never existed or treating it like some vendor-prefixed experiment that can
> be withdrawn at will is irresponsible.
>
>