Re: drop-shadow filter vs. a separate property

Hi Chris,

I agree that doing a drop shadow as a separate property makes sense.
I can't recall an example in Flash where a user needed to apply filters
after doing a shadow. There are cases where artwork with a drop
shadow comes into view with an alpha transition but in that case, the alpha
filter can be applied before the drop shadow.

However, my fear is that this will create some push back from the WG's
since it is yet another property that enters the CSS namespace.
Also, the drop shadow property will be very similar to text-shadow which
might lead to confusion...

Rik

On Fri, Jan 20, 2012 at 10:57 AM, Chris Marrin <cmarrin@apple.com> wrote:

>
> 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.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>
>