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

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

Received on Friday, 11 July 2008 17:32:56 UTC