Re: [css-font-loading] how/when do FontFace objects end up in a FontFaceSet

On Thu, Mar 6, 2014 at 12:19 AM, John Daggett <> wrote:
> Tab Atkins wrote:
>>> Sort of along the line of Jonas's question, it's unclear to me
>>> precisely how/when newly created FontFace objects are added to the
>>> appropriate FontFaceSet (e.g. document.fonts).  Is the intent that
>>> they are automatically added at construction? If so, then the spec
>>> needs to state that clearly. If not, then it should state that an
>>> explicit add is required.
>> Construction doesn't mention anything about automatically adding it
>> to the document's font source, so it doesn't do so.
> I think the spec should state that explicitly.


> I also think the spec should point out via examples possible usage
> patterns here. It seems to me there a multiple patterns here, it would
> be interesting to highlight the difference between loading before and
> after insertion into the FontFaceSet along with the implication for
> how that might affect fallback to local fonts.

Sure, I can add more examples.

>>> It seems odd that FontFace.load() has a return type of void but
>>> FontFaceSet.load returns a Promise. Wouldn't it be more consistent to
>>> have them both return a promise?
>> Yeah, other people have cited this as something weird.  It's a
>> path-dependent thing; I originally didn't have the "status" attribute,
>> so .ready() was the only way to observe the load status.
>> I've removed .ready() from FontFace and just made .load() return the
>> [FontStatusPromise].
> Hmmm, I think we should go the other way. Have load() return a promise
> and leave ready() as it was. The ready() method is the only way to
> passively observe individual font loads using Promises (e.g. a user
> altering a textfield may induce the loading of a fallback font).

Is there a reason to passively observe an individual font using
promises?  I can't think of any good ones, and the lack can be hacked
around by using the events.


Received on Thursday, 6 March 2014 17:10:43 UTC