- From: Lea Verou <lea@verou.me>
- Date: Sat, 16 Nov 2013 02:18:44 +0800
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: www-style list <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>, plinss@csswg.org, "L. David Baron" <dbaron@dbaron.org>
- Message-Id: <029D7B89-6404-4E3B-951C-FC2FFA9556C8@verou.me>
Sooo, after some discussion at TPAC after the recent F2F, some of us (fantasai, dbaron, plinss, me) decided that even though the edge cases about precision aren't that big of a problem, the currently defined behaviour results in abruptness when border-radius interpolates from 0 to any positive value. Therefore, we think the spread rounding should be changed to be defined as: spread rounding = border-radius + spread * ratio(x) where x = border-radius / spread and ratio() is a continuous strictly increasing function that is 0 when border-radius is 0 and becomes 1 after a certain point. Therefore, it would still be 0 at 0 and mostly the same for small differences between the border-radius and the spread size, but would progressively increase when the border-radius is considerably smaller than the spread size. We tried many functions for what ratio() could be [1], and I made a demo of the three best ones that you can find here [2]. We think Cubic works best, which is 1 + (x-1)^3 in [0,1] and 1 when x > 1. Not only this makes interpolation smoother, but it also is more aesthetically pleasing, which reduces the need for manual ”filleting” (as demonstrated in [3]). We’d appreciate some feedback about the ratio() function. Perhaps someone can think of a better one? My demo supports entering a custom one (in JS syntax) so you can experiment there. The requirements are: - It needs to go through (0,0) and (1,1) - Its derivative at (1,1) should be 0 - It needs to be fast to compute and easy for humans to understand [1]: http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiIyKmF0YW4oeCkvcGkiLCJjb2xvciI6IiMwMDk5RkYifSx7InR5cGUiOjAsImVxIjoiMS0xLyg4eCsxKSIsImNvbG9yIjoiI0ZGMDA2RiJ9LHsidHlwZSI6MCwiZXEiOiJzcXJ0KDEtKHgtMSleMikiLCJjb2xvciI6IiMyNkQ0NEYifSx7InR5cGUiOjAsImVxIjoiMSsoeC0xKV4zIiwiY29sb3IiOiIjOUU5OTBDIn0seyJ0eXBlIjowLCJlcSI6Iih4PDEpKngrKHg.PTEpKjEiLCJjb2xvciI6IiMwMDAwMDAifSx7InR5cGUiOjAsImVxIjoiKHg8MSkqKDEtKHgtMSleMikrKHg.PTEpKjEiLCJjb2xvciI6IiNGMjhBOEEifSx7InR5cGUiOjEwMDAsIndpbmRvdyI6WyIwIiwiMS41IiwiMCIsIjEuNSJdfV0- [2]: http://dev.w3.org/csswg/css-backgrounds/spread-radius [3]: http://radesign.in/in-search-of-the-perfect-radius/ ~Lea On Apr 5, 2013, at 11:58, Andrew Fedoniouk <news@terrainformatica.com> wrote: > > Please check this sample in Google Chrome and Firefox: > http://terrainformatica.com/w3/box-shadow-outer.htm > > Note top corners in first and second div's. > > FF renders this according to the spec and so it demonstrates bug in the specification. > > In these two divs top/right border radius has these values: > 0.001px and 0.1px > > The rendering is dependent to particular UA rounding rules. > So R=0.001px is considered as zero radius in FF > and 0.1px is not. > > So together with the requirement "For corners with a zero border-radius, > however, the corner must remain sharp" the spec also shall have a notion > of zero border-radius and/or calculation precision and how exactly > to measure sharpness. > > 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. > > Please consider removing "For corners with a zero border-radius, > however, the corner must remain sharp" statement from the spec. > > Spec reference: http://www.w3.org/TR/css3-background/#the-box-shadow > > -- > Andrew Fedoniouk. > > http://terrainformatica.com
Received on Friday, 15 November 2013 18:19:13 UTC