Intent to Deprecate: CSS font loading's ready as a function in favor of ready as an attribute

155 views
Skip to first unread message

Kenji Baheux

unread,
Nov 7, 2014, 3:07:11 AM11/7/14
to blink-dev

bcc: chromium-dev as an FYI


Primary eng (and PM) emails

ksak...@chromium.org, kenji...@chromium.org


Summary

In M40, we will show deprecation warnings on calls to document.fonts.ready() (returning a promise) as the spec has been updated in favor of having ready as an attribute (promise). Tentatively, we’ll make the switch in M41.


Motivation

For consistency with the pattern of having ready as an attribute (promise). This pattern started to get traction after we shipped our implementation of CSS font loading.



Compatibility Risk

Theoretically there is a risk that we break websites relying on ready being a function. However, in practice the use counter for this particular feature of the CSS font loading API indicates that it's still rarely used (if ever).

https://www.chromestatus.com/metrics/feature/timeline/popularity/464


Firefox is currently implementing CSS font loading and therefore it’s highly likely that their implementation will have ready as an attribute: https://bugzilla.mozilla.org/show_bug.cgi?id=1028497



Alternative implementation suggestion for web developers

Since the name didn't change, we can't have a deprecation period where both versions co-exist.


One solution would be to use the following approach:

var fontsReady = document.fonts.ready;
 if (typeof(fontsReady) == "function")
   fontsReady = document.fonts.ready();
 fontsReady.then(...);


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/464



Entry on chromestatus.com, crbug.com, or MDN

Deprecation: https://code.google.com/p/chromium/issues/detail?id=425447

Impl: https://code.google.com/p/chromium/issues/detail?id=392077



Requesting approval to remove too?

No, this is a behavior change which seems better to postpone to the next milestone (i.e. M41) despite the low usage.


TAMURA, Kent

unread,
Nov 7, 2014, 3:56:22 AM11/7/14
to Kenji Baheux, blink-dev
lgtm.

The function-to-attribute switch without a transition period is not polite.  However because of the low usage, warning-then-switch sounds reasonable.

--
TAMURA Kent
Software Engineer, Google


PhistucK

unread,
Nov 7, 2014, 4:48:18 AM11/7/14
to TAMURA, Kent, Kenji Baheux, blink-dev
A warning with either a link to an explainer page, or embedded code that shows the how to deal with both of the ways (for short term compatibility) like the code that was mentioned in the "Alternative implementation suggestion for web developers" section would be appropriate.


PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Rogers

unread,
Nov 7, 2014, 1:21:44 PM11/7/14
to PhistucK, TAMURA, Kent, Kenji Baheux, blink-dev
LGTM

Chris Harrelson

unread,
Nov 7, 2014, 8:39:55 PM11/7/14
to Philip Rogers, PhistucK, TAMURA, Kent, Kenji Baheux, blink-dev
LGTM

I am a strong proponent of what PhistucK said as well. Do we have a good way yet to show links to explainer pages in the deprecation warning?
Message has been deleted

tim...@gmail.com

unread,
Mar 9, 2015, 10:48:40 AM3/9/15
to blin...@chromium.org
This caught me out today. We had production code using document.fonts.ready() which started throwing errors in Chrome 41 before we'd had time to notice the console warnings and apply a fix. Perhaps my code should have been more defensive but I had no idea the spec was likely to change. The transition period was too short, in my view.

Tim Down

Kenji Baheux

unread,
Mar 10, 2015, 5:24:29 AM3/10/15
to tim...@gmail.com, blin...@chromium.org
Hi Tim,

Really sorry to hear this caught you off-guard.

Unfortunately, the longer we wait, the higher the risk we run.

 
What could have we done better?
Some wild ideas:
  1. show an infobar warning about the imminent compatibility issue (obviously we would need to limit that to a developer crowd and ideally to developers/owners of the website in question)
  2. show a warning in webmaster central
  3. any other suggestion?

Paul Kinlan

unread,
Mar 10, 2015, 5:33:51 AM3/10/15
to Kenji Baheux, tim...@gmail.com, blin...@chromium.org

For a lot of deprecations we've had no real developer relations efforts to try and get this news out to as many developers as possible. We can certainly sort this out.

Also we have no clear way of understanding the exact sites that are impacted by a deprecation so that we can pro actively contact affected sites (even via webmaster central).


Yoav Weiss

unread,
Mar 10, 2015, 12:43:02 PM3/10/15
to Paul Kinlan, Kenji Baheux, tim...@gmail.com, blink-dev
Since we're deprecating a lot of small, sometimes not so well-known features, I'm not sure communicating each one of them with dev-rel is scalable.

Maybe what we need is a stronger message for devs to test their sites in Canary (and Firefox nightly, and IE's preview builds). 
e.g. With Firefox introducing <picture> support, a potentially huge compat bug was caught by Shopify, that tested their Web site on nightly and saw breakage. We need more of that (testing, not compat bugs ;) ), and it can have benefits for deprecations and new features alike.

Also - a "developer mode" where deprecation warnings are more visible outside the console may also help to draw attention to possible future breakage.

tim...@gmail.com

unread,
Mar 11, 2015, 7:19:18 AM3/11/15
to blin...@chromium.org, tim...@gmail.com
Thanks for the responses.

This is what happened for us in this particular case:

- While looking into an unrelated issue on our existing application in late February, a colleague and I noticed the warning message about document.fonts.ready in the console in Chrome 40. We're not a large team and are not in the habit of checking our application with the console open, hence we hadn't spotted it until Chrome 40 had been out for several weeks.
- We were focussed on something else so spent little time on the warning message, which was "document.fonts.ready() method is going to be replaced with document.fonts.ready attribute in future releases. Please be prepared. For more help, check https://code.google.com/p/chromium/issues/detail?id=392077#c3". It didn't seem very serious. It didn't make it explicit that the change would be made in the very next version of Chrome. I had classified it in my mind as being similar to the warnings about synchronous XHR (which is not going away any time soon). Therefore I made a vague mental note, didn't follow the link and didn't create an issue in our issue tracker.
- A couple of weeks later, Chrome 41 is released and our application is broken in that browser.

The fault is entirely mine because I used a new feature based on an unstable spec without using strong enough feature tests. I then failed to act quickly on a warning message. I wasn't developing with Canary. 

In my defence:

- Web specs seem to be in a constant state of flux so it's difficult to get a good feeling for what is and isn't likely to change.
- The warning message text gave no indication of exactly when the change was likely to be made in Chrome. Even following the link gives no obvious indication. All there is is a label of "M-41", which could mean to Chrome developers that it will change in version 41 but doesn't make that obvious to me.

What might have helped:

- The warning message could have been much stronger. "document.fonts.ready() method is going to be replaced with document.fonts.ready attribute FROM THE VERY NEXT RELEASE, WHICH WE THINK WILL BE IN EARLY MARCH 2015". Maybe it could be less shouty, but you get the point.
- A bit more time, maybe one more release. It was only by chance that I saw the warning message at all. I haven't previously seen the need to use Canary for development.
- An infobar rather than just a console warning in a developer version of Chrome would be great. Is Canary the appropriate version? I think a developer mode in Canary or even regular Chrome could be really helpful: infobars as suggested, maybe a panel in dev tools or somewhere else visible with a list of upcoming API changes etc.

Chris Harrelson

unread,
Mar 11, 2015, 1:51:02 PM3/11/15
to tim...@gmail.com, blink-dev
Hi Tim,

Thanks for this useful feedback.

What I learned from it is that we should improve the warning messaging to match more clearly the severity/priority of the issue. I'll work on making sure that future deprecation and removal takes this into account.

Regards,
Chris

PhistucK

unread,
Mar 17, 2015, 3:29:21 PM3/17/15
to Chris Harrelson, tim...@gmail.com, blink-dev
An idea could be to show an information bar in the Developer Tools feature (showed every time it is opened, until it is dismissed and then never again) -
"Are you a developer? Yes No"
It is intentionally vague, because a longer message ("Are you a developer? Check out the developer mode.", or "Are you a developer? Check out the developer mode for API changes and deprecations") would lead to avoidance (in my experience).
Once "Yes" is clicked, a developer mode extension is installed (or a component extension is activated) and a browser action is shown in the toolbar, with a tick sign, or a circled exclamation point (or a circled "i") with a number of relevant messages for the current tab.
In order to only show messages to relevant domains, you could ask another question (only once "Yes" is clicked and never again) - "Does this domain contain pages developed by your team? Yes No".
After the second "Yes", a 'success' message is shown -
"Great! We will let you know about upcoming changes to APIs you use. The relevant domain list can be changed in the settings."

Alternatively, instead of a browser action, a bubble (like the permission bubble) could be shown with a list of messages.

Anyway, this would require a private (or public, better) extension API that exposes these messages, along with a message event for handling the messages as they come. Every message will have stack traces, if relevant, or line and column and could link to the Developer Tools sources panel with the relevant code.

This could be a way to update the developers about API changes, removals, deprecations, of even new, simpler ways of doing things on a best available guess basis ("$.trim(text) could be changed to text.trim()", for example).


PhistucK
Reply all
Reply to author
Forward
0 new messages