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

I hope you understand limitation of flex-pack:justify solution, don't you?

Just few examples:

[div:first]<------flex(1)------>[div:second][div:last]
[div:first]<--flex(1)--->[div:second]<-------flex(2)------->[div:last]

and so on.

And yet I saw people using

div:nth-child(1) { margin-right:*; }
div:nth-child(2) { margin-left:10px; }

to set flexible margin with 10px min constraint between elements.

IMO - it is a bad idea to use properties for defining
flexibility - you cut out too many opportunities otherwise available with
flex units.

>From implementation point of view I do not see any problems
with flex units. Yes, they require some effort to get into them,
but otherwise fit nicely into CSS layout mechanisms.

BTW, flexes as units are used not only in flex-box but in Grid and
other modules AFAIR.

-- 
Andrew Fedoniouk.

http://terrainformatica.com


-----Original Message----- 
From: Alex Mogilevsky
Sent: Tuesday, November 29, 2011 7:54 PM
To: Andrew Fedoniuok ; www-style@w3.org
Subject: 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 04:48:26 UTC