- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 30 Jun 2014 12:48:09 +1000
- 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) { alert("hello"); 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: ...; }"; document.head.appendChild(style); 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 internally.
Received on Monday, 30 June 2014 02:46:40 UTC