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

On Tue, Jul 13, 2010 at 7:49 PM, Tab Atkins Jr. <> wrote:
> Explaining it in terms of existing graphics libraries may help
> implementors, but it does nothing for authors, who have no idea how
> the graphics libraries work or what the relationship is between a
> radius parameter and "how big my shadow will be".

So what?  They can try it and see.  What the spec needs to do is
define something that implementations can implement without ambiguity,
pixel-perfect or indistinguishable from it.  There is no reason to
settle here for less than a pixel-perfect description.  Opera and
Chrome render the following document identically:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
<svg xmlns=""><defs>
<filter id="Gaussian_Blur"><feGaussianBlur in="SourceGraphic"
<rect x="100" y="100" width="100" height="100"

(Firefox doesn't seem to support feGaussianBlur.)  The following
should render exactly the same as the SVG in all browsers, because
HTML5 specifies an exact algorithm also based on Gaussian blurs:

data:text/html,<!doctype html>
<style>* { margin: 0 }</style>
<canvas height="300" width="300"></canvas>
window.addEventListener('load', function () {
context = document.getElementsByTagName("canvas")[0].getContext("2d");
context.shadowBlur = 12.5;
context.shadowOffsetX = 400;
context.shadowOffsetY = 400;
context.shadowColor = 'black';
context.fillRect(-300, -300, 100, 100);
}, false);

Opera displays it correctly, pixel-for-pixel.  Chrome and Firefox both
seem to have buggy canvas shadow implementations, but that's clearly a
bug in both of them, and I assume it will be fixed.

Anyway, the point is, IMO it's a *must* to have pixel-perfect
definitions here.  SVG and canvas already do.  If you want a length
value here (which is reasonable but unfortunately doesn't match canvas
or SVG), say that the standard deviation should be chosen so that the
given length falls at the point where the shadow is exactly 95%
transparent, or something.  But we need something precise.

Received on Wednesday, 14 July 2010 21:17:15 UTC