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

Overall, looks good, I think the new draft does a nice job of using promises and solves the problem of how to load fonts within worker threads.

A few problems/issues:

1. duplication of CSSFontFaceRule struct

The current definition of the FontFace interface unnecessarily duplicates that of the CSSFontFaceRule interface.  Better to define an interface shared by both:

  [NoInterfaceObject] 
  interface FontFaceInfoStuff {
    attribute DOMString family;
    attribute DOMString src;
    attribute DOMString style;
    attribute DOMString weight;
    attribute DOMString stretch;
    attribute DOMString unicodeRange;
    attribute DOMString variant;
    attribute DOMString featureSettings;
  }
  
  CSSFontFaceRule implements FontFaceInfoStuff;
  FontFace implements FontFaceInfoStuff;
  
Note: I added 'src' here intentionally.

The CSS3 Fonts draft will need to be updated but since this is strictly an editorial change and has no impact on the behavior, I think we can make this change without requiring another LC period.

2. side effects of 'new FontFace'
   a. adds FontFace the FontFaceSet object?
   b. adds a new CSSFontFaceRule when on main/Document thread?

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.

Creating independent FontFace objects doesn't really make sense.  They are part of a set of faces and font matching is done against a set of faces.  So a given FontFace needs to be part of a FontFaceSet, which implies you want to use a factory method instead of a constructor.  I realize the general trend is away from factory methods but given that @font-face fonts are loaded at use time and not when defined, I think a factory method makes more sense in this case.  The factory method would simply add all new fonts to the FontFaceSet.

I'm assuming you intended that for the main thread/Document case that creating a FontFace object would also create a CSSFontFaceRule, right?  If so, I think the DOMString or BinaryData parameter to the FontFace constructor needs to be reflected in the value of CSSFontFaceRule.src.  I think it's simply enough to say that if BinaryData is passed to the constructor that the 'src' descriptor is set to the data URL form of that data.

3. order of FontFace objects is important

The order of two @font-face rules defines the load order:

  @font-face { font-family: fontA; src: url(foo.woff); }
  @font-face { font-family: fontA; src: url(bar.woff); }
  
This implies that bar.woff is loaded first, followed by foo.woff if the character matched isn't supported by bar.woff (see step 5 in the font matching algorithm).

So I don't think 'SetClass(FontFace)' for FontFaceSet works unless the order of creation is preserved.  This sort of leads to the next issue...

4. need ability to add/remove/change order of FontFace's in a FontFaceSet?

Not sure this is really needed frankly, for the same reason that I'm not sure we need CSS OM API's to explicitly add/remove @font-face rules.

And, as I mentioned previously, those dang section symbols with the skanky, transitioned yellow background are distracting/ugly/heinous as all heck.  A pox on them all!  Use a 'contextmenu' attribute 'Copy link' instead.

Cheers,

John Daggett

Received on Monday, 9 September 2013 08:31:14 UTC