Re: [CSS3] Box Model Terminology

fantasai wrote:
 > Andrei Polushin wrote:
 >> fantasai wrote:
 >>>
 >>> Directions
 >>> ----------
 >>>
 >>>   n/a (refer to 'direction' property)                 inline direction
 >>>   n/a (refer to 'direction' property)                 block direction
 >>
 >> Not so good: while it became a writing-mode-independent, it's still a
 >> layout-algorithm-dependent: now it is defined in terms of flow layout.
 >>
 >> It might be better to use "logical width/height direction", or simply
 >> "width/height direction", because the direction of physical
 >> width/height always remains constant.
 >
 > These two terms are *about* how the flow layout works,

Yes, and that *is* the problem when you start defining another layout 
algorithm with those terms.

And there is the 3rd direction to flow layout, how would you call it? 
Z-axis? Or overlay-direction?

On the other hand, any flow layout engine could be coded using the 
(x,y,width,height) terms, but then those terms could be easily remapped 
(without renaming) for each particular writing mode. There is no need to 
invent more and more abstract terms.


 > and they're vectors not sizes.

OK, I didn't catch the English meaning for the first time. Then might be 
"width growing direction"? Or "logical X direction"? Or "logical right 
direction" (my favorite)?


 >> I would suggest reusing the terms
 >> from both worlds instead of introducing unusual terminology:
 >>
 >>    top          logical-top         japanese-left
 >>    left         logical-left        japanese-bottom
 >>    right        logical-right       japanese-top
 >>    bottom       logical-bottom      japanese-right
 >
 > That would make left == right in RTL languages, something we want to avoid.

You mean logical-left == physical-right in RTL languages, I guess.

I use the left-handed computer mouse, buttons logically switched. When I 
press the right mouse button, each program receives the "left button click" 
event. So right is left, and left is right, am I right? It works just fine, 
really. Why do you want to avoid this?


 > Also, the 'start/end' terms are already being used; we can't change those.

Did you mean XSL-FO? Or is there CSS *Recommendation* using them? Is there 
any browser that implements them? Are there any web authors aware of that? 
Are there any web authors that would prefer using them?

I suspect you *can* make a change, there is no real compatibility issue.


 >> In this case, logical-top and japanese-left are full synonyms and can
 >> be used interchangeably throughout the specifications.
 >
 > Absolutely not. First of all, the direction mapping used for Japanese is
 > also used in traditional Chinese,

Mostly irrelevant, let it be "east-asian-left". Assuming logical-top is OK 
in Europe, just ask Asians how would they like to call it, instead of 
inventing the third term.


 > secondly it's not the only direction
 > mapping in vertical text: a left-right flip of the Japanese diagram will
 > give you layouts typically used in Mongolian, and a left-right flip of
 > the English diagram will give you layouts typically used in Arabic.

So what? Each time one would use his own set of terms, most convenient
for his own culture, and the mapping is as follows:

  European          Arabic, Hebrew   Chinese, Japanese   Mongolian
  ----------------- ---------------- ------------------- ----------------
  logical-left      semitic-right    east-asian-bottom   mongolian-bottom
  logical-right     semitic-left     east-asian-top      mongolian-top
  logical-top       semitic-top      east-asian-left     mongolian-right
  logical-bottom    semitic-bottom   east-asian-right    mongolian-left

When you see the diagram, you will see it in a manner suitable for your 
culture, no matter in what culture has it been defined.

Now you are not required to rename your left hand into "start hand" each 
time you're writing the CSS spec.

-- 
Andrei Polushin

Received on Wednesday, 27 February 2008 23:04:10 UTC