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

Re: [css-shapes] circle radius as a percentage

From: François REMY <francois.remy.dev@outlook.com>
Date: Thu, 3 Oct 2013 13:57:14 +0200
Message-ID: <DUB120-DS20A30AD6840DCD73B2C1B7A5170@phx.gbl>
To: "Dirk Schulze" <dschulze@adobe.com>
Cc: "Alan Stearns" <stearns@adobe.com>, <www-style@w3.org>
> > According to my reading, the radius defines both an height and a width, 
> > since it replaces radius-x (a width) and radius-y (an height), and 
> > therefore falls in both the first (use viewport's width) and the second 
> > (use viewport's height) categories, hence the indetermination.
> >
> > Anyway, the SQRT-behavior is not what the current Chrome Canary 
> > implementation does. My initial tests seemed to show it always used the 
> > width, but in fact it seems it uses the minimum value between the width 
> > and the height.
> >
>
> It does for clip-path (basic shapes are not only used for layout):
>
>     float diagonal = sqrtf((boundingBox.width() * boundingBox.width() + 
> boundingBox.height() * boundingBox.height()) / 2);
>
> If you see problems in Chromium please open bug reports.

Ok, the bug is now solved into Webkit Nightly and I guess Chromium Nightly 
even if I didn't try there.


However, I believe we now have an issue because we cannot define certain 
classes of useful circles now. There's no formula to define the "cover" or 
the "contain" circle shapes of a box if you don't know its aspect ratio. I 
therefore propose to add a keyword to the circle function to allow this to 
work:

    circle([ <length> | <precentage> [ auto | width | height | cover | 
contain ]? ])

where cover and contain actually represent max/min between width and height.


BTW if shapes are evaluated differently in two different properties in 
Webkit/Blink, this is probably the sign a refactoring would be good in this 
case (kinda a ShapeHelper:absolutize(shape, referenceBox) function). 
Received on Thursday, 3 October 2013 11:57:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:02 UTC