- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Sun, 6 Feb 2011 00:56:53 +0000
- To: fantasai <fantasai.lists@inkedblade.net>, Tab Atkins Jr. <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
I like this line of thought much better too. Essentially things that normally have min/max have that accounted in flexbox algorithm, others don't. It removes a lot of complexity. I definitely support the idea that anything that any flex anywhere is two values -- positive flex and (optional) negative flex. From implementation point of view, I think the model where width/height, paddings and margins are flexible in both dimension at the same time has approximately same implementation complexity but it is conceptually simple and elegant. I still have to get over the concern about flex() function being applicable to mainstream properties, but having effect only in special environment. It may be not that different from % which may or may not have effect depending on parent -- but % is so special that it is mentioned in each property description, and we liked the way flexbox was initially defined as a proof that an entirely new model can be introduced without any updates needed to existing specs... A possible alternative to flex() with general applicability is flex-width, flex-margin-left etc. ... not sure how popular that would be, but considering what we face with writing modes, it may become not that crazy... Another suggestion for flex() function if it is the way to go -- put preferred size to the end: flex(positive-flex [, positive-flex, [preferred-size]]) this way, the most common use will not have to reiterate the preferred size, regardless of default being 'max-content' (additive model, my preference) or zero (absolute model). Fantasai -- not of min/max/calc being applicable is certainly interesting, but I challenge you to come up with an example where one of those actually make sense in combination with flex (other than of course an input to flex). In flex calculations min-width/min-height are restrictions that are applied late in the process and trigger additional calculation passes, I don't see how such a restriction can be plugged into the algorithm without being passed in as a separate value... -----Original Message----- From: fantasai [mailto:fantasai.lists@inkedblade.net] Sent: Wednesday, February 02, 2011 2:01 PM To: Tab Atkins Jr. Cc: Alex Mogilevsky; www-style list Subject: Re: [css3-flexbox] Trying out flex units again On 02/02/2011 01:10 PM, Tab Atkins Jr. wrote: > > It's possible that flex() itself is too complex, though. Widths and > heights already have min/max constraints, so they only need preferred > sizes and the two flexibilities. I think my use-cases could get away > with just having margins/padding take a preferred size, a positive > flexibility (indicating it can grow, with no max), and optionally a > negative flexibility (indicating it can shrink, with no min). Would > it make you happier to track only 3 values per property rather than 5? > That would reduce the difference to 16 vs 34, and additionally > simplify the processing model somewhat. I think that makes sense. Remember also that we have general min(), max(), and calc() functions which can be used on margins and padding. ~fantasai
Received on Sunday, 6 February 2011 00:57:29 UTC