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

Re: [css3-fonts] Please add font-variant-caps: all-small-caps and all-petite-caps

From: Adam Twardoch (List) <list.adam@twardoch.com>
Date: Mon, 22 Mar 2010 09:17:49 +0100
Message-ID: <4BA727AD.3010205@twardoch.com>
To: www-style <www-style@w3.org>
CC: John Daggett <jdaggett@mozilla.com>

On 10-03-01 09:54, John Daggett wrote:
>> For example, the small-cap variants of certain uppercase Greek letters
>> may be different than the small-cap variants of their lowercase
>> counterparts.
Forget it, this is not a good example :)

>> The transformation would also not work for certain
>> Unicode characters that do not have a lowercase variant (e.g. U+1E9E:
>> ẞ). 
> What would a font show for this character with 'c2sc' applied?  The small-caps
> version of 'ss'?
No, a small-cap version of ẞ.

The lowercase form of ẞ is ß, and the uppercase form of ß is SS, because
that's the official German spelling rule. The uppercase ẞ letter has
been added to Unicode for purposes where the user explicitly wants to
use such form, ignoring the official German spelling rule. When ẞ is
lowercased, the font may apply the official German spelling rule and
produce a smallcap version of SS, but when a smallcap of ẞ is produced
directly, a specially-designed smallcap ẞ glyph can be used.

There are more cases like that: Imagine a web page encoded using the
MUFI Private Use Area codes, or other PUA conventions. The web browser
will not know how to apply the casing transformation to produce
lowercase variants, since to the web browser, the PUA codepoints are
"caseless". But a properly-made font will "know" which "uppercase"
glyphs assigned to the PUA codes should be replaced with smallcap
glyphs. This is also important for minority scripts and characters that
will continue to use PUA because they'll never get encoded in Unicode --
yet a properly developed font can include appropriate smallcap variants
that work on the glyph level. In medievalist, liguistic and
minority-language environments, that often rely on special encodings and
special fonts, text-transform: lower-case will not work reliably.

And what if new characters are added to Unicode? A font may include
smallcap rules for those characters, but the internal case-mapping in
browsers may not be updated for a while.

Also, the OpenType specification, and therefore OpenType font
developers, rely on the fact that the smalcapping mechanism is done
through a combination of "smcp" and "c2sc". Some fonts can have "smcp"
lookups and then "c2sc" lookups that rely on the preceding "smcp"
lookups, so an intended result is produced when both features are applied.

If the author wants to use the "text-transform: lower-case;
font-variant: small-caps" combo, they she or he is free to do so. But
this does not have to lead to the same results as "font-variant:
all-small-caps". Also, I think the text-transform: lowercase;
font-variant: small-caps is a "trick" that is somewhat counter-intuitive
to many authors. Of course the author is free to use
font-feature-settings: "c2sc=1,smcp=1", but that again is also
counter-intuitive. The practice of typesetting entire lines in pure
small caps is very widely widespread.

> Why is this something that can only be done when 'smcp' is enabled?  Is
> this just because one can't assume that there are no uppercase forms
> (e.g. '(Apple)')?
The point is: if you mix smallcaps with uppercase (i.e. only "smcp" is
applied), the font developer may prefer to use the standard punctuation,
because of the interspersed uppercase glyphs. On the other hand, when
"all-small-caps" is applied (i.e. "c2sc" and "smcp"), then special
all-small-caps punctuation glyphs would be used, that would be defined
in the "c2sc" feature. Same applies for figures: for example, "smcp"
could leave the default lining figures in place, or replace them with
oldstyle figures, which work good in such context, but when "c2sc" is
also applied, that feature could replace the figures with small-sized
lining figures.

Needless to say, text-transform: lowercase is implemented in different
ways. When I make
<p style="text-transform: lowercase; font-variant: small-caps">Welcome
to the World!</p>
and then view the result in Firefox 3.6, and then copy-paste the text, I
get "Welcome to the World!" but if I view this in Safari 4.0.5, I get
"welcome to the world!".

The latter may or may not be what the user wants if only text-transform:
lowercase is applied -- it's a good question, though somewhat outside
this discussion, whether text-transform should affect the searchability
and clipboard interaction or not. But it's quite certain that it's not
what the user would expect when smallcaps are used.

And of course, in current browsers only the letters are reduced in size,
not of the exclamation sign. Whether the exclamation sign would be
replaced with a smallcap variant, depends on the font. Some fonts with
smallcaps may retain the normal exclamation sign, some fonts may replace
it with a smallcap version when "smcp" is applied, and some may do so
when "c2sc" is applied. It's up to the font developer and the
typographic context of the typeface what to do and when. But this means
that "all-small-caps" should be done "by the book", i.e. simply: through
applying c2sc+smcp. Not by some casing transformation tricks.

> Because of the way small-caps is defined in CSS 2.1, where resized
> uppercase glyphs are used to simulate small caps, we would probably need
> to define 'all-small-caps' with similar behavior.  But I'd prefer not to
> extend that behavior to petite caps, even though that will cause
> confusion for some authors.
I agree. Since petite caps are a rarely used feature, force-simulating
them would not be a reasonable choice.

Received on Monday, 22 March 2010 08:18:24 GMT

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