W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[css-font-loading] using an actual Set object internally for [[ContainedFonts]]

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 30 Jun 2014 12:48:09 +1000
Message-ID: <53B0CFE9.6060506@mcc.id.au>
To: "www-style@w3.org" <www-style@w3.org>
I'd like to question whether [[ContainedFonts]] should be an actual Set 
object that the FontFaceSet interrogates and manipulates.

The author could modify Set.prototype to have some side effects.  Let's 
say they do:

   Set.prototype.add_orig = Set.prototype.add;
   Set.prototype.add = function(x) {
     return this.add_orig(x);

It's not clear whether add() is called when a new CSS-connected FontFace 
object is meant to be added to the FontFaceSet.  So if the author then does:

   var style = document.createElement("style");
   style.textContent = "@font-face { font-family: Blah; src: ...; }";

would the alert show?  I'd say "yes", but I don't know exactly when.

An even less clear case is when you determine whether there are possibly 
pending font loads.  That requires you to know the status of each 
FontFace in the set.  Is the implementation allowed to call the iterator 
on [[ContainedFonts]] to get each FontFace to check?  If so, then we 
need to define exactly when that check is done, otherwise side effects 
from a replaced @@iterator will be observed.  You could avoid this by 
keeping a separate array of FontFaces, but that seems wasteful.

Of course one of the side effects could be manipulating the Set to 
remove CSS-connected FontFaces, insert non-FontFace objects, or all 
kinds of things.  This means the implementation has to be resilient not 
only to Set.prototype.add etc. throwing, but the contents of the Set not 
being what it'd otherwise expect.

The only benefit I can see that offsets against these problems is that 
the definitions of add etc. can be rather simple.  I think we should go 
back to using an abstract representation for the set of FontFaces 
Received on Monday, 30 June 2014 02:46:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC