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

Re: [flex-units] unit abbreviations and the flex()

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 28 May 2010 10:36:29 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <BCD13FCD-9A6D-4DAF-9A3D-E6D6DCF935B5@gmail.com>
To: Zack Weinberg <zweinberg@mozilla.com>

On May 28, 2010, at 10:23 AM, Zack Weinberg wrote:

> Brad Kemper <brad.kemper@gmail.com> wrote:
>> On May 28, 2010, at 9:41 AM, Zack Weinberg (by way of Zack Weinberg
>> <zweinberg@mozilla.com>) wrote:
>>> Well, I think your own example of using max() to set a minimum width
>>> and min() to set a maximum width is a nice demonstration of why this
>>> two-way stretch semantic is confusing even if you don't have a bunch
>>> of ingrained assumptions from TeX.  One-way stretch is just going to
>>> be easier to explain to people coming at this new.
>>> What did you think of calc(min ... pref ... max) ?
>> Why do you need that, or min() or max(), when there is already a
>> min-width and a max-width? I don't think you really need it for
>> borders and margins, where most of the time it would be enough to
>> just say something like 'margin: calc(1fl + 2px)', and only breaking
>> out min() when there is a real concern about the flex amount dropping
>> down to zero for it (which I think would be kind of unusual for the
>> way flex would be used for separating things with margins).
> Maybe this is just me but I think I would want to set a hard lower
> bound on margins almost always (perhaps just a 1px hairline, but still).

No, I agree. But that's why I mentioned 'margin: calc(1fl + 2px)', which would be a 2px hard lower boundary, supposing that '1fl' might typically be much more than that, but capping it at 2px in case it wasn't. If the margin was expected to usually be just a few pixels or less, then I probably wouldn't be using flex units for the margin, but I could still employ flex units and min() for that anyway, if the situation called for it.
Received on Friday, 28 May 2010 17:37:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC