Re: drop-shadow filter vs. a separate property

On Jan 21, 2012, at 5:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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

One of the early ideas for having a drop shadow in filters was to be able to shadow the background, border, border-image, contents, etc. individually or unioned in different combinations. 

I should think it would be useful to have the choice to apply a color filter either before or after drawing the shadow. For instance, I might have a whole page that is sepia-toned, including the shadows, and then have some other color effect when I hover over them, with the shadows losing their sepia tint and not being affected by the filter (or being affected by some filters and not others). Would that work if the shadow was not a filter?

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

I don't speak for the whole CSSWG, but I am not entirely opposed to it being a property. I just don't really understand how that would improve performance. I had envisioned that some properties like that would just be syntactic sugar for what was still really a filter. Even text shadow would be sugar for a filter that filtered just content (not the box it is in, and somehow limited to only textual content), and then knocked out the original content shapes.

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