- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Thu, 2 Jun 2011 08:49:35 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: W3C style mailing list <www-style@w3.org>
I'm looking at what it will take to add multiline flexbox back into new syntax. There are three things that will need to be controlled then: 1) mutliline on/off 2) line stacking direction 3) line packing mode Additional properties could be like this: Name: flex-lines Value: single | multiple | inherit Initial: single Applies to: flexboxes Inherited: no Percentages: no Media: visual Computed value: specified value This is more or less obvious. Naming could be different but it has to be a property, and it has to have two values. That is unless it is another value for 'display' but I don't think we'd want that. Name: flex-line-progression Value: normal | reverse | inherit Initial: normal Applies to: flexboxes Inherited: no Percentages: no Media: visual Computed value: specified value Not sure what you'll want to do here. You can update 'flex-direction' to have values like 'lr-tb', but then it is no longer a 'direction' (as 'ltr' is a 'direction' but 'lr-tb' is a 'writing-mode'). If this stays a separate property, it could be "flex-line-flow: lr | rl | tb | bt", but then it collides with "flex-direction" values. I think the best way would be to go back to separate properties for "flex-direction" and "flex-orientation", and if you want a compact layout you can have a shorthand property "flex-flow: lr-tb | tb-lr | ... all values in writing-mode ...": Flex-orientation: horizontal | vertical | inline-axis | block-axis Flex-direction: normal | reverse Flex-lines-direction: normal | reverse Also, the shorthand property could be a space separated list as other shorthands: "flex-flow:horizontal reverse" (this can only work if values for 'flex-lines-direction' are different) Name: flex-line-pack Value: before | after | middle | justify | inherit Initial: before Applies to: flexboxes Inherited: no Percentages: no Media: visual Computed value: specified value My current implementation maps 'box-align' to one of these values: before --> before after --> after middle --> middle baseline --> middle stretch --> justify which works in some common cases but generally seems wrong. What do you think? Alex
Received on Thursday, 2 June 2011 08:50:05 UTC