W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css3-background] box-shadow spread rounding (was: [css3] box-shadow specification bug)

From: Peter Linss <plinss@csswg.org>
Date: Tue, 26 Nov 2013 01:32:11 +0000
Cc: Andrew Fedoniouk <news@terrainformatica.com>, www-style list <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>, "L. David Baron" <dbaron@dbaron.org>
Message-Id: <DC543A48-DB12-4C9E-9266-58594DB15AB1@csswg.org> (sfid-20131126_013219_465538_0F502310)
To: Lea Verou <lea@verou.me>
Accepting that I may have totally over-engineered this (I blame my German heritage), I was wanting a bit more control over the shape of the ratio function, so I added a cubic bezier function to the mix.

Mathematically it behaves just like the cubic-bezier() function from the transition-timing-function[1] except that I also clamped the y values to [0, 1]. I don't expect authors to be able to specify the control points, but it lets us define the behavior in terms of a specified cubic-bezier, and play with the control points to figure out what they should be (I set what looked like a reasonable default). The end result of the default curve isn't too much different from the current cubic function, but I think it behaves a bit better at small ratios (I'll let others decide if the difference is worth the extra math, but any implementation that includes transitions should already have the code to compute this.)

While I was at it, I also added a visual plot of the ratio function over [0, 1] so you can see what's going on more easily.

Peter

[1] http://drafts.csswg.org/css-transitions/#transition-timing-function

On Nov 15, 2013, at 10:18 AM, Lea Verou <lea@verou.me> wrote:

> 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, 6 December 2013 12:34:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC