- From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
- Date: Wed, 29 Jun 2011 09:43:24 -0700
- To: <www-style@w3.org>
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 Wednesday, 29 June 2011 16:44:02 UTC