W3C home > Mailing lists > Public > www-style@w3.org > May 2003

CSS3 Text: Text-wrap and White-space control

From: fantasai <fantasai@escape.com>
Date: Sun, 04 May 2003 01:27:18 -0400
Message-ID: <3EB4A4B6.6030507@escape.com>
To: www-style@w3.org

CSS3 Text, Section 7
http://www.w3.org/TR/2003/WD-css3-text-20030226/#text-wrapping

Emergency Wrap
--------------

   # emergency
   #   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 box,
   #   independently of 'line-break', 'word-break-cjk' and
   #   'word-break-inside' properties. For example, this
   #   addresses the situation of very long words constrained
   #   in a fixed-width container with no scrolling allowed.

   Brought this up back in November: it's not really clear when
   wrapping is allowed. So, please

   Define the conditions for resorting to the "last resort".

Form Feeds
----------

   # Note: [HTML401] also defines the form feed character
   # (U+000C) as a white space character, but that character
   # is not part of any XHTML versions as they are all based
   # on XML.

   This seems like random trivia. Are you trying to say that
   form feeds in HTML documents are or are not considered
   whitespace by CSS?

Paragraph Separator
-------------------

   # If the characters U+2028 and U+2029 appears in text,
   # they are treated as zero-width characters without
   # semantic meaning.

   Are they treated as zero width space characters (U+200B)
   or ignored completely?

Styling Collapsed Spaces
------------------------

   # When white-space characters are collapsed for
   # rendering purpose, the text decoration style
   # applied to the collapsed set is the one that
   # would be applied to the first white-space
   # character of the original sequence.

   This isn't necessary, as it's implicit in the white space
   collapsing rules. (Spaces after a space get discarded, so
   only the first space remains.) If you wanted to put such
   a sentence in, it would need to include background, and
   border, and font size, and all sorts of other styles.

Line Feed Conversion Algorithm
------------------------------

   The algorithm is not very clear.
   It says
     1. If word separator == space,
           linefeed -> space
     2. If script == ideographic && word separator == none,
           linefeed -> nothing
     3. If script != ideographic && word separator == none,
           linefeed -> zwsp ? nothing //but we don't know which one
     4. Else, linefeed -> space         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

   # Characters of COMMON script (such as punctuation)
   # are treated as the same as the script on the
   # other side:

   Other side of what -- itself or the line break? E.g.
   if I have

   ENGLISH:
   CHINESE

   Does the dash resolve to Latin or Han?

   # If none of the conditions in (1) through (3) are
   # true, the line feed character should be converted
   # into a space character (U+0020).

   Should a line break between Thai and Chinese result
   in a space or a zero-width character?


   What happens if the linefeed is immediately preceded by
   the Ethiopic wordspace? If the script is Ethiopic but
   there is no Ethiopic wordspace?

   See http://www.abyssiniacybergateway.net/fidel/l10n/
   and http://www.unicode.org/book/ch11.pdf


white-space-treatment
---------------------

   # White space characters, when rendered as an advance
   # width, use the width of the empty glyph normally
   # used for the space character (U+0020).

   What's this mean? Do tabs get rendered as an advance
   width the width of a space, too?

   # ignore
   #    White space characters, except for line feed
   #    characters, are ignored. They are removed and are
   #    not rendered.

   Is there still a line breaking opportunity at the point
   where the space used to be? (Same question applies to
   linefeed-treatment)

all-space-treatment
-------------------

   # preserve
   #   All white space characters are rendered as they are. The
   #   rendering of tab characters (U+0009) is described in the
   #   white-space processing section.

   The first sentence is vague and seems to conflict with the
   rest of the section. Does "as they are" mean as they are before
   or after processing?

   Let's just write
     Consecutive white space characters do not collapse.
   and leave it at that.

~fantasai
Received on Sunday, 4 May 2003 09:26:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:21 GMT