[css3-background] Where we are with Blur value discussion

On Jul 7, 2010, at 9:02 PM, Simon Fraser wrote:

> So let's wind up the shadow blur discussion. Brad, can you summarize the state of the discussion in a new thread?

OK. The current LC has tried to be more exact with the definition of blur value, so that it can be a measurable result, instead of something vague or recipe-like. It currently does this by defining the width of the total blur effect (which is centered on the shadow edge) to be equal to the the blur value authored. 

However, this does not match the two most prominent UA engines with shipping versions of box-shadow (Webkit and Gecko), which are still currently use prefixed property names for that (thankfully). They also do not match each other at blur values over about 8px (I think), due to a bug in Webkit. Without that bug, Webkit would presumably be creating box-shadow renderings more or less identical to Gecko, which is that the authored value ends up being approximately half of the total blur, and seems to be almost exactly equal to the outer half of the blur (in tests of an opaque black shadow, and a no-tolerance paint bucket tool applied to a captured rendering). 

OK, so far?

Differences which can never be seen, don't count: 
On large enough shadows, there seems to be a few pixels left over in the dark areas of the supposed "blur region" (that is, the region that is twice the authored value, in Gecko at least) in those tests, which are unblurred total black, but perhaps they are just less than 1% transparency or something. Some of us have expressed a desire to clip those values that fall outside a set range (such as 1% - 99% opacity), and have the remainder fill the measured space. This is a side issue to the bigger question of whether to measure total blur width or just outward blur width.

Text-shadow:
There is some question about whether or not Webkit's rendering is internally consistent with the way 'text-shadow' works. Supposedly it is, and exhibits the same bug. That is what I see, but Tab Atkins had evidence that text-shadow blur widths are more like the current spec. I haven't seen that or independently confirmed through screen shots, but it is possible, since he is on Linux and I am on Mac OS. This seems to be a fairly crucial point, because if it does closely follow the blur logic of the current box-shadow spec, it is good reason to change the implementations for box-shadow to also match (remember, those implementations are currently different from each other). A good time to make a change like that would be when dropping the prefix, so that we can still author to old versions too, and get matching shadows all around.

Ideally, we would want SVG and Canvas shadows to also match. They are currently closer to the "authored value = outer blur only" school than the "authored value = width of blur region" school. To me, these are less important than matching text-shadow, or the expectations of the bigger pool on non-SVG/Canvas CSS authors. I'm not sure if the Webkit bug exists for SVG and Canvas too or not.

SO... Pros and Cons:

Arguments in favor of the distance measuring the Entire blur region width (current spec language):

1) The entire perimeter is blurred, outer and inner, not just outer, so it is logical that the width of the entire blur effect width should match the authored value. 

2) At least one of the implementations has to change what they've been using for years anyway, in order to get cross-UA consistency, so we could change them both to something that is the least surprising to authors.

3) A blur width that is an odd number of pixels in total blur width should be possible (with one less pixel on the inside than the outside, say).

4) What SVG does to specify shadows in its attributes is less important to CSS than meeting the reasonable expectations of the more numerous non-SVG authors of CSS (assuming CSS properties like 'text-shadow' are also kept internally consistent in the meaning of the values). 

Arguments in favor of the distance measuring the Outward blur only:

1) It is more similar to what one UA (Gecko) is doing already, and what another (Webkit) meant to be doing, so changes from the way things already work would be minimal (once Webkit fixes their bug).

2) It is also similar to what SVG, canvas, and PhotoShop Gaussian Blurs do (and text-shadow?). 

3) It can be thought of as how far in either direction a semi-opaque edge between to opacities is smeared, and to some people this is more intuitive.

4) On elements that are smaller than their outward blur width, you would not see the full measure of twice that amount anyway.