I strongly agree on the SetClass matter. A conventional set of method names is fine, but that should not necessitate a misleading subclass relationship.
________________________________
From: Jonas Sicking<mailto:jonas@sicking.cc>
Sent: ý2014-ý05-ý27 04:22
To: Daniel Glazman<mailto:daniel.glazman@disruptive-innovations.com>; Domenic Denicola<mailto:domenic@domenicdenicola.com>
Cc: chairs@w3.org<mailto:chairs@w3.org>; public-webapps<mailto:public-webapps@w3.org>; public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>
Subject: Re: Last Call for "CSS Font Loading Module Level 3"
I've provided this input through a few channels already, but I don't
think the user of [SetClass] here is good (and in fact I've been
arguing that SetClass should be removed from WebIDL).
First off you likely don't want to key the list of fonts on the
FontFace object instance like the spec currently does. What it looks
like you want here is a simple enumerable list of FontFace objects
which are currently available to the document.
Second, subclassing the ES6 Set class should mean that the following
two calls are equivalent:
Set.prototype.add.call(myFontFaceSet, someFontFace);
myFontFaceSet.add(someFontFace);
However I don't think the former would cause the rendering of the
document to change in, whereas the latter would.
Hence I would strongly recommend coming up with a different solution
than using SetClass.
Separately, FontFace.loaded seems to fulfill the same purpose as
FontFaceSet.ready(). I.e. both indicate that the object is done
loading/parsing/applying its data. It seems more consistent if they
had the same name, and if both were either an attribute or both were a
function.
/ Jonas