WD-CSS21-20020802 section 16, "Text", substantive comments

Following are substantive comments on section 16, "Text"
(<http://www.w3.org/TR/2002/WD-CSS21-20020802/text.html>), of the Cascading
Style Sheets level 2.1 draft
(<http://www.w3.org/TR/2002/WD-CSS21-20020802>).



16.1 Indentation: the 'text-indent' property


"User agents should render this indentation as blank space."

Some people will misread this as prohibiting backgrounds within the
indentation area.  Change to "User agents must not render the element's
text or replaced content in the indentation area."



16.2 Alignment: the 'text-align' property


There should be a new value, 'auto', which computes to 'left' when the
'direction' property is 'LTR' and computes to 'right' when the 'direction'
property is 'RTL'.  Once 'auto' is added as a possibility, it should also
be the initial value.  The 'auto' value amounts to naming the currently
implemented behavior, so achieving interoperable implementations by the end
of the Candidate Recommendation phase seems quite feasible.


"Note. The actual justification algorithm used is user-agent and written
language dependent."

There should be a mention of script, yes?


"<string>
Specifies a string on which cells in a table column will align"

Has this acquired any implementations?  (If not, is the Working Group
seriously expecting to have two or more interoperable implementations by
the end of the Candidate Recommendation phase?)


"In this example, note that since 'text-align' is inherited, all
block-level elements inside the DIV element with 'class=center' will have
their inline content centered.

div.center { text-align: center }"

The example encourages use of presentation-based class names, which is poor
practice.  I suggest the class name "important".



16.3.1 Underlining, overlining, striking, and blinking: the
'text-decoration' property 'text-decoration'


"If it is specified for (or affects) an inline-level element, it affects
all boxes generated by the element."

If a child of an inline-level element generates a block-level element with
conflicting 'text-decoration', does the child still take the parent's
decoration?


"The color(s) required for the text decoration should be derived from the
'color' property value."

Change "should" to "must".


"This property is not inherited, but descendant boxes of a block box should
be formatted with the same decoration (e.g., they should all be
underlined)."

Change to "This property is not inherited, but inline-level boxes whose
closest block-level ancestor has text decoration must be formatted with the
same decoration (e.g., they should all be underlined)."


"In the following example for HTML, the text content of all A elements
acting as hyperlinks will be underlined:
a[href] { text-decoration: underline }"

The prose is inaccurate.  Change the prose to "In the following example for
HTML, the text content of all A elements acting as originating hyperlink
anchors will be underlined:".



16.4 Letter and word spacing: the 'letter-spacing' and 'word-spacing'
properties


Change "Letter" in the heading to "Grapheme cluster".


"This property specifies spacing behavior between text characters."

Change "text characters" to "grapheme clusters".  Add an explanatory
reference to Unicode Technical Report #29, "Text Boundaries".  Add "Because
the property controls spacing between grapheme clusters and not necessarily
or only between letters, the name 'letter-spacing' is a misnomer."


"This value indicates inter-character space in addition to the default
space between characters." ... "User agents may not further increase or
decrease the inter-character space in order to justify text."

Change to "This value indicates space between grapheme clusters in addition
to the default space between grapheme clusters." ... "User agents may not
further increase or decrease the space between grapheme clusters in order
to justify text."


"Character spacing algorithms are user agent-dependent.  Character spacing
may also be influenced by justification (see the 'text-align' property)."

Change "Algorithms for spacing between grapheme clusters depend on the user
agent. Justification, too, may influence spacing between grapheme clusters
(see the 'text-align' property).".


"In this example, the space between characters in BLOCKQUOTE elements is
increased by '0.1em'."

Change "characters" to "grapheme clusters".


"In the following example, the user agent is not permitted to alter
inter-character space"

Change "inter-character space" to "space between grapheme clusters"


"When the resultant space between two characters is not the same as the
default space"

Change "characters" to "grapheme clusters".


***

16.5 Capitalization: the 'text-transform' property

"capitalize
  Puts the first character of each word in uppercase.
uppercase
  Puts all characters of each word in uppercase.
lowercase
  Puts all characters of each word in lowercase."

Change to the following.

"capitalize
  Changes the first character of each word to its
  uppercase equivalent, if such an equivalent exists.
uppercase
  Changes each character of each word to its uppercase
  equivalent, if such an equivalent exists.
lowercase
  Changes each character of each word to its lowercase
  equivalent, if such an equivalent exists.


"Conforming user agents may consider the value of 'text-transform' to be
'none' for characters that are not from the Latin-1 repertoire and for
elements in languages for which the transformation is different from that
specified by the case-conversion tables of ISO 10646 ([ISO10646])."

Latin-1 wants a normative reference.  As an alternative to that, we can
change "are not from the Latin-1 repertoire" to "have a codepoint in ISO
10646 ([ISO10646]) higher than U+00FF".

I am unfamiliar with ISO 10646, but I had understood that ISO 10646
provides only character names and positions.  Does ISO 10646 really provide
case-conversion tables?



16.6 Whitespace: the 'white-space' property


For interoperability, we need a specification of what constitutes
whitespace in a document.  I see four possibilities:

  1. Define whitespace as a small set of characters,
     perhaps those counting as XML1.0 whitespace.
  2. Define whitespace as all characters in Unicode
     General Categories 'Zs', 'Zl', and 'Zp'.
  3. Define a minimal set of whitespace characters
     and let the document language define zero or
     more additional whitespace characters.
  4. Let the document language define whitespace.

I favor defining whitespace as all characters in Unicode General Categories
'Zs', 'Zl', and 'Zp'.

Received on Thursday, 14 November 2002 07:13:04 UTC