W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

Re: Updated filters specification

From: Vincent Hardy <vhardy@adobe.com>
Date: Tue, 26 Apr 2011 21:05:13 -0700
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: Erik Dahlstrom <ed@opera.com>, Rik Cabanier <cabanier@gmail.com>, Dean Jackson <dino@apple.com>, Dirk Schulze <vbs85@gmx.de>, "public-fx@w3.org" <public-fx@w3.org>, Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Message-ID: <7FD97A31-5639-4D42-B2B5-C887B5969441@adobe.com>

On Apr 26, 2011, at 8:55 PM, Robert O'Callahan wrote:

On Tue, Apr 26, 2011 at 7:20 PM, Erik Dahlstrom <ed@opera.com<mailto:ed@opera.com>> wrote:
Deprecating (or dropping) 'enable-background' would essentially mean that BackgroundImage and BackgroundAlpha would always generate a transparent black result in the context of filters (I presume this is what the browsers that don't support enable-background already do, and it follows the error handling that is defined for when there was no "enable-background:new" parent element). Typically that means that things still render without errors but probably not as intended by the author.

Why can't we define BackgroundImage and BackgroundAlpha in a way that continues to work in the absence of enable-background? I think we can, even with GPU-accelerated rendering. In the worst case you can detect use of BackgroundImage/BackgroundAlpha and automatically infer the equivalent of enable-background for the ancestor elements.

I think it would be difficult to get the exact equivalent of the current behavior because currently, enable-background can be on the element's parent, grand-parent, or any other ancestor.

Received on Thursday, 28 April 2011 19:30:23 UTC

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