- 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>
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