Re: [css3-flexbox] remove flex() function

Let's say I have two blocks in horizontal layout and I'd like
to place them with "spring" in between. So left one is stuck to
left side of the container and second one to the right side of it:

|div:first|<------flex(1)------->|div:second|

With flexible margins I can do this simply as:

div:first-child { margin-right: flex(1); }

If you decided to drop flexes for margins then how this
can be achieved?  (without floats please)

-- 
Andrew Fedoniouk.

http://terrainformatica.com





-----Original Message----- 
From: Alex Mogilevsky
Sent: Monday, November 28, 2011 7:14 PM
To: www-style@w3.org list
Subject: [css3-flexbox] remove flex() function

I would like to reconsider using flex() function to specify flexibility.

When flex() was introduced to the spec, it was because

   1) flex() was intended to be used on more properties (margins,
      padding). Adding separate properties for
      each flexible length would be excessive then.
   2) flex(<flexibility> <preferred-size>) was expected to be more
      intuitive than separately setting preferred
      size. In particular "flex(1)" is supposed to read
      better than "width:0; flex:1;"

In current state of the spec however, (1) no longer applies and (2) doesn't 
seem a good reason to do things differently from elsewhere in CSS.

If flexibility is specified with flex(), it adds a number of issues:

-- flex() applies to 'width' and 'height' properties always, regardless of 
whether the element is a flexbox item. In parsing and cascading it is 
impossible to tell if a rule will be applied to a child of flexbox, so 
flex() must be valid everywhere, thus overriding non-flex width/height of 
lesser specificity

-- because of being applied to broadly used properties, flex() has to have 
meaning when applied to non-flex-item. It can then be invalid or have a 
special meaning, neither seem ideal:

    if flex() is invalid when not in flexbox,
    "width:100px; width:flex(1 100px)" means "width:auto"
    (because the last value wins in cascading, then gets ignored)

    if flex() applies to anything as preferred size,
    "width:flex(1)" means "width:0"

-- in DOM, specified style has to show as flex(...); any script that read 
selement.style.width will be broken or will have to parse flex()

-- having to specify flex separately for width and height forces unnecessary 
duplication. E.g. if a flexbox is sometimes horizontal and sometimes 
vertical but flexible is same, stylesheet may have something like 
"width:flex(1 auto); height:flex(1 auto)", which will work but is confusing.

-- combining width/height and flexibility in one property makes it 
impossible to change them independently. Sometimes such grouping is done on 
purpose, but I can't see any reason to disallow manipulating flex separately 
from width/height.

-- it is unclear if animations and transitions will work flex(). It seems it 
can be made to work, but not for free.

-- (this is just the list of issues I can think of right now, can't claim 
that it is complete)


*proposal*

Considering that the primary reason (1) of introducing a function no longer 
applies, I would like to propose removing flex() from flexbox spec. It 
doesn't seem that remaining motivation is worth dealing with so many issues 
(most of which coming from not following the way CSS works).

A single 'flex' property will be perfectly adequate:

flex: <pos-flex> <neg-flex>?

preferred width/height will be the value of width/height properties.

It is also possible to include preferred size (although redundant):

flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?


There may be other reasonable alternatives, I am sure we can pick something 
reasonable.

Note that if at some point we do want to apply flex() to multiple 
properties, it can always be added.

Alex

Received on Wednesday, 30 November 2011 02:34:18 UTC