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

On Mon, Nov 28, 2011 at 7:14 PM, Alex Mogilevsky <alexmog@microsoft.com>wrote:

> 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
>

It wouldn't be that hard to structure your CSS to handle whether it's a
flexbox item or not using child selectors.  Something like:

.sometimes-a-flexitem{
  width: 400px;
}

.flexbox > * {
  width: flex(1);
}

-- 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.
>

This is true, but I'm not sure how common something like this is.  It's
also possible to handle with additional style rules.

-- 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.
>

*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.
>

If we just used width/height for preferred width/height, you would have all
the same problems with cascading that you mention above.  If you want the
preferred width to be 0 when a flex item, but when not a flex item, you
want a different width, there's no easy way to express this.

It is also possible to include preferred size (although redundant):
>
>        flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?
>

One of the things that I like about the flex() function is that the default
preferred size is 0.  'auto' as a preferred size is very hard to reason
about when there's text or other non-fixed size content.  'auto' also
forces an extra layout to compute the preferred size.

I suppose you could make preferred size always be specified in flex: (i.e.,
never use width/height for the preferred size).  This seems like it works,
but it might be confusing because it ignores width/height yet obeys min/max
width/height.  This also doesn't solve how transitions would work or how to
easily change a single value.

The main benefit of this proposal is that you can specify the non-flexing
width/height independently, but I'm not sure how common the use case is of
wanting to move a block in and out of being a flex item.

tony