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

RE: [css3-text] 'text-transform' for Accents

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Fri, 18 Mar 2011 02:56:30 -0400
To: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org list" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AB2BFBD40@MAILR001.mail.lan>
Christoph, thank you for the reply.

> > First, I don't see benefits of splitting the property to multiple properties. Do you see any
> benefits for authors and/or implementers?
> The usual benefit is separate cascading, but I'm not sure it's relevant here. Glyph width
> mostly concerns sinograms and casing is most useful for "euroscript", so they will hardly
> ever be used together.

I would suggest to keep them as a single property for now, and if authors want separate cascading, we could separate it in future and make text-transform as a shorthand.

> > "capitalize" is "titlecase" in CSS1 terminology,
> I suggested in the latest 'capitalize' thread to make it the dumb, language-agnostic, useless
> version, whereas 'titlecase' would, perhaps in Level 4, support language-specific behavior
> and only fall back to 'capitalize'.

Let's see people's interests when we do Level 4. I'm a little suspicious though, as it requires huge amount of work and you still can't do it right. If it's high enough and we've got rules by then, CSS can utilize it.

> > Again, I can't find any good use cases that are important enough for implementers to
> implement. Do you have any good use cases?
> Well, 'unicase' will probably be implemented anyway, but as a 'font-variant' sub-value,
> because of Open Type 'unic'. I just believe that the interdependence of 'font-variant' and
> 'text-transform' should be carefully designed, i.e. more with authors in mind, less font
> technology.

Fonts technology and code point transformation is two different animals. You may be right that some may think the two has somewhat similar effects, but I don't think there's a good way to merge them.

> The other values 'mixedcase' and 'camelcase' have hardly any valid usecases, they would
> only be included for a greater degree of completeness - or for humor.

I don't think it's a good idea to add features for such purposes. Adding features costs everyone, and completeness would not justify the cost.

> > Third about width. What text-transform does is code point transformation and it doesn't
> deal with font properties. "fixed" and "proportional" are the font properties, so they should
> be done in CSS3 Fonts. "fullwidth" is Unicode code point transformation, so we have that
> here.
> For an author it doesn't matter much whether different glyphs or different characters are
> used to achieve the same desired visual result. Therefore those properties should be
> unified or closely connected, with code point transformation being the fallback for
> unavailable glyph switching.

The two result very different visuals. It sounds to me like the difference between Courier and Arial is similar to the difference between uppercase and lowercase. I think the two should be separated for authors.

> > Last, accents. What are they used for? Do you have use cases?
> In some orthographies diacritic marks are mandatory on lowercase letters, but (more or
> less) optional on uppercase letters. This, as far as I know, has mostly technical reasons:
> 1. (most) accents on lowercase letters, especially roman vowels, fit easily above the base
> glyph and below the capital height, e.g. on typewriters and in metal type sorts and 2. some
> typewriter and computer keyboard layouts, e.g. the Swiss one (French and German), only
> feature the lowercase accented letters and the uppercase only with dead keys or not at
> all.
> Although no linguistic harm is done when accents remain on uppercasing, some people
> nowadays are accustomed to not seeing capitals with diacritics, for instance almost all
> German place names starting with an umlaut are written with uppercase vowel (base)
> followed by lowercase 'e' and I hear in non-France French accents on capitals are basically
> always omitted, but Unicode defines the case pair with accents of course.
> > Also, as you can see in the current spec, text-transform relies on Unicode for the logic
> to transform, and I can't find what you wrote in Unicode spec. Will you please tell me if and
> where they're defined in Unicode?
> I haven't looked for it there yet, but I think it's basically NFD (or NFKD?) with everything
> from U+0300-036F, U+1DC0-1DFF and perhaps U+20D0-20FF as well as some other
> script-specific combining accents removed. (Combining diacritics probably have a special
> tag, too, but I can never remember those.)
> > If not, I'd prefer to see it defined in Unicode first, and then CSS refers the logic. Is this
> reasonable?
> I'm not sure the Unicode consortium considers this to be in their scope, but if they would
> do (or have already done) it, that's just as fine with me.

I'm not sure if I understand it correctly, but it sounds like it can be better implemented in fonts if it were to fit glyphs into the capital height. That way, you can keep the original code points without increasing the line height.

Received on Friday, 18 March 2011 06:57:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC