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

If @dir is reflected in 'direction' then the meaning of the 'direction' is 
broader then
just base bidi level. 'Direction' is a direction of UI - it defines now how 
horizontal layouts
are handled in CSS. It defines or participates in determination of default 
value of text alignment,
horizontal margins, columns in tables, floats, etc.

Ok. If you don't like the 'direction' itself then what about 
'block-progression' [1] then?
How all these will fit together? 'flow-direction' and 'block-progression' 
... who
will win at the end?

'flow-direction' and 'block-progression' compete for the same entity -
block flow - definition of block layout manager used.

It means it shall be one CSS property that defines block layout method.

I understand motivation behind modularity in CSS but practice shows
that we are loosing slimness of overall CSS design as a result - many 
modules
define same or very similar concepts using different names and methods.
The building looks uglier and uglier, sigh.

[1] http://www.w3.org/TR/2003/CR-css3-text-20030514/#block-progression


-- 
Andrew Fedoniouk

http://terrainformatica.com


-----Original Message----- 
From: Alex Mogilevsky
Sent: Monday, June 06, 2011 12:22 PM
To: 'Andrew Fedoniouk' ; Tab Atkins Jr.
Cc: W3C style mailing list ; Alan Gresley (alan@css-class.com)
Subject: 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 Tuesday, 7 June 2011 02:59:02 UTC