W3C home > Mailing lists > Public > www-style@w3.org > November 2009

[CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: font-variant and font feature support

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 12 Nov 2009 15:20:05 -0800
Message-ID: <4AFC9825.5060902@inkedblade.net>
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 GMT

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