- From: Bert Bos <bert@w3.org>
- Date: Fri, 11 Jul 2008 15:18:59 +0200
- To: www-style@w3.org
(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@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Friday, 11 July 2008 13:19:41 UTC