Re: [CSS] Concept of flows.

"1) there is 8 possible directions for any 2D flow: lr-tb, tb-rl, etc..."

"Yes" when you define writing system (logical definition) in general.

But in my case writing mode definition is split into separate "physical"
and "orthogonal" (in both means) properties:

a) direction of glyphs/inline-blocks inside line box: exactly 4 values: lr, 
tb, etc.
b) direction of line boxes  : exactly 4 values : tb, lr, rl, bt;
c) direction of blocks (among other possible flows): tb, lr, rl, bt;

"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"

Language defines default values for 'inline-flow', 'line-flow' and 
'block-flow'.
For example for languages of European descent and for elements like <div>
we have:

  inline-flow: lr;
  line-flow: tb;
  block-flow: tb;

inline-flow / line-flow are closely tied indeed (in practice) but there are
cases when line boxes may also have non-trivial flow. Consider construct
(hypothetical so far but we've started drifting there):
    <img style="float:center">
Here text flows on both sides of the floating image. So around such an
image you will have line boxes replaced horizontally rather than vertically
as by default.  And someone may want to replace them in Z alike flow.
Ideally you should have an option to define explicitly these nuances.

And yes, 'block-flow' exhibits variety of possible flows already.
Physically it is not tied with writing system.  Writing system definition
just sets default value of the 'block-flow' (for simple containers
like <ul>,<div>, etc).

My point is simple: there are four conceptually orthogonal properties
that define various text/block layouts we are dealing with so far.

[philosophically] It appears as "orthogonality" of system of properties is
closely tied with the concept of quality of system of properties - the
whole setup is more stable, especially for future expansions.
[/philosophically]

-- 
Andrew Fedoniouk

http://terrainformatica.com

-----Original Message----- 
From: Alex Mogilevsky
Sent: Monday, July 18, 2011 9:14 PM
To: Andrew Fedoniouk ; www-style@w3.org
Subject: 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 15:56:58 UTC