- 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