- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 11 Nov 2013 08:22:15 -0800
- To: Lea Verou <lea@verou.me>
- Cc: Andrew Fedoniouk <news@terrainformatica.com>, www-style list <www-style@w3.org>
On Mon, 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. > > 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, 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. Agreed. The current behavior is a mistake (I hadn't yet written http://wiki.csswg.org/spec/limited-ranges which warns against doing this), but I don't think it's one we can change now. ~TJ
Received on Monday, 11 November 2013 16:23:02 UTC