- From: Dirk Schulze <dschulze@adobe.com>
- Date: Fri, 20 Jan 2012 10:48:34 -0800
- To: Chris Marrin <cmarrin@apple.com>
- CC: Dean Jackson <dino@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
First sorry for the double post. The first message was not delivered, or at least with a very big delay of two days :P. On Jan 20, 2012, at 10:44 AM, Chris Marrin wrote: > > On Jan 18, 2012, at 2:41 PM, Dirk Schulze wrote: > >> If we would not allow drop-shadow in the filter chain, developers will just surround the content with the filter by a new div and apply the filter there. The situation gets worst if drop-shadow would be in the middle of the filter chain. User would have to surround the filtered content with two div's and apply three different filters. I assume that it is better to deal with it in the implementation. Even eliminating drop-shadow would rarely make the situation better. > > You're saying that a developer would do that if they need a drop-shadow embedded between other filters, which is true. I'm saying that I don't think this would be a common case at all, if it ever made sense. And in the cases where a developer felt the need to do it, then a sandwich of elements would not be an unreasonable solution. > > And my bigger point is that it seems like drop-shadow is more akin to text-shadow and box-shadow than to filters. So why not treat it the same? I agree, see my previous posting: "I have nothing against adding a new CSS property. WebKit already has an experimental drop shadow property for SVG (-webkit-svg-shadow). But it is a different approach to add a new property to make it easier for web developers to access a feature or to add it because of performance concerns. The performance concern won't disappear with a new property." Dirk
Received on Friday, 20 January 2012 18:49:11 UTC