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

On Jun 13, 2010, at 5:26 PM, Robert O'Callahan wrote:

> In Firefox, a blur with radius 'Npx' increases the size of the blurred object's (in terms of pixels affected) by exactly N CSS pixels in each direction ... if you ignore the effects of rounding. In practice, for large values of N, rounding causes pixels near the edge of the shadow to not change. I think this is a good way to interpret the radius and the word 'radius' is a reasonable term for this value.

I think it illustrates the problem with using the word 'radius', because it means something different to you than it does to Simon & Hyatt:

1. To you it means that (forgive my interpreting, here), like a radius can be doubled to get a diameter (of, say, a blurring brush), that the blur radius can be doubled to get the width of the blurring effect.

2. To Simon, it means "the radius of the gaussian blur that is applied to a masked representation of the element", or as David Hyatt describes, is merely a parameter passed into CoreGraphics. It is an input, not necessary a measure of the result. This is similar, in theory, to PhotoShop's Guassian Blur filter, where a 10px radius  on a black-white high-contrast edge produces a not-intuitive-to-user blur width of 54px (or if you trim off the <1% and >99% pixels at the periphery, then about 42px).

So, from my point of view, an author should not have to specify a 4.5px blur in order to get a blur that is 9px wide. It is not intuitive (especially when we are used to integer values for things that end up as pixel widths), and such math is easy for the UA to do. It is not terribly burdensome for the author to do that doubling, except when learning what the value means, but would be much nicer to just be able to specify a value of 9px to get a blur that covers 9px from solid to transparent.

Think of it this way: If, in some alternate universe, 'border' was a stroke that was centered on the edge of the element (like PostScript path stroking) instead of being drawn completely outside the padding box, would that be specified in half-border widths and be called 'border-radius'? I think not (completely aside from that name already being taken by something where "radius" has more obvious meaning). Yet that is the apparent logic of "blur radius" in Gecko. I will say that at least Gecko is more predictable than Webkit.

The other thing I am thinking is that implementors should change this _now_. The two major UA engines that include implementations of 'box-shadow' do so inconsistently, forcing authors who want consistency at large values to use different values for different prefixed properties. That option won't be available once prefixes are dropped, and at least one implementation will need to change anyway to be consistent. This can be changed for the non-prefixed version (first in the nightlies/betas, as Webkit did for some of the other background & borders properties) to be something that is both consistent and more intuitive for authors, and authors can still include prefixed versions for legacy versions.

Received on Monday, 14 June 2010 17:11:45 UTC