Re: [css3-background] vastly different takes on "blur"

On Jun 11, 2010, at 10:16 AM, Brad Kemper wrote:

> On Jun 10, 2010, at 12:15 PM, fantasai wrote:
> 
>> fantasai: I'd like to publish LC of backgrounds&borders.  If we don't
>>           have time ask now, would like scheduled this month.
>> howcome: Is box shadow in?
>> fantasai: yes
>> howcome: let's do it
>> fantasai: 3 weeks last call period
>> <ChrisL> which wgs are invited to review it?
>> RESOLUTION: LC of css3-background, 3 weeks review, ask SVGWG for comments
> 
> I have a concern that came up after we passed this at the end of the call this week. I found that Firefox and Webkit are interpreting the blur value in vastly different ways, neither of which seem to be following the spec. Check out these screen shots of the same shadow with 100px of blur:
> 
> http://www.bradclicks.com/cssplay/blur_100px_webkit.png
> 
> http://www.bradclicks.com/cssplay/blur_100px_firefox.png

We're looking at the WebKit implementation. It doesn't blur as much as we'd expect, even though we're feeding the correct values to our underlying graphics library.

> Firefox blurs much more than Safari. Last Call is fine, but I really do not want to see this go to CR with prefixes dropped, unless it is with more standardized behavior. Can we get some assurances from implementors that they will be changing to more closely match the description in the spec about where the blur begins and ends? Or if they are interpreting the spec differently or something?
> 
> Also, can we remove the word "radius" from any sentence that is about blur or spread? I find it confusing and misleading, as it is not at all clear what circle or ellipse it is a radius of. AFAICT, it is no more a radius than are border, padding, margin, outline, outline-offset, etc. properties.

The radius refers to the radius of the gaussian blur that is applied to a masked representation of the element, in order to render the shadow. As I've mentioned before, I think shadows are better specified in terms of the steps required to render them, rather than hand-waving descriptions of what things look like. Maybe it could even reference a set of SVG filters that would achieve the same effect? (Aside: can shadows with 'spread' be implemented via SVG filters?)

If we were to ever have shadows applied to shapes with concave outlines (e.g. if we allow shadows to apply to SVG elements), then I think it will matter how the shadow blur is defined. I don't think the current definition, which describes the blur in terms of a gradient, is good for shapes with concave portions.

Something else we need to specify somewhere is whether shadows are drawn before or after transforms.

Simon

Received on Friday, 11 June 2010 18:14:00 UTC