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

[CSS2.1] Text

From: fantasai <fantasai@escape.com>
Date: Wed, 05 Nov 2003 02:37:03 -0500
Message-ID: <3FA8A89F.50002@escape.com>
To: www-style@w3.org

16.3 Text Decoration

> When specified on an inline element, it affects all the boxes
> generated by that element, otherwise, the decorations are
> propagated to the anonymous inline box that wraps all the
> inline contents of the element, using the element's color. It
> is not, however, further propagated to floating and absolutely
> positioned descendants, nor to the contents of 'inline-table'
> and 'inline-block' descendants. Nor is it propagated to
> block-level descendants of inline elements.

This text here is not very tight.
What happens with
   <div style="text-decoration: underline">
   <table style="text-decoration: underline">

There is no "anonymous inline box that wraps all the inline
contents of the element".

> If an element contains no text (ignoring white space in elements
> that have 'white-space' set to 'normal', 'pre-line', or 'no-wrap'),
> user agents must refrain from rendering text decorations on the element.

This seems to say the span element in
   text<span> </span>text
will not be underlined.
Is that what you meant?
In any case, the parenthetical remark is confusing. Change the sentence

# Text decorations on inline boxes are drawn across the entire element,
# going across any descendant elements without paying any attention to
# their presence.

You /have/ to pay attention to their presence: they take up space.
Without "adjusting" for the elements, perhaps?

# This was arguably allowed by the looser wording in CSS2. SVG1,
# CSS1-only, and CSS2-only user agents may implement the older model
# and still claim conformance to this part of CSS2.1. (This does not
# apply to UAs developed after this specification was released.)

Does this exception apply to new releases of older UAs?

# the decorations are propagated to the anonymous inline box that
# wraps all the inline contents of the element,

This anonymous inline box needs to be explained in section 9.2.2

# Help, help!
# I am under a hat!
# -- GwieF

I recommend either getting rid of the <span> or putting some text
outside it.

I suggest making the anonymous inline line gray.

16.4 Letter and Word Spacing

I've noticed that the wording hasn't been changed to use
'grapheme clusters'.

 From http://lists.w3.org/Archives/Public/www-style/2003Apr/0202.html :
> It's not clear how this would be handled:
>   span {letter-spacing: 2px}
>   word<span>spaced out</span> word2
> Is spacing be applied before the 's' or after the 't'?
> If the text broke across two lines, would letter-spacing be applied
> at the start of the second line? The end of the first?
> Also, you should specify whether letter spacing applies to spaces or not.
> (I think it should for the reasons outlined in
>    http://bugzilla.mozilla.org/show_bug.cgi?id=1046#c21 )

Where is word-spacing applied? At every space character? At zero-width-spaces?

 From http://lists.w3.org/Archives/Public/www-style/2002Aug/0332.html
> If I wrote
>   <pre>two  spaces</pre>
> how would word-spacing and letter-spacing affect the gap between
> 'two' and 'spaces'?


There was a mention of titlecase earlier...

16.6.1 The Whitespace Processing Model

# Any text that is directly contained inside a block (not inside an inline)
# should be treated as an anonymous inline element.

  -> should be in an anonymous inline element.

# If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces
# (U+0020) unbroken by an element boundary is treated as a sequence of
# non-breaking spaces. However, a line breaking opportunity exists at the
# end of the sequence.

If 'white-space'is set to 'pre' or 'pre-wrap', any sequence of spaces
(U+0020) is treated as a sequence of non-breaking spaces. However, if
'white-space' is set to 'pre-wrap', a line breaking opportunity exists at
every element boundary within the sequence and also at the end of the

# even a space before the inline, if that space also has...
  -> outside the inline

16.6.2 Bidirectionality with Whitespace Collapsing

# This is best avoided by using the natural bidirectionality of characters
# instead of explicit embedding levels.

It's not always possible to rely on implicit bidi, which is why we *have*
embedding levels. You shouldn't discourage their use like this. The problem
is best avoided by keeping start and end tags close to the text: by not
putting spaces at the start and end of inline elements.

Received on Wednesday, 5 November 2003 02:37:08 UTC

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