Re: [font-load-events] comments on new promises-based draft

On Mon, Sep 9, 2013 at 6:26 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Tab Atkins wrote:
>>> 2. side effects of 'new FontFace'
>>>    a. adds FontFace the FontFaceSet object?
>>>    b. adds a new CSSFontFaceRule when on main/Document thread?
>>
>> The spec doesn't define any additional side-effects for "new
>> FontFace()", so nothing additional happens.  Would you like an
>> explicit note that nothing additional occurs?
>
> Well, the implications are sort of funky I think.  You force authors
> to explicitly add it to the font set?
>
>   var f = new FontFace(...);
>   document.fonts.add(f);
>
> When will a FontFace object be useful independent of the set of fonts
> used to support font matching?

As I said, you can transfer them to Workers, for instance.  I'm not
sure what future things we may create that use FontFace objects
directly, but this was a straightforward and future-friendly solution
to the workers problem.

> And what are the semantics of loading for fonts that don't belong to a
> FontFaceSet?
>
>   var f = new FontFace(...);
>   f.load();
>
> So none of the event handlers of FontFaceSet would fire on the load,
> right?  And this load would be outside of the promise fulfilled by
> FontFaceSet.ready()?

Yes, the events and ready promise of FontFaceSet is defined pretty
well, I think, and it depends explicitly and solely on the fonts
inside the set.  You can, of course, use the independent FontFace's
ready promise to track its load progress.

>>> The spec really needs to state more clearly both what happens with
>>> a new @font-face rule is created and what happens when a new
>>> FontFace object is created.  It implies that the two are linked
>>> ("CSS-connected") but the exact association isn't clearly spelled out.
>>
>> Ooh, you're right.  I handle the case where you add a new stylesheet
>> that contains @font-face rules, but not the case where you just add
>> a new @font-face to an existing stylesheet.  I'll take care of this.
>
> I think there's an odd pair of dual OM's here and the spec needs to
> spell out the details a bit more.  That is, on the one hand you have a
> set of @font-face rules in a stylesheet that can be manipulated using
> CSSRule-derived objects and on the other hand you have a set of
> FontFace objects.  It's not just adding but any form of manipulation
> and whether mutations are reflected from one to the other.
>
>   @font-face {
>     font-family: Whitney;
>     src: url(...);
>   }
>
>   fontFaceRule.src = "local(Whitney)," + fontFaceRule.src;
>
> Based on what you've written so far, it seems that you're imagining
> that the manipulations above are automagically reflected in the
> FontFace object that represents the @font-face rule.  But new FontFace
> objects added to document.fonts are *not* automatically reflected in
> the CSS OM?

Yes.  We need to have a separate instantiation of what a "font face"
is, separate from the CSSOM, because that has connections into the
document and thus isn't friendly for workers.  Having @font-face rules
get linked to the FontFace objects, so that any manipulation to either
changes the other side, seems like the least surprising thing for
authors.

However, reflecting back the other way, where independent FontFace
objects create @font-face rules, seems unnecessary and weird.  It's
not really compatible (without incurring potentially large memory
costs) with constructing a font directly from an ArrayBuffer, and it
would involve a completely arbitrary choice as to which stylesheet to
insert the @font-face rule.  The whole thing just seems icky and
unnecessary.

CSSFontFaceRule objects represent the @font-face syntax construct,
nothing more.  The actual font face denoted by the @font-face rule is
represented by the FontFace object instead.  This seems like a decent
separation of concerns, at least to me.

~TJ

Received on Tuesday, 10 September 2013 01:39:35 UTC