- From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
- Date: Tue, 21 Sep 2010 20:25:41 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: <www-style@w3.org>
-------------------------------------------------- From: "Tab Atkins Jr." <jackalmage@gmail.com> Sent: Tuesday, September 21, 2010 11:11 AM To: "Andrew Fedoniouk" <news@terrainformatica.com> Cc: <www-style@w3.org> Subject: Re: [css3-box] providing an aspect-ratio for a box (Re: suggestion: fixed-aspect-ratio CSS rule for block elements) > On Mon, Sep 20, 2010 at 10:17 PM, Andrew Fedoniouk > <andrew.fedoniouk@live.com> wrote: >> Just in case, I am using the following construction: >> >> div >> { >> width:25%; >> height: width(30%); >> } >> >> So height will be 30% of computed value of the width. >> >> The 'width(percentage)' is a kind of function that describes base/source >> of >> percentage operation. >> >> There are logical problems (chicken-egg alike) with aspect-ratio or the >> like >> properties. >> >> E.g. it is not clear what to do with this: >> >> div >> { >> width:25%; >> height:25px; >> aspect-ratio:0.3; >> } >> >> and meaning of the following is not clear too: >> >> div >> { >> height:25%; >> aspect-ratio:0.3; >> } >> >> That is actually even prohibited configuration by the CSS nature: >> compute-widths-and-then-heights. >> >> So the aspect-ratio is a value of the height property and only the height >> and definitely not a separate property. > > No, aspect-ratio is not just a value of the height. For one thing, > when you have horizontal block progression, width becomes dependent on > height. For two, if you have an explicit height and an aspect ratio, > it's unambiguous what the width should be. > > Per the previous discussion on this topic, it would work like this: > > 1. If both width and height are not 'auto', then aspect-ratio has no > effect. > 2. If one of width and height are 'auto' and the other is not 'auto', > then the 'auto' one is computed by using the other dimension and the > aspect-ratio. > 3. If both width and height are 'auto', then whichever dimension is > calculated first is calculated normally (width, in normal block flow), > then aspect-ratio is used to calculate the other dimension. > > Likely, aspect-ratio would only be defined for normal flow. I suspect > that it wouldn't play nicely with tables. > I would insist that in vertical flows [block progression] the following { width:auto; height:25%; aspect-ratio:0.3; } is very "unreliable" combination. Try this in WebKit based UA: <html> <head> <title></title> <style> td { width:25%; border:1px solid; vertical-align:top;} span { display:inline-block; height:100%; border:1px solid red;} </style> </head> <body> <table> <tr> <td><span>h:100%</span> dum spiro spero dum spiro spero dum spiro spero dum spiro spero dum spiro spero</td> </tr> </table> </body> </html> WebKit is trying its best to make vertical percents at least somehow practical (such rendering is not standard of course but that's another story). Try to resize browser window and imagine that 'span' above will get some aspect-ratio defined and you will get perfectly divergent layout algorithm. There are too many other cases that may produce such results. In particular use of scripting for layout purposes may also produce funny results with aspect-ratio defined. And yet flow/flexes, at least in David's version, I suspect, will also conflict with standalone aspect-ratio property. If to think "systemically" then aspect-ratio as a separate property will really add one more dimension to the property/feature compatibility matrix. This will make the whole system of box related properties even more complex and fragile than it is already. In contrary having "coloured" percents will not make the system more complex than it is now. In vertical block progression: div { height: width(50%); } In horizontal block progressions: div { width: height(50%); } width(X%)/height(X%) functions can be replaced by single aspect-ratio(X%) function but it will prevent such quite useful cases as: div { height: width(50%); margin: width(25%) 0; } and the like. -- Andrew Fedoniouk http://terrainformatica.com
Received on Wednesday, 22 September 2010 03:26:19 UTC