[css3-marquee] Comments on Terminology and marquee-direction

[fantasai]

Writing Mode Terminology
------------------------

   # The specification may refer to the specified value, the used value,
   # and the computed value of a property. Unless stated explicitly, the
   # short form "value" means the computed value.
   #   A glossary of technical terms can be found in chapter 3 of CSS
   # level 2 [CSS21].

Swap these two paragraphs, and then merge them into one paragraph.
Add "as defined in <insert CSS2 reference here>" right after "computed
value of a property" in that first sentence.

   # Furthermore, the following writing modes are defined for the purpose
   # of this module.

There's a sentence in the definition of "vertical writing mode":
   # An element can have horizontal or vertical writing mode, but not
   # both. (Although child elements can have different writing modes
   # from their parent.)
This sentence is quite general, and should be pulled out of this definition
and put, e.g. right after that "Futhermore" sentence.

Shift the "The precise definition will be in a separate module..." sentence
into a non-normative note. s/block-progression/writing-mode/.

   # horizontal writing mode -
   # A horizontal element (or box) is one that is laid out as horizontal
   # line boxes with later lines below earlier ones. This is the usual
   # writing mode for English.

I suggest s/laid out as/laid out as (or would be laid out as if its
'display' value were 'block')/ to make sure non-blocks such as table
row elements can be classified correctly.

Secondly, you need to remove "with later lines below earlier ones"
because it's possible to have a bottom-top writing mode as well.

I suggest splitting the definitions of left-right writing mode and
right-left writing mode into their own sections. Add a definition
for top-bottom writing mode.

Minor editorial comment: Replace "Otherwise" in the definitions of
marquee-line and marquee-block with "In vertical writing mode".

marquee-direction
-----------------

The table here is only correct if we don't later add the ability to
reverse-stack line boxes for horizontal and right-left writing modes
or the ability to forward-stack line boxes for left-right writing mode.
By reverse-stacking, what I mean is that the lines stack like they do
in Mongolian, where if you took the box and turned it 90deg the English
would either be laid out stacking top-to-bottom but with each line
upside down or with the lines right-side-up but stacking bottom-to-top.

In other words, as long as horizontal writing modes always have
right-side-up lines and vertical writing modes have 90deg
clockwise-rotated lines, the table is correct. If we add the ability
to rotate 90deg counter-clockwise in a vertical writing mode, then the
table is incorrect.

My suggestion here is to replace the table with definitions for
'start', 'end', 'before', 'after' and define the directions in terms
of these relative directions.

The table would then look like this:

                forward moves toward    | reverse moves toward
-------------+-------------------------+--------------------------
marquee-line |  start edge             |  end edge
-------------+-------------------------+--------------------------
marquee-block|  before edge            |  after edge
-------------+-------------------------+--------------------------

In the marquee-style definitions you'd need
   s/when the marquee direction is to the left/for marquee-line in the forward direction/
   s/margin-left/start edge margin/
   s/margin-right/end edge margin/

And finally you'd need some definitions for these terms, perhaps something like

   start edge
     The edge at which inline content, if the element had any, would
     begin and progress away from. E.g. for a box in top-bottom writing
     mode as described in CSS2.1, the start edge would be the left
     edge for elements with 'direction: ltr', and the right edge for
     elements with 'direction: rtl'. For an element in right-left
     writing mode whose left-to-right text runs from top to bottom, the
     start edge would be the top edge for elements with 'direction: ltr'
     and the bottom edge for elements with 'direction: rtl'.
   end edge
     The edge opposite to the start edge, i.e. the edge towards which
     inline content, if the element had any, would progress.
   before edge
     The edge perpendicular to the start and end edges that in normal
     block flow would be closer to earlier content. For top-bottom
     writing mode this is the top edge. For right-left writing mode
     this is the right edge.
   after edge
     The opposite the before edge, i.e. that in normal block flow would
     be closer to later content.

~fantasai

[Bert Bos]

(For those wondering what specification "css3-marquee" refers to: the WG
decided a few months ago to put the marquee-* properties from the Box
module into a module of their own[1]. The quotes are from text for that
module that I expect to be published in about two weeks, if the holiday
season doesn't slow things down too much.)

[1] http://www.w3.org/Style/CSS/current-work.html#css3-marquee



On Thursday 10 July 2008 00:11, fantasai wrote:

> Writing Mode Terminology
> ------------------------
>
>    # The specification may refer to the specified value, the used
> value, # and the computed value of a property. Unless stated
> explicitly, the # short form "value" means the computed value.
>    #   A glossary of technical terms can be found in chapter 3 of CSS
>    # level 2 [CSS21].
>
> Swap these two paragraphs, and then merge them into one paragraph.
> Add "as defined in <insert CSS2 reference here>" right after
> "computed value of a property" in that first sentence.

OK

>
>    # Furthermore, the following writing modes are defined for the
> purpose # of this module.
>
> There's a sentence in the definition of "vertical writing mode":
>    # An element can have horizontal or vertical writing mode, but not
>    # both. (Although child elements can have different writing modes
>    # from their parent.)
> This sentence is quite general, and should be pulled out of this
> definition and put, e.g. right after that "Futhermore" sentence.

That sentence indeed applies to both definitions, but moving it before
the DL doesn't seem to improve readability, nor does moving it after
the list. I've instead merged the two DDs into one. That makes it more
consistent with the next definition, which also defines two mutually
exclusive terms.

>
> Shift the "The precise definition will be in a separate module..."
> sentence into a non-normative note.
> s/block-progression/writing-mode/.

Marked it up as a note.

But why 'writing-mode'? 'Writing-mode' is too wide, it
includes 'direction', which doesn't affect this definition.

>
>    # horizontal writing mode -
>    # A horizontal element (or box) is one that is laid out as
> horizontal # line boxes with later lines below earlier ones. This is
> the usual # writing mode for English.
>
> I suggest s/laid out as/laid out as (or would be laid out as if its
> 'display' value were 'block')/ to make sure non-blocks such as table
> row elements can be classified correctly.

I tried to avoid mentioning what kinds of elements the terms apply to,
to avoid contradicting what the Text Layout Module will say. All that I
need is that elements to which 'overflow' applies can be classified as
horizontal or vertical. 'Overflow' applies to non-replaced block-level
elements, table cells, and inline-block elements. There may be more in
level 3.

Inline elements, table rows, replaced elements, etc., may or may not
have a writing mode, but as far as the Marquee module is concerned,
that is of no importance, because the marquee properties don't apply to
them.

>
> Secondly, you need to remove "with later lines below earlier ones"
> because it's possible to have a bottom-top writing mode as well.

I'll remove it, but I thought we decided to not support bt mode in CSS?

>
> I suggest splitting the definitions of left-right writing mode and
> right-left writing mode into their own sections. Add a definition
> for top-bottom writing mode.

Only if you convince me that we indeed decided to support 'bt'...

(Theoretically, it doesn't matter to define terms for situations that
never occur, but in practice it will cause confusion.)

>
> Minor editorial comment: Replace "Otherwise" in the definitions of
> marquee-line and marquee-block with "In vertical writing mode".

OK

>
> marquee-direction
> -----------------
>
> The table here is only correct if we don't later add the ability to
> reverse-stack line boxes for horizontal and right-left writing modes
> or the ability to forward-stack line boxes for left-right writing
> mode. By reverse-stacking, what I mean is that the lines stack like
> they do in Mongolian, where if you took the box and turned it 90deg
> the English would either be laid out stacking top-to-bottom but with
> each line upside down or with the lines right-side-up but stacking
> bottom-to-top.

Reverse stacking line boxes in CSS? If we ever add a thing like that,
we'll have time enough to update the marquee module.

You can no doubt do strange things by writing English in 'lr' mode and
using 'transform: rotate(90deg)' to put the whole thing on its side.
But if you really want to write xingped (as in

    X I N G
     P E D

which takes me at least two seconds to parse, every time I see it
painted on a street in the US :-) ) I suggest you use SVG...

And, actually, a 'forward' marquee would show you the PED before the
XING just fine.

>
> In other words, as long as horizontal writing modes always have
> right-side-up lines and vertical writing modes have 90deg
> clockwise-rotated lines, the table is correct. If we add the ability
> to rotate 90deg counter-clockwise in a vertical writing mode, then
> the table is incorrect.
>
> My suggestion here is to replace the table with definitions for
> 'start', 'end', 'before', 'after' and define the directions in terms
> of these relative directions.

Writing precise and clear specifications is a bit like solving a puzzle
(or writing a software program). It requires as much creativity as
inventing the described features in the first place...

I've tried three or four different ways of organizing the table:
splitting it into two or more tables, making a table with fewer columns
and more rows, defining auxiliary terms... but this one was the
shortest and clearest. (Actually, it was even better
with 'block-progression', but as you pointed out earlier, that
introduced a dependency on the text layout module.)

Somewhere it has to be defined whether the content moves up, down, to
the left or to the right. I can split the table in two: one table that
relates forward/reverse, line/block and start/after/end/before, and a
second one that relates writing mode, ltr/rtl, start/after/end/before
and left/right/up/down. But why? It just adds more jargon and makes the
definition longer.

Start and before aren't really helpful words for remembering what
concept they stand for either. On the contrary, it takes effort to
remember which one is which. (My trick is to remember that they are
the "wrong way round," i.e., the '::before' of CSS is by default
*not* "before" the element; the meaning of the other three then follows
from their symmetry.)

And in this case the words fit the specification even less, because the
table needs words to express a direction, not a location. If the "top"
edge is the "start" edge, then going "up" is going startward? ahead?
back? forward? (Hmm, not forward, because that is the keyword we're
trying to define in the first place :-) )

I'm always trying to make definitions in WDs shorter and more memorable
by defining suggestive (but precise) intermediate terms. I haven't yet
found a word, or even a short phrase, that means going in the opposite
direction from the block progression direction. And if the term isn't
good, then it will only make the definitions more difficult to read. So
far, in all drafts I've tried, it has been easier to talk about top and
left and just repeat the definition for the other sides; or,
alternatively, to use a table like I did here.

The former may be verbose, but is easy to read, because it talks about
concrete things. You can draw a picture of it. The latter is compact,
because it uses two dimensions instead of one to explain the relation
between the sides and the properties that affect them.



Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@...                             2004 Rt des Lucioles / BP 93
  [phone]            06902 Sophia Antipolis Cedex, France

[fantasai]

Bert Bos wrote:
>
>> Shift the "The precise definition will be in a separate module..."
>> sentence into a non-normative note.
>> s/block-progression/writing-mode/.
>
> Marked it up as a note.
>
> But why 'writing-mode'? 'Writing-mode' is too wide, it
> includes 'direction', which doesn't affect this definition.

Then remove the comment about what property it might be controlled by.
I would rather not be over-precise here.

>>    # horizontal writing mode -
>>    # A horizontal element (or box) is one that is laid out as
>> horizontal # line boxes with later lines below earlier ones. This is
>> the usual # writing mode for English.
>>
>> I suggest s/laid out as/laid out as (or would be laid out as if its
>> 'display' value were 'block')/ to make sure non-blocks such as table
>> row elements can be classified correctly.
>
> I tried to avoid mentioning what kinds of elements the terms apply to,
> to avoid contradicting what the Text Layout Module will say. All that I
> need is that elements to which 'overflow' applies can be classified as
> horizontal or vertical. 'Overflow' applies to non-replaced block-level
> elements, table cells, and inline-block elements. There may be more in
> level 3.
>
> Inline elements, table rows, replaced elements, etc., may or may not
> have a writing mode, but as far as the Marquee module is concerned,
> that is of no importance, because the marquee properties don't apply to
> them.

CSS3 is likely to introduce other kinds of boxes, to which 'overflow'
may or may not apply. Also it's possible that 'overflow' will soon
apply to table-row-group elements. Not all of these boxes have line
boxes that we can refer to, but they would if they were "display: block"
and had text content. That's why I think you should add that parenthetical.
To make sure that all boxes can be classified.

Also, going forward, it's likely that this Terminology section will be
useful to other specs (such as multi-col, which also needs these terms)
that advance to CR before CSS3 Text Layout is ready.

>> Secondly, you need to remove "with later lines below earlier ones"
>> because it's possible to have a bottom-top writing mode as well.
>
> I'll remove it, but I thought we decided to not support bt mode in CSS?

I'll comment on that offline. For now, please remove it.

>> I suggest splitting the definitions of left-right writing mode and
>> right-left writing mode into their own sections. Add a definition
>> for top-bottom writing mode.
>
> Only if you convince me that we indeed decided to support 'bt'...
>
> (Theoretically, it doesn't matter to define terms for situations that
> never occur, but in practice it will cause confusion.)

I am only suggesting to define "top-bottom" writing mode, which is what
we have in English.

>> marquee-direction
>> -----------------
>>
>> The table here is only correct if we don't later add the ability to
>> reverse-stack line boxes for horizontal and right-left writing modes
>> or the ability to forward-stack line boxes for left-right writing
>> mode. By reverse-stacking, what I mean is that the lines stack like
>> they do in Mongolian, where if you took the box and turned it 90deg
>> the English would either be laid out stacking top-to-bottom but with
>> each line upside down or with the lines right-side-up but stacking
>> bottom-to-top.
>
> Reverse stacking line boxes in CSS? If we ever add a thing like that,
> we'll have time enough to update the marquee module.

left-right writing mode reverse-stacks line boxes by default, because
that's how English embedded in Mongolian reads. What will make your
table wrong as-written is adding an option to forward-stack line boxes
in left-right writing mode.

>> In other words, as long as horizontal writing modes always have
>> right-side-up lines and vertical writing modes have 90deg
>> clockwise-rotated lines, the table is correct. If we add the ability
>> to rotate 90deg counter-clockwise in a vertical writing mode, then
>> the table is incorrect.
>>
>> My suggestion here is to replace the table with definitions for
>> 'start', 'end', 'before', 'after' and define the directions in terms
>> of these relative directions.
>
> Writing precise and clear specifications is a bit like solving a puzzle
> (or writing a software program). It requires as much creativity as
> inventing the described features in the first place...
> ...
> Somewhere it has to be defined whether the content moves up, down, to
> the left or to the right. I can split the table in two: one table that
> relates forward/reverse, line/block and start/after/end/before, and a
> second one that relates writing mode, ltr/rtl, start/after/end/before
> and left/right/up/down. But why? It just adds more jargon and makes the
> definition longer.

No, no. We don't want to add a table that relates writing mode, ltr/rlt,
start/after/end/before, and left/right/up/down. That is what I am trying
to avoid by defining start/after/end/before without mapping it. There is
the strong possibility of another control, as yet undefined, that will
also affect this mapping. If it weren't for that--if we were sure that
left-right writing mode always reverse-stacked and right-left writing
mode always forward-stacked, then your table would be fine as-is.

> Start and before aren't really helpful words for remembering what
> concept they stand for either. ... If the "top"  edge is the "start"
> edge, then going "up" is going startward? ahead? back? forward?

Yes, I agree these terms aren't ideal. Steve and Paul and I spent some
time trying to come up with better terms, but couldn't think of any.
If you have suggestions...

http://lists.w3.org/Archives/Public/www-style/2008Feb/0294.html

~fantasai

[Bert Bos]

fantasai wrote:
> Bert Bos wrote:

>> But why 'writing-mode'? 'Writing-mode' is too wide, it includes
>> 'direction', which doesn't affect this definition.
>
> Then remove the comment about what property it might be controlled by.
> I would rather not be over-precise here.

I try to say as little as possible in normative text, but I like to give
some extra clues in notes. But I've removed the mention of any
properties by name.


> CSS3 is likely to introduce other kinds of boxes, to which 'overflow'
> may or may not apply. Also it's possible that 'overflow' will soon
> apply to table-row-group elements. Not all of these boxes have line
> boxes that we can refer to, but they would if they were "display:
> block"
> and had text content. That's why I think you should add that
> parenthetical.
> To make sure that all boxes can be classified.

I've added "if its 'display' property were set to ''block'' and its
content set to text." That's good enough for this module, but it is
wrong in general, because it says that 'inline' boxes have a writing
mode, too.

>
> Also, going forward, it's likely that this Terminology section will be
> useful to other specs (such as multi-col, which also needs these
terms)
> that advance to CR before CSS3 Text Layout is ready.

It's probably fine for multi-col, because that also only deals with
blocks. But it is not so reader-friendly to make the multi-col module
refer to the marquee module for some of its terminology.


> I am only suggesting to define "top-bottom" writing mode, which is
> what
> we have in English.

OK, that makes sense. If I use the term top-bottom, I no longer need
horizontal and vertical, which makes the text a bit shorter again.

>
>>> marquee-direction
>>> -----------------
>>>
>>> The table here is only correct if we don't later add the ability to
>>> reverse-stack line boxes for horizontal and right-left writing modes
>>> or the ability to forward-stack line boxes for left-right writing
>>> mode. By reverse-stacking, what I mean is that the lines stack like
>>> they do in Mongolian, where if you took the box and turned it 90deg
>>> the English would either be laid out stacking top-to-bottom but with
>>> each line upside down or with the lines right-side-up but stacking
>>> bottom-to-top.
>>
>> Reverse stacking line boxes in CSS? If we ever add a thing like that,
>> we'll have time enough to update the marquee module.
>
> left-right writing mode reverse-stacks line boxes by default, because
> that's how English embedded in Mongolian reads. What will make your
> table wrong as-written is adding an option to forward-stack line boxes
> in left-right writing mode.

OK, so lr is "reverse" only from the point of view of English. That
means that rl is reverse from the point of view of Mongolian. Fine.

We'll see if it is a good idea to add more properties to a module, Text
Layout, that is already so difficult to understand, but as long as the
properties don't put the first line box *between* the second and third,
there is no problem for the marquee properties:

     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1
     1  2  3        3  2  1        3  2  1

       lr         reverse lr         rl

but for the purposes of Marquee, the last two are the same:

     "left-right"  "right-left"  "right-left"

The marquee animation has to move in one of four directions. If this
module doesn't define which direction that is, what does?

I can add the bottom-top to the table, for completeness sake, but other
than that, the table is complete. No matter how many as yet unspecified
properties reverse or restore the line stacking order, the result is
always one of these four.



Bert
--
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@...                             2004 Rt des Lucioles / BP 93
   [phone]            06902 Sophia Antipolis Cedex, France

[fantasai]

Bert Bos wrote:
>
> I've added "if its 'display' property were set to ''block'' and its
> content set to text." That's good enough for this module, but it is
> wrong in general, because it says that 'inline' boxes have a writing
> mode, too.

(Well, they do. If their writing mode is different from their containing
block, they become inline-boxes.)

>>
>>>> marquee-direction
>>>> -----------------
>>>>
>>>> The table here is only correct if we don't later add the ability to
>>>> reverse-stack line boxes for horizontal and right-left writing modes
>>>> or the ability to forward-stack line boxes for left-right writing
>>>> mode. By reverse-stacking, what I mean is that the lines stack like
>>>> they do in Mongolian, where if you took the box and turned it 90deg
>>>> the English would either be laid out stacking top-to-bottom but with
>>>> each line upside down or with the lines right-side-up but stacking
>>>> bottom-to-top.
>>>
>>> Reverse stacking line boxes in CSS? If we ever add a thing like that,
>>> we'll have time enough to update the marquee module.
>>
>> left-right writing mode reverse-stacks line boxes by default, because
>> that's how English embedded in Mongolian reads. What will make your
>> table wrong as-written is adding an option to forward-stack line boxes
>> in left-right writing mode.
>
> OK, so lr is "reverse" only from the point of view of English. That
> means that rl is reverse from the point of view of Mongolian. Fine.
>
> We'll see if it is a good idea to add more properties to a module, Text
> Layout, that is already so difficult to understand, but as long as the
> properties don't put the first line box *between* the second and third,
> there is no problem for the marquee properties:
>
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>     1  2  3        3  2  1        3  2  1
>
>       lr         reverse lr         rl
>
> but for the purposes of Marquee, the last two are the same:
>
>     "left-right"  "right-left"  "right-left"
>
> The marquee animation has to move in one of four directions. If this
> module doesn't define which direction that is, what does?
>
> I can add the bottom-top to the table, for completeness sake, but other
> than that, the table is complete. No matter how many as yet unspecified
> properties reverse or restore the line stacking order, the result is
> always one of these four.

Your diagram is wrong. It's not the direction of stacking that changes
for reverse lr, but the line boxes are effectively rotated 180deg. The
order is still left-to-right. So the direction for marquee-block doesn't
change, but the direction for marquee-line does. That is where your table,
as written, would be wrong.

~fantasai

[Bert Bos]

I prefer to write this module *with* i18n support, so that it doesn't
have to change after Text Layout becomes available, but for the Mobile
Profile it is enough to describe just horizontal text. (And we can't
write test cases for vertical text anyway right now.) So if you think
we can't make Marquee abstract enough, we could just limit it to
horizontal text and add the vertical extensions to a revised
Recommendation later.

On Wednesday 16 July 2008 18:01, fantasai wrote:
> Bert Bos wrote:
> > I've added "if its 'display' property were set to ''block'' and its
> > content set to text." That's good enough for this module, but it is
> > wrong in general, because it says that 'inline' boxes have a
> > writing mode, too.
>
> (Well, they do. If their writing mode is different from their
> containing block, they become inline-boxes.)

(I'd rather not have the writing mode influence the value of 'display'.
It's already difficult enough to understand that it is influenced by
float and position... But that is a discussion for another time.)

>
> >>>> marquee-direction
> >>>> -----------------
> >>>>
> >>>> The table here is only correct if we don't later add the ability
> >>>> to reverse-stack line boxes for horizontal and right-left
> >>>> writing modes or the ability to forward-stack line boxes for
> >>>> left-right writing mode. By reverse-stacking, what I mean is
> >>>> that the lines stack like they do in Mongolian, where if you
> >>>> took the box and turned it 90deg the English would either be
> >>>> laid out stacking top-to-bottom but with each line upside down
> >>>> or with the lines right-side-up but stacking bottom-to-top.
> >>>
> >>> Reverse stacking line boxes in CSS? If we ever add a thing like
> >>> that, we'll have time enough to update the marquee module.
> >>
> >> left-right writing mode reverse-stacks line boxes by default,
> >> because that's how English embedded in Mongolian reads. What will
> >> make your table wrong as-written is adding an option to
> >> forward-stack line boxes in left-right writing mode.
> >
> > OK, so lr is "reverse" only from the point of view of English. That
> > means that rl is reverse from the point of view of Mongolian. Fine.
> >
> > We'll see if it is a good idea to add more properties to a module,
> > Text Layout, that is already so difficult to understand, but as
> > long as the properties don't put the first line box *between* the
> > second and third, there is no problem for the marquee properties:
> >
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >     1  2  3        3  2  1        3  2  1
> >
> >       lr         reverse lr         rl
> >
> > but for the purposes of Marquee, the last two are the same:
> >
> >     "left-right"  "right-left"  "right-left"
> >
> > The marquee animation has to move in one of four directions. If
> > this module doesn't define which direction that is, what does?
> >
> > I can add the bottom-top to the table, for completeness sake, but
> > other than that, the table is complete. No matter how many as yet
> > unspecified properties reverse or restore the line stacking order,
> > the result is always one of these four.
>
> Your diagram is wrong. It's not the direction of stacking that
> changes for reverse lr, but the line boxes are effectively rotated
> 180deg. The order is still left-to-right. So the direction for
> marquee-block doesn't change, but the direction for marquee-line
> does. That is where your table, as written, would be wrong.

The content of the line box has no influence on the marquee direction.
If a horizontal block has a direction of 'ltr', then the marquee moves
to the left. It doesn't matter if that block contains English, a
mixture of English and Hebrew or only Hebrew: if the mark-up says it is
an ltr paragraph, it moves left.

The order of letters in a vertical line box is certainly more
complicated to compute than in a horizontal line box, because letters
do not only have a direction, but certain letters can also be oriented
in two or three different ways: upright, lying on their left side or
lying on their right side. But, again, that doesn't affect the marquee
direction. If you have a lr, ltr block filled with Mongolian, the
marquee moves up. If you replace a small part of the Mongolian text by
English with its letters lying on their left side, the marquee still
goes up. And if you replace *all* the Mongolian, it *still* goes up,
even though the text is now effectively read from bottom to top.

(B.t.w., why do we need letters rotated to the left? If it is to make
sideways text as in the background image of W3C
specifications, 'transform: rotate(90)' or a bit of SVG seem enough for
that.)



Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@...                             2004 Rt des Lucioles / BP 93
  [phone]            06902 Sophia Antipolis Cedex, France

[fantasai]

Bert Bos wrote:
> I prefer to write this module *with* i18n support, so that it doesn't
> have to change after Text Layout becomes available, but for the Mobile
> Profile it is enough to describe just horizontal text. (And we can't
> write test cases for vertical text anyway right now.) So if you think
> we can't make Marquee abstract enough, we could just limit it to
> horizontal text and add the vertical extensions to a revised
> Recommendation later.

I think we can make it abstract enough. We just can't do it if you insist
on making a table that takes writing mode and the 'direction' property as
input and outputs an absolute direction. You can do it with a table that
takes writing mode and the absolute inline direction (left, right, up, down)
as input, or you can do it by defining logical terms and making a table
that outputs logical directions.

> The order of letters in a vertical line box is certainly more
> complicated to compute than in a horizontal line box, because letters
> do not only have a direction, but certain letters can also be oriented
> in two or three different ways: upright, lying on their left side or
> lying on their right side. But, again, that doesn't affect the marquee
> direction. If you have a lr, ltr block filled with Mongolian, the
> marquee moves up. If you replace a small part of the Mongolian text by
> English with its letters lying on their left side, the marquee still
> goes up. And if you replace *all* the Mongolian, it *still* goes up,
> even though the text is now effectively read from bottom to top.

This is getting into discussions of primary directionality etc. Let's
avoid that here if possible...

~fantasai