[css-font-loading] FontFaceSet.load() promise rejections

[litherum]

The spec says:

3. Find the matching font faces from font face set using the font and text arguments passed to the function, and let font face list be the return value (ignoring the found faces flag). If a syntax error was returned, reject promise with a SyntaxError exception and terminate these steps.
4. Queue a task to run the following steps synchronously:
   1. For all of the font faces in the font face list, call their load() method.
   2. Resolve promise with the result of waiting for all of the [[FontStatusPromise]]s of each font face in the font face list, in order.

However, this is not, in fact, what (any) browser does. This text indicates that either A) the string passed to load() is a syntax error, or B) the promise is resolved (rather than rejected). However, WebKit, Chrome, and Firefox all reject the promise if no fonts were able to be loaded. (WebKit rejects the promise if any font was unable to be loaded, and I'm not sure about the other browsers.)

I suggest we make the spec match what is de-facto true in browsers.

test.html.zip

[litherum]

This issue was recently filed and has 0 comments, so I'm not sure if it's rude or not to suggest it should be added to the agenda for TPAC or not. Maybe if there's extra time at the end or something this would be a good candidate issue to discuss?

[astearns]

No worries about tagging recent issues or ones that have not gotten replies. If an issue is important to you it is very useful input for the entire group.

[svgeesus]

On a related note, (and ideally after we have resolved this issue):

• [css-font-loading-3] Lots of edits since 2014 /TR, republish? #7065

[tabatkins]

The "fulfill the promise if there are no fonts" is just how Promise.all() normally works when fed an empty list (and in particular is how WebIDL works by default, if you refer to its algorithms; this spec was written before those were established, but I should fix to refer to them).

Is there a good reason we should diverge from that, or is this just an artifact of browsers doing stuff in idiosyncratic ways before we got good spec algos to encourage consistency?

Note that this is also consistent with the current spec for .check(), which returns true if no fonts need to be loaded at all.

[litherum]

fulfill the promise if there are no fonts

That's not the situation here. The situation is:

1. There are fonts
2. The fonts fail to load

[tabatkins]

Oh, I'm confused then. If there are fonts, then you return a promise with the result of "waiting for all" the load() promises. The load() promise rejects if the load fails, see https://drafts.csswg.org/css-font-loading-3/#font-face-load. So it sounds like WebKit is correct in this regard, rejecting if any of them reject.