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

Tab, can you reply with a link or the text of the simplest example you can craft that shows what you consider a valid rendering in non-Chrome and an invalid rendering in Chrome?

I'd like to take a look at it to see what in-browser testability I can squeeze out of it.


-----Original Message-----
From: Tab Atkins Jr. [] 
Sent: Tuesday, July 27, 2010 9:50 AM
To: Brad Kemper
Cc: Sylvain Galineau; Dennis Amrouche; Brian Manthos; Aryeh Gregor; L. David Baron; Simon Fraser; Brendan Kenny; www-style list
Subject: Re: [css3-background] Where we are with Blur value discussion

On Tue, Jul 27, 2010 at 8:50 AM, Brad Kemper <> wrote:
> On Jul 27, 2010, at 7:50 AM, Tab Atkins Jr. wrote:
>> I've suggested precisely what I think the criteria should be already.
>> The shadow must approximate a gaussian blur with a stdev equal to half
>> the length, with each pixel being within 5% (of the whole color space,
>> so about 12 "color units" to each side) of the color that a true
>> gaussian would be.
> I prefer it in language that gave the guassian blur you mention as the example, but with more precise language (similar to how we currently word it) about which part of the resultant blur will match the authored value. Something like this:
> The exact algorithm is not defined; however for a long, straight shadow edge, this should create a color transition of twice the length of the blur distance that is perpendicular to and centered on the shadow's edge, and that ranges from the full shadow color at the radius endpoint inside the shadow to fully transparent at the endpoint outside it. Within the blur transition area, as defined by the authored blur value, no pixel should be less than 2% opacity or more than 98% opacity. Such pixels would fall outside the distance specified by the author, as they would be when using a guassian blur with a stdev equal to half the authored length.
> Or something like that.

That's much less precise language, though.  It would almost certainly
make Chrome's Skia blurs conformant (once we tweaked how we interpret
the blur length appropriately), which I thought we definitely didn't
want, on account of how ugly they are.

I supported that sort of language before, when I thought that everyone
did something different.  As it turns out, though, everyone closely
approximates a gaussian except Chrome when it's using Skia.  So I
suggest we just require approximating a gaussian, with approximately
the language I'd suggested.

We can fluff it out with additional language stating precisely what
the blur length means given the conformance criteria (similar to what
you have above), so that authors can decipher what it means without
reverse-engineering a gaussian, but I'm against that being the actual
conformance criteria itself.


Received on Tuesday, 27 July 2010 17:42:05 UTC