W3C home > Mailing lists > Public > www-style@w3.org > June 2011

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

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Wed, 8 Jun 2011 09:40:22 -0700
Message-ID: <BLU165-ds1780776C863C5EB5E96B41F8620@phx.gbl>
To: "Alan Gresley" <alan@css-class.com>
Cc: "fantasai" <fantasai.lists@inkedblade.net>, <www-style@w3.org>
-----Original Message----- 
>From: Alan Gresley Sent: Wednesday, June 08, 2011 4:05 AM To: Andrew 
>Fedoniouk Cc: Andrew Fedoniouk ; fantasai ; www-style@w3.org Subject: Re: 
>[css3-flexbox] getting multiline flexbox back into the spec
>On 8/06/2011 4:50 PM, Andrew Fedoniouk wrote:
>> From: fantasai Sent: Tuesday, June 07, 2011 10:50 PM To:
>>> On 06/08/2011 01:06 PM, Andrew Fedoniouk wrote:
>>>> Explicit declaration as 'horizontal-ltr' is significantly more reliable
>>>> than anything like 'direction:horizontal reverse'
>>> While I agree that we should have a way to explicitly say
>>> 'horizontal-ltr',
>>> I'm not so certain that logical backwardness isn't needed. I can't think
>>> of a use case for backwards ordering in the inline dimension, but I can
>>> see backwards ordering being useful in the block direction when you have
>>> columns.
>> I assume that columns are defined as:
>> block-flow: vertical-wrap;
>> then if you want to define full set of progressions we will probably
>> need to use parametric form of LM defintiion:
>> block-flow: vertical-wrap[(ttb | btt [, ltr | rtl ])];
>> that will define all possible configurations.
>Why 'ltr' and 'rtl"?

Full definition of vertical-wrap should include:
  1. block progressions in columns (vertical, ttb | btt)
  2. columns progressions (horizontal, ltr | rtl)

I mean that each layout mode/manger has its own
and specific progression/directionality definitions.
I beleive that functional form like 'vertical-wrap(ttb)'
is the most convenient for that. Separate proeprties
like proposed flex-direction/order simply make no sense as
each manager requires its own direction parameters (if any).

>> I don't think that logical directions make sense in CSS at all.
>You think the reverse is true with visual direction? Do they make sense?

I even have dificulties to understand this phrase.

In any case, something like 'progression:reverse' tells
me nothing without context it is used. Sounds like author asking
for "do me something good".
Instead, 'progression:ltr' is clear and predictable.

CSS should be smart but not too smart.

It is enough to have environment directionality pseudo-classes
to define explicitly what author wants:

.cont { progression:ltr; }
.cont:rtl { progression:rtl; } or
.cont:rtl { progression:ltr; }

>> They just complicate CSS usage a lot. I said couple of times here that 
>> CSS
>> should just have pseudo-classes :ltr, :rtl, :ttb that are set from
>> @dir. In this case we can define:
>> .toolbar:rtl
>> {
>> block-flow: horizontal(rtl); // or just block-flow: horizontal
>> horizontal-align: right;
>> }
>> Explicit definitions are always better (manageable) than
>> bunch of nested after/before, start/end, reverse/non-reverse, etc.
>You have 'block-flow: horizontal(rtl)' Blocks do not flow in how you think. 
>They progress in an order (perpendicular to the flow). Think of it like a 
>stream with boats that move sideways. For a horizontal base writing system, 
>consider line-left as bank-left and line-right as bank-right.
>   |  (   (   (   (  |
>   |[     BOAT      ]|
>   |  )   )   )   )  |
>   |[     BOAT      ]|
>   |  (   (   (   (  |
>   |[     BOAT      ]|
>   |  )   )   )   )  |

I suspect that I do not understand your metaphor here.

Anyway if you think that such a z-alike block flow makes any sense
(each row has its own direction of blocks) then we should add
another layout manager or mode of existing one:

'block-flow: horizontal-wrap-alternate(rtl)'

This will create first row with rtl block flow,
next one with ltr block flow, etc.

>>>> By the way, you used keyword 'reverse'. It is 'reverse' to what
>>>> actually?
>>>> I mean what exactly defines normal, non-reversed order then, the
>>>> 'direction'?
>>> Yes.
>> If "yes" then it means direction of block-flow is governed by the
>> 'direction'.
>No it isn't. It can be reversed.

Sorry, it can be reversed by what/whom?

>> At least in default form. And 'direction' is not just a
>> text direction but "UI-directionality", right?
>The default is the initial embedding level (base direction) of most UI.
><root></root>  =  <root dir=ltr"></root>

Actually that is a wrong assumption. You've forgot about implicit
'inherit' value:

<root></root>  ==  <root dir="inherit"></root>

UA may provide 'parent value' of @dir so any loaded document
will inherit the value if it not defined in the document itself.

Andrew Fedoniouk

Received on Wednesday, 8 June 2011 16:40:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC