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 Sunday, 5 June 2011 05:29:57 UTC