"Robert O'Callahan" <robert@ocallahan.org> wrote: > > Hacking calc() to allow mixing of flex and specified widths seems > problematic to me because of the time-of-evaluation issue. We could just specify that at em-unit-calculation-time, calc() reassociates as necessary to put its argument in a canonical form of <fixed> +/- <flex>, and then the <flex> gets processed at layout time. Alternatively, borrowing even more from TeX: glue(size) glue(size, plus) glue(size, plus, minus) where each of the three arguments can be a calc-expression, but flex units and non-flex units may not be combined within a single expression. I'm not fond of the box-flex idea because it's not obvious which dimension, or even which *axis*, it applies to. Keep it around for XUL back compat, sure, but not the recommended way forward. As a side issue, what's the rationale for restricting flex units to some subset of the box dimension properties? I would think it would be useful in any length property. zwReceived on Monday, 13 April 2009 02:06:00 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:36 UTC