W3C home > Mailing lists > Public > www-style@w3.org > September 2011

[css3-text] comments on text-transform

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 12 Sep 2011 18:25:01 -0700 (PDT)
To: W3C Style <www-style@w3.org>
Message-ID: <2137774331.10153.1315877101700.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
A few comments below on recent changes to the definition of
'text-transform' in CSS3 Text.  I think the description now is much
clearer than before but it still needs a few tweaks.

1. Value renamings

>From the list of recent spec changes:

> Renamed ‘fullwidth’ and ‘fullsize-kana’ to ‘full-width’ and
> ‘full-size-kana’ to match values in ‘font-variant-width’. [CSS3FONT]

I don't agree with this, these are different types of transformations
and we shouldn't conflate the two in the user's eyes. The
width-related values of 'font-variant-east-asian' (*not*
'font-variant-width'), are glyph-level transforms based on the data
contained in the font. OpenType has a whole slew of xxx-width features
and they denote a substitution from one glyph to another dependent on
the font.

The 'fullwidth' value of text-transform defines something different,
it defines a codepoint transformation of very specific and
well-defined codepoints (i.e. the fullwidth codepoints to their
halfwidth equivalents) and is in no way dependent on font data.  I
think it's better for the text-tranform property to match Unicode and
the font-variant-east-asian to match OpenType, since that's what the
respective properties are based on.

I think these two values should be renamed back to their previous
value names.

2. Clear indication that this property involves character transformation

Along the same lines as the previous comment, I think there needs to
be clear wording that defines text-transform as a character-level
transform, as opposed to a glyph level transform via OpenType.  This
assures implementors understand what these mappings are and helps
authors understand the consequences of these transform (e.g. line
breaking will be different with 'fullwidth').

Current spec wording:

> This property transforms text for styling purposes. Values have the
> following meanings: 

New wording:

> This property transforms text for styling purposes.  Text layout is
> done using the properties of the characters that result from this
> tranformation. Values have the following meanings: 

3. Case mapping rules

The description of the 'text-transform' property in the CSS3 Text spec
contains this paragraph:

  The case mapping rules for the character repertoire specified by the
  Unicode Standard can be found on the Unicode Consortium Web site
  [UNICODE]. The UA must use the full case mappings for Unicode
  characters, including any conditional casing rules, as defined in
  Default Case Algorithm section. If (and only if) the content
  language of the element is known, then any applicable
  language-specific rules must be used as well. (See SpecialCasing.txt)

What does 'if (and only if) the content language of the element is
known' imply?  The rules for inferring language are contained in the
HTML spec and I think all CSS specs should use that without
qualifications like this.

I would suggest the edit below.

Current spec wording:

> If (and only if) the content language of the element is known, then
> any applicable language-specific rules must be used as well. (See
> SpecialCasing.txt)

New wording: 

> User agents must also apply language specific casing rules as
> defined in Unicode (see SpecialCasing.txt).

The only addition here would be to allow for improvements beyond just
what's contained in SpecialCasing.txt, based on last week's resolution.

4. Drop 'full-size-kana' and remove Appendix F

While this transformation might be useful to some, without a strong
general use case I think we shouldn't have very special use case
values like this.  If it's really important, define it as a simple
mechanism that allows arbitrary text transforms:

Example:

@text-transform vowelcaps {
  from: "aeiou";
  to:   "AEIOU";
}

h4.articleheader { text-transform: custom(vowelcaps); }

Cheers, 

John
Received on Tuesday, 13 September 2011 01:25:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:44 GMT