- From: François REMY <francois.remy.dev@outlook.com>
- Date: Thu, 3 Oct 2013 13:57:14 +0200
- 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