[bump to f2f

Peter: Re-opened as they published a new version of their API.

... Last time we looked at this we pushed back, saying why not use a font picker. I don't see that taken on here...

David: Some of the folks who wanted this might have been design tools folks like Figma. Examples in the old explainer didn't really motivate it very clearly.

Peter: ... don't necessarily want just local fonts, but also web fonts.

Rossen: Won't this go against efforts around privacy and not allowing system fonts to be exposed? Two opposing forces working against each other.

... I remember discussions with the CSSWG in Fukuoka TPAC. There was a strong push-back on this one then. But I don't remember much else.

Peter: (quoting) ... haven't heard interest in a font picker implementation. People aren't asking about a privacy-preserving version.

Rossen: The explainer doesn't give the impression that privacy is top of mind.

Alice: Spec does talk about privacy options in the goals...

Peter: How useful is this API in the case where everyone gets the same small set of data?

Alice: Seems like the intention is that the "full" set will be given (only) in trusted contexts, with that being left up to the UA to determine.

Peter: I see lots of references to partners... it reads like it's designed for one application.

Rossen: Did we ask how this could benefit the rest of the web platform beyond the one (presumed) use case?

Peter: Looking over our comments, we previously closed the issue for lack of progress. There is a new version but I don't see anything that addresses our earlier feedback, and most of the issues we previously filed are still open.

... What feedback could we give that would be productive?

David: From Tess' comment, 6 issues are listed, 1 is closed, 4 still open, and 1 is a broken link.

Alice: Perhaps we could just ask for a summary of what's changed and why? And possibly for more clarity around intended use cases (beyond the "goals" and the tightly scoped "key scenarios" - what is the context for these goals and scenarios?)

Peter: I'll try and leave that feedback.

Tess wrote up a comment capturing our current thinking on this re: a picker-style alternative API approach.

Tess: Want an in-page picker where each font is a live preview of itself.

... I understand the desire for that, once you get all of them (?) it's a can of worms that a picker would avoid

Lea: Seems like very limited use cases beyond an in-page picker.

Tess: Can accomplish most of those use cases in other ways. Would prefer a font picker to this API.

Rossen: There's a reason we have the file picker as a file picker...

Tess: <input type=file> is probably one of the best features in terms of how it implicitly grants permissions without showing a permission prompt: you grant permission to the single file when you pick it from the picker.

... Users don't think about fonts the same way they think about files. A lot of systems have native font picker dialogs, which you could imagine this would invoke.

Lea: That would also be a lot more [developer friendly] than a font API.

Tess: Geared towards complex, enterprise tools rather than middle-of-the-road web developers. Most developers aren't working on Google Docs, they're working on a rich text editor in something like WordPress. Bit of a smell when an API is really only for big tools, and overkill for little ones. If you're really dedicated to having that custom, in-page picker, input type=font wouldn't do the job for you, but you could still do it. Full Font Enumeration API is overkill.

Lea: Once pickers are more extensible and stleable they could cover more of those use cases as well.

Rossen: This goes back to the design principle we were talking about last week about high vs. low levels: enumerate your use cases, potential levels, ship the highest level API you can to begin with.

Tess: Also least power principle: font picker has less power than a font enumeration API.

... what's the status of the review?

... filed a bunch of issues previously, at least one was "why not use a picker"

Peter: Explainer lists goals, but the goals don't really shed any light on user needs.

Tess: They combined two proposals, more or less because we told them to.

Peter: One use case I can think of where you'd want low-level access... grouping similar types of fonts so users can pick types of fonts (with similar metrics, e.g)... font picker wouldn't provide that functionality, but not clear to me that S&P risks are worth it.

Lea: Any kind of font tool also... but very niche use cases.

Tess: This is being pursued precisely for the Google Docs kind of use case, where they would see it as more of a showstopper that we can't get the extra 10%, IIRC.

Rossen: Is it fair to suggest re-opening the conversation about the [font] picker, and have an additional conversation as warranted... what are we missing if we have the font picker only? Then becomes a conversation about how to extend the font picker to get the use cases they need.

Peter: We did leave a comment in this issue https://github.com/w3ctag/design-reviews/issues/399#issuecomment-561387155 in December 2019 saying a picker style API would be better... don't see a reply to that.

... can we ask again for their reasoning on that, as well as what are the user use cases, as opposed to the goals listed in the explainer?

... got a summary of changes, but not how they addressed the feedback.

Tess: https://github.com/WICG/local-font-access/issues/62 was opened by someone else very recently which is very relevant to our feedback.

... also one from Anne https://github.com/WICG/local-font-access/issues/36 which is also very similar. From July... "the website invokes query() and the user then gets a browser-driven dialog with which they can select zero or more fonts to expose to the website." Also still open, there has been some discussion on that.

Tess: I can try and write something up... along the lines of enumerating the points of feedback and issues that are yet to be addressed, particularly around the API being more powerful than needed for the 90% use case, and whether it could start from a picker model and be extended from there to address any gaps in functionality.

Bumped, waiting for feedback

This has been pending external feedback for a while. They said they would update the explainer "soon", in January. Tess pinged them for an update.

Hasn't been updated since January, no response to our request for update in May. Closed with an invitation to the OP to reopen when and if they're ready.