- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 22:55:49 -0700
- 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