Re: [css3] box-shadow specification bug

On Nov 11, 2013, at 3:02 AM, Lea Verou <lea@verou.me> wrote:
> 
>> On Apr 5, 2013, at 11:58, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> Chrome renders this against the spec but mathematically correct,
>> distance there is distance - all points with similar color lie on the same
>> distance from the border, no matter what radius is used
>> and so this implementation is stable to rounding problems, floating 
>> point precision, etc.
> 
> Not sure what you mean that "Chrome renders this [бн] mathematically correct". Both browsers do what the spec says and have the same behavior, they just have different precision for border-radius. Gecko has a precision of 1/60th of a pixel, Chrome of 1px (values < 1px as treated as 0px). This would have been clearer if your testcase had a blur of 0.

Agreed. I could not tell the difference on my iPad (WebKit only). Maybe it has different precision. But since the blur rounds the corners anyway, I the more blur to spread there is, the more subtle the difference. 

> I don't think this is a serious enough problem to warrant changes at this point. There are precision issues everywhere. Eventually WebKit/Blink will also render subpixel lengths, so it will be even less noticeable. I agree that none/0 would be a useful distinction if border-radius were specced now,

I don't, though I agree with everything else you said. It is such an edge case that it doesn't warrant a separate value just for that. The only time it is noticeable is when there is a large spread and small or no blur, and when transitioning very slowly, or intentionally trying to hack a fake outline with rounded corners on the outside. 

> but it's too late and not that serious of an issue to warrant a change that would cause compatibility issues, regardless of how few or minor they might be.

Yeah, so it's academic at this point.

Received on Monday, 11 November 2013 19:04:47 UTC