W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[CSSWG] Minutes Tokyo F2F 2013-06-06 Thu AM PM I: Fonts

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 22:55:49 -0700
Message-ID: <51D3BCE5.9000904@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Fonts
=====

   - Discussed font loading API
   - RESOLVED: We will use Promises in the font loading API
   - RESOLVED: We will not add Glenn's proposal of font-feature-settings: none
   - RESOLVED: If an element with text-decoration set and font-variant non-normal
               then we synthesize subs/sups, and then text-decoration follows
   - Deferring any extensions to current font-language-override feature to L4

====== Full minutes below ======

Font Load Events
----------------
Scribe: dino

   <stearns> http://dev.w3.org/csswg/css-font-load-events/
   <TabAtkins> http://dev.w3.org/csswg/css-font-load-events/#fontloader-interface
   jdaggett: there is a problem when loading @font-face. they are lazily
             loaded. if you never reference the font... no font would be
             loaded. The flip side is that because it was never loaded,
             you can't use it.
   e.g. canvas
   e.g. show a menu of available fonts
   - you don't know metrics, etc
   jdaggett: been an issue, many people want a solution.
   jdaggett: I sketched out a proposal for a FontLoader that hangs off document.
   jdaggett: gives a way to trigger some loads... just tell me when I'm done.
   jdaggett: most authors don't need to know specifics
   jdaggett: there is a more complex use case where they want to know exactly
             when every font is available
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html

   jdaggett: two handlers, and a bunch of methods
   jdaggett: loadFont ( font, text, successCallback, errorCallback )
   jdaggett: it's the same as the font property
   jdaggett: text is provided to help selection
   krit: ???
   krit: so font is a list of fonts?
   jdaggett: yes
   glenn: what are semantics of the text member of LoadFontParameters?
   jdaggett: you go through the characters to see if you need fonts.
   glenn: Please rename this parameter to something more descriptive.
   jdaggett: successcallback just tells you when things went ok
   [ignore that last line]
   jdaggett: explains checkFont and notifyWhenFontReady
   [ they were obvious so I didn't minute ]

   TabAtkins: [ explains futures ]
   TabAtkins: most of the API is "do something and tell me when it completes"
   TabAtkins: All of John's API is reproduced in my proposal.
   TabAtkins: e.g. - tell we when everything is ready to draw
   TabAtkins: ... is ready().. returns a Future
   TabAtkins: you then register callbacks on the Future...
   glenn: Is this the first place in the Web ecosystems that is using Futures?
   TabAtkins: No. e.g. JSON Linked Data.
   Rossen: How are they different from Promises?
   TabAtkins: The name has changed, but the same.
   TabAtkins: The new TAG likes Futures and will be pushing it.
   plinss: The TAG has consensus that this is a good approach.
   glenn: I object unless there is a concerted effort to convert to Future
          across the board.
   plinss: That is the plan.
   <SimonSapin> http://w3cmemes.tumblr.com/post/48887723979/does-your-api-use-futures-yet
   <ivan> (A blog of Tab on futures, for those (like me) who do not really
           know what those are: http://www.xanthir.com/b4PY0)

   jdaggett: Microsoft/Rossen and Apple/Dean, have you heard about Promises?
             Are you using them?
   Rossen: We shipped them already. They are the way you write apps in Win8.
   Dean: I have been paying no attention.
   plinss: There were two people from Mozilla that support this.
   jdaggett: Just concerned about time lag if we have to depend on the feature.
   Glenn: My concern too.
   TabAtkins: There is an answer that avoids time lag. Segment the API so that
              there is part of it that doesn't use Futures. Not as convenient.
   Dean: It's new features like this that will drive the use of futures, so I
         support it.
   TabAtkins describes how JD's proposal merges into his. Basically callbacks
     become futures.

   <dbaron> onloading is any transition from 0 fonts loading to 1 font loading
   <dbaron> onloadingdone is any transition from 1 font loading to 0 fonts loading
   jdaggett: in my proposal onloading is fired when a font starts loading.
             onloadingdone fires when all fonts are loaded.
   jdaggett: onloadstart fires on each font
   jdaggett: the difference is that if you want to know when fonts load you
             have to create a future for each of the fonts
   TabAtkins: you just want to be notified when fonts load
   dbaron: Tab, I think you've removed the low-level api that allows people
           to listen for each font load.
   TabAtkins: no...
   jdaggett: e.g. i have an app with a lot of fonts. I want to know when
             any font loads. I don't want to have to set up a future for
             each load.
   TabAtkins: that's a small use case. I suggest waiting for the all loaded
              event.
   TabAtkins: it takes a little longer.
   dbaron: that makes the basic api more complex
   TabAtkins: no, the basic API is just knowing when all fonts are loaded
   Krit: ???

   Liam: Does the spec handle the case when the font failed?
   <liam> [answer: yes, I don't have to wait until all fonts have loaded
           before finding that one failed]

   dbaron: in tab's proposal, what happens if one loads and one fails?
   TabAtkins: loading done will fire when they are both finished. The event
              will have info on which ones worked and which ones didn't.
   krit: ???
   jdaggett: it is weird to have a mix of futures and events
   TabAtkins: it's not too weird
   plinss: there is a promises-like thing for streaming situations
   krit: ???
   krit: is this API necessary?
   everyone: YES!!
   jdaggett: e.g. webkit does not include font loads in the "load" event
   TabAtkins: Google Docs slaps me every day about this.

   jdaggett: We have a direction.... I'm not completely comfortable, but
             that's just details.
   jdaggett: Issues - canvas web workers want fonts, but they have no DOM.
   jdaggett: e.g. pdf.js wants to do work on a different thread.
   jdaggett: But Fonts are tied to a document
   jdaggett: It seems that the group wants to go in the direction of Futures...
   glenn: Should we ask for a straw poll.
   Straw poll: 11 people want a futures-based API. 1 against (for the record,
               it was Glenn)
   RESOLVED: We will use Promises in the font loading API

font-feature-settings: none
---------------------------

   jdaggett: Next topic - Glenn wanted the ability to turn off all font settings.
             e.g. font-feature-settings: none.
   jdaggett: With Open Type, there are a set of features that are required
             (arabic ligatures), and there are some that are not required
             but are on by default.
   jdaggett: I don't see the need.
   glenn: It's a shorthand, so it isn't functionality. In the case where you
          don't know what features are present in the font, you can't necessarily
          enumerate all the ones you want turned off.
   glenn: Very useful for testing.
   glenn: You can already turn all these off. it's just a shorthand.
   glenn: If there was a way to enumerate the properties of a font... you could
          do that.
   fantasai: this is not a shorthand in the typical sense.
   Dean: "shortcut" not "shorthand"
   * fantasai agrees with Vladimir's response on www-style
     http://lists.w3.org/Archives/Public/www-style/2013Jun/0080.html

   Alan: Glen is saying if there was a way to enumerate all the available
         features, he might be able to avoid this.
   fantasai: just list them all
   glenn: there are some custom/private ones
   glazou: how can I know that ligatures are enabled?
   glenn: you can't
   jdaggett: you'd turn it off and on and see if there was a difference
   jdaggett: there is no computed value to check
   dbaron: this is a low-level control property
   jdaggett: I have had this situation as a developer. I don't know what is
             enabled. I have to iterate through and see what's there.
   glenn: My example is that I get a font from a customer with strange results.
          I don't have any way to know why.
   jdaggett: this is a pretty edge use case
   jdaggett: but it is a weapon of mass destruction too
   glenn: Not really. This is not new - you can already do it.
   Liam: is there a way to revert the font to its default behaviour
   [yes you can revert to default feature set
   font-feature-settings: normal; font-variant: none;

   glenn: But normal means different things for different fonts
   jdaggett: No.
   glenn: No. It does not mean turn on features.
   jdaggett: Propose to reject this feature request.
   glenn: I will implement it anyway
   plinss: yes, as long as it is prefixed

   Alan: I'd object to having this value; too much of a footgun.
   Alan: I reject to having this as an available feature.
   fantasai: me too
   RESOLVED: We will not add Glenn's proposal of font-feature-settings: none

Text Decoration on Superscripts/Subscripts
------------------------------------------

   jdaggett: [shows example of why text decoration on the baseline can
              cause problems in the synthetic case for superscripts and
              subscripts ]
   jdaggett: Suggestion: sup and sub metric don't work for text decoration
             placement. The way to handle this is similar to when all the
             variants are not in the font, if there are not variant sup or
             sub glyphs then synthesize. If there are any text decorations
             we should use the synth glyphs and adjust the decoration
   fantasai: I can live with that.
   dbaron: I think that is reasonable.
   dbaron: so just doing synthesis and then text decoration stuff will be
           whatever the text decoration spec says?
   jdaggett: shows an example from The Guardian with some superscript
   [which looks like shit]
   [the lines are not equally spaced]
   [looks much better with the variants available]
   <Bert> (That's why many authors nowadays set 'sup {line-height: 0}')
   <r12a> people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html
   <r12a> http://people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html

   Leif: on wikipedia has superscripts that are underlined on hover.
   jdaggett: they get the fallback
   Leif: is there a way to force synthesis?

   dbaron: it's only for sites that are using this new feature to do supsub
   jdaggett: However, if they are matched to the font, the text decorations
             are really hard to see. These variants are small.
   RESOLVED: If an element with text-decoration set and font-variant non-normal
             then we synthesize subs/sups, and then text-decoration follows

<br data-duration="900s">
Scribe: Leif

font-language-override
----------------------

   Issue: http://lists.w3.org/Archives/Public/www-style/2013May/0578.html
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0736.html

   jdaggett: OpenType has the ability to have language-specific features
   jdaggett: If a specific language has glyph variants that are more common
             (e. g. cyrillic), then based on the content language of the
             element, glyphs are automatically switched.
   jdaggett: there are cases where the semantic language may not be supported
             by the font
   jdaggett: e.g. Serbian and Macedonian uses the same traditions, so you want
             to say content language is Macedonian, but want to use a font
             that only supports Serbian
   jdaggett: an uncommon use case
   jdaggett: Some people unfortunately always want to set the low-level feature.
   jdaggett: They view the property as a way to set the low-level property.

   jdaggett: fantasai wants a fallback list instead of a single language
   jdaggett: But when you're specifying it, you know the font, so no need
             to specify
   fantasai: But if your font has Macedonian, you should be able to express
             that that is your first preference.
   jdaggett: You're asking for a different feature.
   jdaggett: You want fallback.
   fantasai: You may or may not get the font that you specify.
   jdaggett: The point is that when you know the font, you'll specify it.
   stearns: fantasai's use case is recognized, but sometimes you want an
            override instead of a fallback.
   r12a: I'm not sure fantasai is asking for a fallback, because a fallback
         should go back to the language asked for.

   jdaggett: This mechanism really is an override.
   jdaggett: As long as the font supports it, you can have multiple languages;
             by default uses the right glyphs from the same font.

   fantasai: The use case in the spec is if your font is missing support for
             your language, you want to use a fallback language.
   fantasai: Depending on which font you end up using, you'll want either
             the real language or the fallback language.
   fantasai: Another case is if you're typesetting in one language, and have
             e.g. a quote from another language. You want to mark up the
             languages correctly, but not change the typesetting style.

   jdaggett: This doesn't feel like a general-purpose feature. I'm worried
             about getting implementations.
   jdaggett: Might be at risk.

   jdaggett: To extend it, means a lot of work defining the fallback.
   fantasai: I see two UCs: Using a language close to your desired style,
             as described in the spec example
   fantasai: 2nd case: You want your text to have a consistent typographic style.
   fantasai: If you have a quote from another language, you don't want to
             suddenly change shapes.
   fantasai: Use style of surrounding paragraph. In that case, would make
             sense to have language override to use paragraph's language
             for that quote.

   glenn: We need to know what features and languages a font supports.
   glenn: Having a fallback seems unnecessary, knowing what the font has.
   fantasai: If font downloading is turned off, and you're using a system font,
             e.g. on a ebook reader, I don't want the font-language-override
             to tell me to use a fallback language if the font actually used
             has the *desired* language.
   jdaggett: The fonts on your system are not going to be that sophisticated.
   fantasai: How do you know?
   jdaggett: I see your points, but I don't think there's a lot to be gained.
   stearns: The existence of an override would not preclude a future fallback
            mechanism.
   fantasai: The use case we're aiming for, you're telling the font to use
             the wrong thing.
   stearns: In all the mailing list feedback, they're talking about an override
            where they know the font.
   fantasai: But that's not always the case while loading the page
   jdaggett: A system font won't have all these features.

   jdaggett: Straw poll…?
   glazou: fantasai, can you live with no change?
   fantasai: I don't understand the objection to fallback
   jdaggett: You're asking for more work, and I want to get the spec done.
   jdaggett: The feature is at risk anyways.
   jdaggett: Prefer something simple that's actually implemented, then we'll
             go from there.
   glazou: We've said for other things that "this is interesting, but we'll
           move forward"

   fantasai: I can live with it. I just don't agree with the attitude
             "I know what fonts I have".
   <dbaron> fantasai, In theory, I'd agree, except the odds of a user happening
            to have a font with language-specific features already is probably
            pretty low
   jdaggett: It can go on the css4-fonts wiki page.
   glazou: or log an issue

   glenn: Do you define that this string must be a case-sensitive match to
          opentype language?
   glenn: Should be case-sensitive
   jdaggett: Have to look at that.
   jdaggett: Lots of case-sensitivity stuff sprinkled around.
   fantasai: Spec doesn't specify case-sensitivity, and I raised that a
             an issue.
   jdaggett: Can discuss text on the mailing list.
   r12: spec says it's case sensitive
Received on Wednesday, 3 July 2013 05:56:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 July 2013 05:56:17 UTC