W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: suggestion: fixed-aspect-ratio CSS rule for block elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 6 May 2010 10:23:40 -0700
Message-ID: <s2jdd0fbad1005061023h32c102cbnbe708a01123cda12@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: julien.cayzac@gmail.com, www-style@w3.org
On Thu, May 6, 2010 at 6:50 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Le 05/05/10 17:45, Tab Atkins Jr. a écrit :
>> 3) We add aspect-ratio, but have it only interact with 'auto' values
>> for width/height.  So, in the previous example, the aspect-ratio would
>> have no effect, since both width and height are already specified.  If
>> you set height:auto instead, though, then aspect-ratio will be
>> consulted to resolve it.  Or you could set height and leave width as
>> auto, so aspect-ratio would also have an effect.  Finally, if both
>> were auto (the default), then whichever is resolved first (typically
>> width) would be resolved normally, then aspect-ratio would be used to
>> resolve the other dimension (typically height).
> I agree. 'aspect-ratio' could then take three different values:
>  none
>    no aspect ratio specified
>  <number>
>    the aspect ratio width/height; example: 'aspect-ratio: 1.5'
>  <integer>/<integer>
>    the aspect ratio width/height computed by the division of the two
>    integers; both integers must be positive, second integer cannot be
>    0

Heh, that's a clever use for the /.  I totally didn't consider it.  It
might be *too* clever, but maybe not?

> I hope nobody's suggesting keywords like 'vga' or '1080p', because
> that's a true pandora's box.

No, that's too silly.  Aspect ratios aren't difficult to figure out.

> And yes, we need to preserve the min/max contraints otherwise the algo
> to computed this will be hell.
> Just one comment: 'aspect-ratio' could take a second component value to
> say if the width or the height has precedence in the case both width
> and height are auto. Like 'aspect-ratio: 4/3 width'.

Is there any reason for this?  I'd think it would just use the normal
rules for resolving width/height.  Whichever one normally takes
precedence does so, and then aspect-ratio is consulted to constrain
the other one.  If we wanted to change which dimension was used as the
"primary" input for the sizing algo, we should do that separately
rather than shoving it into a nominally unrelated property.

Received on Thursday, 6 May 2010 17:24:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:34 UTC