Re: [css3-flexbox] Too many flex-flow values?

Hi Phil.

Question is how you will assign that direction...

Let’s say you have document in RTL context and you want your grid to be strictly LTR. So you will define:

grid { direction:ltr; }

but direction is an inheritable property so anything inside will also be LTR. But that is not what you will want, cells may have content by themselves.  
So you will end up with something like:

grid { direction:ltr; }
grid > * { direction:rtl; }

Actually even more complicated - you will need here :rtl /:ltr pseudo-classes [1]

grid:rtl { direction:ltr; }
grid:rtl > * { direction:rtl; }

But even with that you will have rule clashes if some cells in your grid will use different directions like in formula/description case.

Really, that easily can become non-manageable mess. ‘Been there already.

I don’t know if these problems are specific to UI of applications only (my use cases) but real-life developers
prefer to use physical directions and explicitly define style sheets for RTL versions. Transforming UI to RTL
is far not only about CSS as we know. Images, various graphs like charts, transitions, etc. are not subjects
of trivial direction switch. But as I said this is probably because of just such specific domain.

I honestly think that the most useful thing that we can do is to add those :rtl / :ltr [1] context pseudo-classes
so designers can build reliable style systems using explicit directions. 


Andrew Fedoniouk

From: Phil Cupp 
Sent: Sunday, September 25, 2011 2:00 AM
To: Andrew Fedoniouk ; Ojan Vafai 
Cc: Tab Atkins Jr. ; www-style list 
Subject: RE: [css3-flexbox] Too many flex-flow values?

Hi Andrew,


These are great scenarios, but I don’t think they necessitate a separate physical coordinate system.  The author is in control of the direction for any given element.  If they want the first column grid line always on the left, then they can ensure the direction assigned to the grid element is left to right.  They can do that even if they’ve established an rtl direction for the rest of the document.


In my experience, most scenarios benefit from having an element’s layout adapt to direction.  It seems reasonable to me to have authors set an additional attribute or define an additional CSS rule for an element to handle the less common scenarios.




From: [] On Behalf Of Andrew Fedoniouk
Sent: Thursday, September 22, 2011 7:45 PM
To: Ojan Vafai
Cc: Tab Atkins Jr.; www-style list
Subject: Re: [css3-flexbox] Too many flex-flow values?


Consider something close to tiled map implementation where element-tiles 

shall go in strictly physical order no matter of base UI directionality. 

That is one of practical situations we’ve bumped into with our flex/flow 

implementation that used only logic directions initially. 


Another case is when content contains explicit mentioning of 

the direction, like: “Result of formula (on the left) is presented in 

the table on the right”. It is better to use physical directions here

for many reasons including potential misinterpretation of information

when blind translations are used.


Obviously this applies to flexbox and grid use cases.


Andrew Fedoniouk




From: Ojan Vafai 

Sent: Thursday, September 22, 2011 5:08 PM

To: Andrew Fedoniouk 

Cc: Tab Atkins Jr. ; www-style list 

Subject: Re: [css3-flexbox] Too many flex-flow values?


Can you give use-cases where logical directions are insufficient. It's hard to argue against "for ttb systems use of only logical directions in Grid is plainly wrong" because it doesn't actually say what's wrong or what use-cases don't work.



Received on Sunday, 25 September 2011 19:13:15 UTC