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

RE: [css3-flexbox] getting multiline flexbox back into the spec

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sat, 4 Jun 2011 06:05:19 +0000
To: Andrew Fedoniouk <news@terrainformatica.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: W3C style mailing list <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284120101E2@TK5EX14MBXC213.redmond.corp.microsoft.com>
It is true that two-dimensional flow order can be represented using writing-mode property. There are reasons to use writing-mode for defining flexbox orientation and direction:

	1) flexbox orientation is UI decision, separate of text flow direction. In an English page you can have a mix of horizontal and vertical flexboxes, so you will have to frequently switch direction on flexbox and flexbox items to have correct text rendering
	
	2) default direction is commonly derive from writing mode and changes with it. For example, English menu goes either top to bottom or left to right. Arabic menu goes top to bottom or right to left. If 'direction' or 'writing-mode' property has to be used for flexbox direction, large set of use cases will become harder to localize

± -----Original Message-----
± From: Andrew Fedoniouk [mailto:andrew.fedoniouk@live.com]
± Sent: Saturday, June 04, 2011 2:51 PM
± To: Alex Mogilevsky; Tab Atkins Jr.
± Cc: W3C style mailing list
± Subject: Re: [css3-flexbox] getting multiline flexbox back into the spec
± 
± Sorry but all this looks like a competition whose team will make the
± subject more complex.
± 
± May I remind again that all this flex-box-vagance  can be defined by just
± one new property:
± 
±   flow: vertical | horizontal | horizontal-wrap | vertical-wrap | stack |
±            "template" | etc.
± 
± and the flex units.
± 
± Direction of blocks is defined as usual by the 'direction' property that
± is already there. The direction  defines direction of e.g. float elements,
± table cells, inline blocks. So what is wrong with it?
± 
± Am I the only one who see that multiple block layout methods are
± 1) Share common features like flexibility.
± 2) Mutually exclusive so shall be applied by value of single property.
± 3) And so to be defined by single CSS Layout Methods Module or the like.
± 
± Given that 'flow' property above and the flex units I would like to see
± definition of practical problem that cannot be solved with them and so
± requires all these:
± flex-direction,
± flex-lines,
± flex-lines-direction,
± flex-lines-progression,
± flex-orientation,
± flex-pack,
± flex-whatever ...
± 
± --
± Andrew Fedoniouk
± 
± http://terrainformatica.com

± 
± 
± -----Original Message-----
± From: Alex Mogilevsky
± Sent: Friday, June 03, 2011 9:40 PM
± To: Tab Atkins Jr.
± Cc: W3C style mailing list
± Subject: RE: [css3-flexbox] getting multiline flexbox back into the spec
± 
± ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] ± Sent: Friday, June
± 03, 2011 2:01 PM ± ± flex-direction: lr | rl | tb | bt | lr-tb | lr-bt |
± rl-tb | rl-bt | tb-lr ± | tb-rl | bt-lr | bt-rl | <the inline variants of
± these> ± ± The single-direction values imply single-line, while the two-
± direction ± values imply multiline.  Presumably the inline variants would
± be "ba | ab ± | se | es | ..."?
± 
± Let me try listing the options:
± 
± Option 1: writing-mode-like codes for all physical and logical directions
± 
± flex-direction:
± lr | rl | tb | bt |
± lr-tb | lr-bt | rl-tb | rl-bt | tb-lr | tb-rl | bt-lr | bt-rl | se | es |
± ba | ab | se-ba | se-ab | es-ba | es-ab | ba-se | ba-es | ab-se | ab-es
± (initial:se)
± 
± Option 2: verbose version
± 
± flex-direction:
± horizontal | horizontal-reverse | vertical | vertical-reverse |
± horizontal-vertical | horizontal-vertical-reverse | horizontal-reverse-
± vertical | horizontal-reverse-vertical-reverse | vertical-horizontal |
± vertical-horizontal-reverse | vertical-reverse-horizontal | vertical-
± reverse-horizontal-reverse | inline | inline-reverse | block | block-
± reverse | inline-block | inline-block-reverse | inline-reverse-block |
± inline-reverse-block-reverse | block-inline | block-inline-reverse |
± block-reverse-inline | block-reverse-inline-reverse
± (initial:inline)
± 
± Option 3: multiline settings separate
± 
± flex-direction: lr | rl | tb | bt | inline | inline-reverse | block |
± block-reverse
± (initial:inline)
± 
± flex-lines: single | multiple
± (initial:single)
± 
± flex-lines-direction: normal | reverse
± (initial:normal)
± 
± Option 4: multiline settings separate, combined
± 
± flex-direction: lr | rl | tb | bt | inline | inline-reverse | block |
± block-reverse
± (initial:inline)
± 
± flex-lines: single | multiple | multiple-reverse
± (initial:single)
± 
± Option 5: separate direction and orientation (as in 2007 spec)
± 
± flex-orientation: horizontal | vertical | inline | block
± (initial:inline)
± 
± flex-direction: normal | reverse
± (initial:inline)
± 
± flex-lines: single | multiple
± (initial:single)
± 
± flex-lines-progression: normal | reverse
± (initial:normal)
± 
± To be honest I still prefer the 2007-style separate properties (option 5).
± It has the most useful default (authors will very rarely use anything
± other than 'flex-orientation', and when they do it is clear what's
± changing).
± 
± Alex
± 
± 

Received on Saturday, 4 June 2011 06:05:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT