Re: [css-font-loading] IE Review of font loading

On Mon, Mar 3, 2014 at 4:43 PM, Greg Whitworth <gwhit@microsoft.com> wrote:
> ·         The spec assumes that Promises are already implemented. However,
> at this point, this would be the first spec to require promises and it still
> doesn’t link the suggested Promises implementation and spec. At the very
> minimum the spec should link the current draft for Promises specification.

I've linked to Domenic's Promise spec, with the caveat that this is
being added to ES6 and that definition should be used instead later.

> ·         Current definitions for FontFace interface attributes suggest that
> FontFace object properties would be editable; in most cases that would
> invalidate current styles and require additional layout passes on every
> property change and might be expensive.  Is this really intended or should
> those attributes be read-only and instantiated in the constructor?

It's intended.  If you can mutate the attributes of a CSSFontFaceRule,
there's no reason you shouldn't be able to mutate a FontFace too.

> ·         If script in the ready handler changes DOM or styles this might
> require additional layout calculations (however, this is no different from
> existing script callbacks handlers). We think that the spec should tell
> developers that this will not address font loading performance issues, it
> mainly addresses async loading. A good spot for this might be in the
> abstract of the spec.

I don't think I imply that it's about performance issues at all.
FontFaceSet#ready is just a nice convenient way to deal with async
loading, and as far as I can tell, that's exactly what I communicate
in the intro paragraph of that section.  Can you explain more about
what confused you?

> ·         In the current FontFace interface definition ‘source’ is set in
> constructor. Should this be reconsidered to semantically align this object
> with XHR more?

Oh gosh no.  XHR is a super-terrible API that shouldn't be emulated by
anyone ever.

Also, there's really no connection between this and XHR beyond the
fact that both happen to cause network chatter.  The real connection
is between the property-bag argument that FontFace() takes, and the
syntax of @font-face.  By a nice syntax coincidence they look almost
identical.

> ·         Something that might require clarification in the spec: If source
> is set to multiple Urls, then we would suggest to fire success at first
> successfully loaded url and fire error when we’ve tried all available
> options (and don’t fire on each individual attempt). The term font load
> indicates when the loading of content for a given FontFace object completes.

The .load() method says to load it as specified in CSS Fonts.  Is this
unclear in some way?

> ·         Paragraphs “A FontFace object may list multiple alternate
> resources within its [Urls] attribute, including references to local fonts,
> but the term font load only refers to the loading of the finally selected
> resource for a given FontFace, not to the loading of each individual
> resource” should move to the FontFace interface description
> (http://dev.w3.org/csswg/css-font-loading/#dom-fontfaceset).

Actually, I don't need that paragraph at all anymore.  I think it's a
leftover from before I added the "status" attribute and phrased things
in terms of that.

> ·         It is unclear why FontFaceSet is needed for Workers. In our
> understanding of the spec this addresses the core problem that developers
> would try to solve with Workers in the first place.

You can draw to a canvas proxy in a Worker, but it's unclear what
fonts, if any, should be considered available to the worker for the
purpose of drawing text into that canvas.

> ·         FontFaceSet might contain more fonts than LoadingFonts +
> LoadedFonts + FailedFonts + PendingReadyPromises (see notes for Example 4
> below).

Do I suggest that it contains only those Fonts at some point?

> ·         Examples feedback:
>
> o   Example 2 (typo?): possibly means document.FontFaceSet, not
> document.fonts.

No, FontFaceSet is the name of the interface.  It's exposed as the
"fonts" attribute on document:
http://dev.w3.org/csswg/css-font-loading/#font-face-source

> o   Example 3: This example is illustrates a pattern that would lead to
> terrible performance. Maybe there is another alternative to demonstrate this
> concept?

No, this is literally the core use-case for that function.  What makes
you think it would have terrible performance?

> o   Example 4: If there are 3 @font-face rules, but in CSS only 2 are used –
> it’s suggested that implementation would fire loaded when all 3 are loaded,
> while currently only 2 actually used fonts would get loaded.

How does the example suggest that?

This was a good opportunity to demonstrate that unused fonts don't
have any effect on the loading events or promises, though, so I added
a third font.

~TJ

Received on Wednesday, 5 March 2014 00:18:01 UTC