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

You can "flex-pack:justify" for the same effect.

-----Original Message-----
From: andrew.fedoniouk@live.com [mailto:andrew.fedoniouk@live.com] On Behalf Of Andrew Fedoniuok
Sent: Tuesday, November 29, 2011 6:34 PM
To: Alex Mogilevsky; www-style@w3.org
Subject: 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 03:55:17 UTC