- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Tue, 29 Nov 2011 03:14:45 +0000
- To: "www-style@w3.org list" <www-style@w3.org>
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 Tuesday, 29 November 2011 03:15:18 UTC