- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 12 Nov 2009 15:20:05 -0800
- To: www-style@w3.org
font-variant and font feature support in CSS
--------------------------------------------
jdaggett proposes adding subproperties to font-variant for allowing
access to the more common OpenType features. font-variant would
become a shorthand for font-variant-{ligatures,alternates,caps,numeric,position}
There some concern about fallback behavior for subscript and superscript features,
and winding up with either a complete loss of semantics or a double-sub/superscript
rendering.
John notes that OpenType has language-sensitive rendering, and proposes allowing
an explicit choice of typographic language different from the content language.
There's concern about exposing alternate glyphs from a generic mechanism such as
font-variant, because the choices are very font-specific. Proposals include
dealing with it in @font-face; and pairing the glyph set number with the font
name so that it only triggers on that font name.
Otherwise the WG is mostly in agreement and pressures jdaggett into putting his
proposal in the editor's draft. :)
<jdaggett> original proposal: http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
<jdaggett> demo page: http://people.mozilla.org/~jdaggett/webfonts/features.html
<jdaggett> experimental build: http://people.mozilla.org/~jkew/ot-feature-build
====== Full minutes below ======
<RRSAgent> http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
Font Feature Support in CSS
---------------------------
<Zakim> +Håkon Wium Lie (Opera)
<Zakim> +Jonathan Kews (Mozilla)
ScribeNick: dbaron
<jdaggett> next discussion is font feature support in css
<jdaggett> original proposal: http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
<jfkthame> so i'm hearing occasional bursts of sound on the phone,
but lots of silence..... if you're discussing anything,
i can't tell
<jdaggett> demo page: http://people.mozilla.org/~jdaggett/webfonts/features.html
<jdaggett> experimental build: http://people.mozilla.org/~jkew/ot-feature-build
jdaggett: Font feature support in CSS.
jdaggett: Many opentype fonts have additional glyph sets in the font.
<howcome> www.princexml.com also supports font features
jdaggett: They have variations to support various types of ways of
rendering text.
jdaggett: I'll show demos using an experimental build of Firefox.
jdaggett: Demo of 'font-variant: small-caps' with shrunk capitals
vs. small cap glyphs in the font.
jdaggett: Second demo with "MEgalopolis Extra" font: alternate glyphs,
discretionary ligatures, alternates and ligatures.
(Q about whether selection works; demo)
jdaggett: third demo: contextual substitution of opentype fractions
jdaggett: fourth demo, Coluna font, old style figures by default
(numbers have descenders), but options for lining (no descenders),
tabular (all digits same width), lining+tabular
jdaggett: Some proposed extensions to font-variant; URL above ("original
proposal")
jdaggett: font-variant would become a shorthand for
font-variant-{ligatures,alternates,caps,numeric,position}
<jdaggett> http://people.mozilla.org/~jkew/ot-feature-build
jdaggett: In WPF, Microsoft has implemented ...
<jdaggett> http://msdn.microsoft.com/en-us/library/ms745109.aspx
jdaggett's slide shows font-variant-
ligatures: common, additional, historical, ...
alternates: normal, contextual, styleset #, swash #
caps: normal, smal-caps, pettie-caps, titling-caps
numeric: normal, lining, oldstyle, tabular, proportional, fractions, ...
position: normal, subscript, superscript, ruby, ...
fantasai: what happens if the font doesn't have a subscript variant?
jdaggett: you get the regular glyph
jdaggett: also ones for CJK alternates, need to do more research about them
to figure out what's needed
jdaggett: you could argue that some of these shouldn't be here ...
dsinger: If the font doesn't have subscript, I'll get inline figures which
changes the semantics
jdaggett: This is just saying "give me that glyph", not "change the baseline"
dbaron: Is it that the fonts have different glyphs for "when used as
a subscript"?
dbaron: And you'll still get subscript size/positioning if they don't have
that?
ChrisL & dsinger: bad failure modes are getting double-subscript or none
at all
jfkthame: If the semantics are important, people should be using sup/sub
elements
jfkthame: The opentype features of superiors or inferiors aren't really
a first-class replacement for that.
jfkthame: If you request the feature and the font doesn't support it,
you'll get no change.
jfkthame: Intended more for footnote numbers, numeral suffixes
fantasai: But if we have this feature people will use it for semantic
subscripts (e.g. by assigning styles to <sub>)
fantasai: And then for somebody else who doesn't have the font, the
user won't see the superscript/subscript.
<fantasai> because the currently faking it is ugly
jdaggett: I'll note this as an issue and look into it.
jdaggett: small-caps has issue being existing value
alexmog: I want all my subscripts to do the typographically correct thing,
but I never want the effects to multiply.
SteveZ: small-caps has two effects ...
SteveZ: some of these are mutually exclusive
jdaggett: yes, the proposal goes into that in detail
(shows 0506.html)
jdaggett: Shows old-style numerals vs. lining numerals
jdaggett: Demo: swash characters in Garamond Premier Pro
jdaggett: ... and additional ligatures
jdaggett: Opentype has language-sensitive rendering. Demo for Macedonian.
alexmog: yes, that looks more Macedonian.
jdaggett: important not to ligaturize fi in Turkish so that dotted and
dotless i can be distinguished
jdaggett: Demo: Also small-caps distinctions for Turkish.
jdaggett: example of lots of features at once
tantek: That also looks like copyfitting.
jdaggett: OpenType has the ability to specify a script and a language.
jdaggett: But it's not precisely a language, it's a language system.
<tantek> would be great to get a URL to the "lots of features at once" example
jdaggett: But you can display Greek in the French way of displaying Greek.
jdaggett: So one might want a way of choosing the typographic language
separately from the language.
fantasai: As long as the default is 'auto' and that uses the markup language.
(Turkish demo was using 'calluna' font.)
jdaggett: Style sets get kind of hairy, having the number.
<TabAtkins> http://people.mozilla.org/~jdaggett/webfonts/features.html,
page to the end
jdaggett: This is the argument we've been having on the list... what
happens in the fallback case.
jdaggett: You're not going to get unreadable text, you just won't get
what the author hoped for.
jdaggett: Or you could say some of these apply only to the first font
in the list.
<tantek> TabAtkins - interesting, in an old nightly of Webkit - the
text is *not* copyfit - so this tells me that the OpenType
features may be making use of some copyfitting feature somewhere?
ChrisL: That could have issues if you're using a font list to get good
Latin from one font plus good Japanese from the second font,
you might want properties for the Japanese font.
jdaggett: Doing something fancy... but that has the problem of an author
having trouble figuring out what happened.
<tantek> TabAtkins - n.m. just viewed source - each line's font-size is
set explicitly.
fantasai: Leave swash in as a keyword, so you can just get the first one.
<tantek> for reference: http://people.mozilla.org/~jdaggett/webfonts/features.html#page%2014
<TabAtkins> tantek: Yah, just wait a bit and we'll hit the copyfitting
issue. ^_^
* tantek didn't know that you could put a " " (space) in an id attribute
and have it "work"
jdaggett: We could add a font-variant descriptor for @font-face that
would only apply the features to that specific face.
jdaggett: I like the idea of allowing that, but I don't like the idea of
requiring it.
howcome: There's pain to dealing with several @font-faces, but it's a
neat way of achieving what we want.
<Bert_lap> -> http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.html
The multi-feature, justified example with MEgalopolis from the slides
<TabAtkins> In the font-variant-* properties, use a functional notation
to target it at specific fonts.
howcome: I'm tempted to go down the @font-face route, even if it's a
little inconvenient sometimes.
jdaggett: I think it's impractical because you'd have so many permutations
that it's impractical to use @font-face rules
<TabAtkins> font-variant-ligatures: font-face("foo",lig 1), lig 2
<TabAtkins> ^^^ Would activate lig2 on all fonts, but lig1 only on "foo" font.
fantasai: I'm saying a property is fine for most of these, but require
it in @font-face for alternate glyphs, whose values are very
specific to individual fonts.
SteveZ: In that list, there are only 2 things taking numeric values:
style sets and alternates. Treating those two differently
from all the others makes perfect sense.
SteveZ: And, secondly, those are the two places where things are much
more font-specific.
SteveZ: So I would argue that I'd introduce a property: one for style
sets and one for alternates, where the property would take...
SteveZ: ... a font and a style set number that goes with that font.
SteveZ: So you'd match which element in the list corresponded to the
font actually chosen.
howcome: You're proposing two new properties with comma-separated values?
SteveZ: yes
TabAtkins: font-variant-ligatures: font-face("foo",lig 1), lig 2
jdaggett: Originally I had a functional syntax, but people said we don't
really have that. I think a functional syntax would work just
as well.
dsinger: It seems like you'd only have an explosion of @font-face rules
if you have an explosion of styles on the page, which often
isn't a good thing.
jdaggett: @font-face is just defining one face of a family: So you'd
then have to define all these variations across all faces of
the family.
SteveZ: If I want to write a description of 18th century typography in
English... historical ligatures, historical letterforms...
which I only want to use in examples.
dsinger: You're probably using a different font for the 18th century text.
dsinger: The features would be consistently off in the modern text and
on in the 18th c. text.
SteveZ: It's perfectly reasonable that I'm using an 18th c. font for
my body text.
fantasai: It doesn't matter how many features you're turning on and off.
SteveZ: Each paragraph would have different features on it.
SteveZ: Because I'm writing about typography
fantasai: That's a very special edge case.
dbaron: Writing about typography is an edge case.
dsinger: If you're actually showing lots of faces, that's not a failure
of CSS.
jdaggett: That's against the way CSS works, because you're forcing
everything into @font-face rules, and people don't have the
ability to change specific properties.
jdaggett: You've eliminated inheritance.
dsinger: But then you're asking for a feature in a font that you might
not be using.
...
dsinger: I don't mind changing what it looks like, but I mind changing
the meaning.
jdaggett: It's not undermining fallback, it's still an "a".
jdaggett: 3 options, let substitution occur, (2) apply only to first font
(3) put feature variants into @font-face, (4) Steve's property
that takes family name
fantasai: Issue of mixing Latin font with Chinese font and choosing
alternatives in both.
jdaggett: I like the idea of allowing features to be set in @font-face,
but I don't like it being the only mechanism.
howcome: You could combine (2) and (3).
jdaggett: The complication that these are all shorthands: set all other
values to default.
SteveZ: My proposing allows a list that includes fonts that aren't being
used... reduces that problem.
<ChrisL> szilles proposal does not suffer from that
howcome: There's basically a scripting language underlying that... similar
to text-replace.
<glazou> text-replace lalala lalala :-)
jdaggett: But that's all *inside* the font.
howcome: But you can turn those features in the font on and off using
this mechanism.
Steve: Fonts gave you that problem, even without variants.
ChrisL: That's how people used to do Greek in Web pages.
<Bert_lap> (People in India are still doing this, using fonts with Indic
glyphs in ASCII slots...)
jdaggett: I think that's all I have... I just wanted to present this.
jdaggett: I think there's more that needs to be hashed out.
ChrisL: You were demoing with a special build.
jdaggett: Yes, that build just has a single property demo hack to turn
off opentype features by name.
SteveZ: I'd like some action to come out of this discussion. (1) Do
people think that John is on the right track?
ChrisL, fantasai: yes
<ChrisL> I'd like to see this put into the spec
Bert: I'm happy to see more attention to typographic features; I've always
wanted tabular figures; but I'm wondering why suddenly this attention
for putting every opentype feature into CSS when we still don't have
hyphenation and leaders.
jdaggett: We're not talking about every opentype feature; a fair number
have been omitted. We're taking some features that are more
abstract. Also not, e.g., not exposing multiple ways of doing
fractions.
fantasai: hyphenation's also hard because of need for dictionary
jdaggett: Hyphenation is a somewhat tricky problem: language-based, and
all sorts of typographic rules for hyphenation.
ChrisL: These are orthogonal features.
howcome: We have hyphenation specced out.
Bert: Prince now has the whole-paragraph justification from TeX, but Mozilla
will have swash characters but still won't do justification right.
Bert: Things like proper justification and hyphens have a much bigger effect.
dbaron: those are layout features, adding to an area of CSS that's already
very complicated.
fantasai: font features are better encapsulated
jdaggett: And having @font-face gives us the opportunity to do more with
fonts now.
SteveZ: The other thing I'd want is getting a clear statement of how
things like subscripts and small-caps interact with existing
facilities: so that (a) we don't get semantic changes and (b) ...
dsinger: yep
jdaggett: font-variant is part of the 'font' shorthand; we don't want
any of this new stuff in the 'font' shorthand
howcome: John, if we have a property that holds the features, do you
see that as inherited independent of font-family?
jdaggett: Yes. It makes sense for many things, e.g., tabular figures.
howcome: Should a randomly-named feature inherit?
jdaggett: I don't even have a plan for including enabling/disabling
arbitrary features.
jdaggett: I'm not keen on writing a spec for that, at least initially.
howcome: When I said I wanted to go down the @font-face route, I meant
that only for arbitrary features, not for features that we
standardize.
howcome: For the features we standardize, I think we should absolutely
have properties that work the normal way.
SteveZ: So it sounds like we're mostly in agreement.
ChrisL: So we can start moving this stuff into the spec?
jdaggett: I still don't have a sense of the alternates...
ChrisL: I think it's time to start moving it into a spec now.
fantasai: I agree with that.
ChrisL: exposes it to more people, get wider review
jdaggett: Still not confident of ...
dbaron: Put big red issues in the spec so people know.
fantasai: That's why we have class="issue" :)
<ChrisL> Don't let that put you off. Lets get it into the spec
Received on Thursday, 12 November 2009 23:20:50 UTC