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

On Mon, Jul 13, 2015 at 8:29 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

How do you handle .load() when it only references fonts from the
tainted sheet, tho?  It needs to return a promise, which resolves to a
list of FontFace objects.  Are you saying that we should simply make
that situation *not work* for no good reason?

~TJ

Received on Tuesday, 14 July 2015 20:34:11 UTC