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

On Jun 19, 2010, at 9:45 AM, Brad Kemper wrote:

> On Jun 18, 2010, at 5:16 PM, Simon Fraser wrote:
> 
>> On Jun 14, 2010, at 6:00 PM, Robert O'Callahan wrote:
>> 
>>> On Tue, Jun 15, 2010 at 12:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> I have no opinion on the name, but the most intuitive thing for me is
>>> for the specified length to be the amount that the blur extends out of
>>> the native shadow box.
> 
> When an author just wants to extend the shadow, that is what _spread_ is for, so it makes sense for spread to be specified that way. But when an author provides a measure for blur, it is because he wants a certain amount of blurriness.  It does not make sense to me that the number he picks should only measure the part of the blur that extends outside the original box, and not the whole blur.
> 
>>> That's what we currently do, but not what the spec currently says. Currently the spec says the blur will extend out of the normal shadow box by half of the specified length.
>> 
>> We've investigated WebKit shadow blur radius.
> 
> It's not really a radius.

It is in the implementation.

>> The behavior of the underlying graphics library (Core Graphics) is, amusingly, codified in the HTML5 canvas spec:
> 
> Not all that surprising, as Canvas was initially an Apple technology.
> 
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn>
> 
> Interesting recipe. I guess no one will be accused of hand waving there. It is so completely divorced of any kind of description of the intended result, that a person cannot really argue with it without an understanding of the math of what, precisely, standard deviations do to Guassian blurs.
> 
> But hey, it's a WD; it can be changed. At least it doesn't pretend that the length is a radius of something, or use the word "radius" as though it was interchangeable with the word "amount". It refers instead to a "blur level".
> 
>> but we think it's actually an implementation bug that we treat radii > 8px differently. 
> 
> I don't really understand the reasoning behind the "> 8px" thing, and the canvas spec gives no hint. Is there something special about 8px?

This only reason for this 8px discontinuity is that above 8px, the implementation falls back to a cheaper, multi-pass box blur. This is a bug, and it's unfortunate that it's in the canvas spec, but we should not copy this for CSS.

> 
>> Here's our intended rendering of a 100px x 100px box with "box-shadow: black 0 0 100px".
>> <http://smfr.org/misc/shadow.png>
>> Here, the effect of the shadow projects out from the element by the specified radius.
> 
> Interesting that you picked an example with no offsets, so that only the outer half the blur is visible.

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.

> 
>> However, the spec currently states that the color transitions is the length of the blur distance, and that the color transition is centered on the shadow edge. This gives a color transition that is half the length of what WebKit's intended behavior is,
> 
> Right. Webkit's and Gecko's behavior is that the transition is only half the width of the distance authored in the declaration.
> 
>> and, for shadows with no offset or spread, means that the shadow will only project out by half of the blur radius.
> 
> Regardless of the interpretation of the authored blur amount, the shadow projects out by half of the width actually blurred (absent of any spread, that is). 
> 
> If the property was called "box-glow" instead of "box-shadow", and XY offsets were only a small, less important part of the use cases, then I could understand why the amount it projects out would be a more important distance than the amount that actually ends up blurry. But it's not.
> 
>> So I would adjust the spec wording accordingly:
> 
> 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), I don't see any reason to choose a different behavior for the spec.

Simon