RE: text direction and CSS

Cleaning out my mailbox...

Concerning http://www.w3.org/TR/i18n-format/ (note that the WD has
been updated on Sep 11)

Garth Wallace wrote on Aug 11:
> Wow! That's a really nice WD. I'll have to bookmark that one.
> A lot more complete than my suggestion, and some of the
> miscellaneous text formatting properties would be useful in
> any language, especially in tabular data.
> 
> I have a couple of suggestions about the content of the draft,
> one technical correction, and a small miscellaneous comment.
> 
> First, the suggestions:
> 
> - First, Japanese line breaks are a little more complicated than
> that. Breaking inside a katakana string is okay, but hiragana
> is mostly used for word endings and particles (conjugation,
> declention, etc.) and in that case should be associated with
> the preceding kanji. In other words, the line should never break
> before a hiragana character unless the preceding character is
> a katakana character.

Good to know there is expertise available on this list!

I believe those line breaking rules are covered by the setting of
'line-break'. If you set that to 'strict', the browser is supposed to
apply a set of "kinsoku" rules equivalent to (or at least similar to)
those defined by JIS 4051, a Japanese standard for typography. That
standard gives all the pairs of characters between which you are
normally not allowed to break a line. (See the WD for more
explanation).

Do you think this strict/loose distinction is not enough?

Btw., I am thinking that the properties 'line-break' and 'word-break'
have rather confusing names, especially since we also have to bring in
hyphenation somewhere, which is another line-breaking phenomenon. I'd
suggest 'ideographic-line-break' (with values 'none', 'strict' and
'loose') and 'hyphenation' (with values 'none', 'hyphenate',
'anywhere' and 'long-words'.

It would be easier to understand that one affects ideographic scripts
and the other alphabetic ones.

The 'none' value on 'ideographic-line-break' takes the place of
'keep-all' in the draft.

The values 'none' and 'hyphenate' should be clear enough. 'Anywhere'
means break the word anywhere, without regard for hyphenation rules,
'long-words' means the same as 'none', except when a word is so long
that it is wider than the line; in that case it may be broken.

Comments?

> 
> - Second, layout-grid-char seems to duplicate letter-spacing. I
> understand why you wouldn't want to use line-height instead
> of layout-grid-line for spacing between lines, since line-height
> implies a vertical dimension. However, letter-spacing doesn't
> imply anything other than "between letters." It might be simpler
> (for authors at least) to just redefine letter-spacing's behavior to
> take the grid into account if layout-grid-mode is not set to "none."
> 
> The layout-grid property would then be shorthand for
> layout-grid-mode, layout-grid-type, layout-grid-line, and
> letter-spacing.

Letter-spacing indeed plays a role which is not explained in the
draft. I am in fact wondering if it doesn't already do what
layout-grid does, at least in the horizontal direction (or rather: in
the direction of the letters).

The line spacing might be better handled by an extension to
'line-height', to allow designers to fix the line height and not allow
it to grow arbitrarily because of tall inline elements. Although you
are right that "height" seems to indicate something vertical...

I'm actually hoping that 'layout-grid-type' is not real. Or at least
that we can do without.

Between them, 'letter-spacing' and 'line-height' (maybe with a small
addition) should then be able to completely replace the grid
properties.

> 
> And now the technical stuff (Yeah, I know it's just a working
> draft, but I figure it's safer to be nitpicky now rather than
> letting some mistakes into a more official document):
> 
> In the notes for section 3.6 (layout-grid shorthand property),
> the second example reads:
> 
> DIV.section1 { layout-grid: strict line .5in 20% }
> 
> However, this puts the layout-grid-type value and 
> layout-grid-mode value in reverse order to how the property
> is defined earlier.
> 
> And finally, In the section on tate-chu-yoku text, it might
> make more sense to use a lang type selector rather than
> an inline style just to be consistent. That's the sort of thing
> language selectors are for, right?

The section on vertical text has disappeared from the draft for a
major overhaul.

But referring to the previous version: I'm not sure you can use a
language selector. What language would you put on the "1996"? I
probably would use CLASS="year" or something.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 22 September 1999 14:34:04 UTC