W3C home > Mailing lists > Public > www-style@w3.org > October 2002

Re: Last call WDs: css3-text, css3-ruby

From: Mark Davis <mark.davis@jtcsv.com>
Date: Fri, 25 Oct 2002 11:09:40 -0400 (EDT)
Message-ID: <005101c27c38$529b7dd0$7300a8c0@DAVIS1>
To: "Bert Bos" <bert@w3.org>, <www-style@w3.org>
Cc: <w3c-i18n-ig@w3.org>

[sorry; had omitted www-style from the addresses]

A couple of quick comments on CCS3:

>"it is recommended that breaks between small katakana and hiragana
characters be allowed."

I believe the intent of this sentence is not "allow a break between a small
katakana and a subsequent small hiragana", but rather "allow a break between
any character and a subsequent small katakana or small hiragana". If so, it
needs to be reworded.

Words can be broken at an appropriate hyphenation point. It requires that
the user agent have an hyphenation dictionary for the language of the text
being broken. Setting this value activates the hyphenation engine in the
user agent. "

Intra-word breaks may or may not be indicated by a visible hyphen, depending
on the language. This paragraph should be rewritten to be a bit more
general. If the word "hyphenate" is retained, it should be stressed that
this does not imply the actual use of a visible hyphen glyph.

>"7.1. Text wrapping: the 'wrap-option' property"

This option is long awaited; finally, to be able to stop Internet Explorer
from breaking in the middle of "-3"!. That would be nice as an example: "The
answer is <span style="word-option: hard-wrap">-3</span>".

The text is wrapped at the best line-breaking opportunity (if required)
within the available block inline progression dimension (block width in
horizontal text flow). The best line-breaking opportunity is determined in
priority by the existence of preserved line-feed characters (U+000A), or by
the line-breaking algorithm controlled by the 'line-break' and word-break'
The text is only wrapped where explicitly specified by preserved line feed
characters (U+000A). In the case when lines are longer than the available
block width, the overflow will be treated in accordance with the 'overflow'
property specified in the element.
The text is wrapped exactly at the block width and where explicitly
specified by preserved line feed characters (U+000A). No line-breaking
algorithm is invoked.
The text is wrapped like for the 'wrap' case, except that the line-breaking
algorithm will allow as a last resort option a text wrap after the last
character which can fit before the ending-edge of the line, independently of
'line-break' and word-break' properties. For example, this deals with the
situation of very long words constrained in a fixed-width container with no
scrolling allowed. "

The exact meaning of all of these options and the differences between them
is not clear. Some examples would help. For example, strictly speaking it
appears that the interpretation of soft wrap is that it wraps text at a
position between two characters if and only if (a) that position is
precisely (to the pixel) at the block width, AND (b) that position is after?
(before?) a preserved linefeed character.

I really doubt, however, that this is what is meant, since such an option
would be pretty useless. The language for all of them needs to be clarified.

>"Note: The Unicode Standard [UNICODE] recommends that the zero width space
is considered a valid line-break point and that if two characters with a
zero width space in "

Should be: "The Unicode Standard [UNICODE] specifies...", since the standard
does define the semantics of the character.

And URI can replace any of the string value and set an image to be used as
the hint indication. Being specified is equivalent to a non empty string for
the respective ellipsis. "

I think this was intended to be "Any". Secondly, it would appear to be quite
useful if a graphic could be used for the ellipsis-end or elipsis-after; one
does see that, especially in certain European magazines.

>"When the resultant space between two characters is not the same as the
default space, user agents should not use ligatures. "

I disagree with this. You don't want to necessarily break ligatures; it
depends on what the delta value is, and the language. You still may want to
use a ligature, but perhaps a different form. Consider Arabic ligatures, for
example. The wording should be something like: "When the resultant space
between two characters is not the same as the default space, user agents
should consider avoiding the use of ligatures."

►  “Eppur si muove” ◄

----- Original Message -----
From: "Bert Bos" <bert@w3.org>
To: <w3c-i18n-ig@w3.org>
Sent: Friday, October 25, 2002 06:29
Subject: Last call WDs: css3-text, css3-ruby

> The CSS WG published two last call drafts of CSS3 modules: "Text" and
> "Ruby." (The third expected draft, "Line," is delayed by a week or
> two.) It would be nice if the I18N group could review them, especially
> since they contain quite a bit of non-western typography, for which,
> we hope, the I18N group has some expertise.
> The deadline for comments is set to 27 November, but let us know if
> you need more time. The preferred place for comments is the public
> mailing list www-style@w3.org.
> Here are the abstracts:
> css3-ruby
>     "CSS3 module: Ruby"
>     http://www.w3.org/TR/2002/WD-css3-ruby-20021024
>     This document proposes a set of CSS properties associated with the
>     'Ruby' elements.
> css3-text
>     "CSS3 module: text"
>     http://www.w3.org/TR/2002/WD-css3-text-20021024
>     This document presents a set of text formatting properties for
>     CSS3. Many of these properties already existed in CSS 2. Many of
>     the new properties have been added to address basic requirements
>     in international text layout, particularly for East Asian and
>     bidirectional text.
> Bert
> (for the CSS WG)
> --
>   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 Friday, 25 October 2002 11:33:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:04 UTC