explainer suggests iterating all the fonts in order to find Consolas

[dbaron]

The Accessing Font Tables section of the explainer has an example containing:

  for await (const metadata of navigator.fonts.query()) {
    // Looking for a specific font:
    if (metadata.postscriptName !== "Consolas")
      continue;

This seems like a bad example in two ways:

First, it seems inefficient to iterate all the fonts in order to find "Consolas", which is inefficient; it seems like the API should perhaps have a way to ask for the "Consolas" font.

Second, while it's using local font enumeration, it doesn't provide a particularly strong use case for the enumeration feature, since it's a use where enumeration isn't particularly a desirable feature. So showing this as an example rather weakens the argument that enumeration as a feature is worth the additional fingerprinting risk that it adds.

[jakearchibald]

This stood out to me too.

Elsewhere (clients api, cache api) we use .match(query) and .matchAll(query) to get one/multiple items respectively. Calling .matchAll() without a query returns all items.

(although matchAll() doesn't return an async iterator in other apis, which might warrant a new name)

[poiru]

@oyiptong Doesn't seem like this was resolved in #47, could we re-open this?

Figma would also find it useful to be able to lookup font metadata based on the unique Postscript name. This would allow us to access the blob only when needed.

[jakearchibald]

I agree that this isn't resolved.

[inexorabletash]

The example was removed, but more importantly the API shape was updated so that query() takes a property bad, including select which can be a list of names to match against. So to find Consolas: const array = await navigator.fonts.query({select: ['Consolas']});

Not sure why we didn't re-open this earlier, but I'd consider it resolved now.