Intent to Ship: Font Load Events
Kenji Baheux
Primary eng (and PM) emails
ksak...@chromium.org (kenji...@chromium.org)
Spec
http://dev.w3.org/csswg/css-font-load-events/
Summary
Events and interfaces used for dynamically loading font resources.
Link to “Intent to Implement” blink-dev discussion
N/A (the intent to implement this API predates blink; the corresponding crbug entry was filed back in 2010!).
Motivation
According to HTTP Archive, ~37% of the top 300K sites are using web fonts. This represents more than a 2x y/y increase. This is great for several reasons ranging from improved accessibility and searchability to high-DPI friendliness and obviously much greater expressiveness.
Unfortunately, when you start to rely on web fonts you quickly realize the limitations of the platform:
- you have to use fragile hacks to gain insights about the actual availability of your web fonts
- you have no control over the user experience:
- all the font requests are blocked on DOM and CSSOM so that the browser can determine which web fonts are needed by the document. As the designer, you most likely know which web fonts are critical but you can’t tell the browser about it.
- some browsers will fallback on a system font immediately, some will fallback after a 3 seconds timeout and others would be happy to wait forever after a web font.
The Font Load Events API gives you control and insight into how and when the fonts are loaded. For instance, you can check beforehand if all the necessary fonts are readily available, or schedule font downloads at will and do something when they are ready.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
Demo link
http://jsbin.com/uxubEPo/1/quiet
Steps:
Open in Incognito to guarantee that you start from a fresh cache
unless you are on super fast connection, you should see a page with a bland choice of web fonts
-
Open one more time the demo page in a second tab
web font galore!
What the demo does:
kicks web font downloads as soon as possible with the load() method
-
before the page is rendered, it checks if all the fonts are ready with the check() method
if all the web fonts are ready then it changes the style to take advantage of said web fonts
Compatibility Risk
This is a bucket 4 item: “The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.”. Concretely, Mozilla sees the value provided by this API and is generally supportive (bugzilla).
OWP launch tracking bug?
Link to entry on the feature dashboard
http://www.chromestatus.com/features/6244676289953792
Scope
In M34, the implementation will most likely have the following minor limitations:
FontData construction from BinaryData won’t be available in M34
The coherence of FontFace, @font-face rule, and font matching engine upon property changes might not be guaranteed in M34
We believe that even with these limitations, the API is extremely valuable and effectively solve the most important use cases. In any event, these limitations will be addressed in M35.
Glenn Adams
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Kenji Baheux
- Use Chrome canary
- enable chrome://flags/#enable-experimental-web-platform-features
- If you open the page a second time in a new tab, you might have ended up with the fallback fonts.
- This is because a fresh renderer needs some time to load and parse the fonts in memory
- In the previous version of the demo, it was conceivable that check() would be called before the fonts were available in memory :(
- the page sets a predefined timeout (e.g. 50ms) in the form of a Promise. It represents how long we can afford to wait for the fonts
- the page pitches this Promise against the document.font.ready() Promise in a race and either use the fonts or stick with the fallback system fonts.
Kenji Baheux
- match() has been removed. It was considered superfluous (load ought to be enough).
- now, check() returns true in the platform-only fontlist case (the spec used to say "returns false" but this was a mistake).
Kenji Baheux
Dimitri Glazkov
Eric Seidel
- Seems like not a lot of folks are paying attention to this. I worry
we'll commit to something which will later, change, this is clearly a
missing feature of our platform and we can't indefinitely.
- ready seems redundant with load() if we just make load() return a
promise. Clients can already poll the .status accessor to get "ready"
w/o going through a promise. load() seems more useful as a promise
API anyway.
Overall LGTM. Useful feature to have in the platform.
Domenic Denicola
- Seems like not a lot of folks are paying attention to this. I worry
we'll commit to something which will later, change, this is clearly a
missing feature of our platform and we can't indefinitely.
I agree with this worry. I can try to get the TAG to review the spec ASAP (by end of weekend most likely). Would that be helpful? Or has there been enough LGTMs that the ship-it train is running out ahead of the spec-review train, and we should resign ourselves that whatever Blink ships will likely be the final form?
Glenn Adams
Domenic Denicola
> I can't imagine how a TAG review would help. But, since the editor, Tab Atkins, is reading this ML, perhaps he should provide input here.
In general we try to provide guidance on building idiomatic and well-factored JavaScript APIs that fit with the overall story of the platform. You can see other such reviews at [1] and a (draft of a) recent one at [2].
Tab is very competent at crafting such APIs already, so we may not have much to add. But it could be helpful just to get fresh perspectives, and see anything he missed, or try to highlight things that might prove problematic, as a way of guarding against the original worry that the API has not undergone enough scrutiny to protect it from future changes.
I somewhat agree that the most helpful review for this spec would be from other implementers, but hopefully the TAG can provide some benefits and perhaps act as a proxy for their concerns based on our past experience.
[1]: https://github.com/w3ctag/spec-reviews
[2]: https://github.com/w3ctag/spec-reviews/blob/81f3b35eeebd06e1d5da21ff3b5e844639d359f3/2014/02/quota-management-api.md
Glenn Adams
From: Glenn Adams <gl...@skynav.com>
In general we try to provide guidance on building idiomatic and well-factored JavaScript APIs that fit with the overall story of the platform. You can see other such reviews at [1] and a (draft of a) recent one at [2].
> I can't imagine how a TAG review would help. But, since the editor, Tab Atkins, is reading this ML, perhaps he should provide input here.
Tab is very competent at crafting such APIs already, so we may not have much to add. But it could be helpful just to get fresh perspectives, and see anything he missed, or try to highlight things that might prove problematic, as a way of guarding against the original worry that the API has not undergone enough scrutiny to protect it from future changes.
I somewhat agree that the most helpful review for this spec would be from other implementers, but hopefully the TAG can provide some benefits and perhaps act as a proxy for their concerns based on our past experience.
Glenn Adams
Domenic Denicola
> Generally a TAG review is called for if there is an architecturally issue or a principle at stake. I don't believe that applies here. It is not customary for the TAG to review every REC track spec.
I don't want to derail this thread too far, but we are trying to take a more active role in spec review, viewing JavaScript APIs as an important part of web architecture. We can discuss this further on www-tag if you wish.
> Further, this spec has only reached FPWD status this week. As such, it is extremely early in the process to have any external group perform a review. Generally, a WG doesn't request reviews from other groups until the LCWD stage unless something special arises.
We are less concerned with the formal stage in the process that the spec is in, relative to the fact that it is going to be shipped in a major implementation.
Tab Atkins Jr.
> Further, this spec has only reached FPWD status this week. As such, it is
> extremely early in the process to have any external group perform a review.
> Generally, a WG doesn't request reviews from other groups until the LCWD
> stage unless something special arises.
to ask for FPWD months ago, immediately after the CSSWG Paris f2f.
It's been stable for months, and I'm happy enough with it. I plan to
ask for LC this week.
~TJ
Tab Atkins Jr.
> BTW, I agree with Eric's comment about ready() seeming redundant, and best
> folded into load(). Perhaps Tab can elaborate on why they were separated.
spec, plus my observation that .ready() is a common name among
promise-based APIs for observing "completion" of some object. I
didn't originally have the .status attribute, for example, so .ready()
was the only way to observe whether it was finished loading or not.
I'm fine with having .load() return a promise instead of nothing, and
removing .ready() if possible.
~TJ
TAMURA, Kent
On Thu, Feb 20, 2014 at 6:26 AM, Kenji Baheux <kenji...@chromium.org>
wrote:
TAMURA Kent
Software Engineer, Google
