- From: John Daggett <jdaggett@mozilla.com>
- Date: Mon, 12 Sep 2011 18:25:01 -0700 (PDT)
- To: W3C Style <www-style@w3.org>
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 UTC