- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Tue, 27 Jul 2010 14:21:09 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, Dennis Amrouche <dennis@screenlabor.de>, Brian Manthos <brianman@microsoft.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, SimonFraser <smfr@me.com>, Brendan Kenny <bckenny@gmail.com>, www-style list <www-style@w3.org>
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 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? > 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. > > 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).
Received on Tuesday, 27 July 2010 21:22:24 UTC