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

Re: [css-font-loading] Handling cross-origin CORS-tainted font faces

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 14 Jul 2015 13:29:53 +1000
To: John Daggett <jdaggett@mozilla.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <20150714032953.GA16559@wok.mcc.id.au>
John Daggett:
> If style rules from a cross-origin stylesheet don't show up in the OM then
> I think it makes more sense for FontFace objects to not be exposed via
> FontFaceSet methods. Having "opaque" objects seems nasty. So I guess option
> (1) would be one way to achieve this.

I think I also prefer not exposing any kind of FontFace object for these
@font-face rules.

Most of the time this situation will arise in is when the inaccessible
cross-origin style sheet references similarly inaccessible cross-origin
fonts.  So these fonts will never load and they’re not going to be
particularly useful if exposed in the FontFaceSet.

Given that the FontFace objects will all be in an error state, it is
simplest just to pretend that they don’t exist from script’s
perspective.  So that would make them not appear in the set, not
influence the ready promise or the events that are dispatched, and not
considered in the load/check methods.

Now, you could have an inaccessible cross-origin style sheet that
references an accessible font, using a local() src, a data: URL src, or
probably much more rarely an accessible http(s): URL src.  Unless there
is a legitimate use case for inaccessible style sheets with accessible
fonts, I reckon we should just not expose them in the FontFaceSet
either.  I think this is the simplest thing to do.

It is fine of course to track these FontFaces as hidden state on the
FontFaceSet so that the algorithms that kick off implicit loads based on
content still work.

Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 14 July 2015 03:30:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC