W3C home > Mailing lists > Public > www-style@w3.org > November 2011

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

From: Tony Chang <tony@chromium.org>
Date: Tue, 29 Nov 2011 11:38:38 -0800
Message-ID: <CAL-=4P1oxXhO4D3faNU22U0P25V2017xhJRJqGgkgKfYk9aiqg@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: "www-style@w3.org list" <www-style@w3.org>
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:

  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.


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

Received on Tuesday, 29 November 2011 19:39:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC