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

On Tue, Jul 27, 2010 at 2:21 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Jul 27, 2010, at 9:49 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>> 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'm trying to be precise about what opacity a pixel should be at a given distance. So if it is <2% outside that distance, >=2% inside that distance, gets consecutively more opaque towards the shadow center, until it gets to <=98% at the other end (or until it gets to the shadow center, whichever comes first), with any pixels >=98% on the other side of that distance, then I think I've defined the blur distance pretty well, while still allowing a UA to make tradeoffs of beauty vs. performance within the blur. After all, the author only gave a distance, not a blend beauty indication. Thus, Firefox can continue to have much mote visible banding than Safari, if they feel that's needed.
>
> I'm not opposed to Skia or Opera-mobile-super-light or whatever having less beautiful blurs, as long as they are conferment on blur width in a measurable way.

I'm opposed to Skia doing so, now that I know that there weren't any
particular performance considerations behind its ugly blurs.

Specs can always be violated for reasons of hardware limitations.
HTML5 makes this explicit, but this should be implicitly assumed for
everything.  We should define things that are reasonable for current
implementations such that they shouldn't have to violate the spec for
performance, but limited devices will exist along a large spectrum
that we can't predict or reasonably design towards.


>> 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.
>
> Everyone, or just the major desktop browsers that have implemented box shadow so far? Might not a future UA want to have a much less processor-intensive blur?

Sure, they might.  But there doesn't appear to be any good reason to
let them do so in a way that produces an ugly blur.  If they find a
cheap way to approximate a gaussian, good on them.

>> So I
>> suggest we just require approximating a gaussian, with approximately
>> the language I'd suggested.
>
> "approximating" seems less precise than saying exactly how wide the blur should be, with the endpoints of that measurement defined.

That's an illusion.  The width of the blur is defined precisely but
implicitly by the gaussian, and the requirement that the shadow be
within a percentage of that gaussian.  (Like I said, though, I
definitely want an explicit statement about the blur length in the
property description - it's just not needed as part of conformance
criteria, because it's already covered.)


>> 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.
>
> I'd rather see it turned the other way around, to allow better testability and to allow performance tradeoffs (such as those already being made, apparently).

As I said above, specifying the bounds with which an impl must
approximate a gaussian actually provides much better testability.
Specifying just the point at which it must hit 2% or whatnot allows
things like a linear gradient being used as a shadow, which we'd like
to avoid.

~TJ

Received on Tuesday, 27 July 2010 21:57:53 UTC