RE: [CSS] Concept of flows.

Having consistency across different kinds of direction declarations is good, I certainly like this line of thinking.

The problem space is a little bigger here: 
1) there is 8 possible directions for any 2D flow: lr-tb, tb-rl, etc...

2) text direction is based primarily on language, it is always physical (there is no reason to add text flow directions like inside-outside), so there is no more than 8 options that are relevant

3) block-flow direction (as in multiline flexbox or in grid) also has 8 possible options but it is not necessarily based on writing mode. In any language a designer can choose to arrange UI buttons or product images horizontally or vertically, and to align toolbars on any edge of the screen. Following current writing mode should still be possible though (natural for block content, like a table, embedded in text).

Then for defining a 2D block flow, full set of options should include 8 physical (lr-tb), 8 logical (inline/block, reverse-block/reverse-inline, etc.), and possibly some mixed (horizontal or vertical: define primary dimension, then pick up directions from writing mode; not sure how many should count, I think also 8, including "horizontal/bottom-to-top")

We get to about 24 possible flexbox directions then (more if I've missed some). It is not impossible for one property; for multiple properties consistency is good too.

Not proposing any system right here yet... just setting the space.

± -----Original Message-----
± From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
± Of Andrew Fedoniouk
± Sent: Wednesday, June 29, 2011 9:43 AM
± To: www-style@w3.org
± Subject: Re: [CSS] Concept of flows.
± 
± I've got couple off-list "like"s on this message so I think I need to
± explain the idea better...
± 
± Let's assume that existing 'display' and 'direction' are "logical"
± properties in the way they are defined in CSS 2.1.
± And we have four "physical" properties:
± 
± inline-flow: default | tb | lr | rl | bt;
± line-flow: default | tb | lr | rl | bt;
± block-flow: default | vertical | horizontal | table
±                    vertical(flex) | horizontal(flex) | etc.
± "super-flow": default | straight | paged | columns(...) | region(selector)
± | etc.
± 
± Having this set of properties in place all existing  'display',
± 'direction', 'writing-mode' , flexbox, etc. cases can be defined  as a
± combination of these four.
± 
± Let's assume for the moment that all flow's above have 'default' value set
± on them. Then
± 
± declaration:
± 
±   elem { display: block;  direction: rtl; }
± 
± will result in following computed/used values :
± 
± elem
± {
±      inline-flow: rl;
±      line-flow: tb;
±      block-flow: vertical(tb);
± }
± 
± elem { display: block; direction: ttb-rtl; }
± 
± that is "han" writing mode:
± 
± elem
± {
±    inline-flow: tb;
±    line-flow: rl;
±    block-flow: horizontal(rl);
± }
± 
± This way existing CSS properties define what they are now (backward
± compatibility) and the new set allows to define various other useful
± combinations.
± 
± And if someone need  multi-rows in "han" writing mode then it can be
± defined explicitly:
± 
±   block-flow: horizontal-wrap(rl,tb);
± 
± The above will create horizontal rows of vertical text blocks that will
± wrap on multiple rows (or are they columns actually?).
± 
± 
± --
± Andrew Fedoniouk
± 
± http://terrainformatica.com

± 
± >-----Original Message-----
± >From: Andrew Fedoniouk Sent: Monday, June 27, 2011 11:03 PM To:
± >www-style@w3.org Subject: [CSS] Concept of flows.
± >At the moment various CSS properties are trying to compete for the same
± >entity - block/box flows:
± >
± >'display' - indirectly but still;
± >'writing-mode :  horizontal-tb | vertical-rl | vertical-lr | horizontal-
± tb'
± >'flex-direction:  lr | rl | tb | bt | inline | inline-reverse | block |
± >block-reverse' and/or 'grid-columns' and 'grid-rows' (grid module),
± >etc.
± >
± >It appears as something is definitely wrong/missed in overall CSS
± >design
± >- it shouldn’t be that redundant.
± >
± >Conceptually there are four 'flows' that we know about so far:
± >
± >1. glyphs and inline blocks flow (inside line box) -  lr | rl | tb | bt
± >2. flow of line boxes - lr | rl | tb | bt 3. block flow -
± >                        vertical | horizontal
± >                        | flex-vertical | flex-horizontal
± >                        | flex-vertical-wrap | flex-horizontal-wrap
± >                        | table/rows
± >                        | "template".
± >4. "super"-flow - paginated flow / multi-column flow and CSS regions.
± >
± >Probably it makes sense to define just four properties for each entity
± >above?
± >
± >It could be something simple as:
± >
± >inline-flow :  default | ltr | rtl | ttb | btt line-flow : default |
± >ltr | rtl | ttb | btt etc.
± >
± >where the 'default' value will be computed using 'direction' property
± >that defines general directionality.
± >
± >If some values of 'block-flow' require parameterization then we can use
± >function in the same manner as for example gradients:
± >
± >block-flow:  flex-vertical(ttb);
± >
± >Such four properties will establish pretty strong foundation for
± >further evolution.
± >
± >--
± >Andrew Fedoniouk
± >
± >http://terrainformatica.com

± >
±

Received on Tuesday, 19 July 2011 04:14:55 UTC