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

As I said earlier in this thread, it is possible to specify direction of boxes using text direction properties, but it would be using properties for something different from their intended meaning - and that's why you have to compensate such misuse by a child selector like ".flex-container > * { direction: ltr; }".

Specifying direction of flexbox has nothing to do with specifying direction of text flow within these boxes, therefore text direction properties should not be used for that purpose. Flexbox should have its own way to specify its layout direction.

Alex

± -----Original Message-----
± From: Andrew Fedoniouk [mailto:andrew.fedoniouk@live.com]
± Sent: Saturday, June 04, 2011 10:29 PM
± To: Alex Mogilevsky; Tab Atkins Jr.
± Cc: W3C style mailing list
± Subject: Re: [css3-flexbox] getting multiline flexbox back into the spec
± 
± 
± Flexbox orientation is, as a rule, defined by @dir attribute that is
± reflected in CSS direction. If someone wants to override default ordering
± then it can easily be done by this:
± 
±   .flex-container { flow:horizontal; direction: rtl; }
±   .flex-container > * { direction: ltr; }
± 
± or by explicit declarations:
± 
±   .flex-container { flow:"3 2 1"; }
± 
± or may be even as something like this:
± 
±   .flex-container { flow:horizontal-rtl; }
±   .flex-container { flow:horizontal(rtl); }
± 
± Not all layouts have a concept of x/y direction. So not all of them need
± flex-direction at all.
± 
± For example `flow:stack` replaces children as a deck of cards.
± Intrinsic dimensions of flow:stack container is determined by child having
± max intrinsic dimension - this cannot be reproduced by any CSS means at
± the moment. But is needed for tabs alike containers.
± 
± In any case you should have an option to use either base direction of the
± page *or* to use something explicitly defined.
± 
± At the moment order of columns in tables is defined by the `direction`
± property. Order of floats is too. I do not see why do you need to invent
± new property with the same or very close meaning.
± 
±   "If 'direction' ... property has to be used for flexbox direction,
±    large set of use cases will become harder to localize"
± 
± In fact our practice shows exactly opposite.
± 
± I do remember that I've got request for flow:horizontal to use 'direction'
± from Middle East developers. They were very surprised that my initial
± implementation did not obey 'direction'ality of the page.
± 
± --
± Andrew Fedoniouk
± 
± http://terrainformatica.com

± 
± 
± >-----Original Message-----
± >From: Alex Mogilevsky
± >Sent: Friday, June 03, 2011 11:05 PM
± >To: Andrew Fedoniouk ; Tab Atkins Jr.
± >Cc: W3C style mailing list
± >Subject: RE: [css3-flexbox] getting multiline flexbox back into the
± >spec
± >
± >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 ...
± >±
±

Received on Monday, 6 June 2011 19:27:18 UTC