RE: Chrome 37 will honor the font fetching requirements as defined by the CSS fonts module specification

Workitem on status.modern.ie reflects our commitment to make real content on the Web work, you shouldn’t take the description literally (and “Established standard” is not quite correct description either☺). This work doesn’t mean that goal is to remove CORS. With our recent goal being to make most sites work on mobile[*], we disabled CORS on the Windows Phone builds only. Behavior of desktop browser stays the same in IE11 as it was since IE9.

Our goal is to make web content work in all browsers. With Chrome on board (Thanks!) and hopefully developers fixing their sites, our hope is that we will be able to eventually re-enable CORS on the phone as well.

My understanding is that with Chrome fix it will be only Safari that does not comply with the spec. WebKit bug[**] doesn’t get much traction. Can we, as working group push them again towards fixing it?

And another question I had is, will Chrome on Android get this fix in sync with desktop? If not, when can we expect this to happen?

Thanks,
Sergey

[*]http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx

[**]https://bugs.webkit.org/show_bug.cgi?id=86817


From: kenjibaheux@google.com [mailto:kenjibaheux@google.com] On Behalf Of Kenji Baheux
Sent: Monday, August 4, 2014 9:48 PM
To: public-webfonts-wg@w3.org
Cc: Sergey Malkin
Subject: Re: Chrome 37 will honor the font fetching requirements as defined by the CSS fonts module specification

There has been some discussion on the blink-dev/chromium-dev about the following:

http://status.modern.ie/crossdomainfontloading?term=font%20loading


Cross-Domain Font Loading [In Development]
Increases interoperability with the web by relaxing domain and licensing metadata restrictions for EOT, WOFF, and TrueType fonts.
w3c established standard<http://w3c%20established%20standard>


It sounds as if Internet Explorer is about to reverse course on honoring the font fetching requirements. A few things are confusing, in particular the link for the w3c established standard points to WOFF 1.0.

Sergey, can you tell us what this is about?

If it is indeed true then please accept my sincere apologies on behalf of the team if this was triggered in part by us not following the spec for so long. Chrome 37 is just around the corner, would that be enough to reconsider the decision?

From our user metrics, there is just a bit less than 5% of the requests affected by this change. Given that the fallback user experience is reasonably good in virtually all instances (e.g. falling back to system fonts), we are moving forward and have been reaching out to website owners and CDN vendors.


On Thu, Jun 19, 2014 at 10:25 PM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto:Vladimir.Levantovsky@monotype.com>> wrote:
Hello Kenji,

Thank you very much for a great news!
I am sure that this is a very welcome change for many font vendors and web developers alike, who no longer have to wonder why things work differently in different browsers. It was exciting to watch the progress on this issue and see how much thought the Chrome developers team have put into it to make sure that compliance with the spec is enforced yet the transition to CORS-enabled browser behavior is as seamless as possible.

Thank you again, and thanks to the entire team for making this milestone!
Vlad

From: kenjibaheux@google.com<mailto:kenjibaheux@google.com> [mailto:kenjibaheux@google.com<mailto:kenjibaheux@google.com>] On Behalf Of Kenji Baheux
Sent: Thursday, June 19, 2014 4:11 AM
To: public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>
Subject: Chrome 37 will honor the font fetching requirements as defined by the CSS fonts module specification

Dear webfont working group members,

I would like to share a quick update about CORS support for webfonts in Chrome/Blink.

From milestone 37, Chrome will honor the same origin restriction for webfont requests (crbug.com/286681<http://crbug.com/286681>: fixed)
Given that this behavior has been the norm in Internet Explorer and Firefox for a long time, we believe that this would not cause any major issues.

Finally, the access-control-allow-origin header can be used to relax the restriction.
Obviously, relaxing the restriction should be done in conformance with the licensing terms if any.

Please, consider helping us testing this change by downloading Chrome canary. Let me know if you find any issues.

Sincerely,
  Kenji Baheux on behalf of the Chrome/Blink team.



Additional notes:

  *   Chrome 36 has been issuing a warning in the console for non-compliant web font requests.
  *   Branch cut for Chrome 37: June 20th.
  *   Based on our typical release cycle, one can expect to see Chrome 37 stable 6 weeks after the branch cut.
  *   Chrome canary: http://www.google.com/chrome/browser/canary.html