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

On Jun 21, 2010, at 8:04 AM, Simon Fraser wrote:
>>> 
>>> We've investigated WebKit shadow blur radius.
>> 
>> It's not really a radius.
> 
> It is in the implementation. 

Of what circle? With 'border-radius', there is a quarter circle it creates at a corner, so it makes sense to use a radius for that measurement and call it that. It is not at all obvious what curve a 'blur radius' refers to. Calling it that only seems to benefit the few who understand it to mean something in particular (not necessarily the same meaning as someone else who understands it to mean something in particular), while muddling the understanding for everyone else.

You spoke of radii > 8px, but the canvas page you linked to shows that the number is used in both cases as a "standard deviation" input to a Gaussian blur, after doing certain math on whatever was authored (authored/2, or √(authored * 2)). I don't see anything about a radius or circle or ellipse.


> I didn't realize that your screenshots used a large offset to move the shadow from under the element. It would have been helpful to show the CSS, and have the test put a reference box over the shadow.

I was mainly trying to see how many pixels were actually blurred, as this is the important result of specifying a blur value. To do that, I needed an offset large enough that the border box would not knock out of it.

I've since posted the CSS, but perhaps this version will also help:

http://www.bradclicks.com/cssplay/shadow-blur.html

>> Or you could divide by 2 as the first step prior to sending it to Core Graphics. Is that really so burdensome? Does this create a problem with odd numbers of pixels of something? Does the total blur width have to be an even number? I would imagine that if you sent a blur of, say, "10.5px" to the Gaussian function, that it would either round off, or the resulting blur width would be 1px wider on one side of the original path than the other. But either way, the effect of authoring an odd number the way the spec if worded now, or authoring in half px the way you have it, both would have the same sort of result.
>> 
> 
> Since both WebKit and Firefox have a non-offset shadow project out by the blur length in their current implementations (barring bugs),

But they _don't_ match in practice, whatever the reason, so something has to change anyway. And even if the old webkit version had a bug, it will probably need to stay consistent in the prefixed version that has been around for so long, as authors may already be giving webkit a different measurement than gecko.

> I don't see any reason to choose a different behavior for the spec.

The reason to change both to the different behavior for the spec, is to make it something more sensible and less surprising to authors, who should not be expected to understand the mechanics of Gaussian blurs, but who (by including a distance there) are indicating they want a specific amount of blurriness. That blurriness has a width, and the amount that width sticks outside the original (unblurred) edge is not as relevant as the width itself. 

And the change is a very simple one: you only have to initially divide by two as one little extra bit of math added to the bits of math you are doing anyway. And now is the best time to do it, when switching from a prefixed version that needs to stay the same, to a non-prefixed version that will act in one particular, consistent way for years to come.