That discussion was a continuation from https://lists.w3.org/Archives/Public/www-style/2015May/0315.html .

However, the draft is now 404, and the TAG can't find a replacement for it.

Peter found it at http://tabatkins.github.io/specs/css-font-display/

A few quick thoughts:

• the introduction should be marked as non-normative
• it'd be great to see an explainer for this (and have it linked from the spec)
• there aren't meaningful examples (perhaps these could be in an explainer)
• are the values of this property available to script? On assume so via the CSS OM, but it'd be nice to see example code.
• would be nice to understand if there's an event that could correspond to the status of load changes, e.g. for when swap happens or the document has given up on it
• how does this integrate with the CSS loader API? Does one layer on top of the other?

In general this looks good.

I agree this is good. Can be used to improve the user experience. Seems a little concerning (from an interop perspective) to have 'auto' be user-agent defined, but user agents can change their behavior to harmonize without it impacting the spec.

The other thing that either @slightlyoff or @plinss mentioned was whether there should be a way to tell whether a font was used or not. I'm not sure what such an API would look like, though.

the introduction should be marked as non-normative

Happy to do so, but that's generally true. Maybe I can just put it into the CSSWG boilerplate.

it'd be great to see an explainer for this (and have it linked from the spec) there aren't meaningful examples (perhaps these could be in an explainer)

Yeah, definitely need to add some good examples.

are the values of this property available to script? On assume so via the CSS OM, but it'd be nice to see example code.

Yes, via the CSSOM, same way all other @font-face descriptors are.

how does this integrate with the CSS loader API? Does one layer on top of the other?

What's the "CSS loader API"? Do you mean https://drafts.csswg.org/css-font-loading/? If so, it's kinda close to being sugar on that, but there are several specific things that aren't provided right now that mean you can't faithfully polyfill it:

• no way to be notified that the UA is requesting a font-face so it can render with it
• requires mutating styles to tell the browser "use this other font for now, while I load"
• no way to produce an "invisible fallback font face" from another arbitrary font face (particularly since it might be a system font), at least without setting color: transparent on the element and hoping nothing is relying on currentcolor doing something useful.

The other thing that either @slightlyoff or @plinss mentioned was whether there should be a way to tell whether a font was used or not. I'm not sure what such an API would look like, though.

Is this what I said above with "no way to be notified that the UA is requesting a font-face so it can render with it", or something else?

Seems a little concerning (from an interop perspective) to have 'auto' be user-agent defined, but user agents can change their behavior to harmonize without it impacting the spec.

As documented in the intro table, UAs generally disagree with each other today. auto is needed to explain that, so we have an initial value that reflects reality.

The concern was getting an event when the block or swap periods end, not just when the font is done loading, or alternatively, getting information about what loading period the browser is in when loading completes. e.g. the font has just loaded, but isn't going to be used anymore because the swap period has expired.

I'm curious what the use-case is for knowing that a font has switched into a new period. I definitely see use-case for knowing that a font is "dead", and being able to bring it back to life when it's loaded.

If the author is doing something tightly coupled to the current font being displayed, for example, poly-filling drop caps, they'll need to know when the fallback font is applied. Another use could be coordinating use of fonts between elements, e.g. headings and body text, if the body text swaps to the fallback, the author may want to change the heading font. The author may also want to be notified when the swap period ends and use that signal to explicitly abort loading a font or other resource.

Thanks for the great feedback!

Re the use cases above, I'm wondering if those are better served by the CSS font loading API.

Agreed, the font loading API is the proper place for those features, we just wanted to be sure that it accounted for the new capabilities.

Ping on adding an explainer and examples to either the spec (non-normative) or the explainer.

Doesn't look like things have changed... We'll close it for now until we see changes to review.... /cc @tabatkins ?