W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: drop-shadow filter vs. a separate property

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>
Message-ID: <02DAA108-4999-4740-8804-EFFB7DA09B9B@adobe.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 January 2012 18:49:11 GMT