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

Re: drop-shadow filter vs. a separate property

From: Chris Marrin <cmarrin@apple.com>
Date: Fri, 20 Jan 2012 10:57:32 -0800
Cc: Dean Jackson <dino@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-id: <00465C5F-0705-4218-98AE-525B15414E1C@apple.com>
To: Dirk Schulze <dschulze@adobe.com>

On Jan 20, 2012, at 10:48 AM, Dirk Schulze wrote:

> 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."

That's true (and sorry for missing your original post). There are really two reasons I bring this up. In starting to implement the hardware acceleration path, I encountered problems embedding drop-shadow into a hardware filter chain. It's much more complex than the others and so it added complications. These complications can certainly be solved with some amount of pain, which is fine. But that got me thinking about the sense of having drop-shadow in CSS Filters at all. Given that text-shadow and box-shadow were separate properties, it seemed that maybe drop-shadow should be, too.

So I think it makes sense from a spec standpoint to get rid of the drop-shadow filter and add it as a separate property. And it's a nice side effect that adding drop-shadow as a separate pass from the filters makes our implementation simpler.

Received on Friday, 20 January 2012 19:03:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC