On Apr 28, 2011, at 12:28 AM, Erik Dahlstrom wrote: > On Wed, 27 Apr 2011 06:05:13 +0200, Vincent Hardy <vhardy@adobe.com> wrote: > >> >> 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. >> >> Vincent. > > That's true, but in practice I think that most files with > 'enable-background' has had that attribute set only on the root svg > element. Yes. Are you suggesting to then default to having BackgroundImage be the root svg canvas's current, accumulated rendering? > That accounts for most of the Illustrator files I've seen anyway. > Btw does Illustrator always add 'enable-background' there, even when it's > not used by any filters? I'll have to check on that. Thanks, Vincent.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