search

w3c / woff

WOFF File Format specifications
https://w3c.github.io/woff/woff2/
Other
20 stars 11 forks source link

MIME type distinction for variable fonts #2

Open yoavweiss opened 6 years ago

yoavweiss commented 6 years ago

In https://github.com/w3c/preload/issues/118 there's a use case describing preloading of variable fonts only in supporting browsers. preload already has mechanisms to solve that, but they are based on MIME type, and AFAICT there's no MIME type defined for the variable font variants of WOFF2, TTF, etc.

Is it possible to define such a MIME type so that content negotiation or client-side preloading of the right font is possible?

/cc @svgeesus

svgeesus commented 3 years ago

Could the supports feature from CSS Fonts 4 be used for this (if it is still needed)?

svgeesus commented 3 years ago

I see this was already suggested

yoavweiss commented 3 years ago

Preload is not the only consumer for MIME types. Accept headers based content negotiation also uses it. It seems significantly better to change/add to the mime type when new features are added, rather than add a separate content negotiation dimension.

vlevantovsky commented 3 years ago

The subtype 'woff2' defines the container format, and IMO it needs to be there to determine what type of decoder implementation is needed to consume the data. However, since the WOFF2 file can have multiple different payload formats (different outline formats / layout tools, static vs. variable fonts, etc.), it may make sense to define a set of optional parameters that would identify the specific type of a font data packaged inside the WOFF2 file, similar to how it was done e.g. for generic SFNT font type

svgeesus commented 3 years ago

Optional parameters on MIME types have historically been little used, because normal web developers have no control over advanced setup for the web servers they use, even if they decide in advance on some strategy (file naming, folder naming, a smart server component) to allocate the correct parameters.

yoavweiss commented 3 years ago

I think you're confusing 2 different things here: a) MIME types as set by the server to tell the client what the content is b) MIME types used by the client to indicate support.

a) is indeed not likely to be used and generally uninteresting. b) is what this is about, and lack of access to the web server's parameters shouldn't impact developers: For client side negotiation, no server need to change. For server side content negotiation, the assumption is that the developers are writing their own serving logic.

svgeesus commented 3 years ago

I'm not confusing them at all, I am fully aware of the distinction.

But yes, to clarify, the first method - classical, server-choice conneg where the client sends an Accept header containing list of acceptable types, perhaps with q factors, and the server decides what resource is returned - has historically been poorly implemented (like browsers sending the same accept list for all requests, servers hard or impossible to configure), is tricky to set up even if access is available, and typically does not work well because there isn't a single ranking of "best" that meets all circumstances.

The second method - browser-choice conneg where the content creator explicitly lists the options and the browser chooses among them based on things like screen resolution, supported codecs, etc - works much better. This is what is used for the source element, for @font-face and so on. For source, in addition to type to hold the MIME type, there are the media , srcset and sizes attributes to help guide the choice. For @font-face (which historically did not use MIME types at all, due to resistance at the time to a font top-level type, now resolved) in addition to format to hold a MIME-analog there is also supports and of course @media and @supports.

As you say, the developers are writing their own logic. I don't see how stuffing everything into a MIME type helps developers, compared to having several attributes. And the Accept header is not used in this scenario.

yoavweiss commented 3 years ago

the first method - classical, server-choice conneg where the client sends an Accept header containing list of acceptable types, perhaps with q factors, and the server decides what resource is returned - has historically been poorly implemented (like browsers sending the same accept list for all requests, servers hard or impossible to configure), is tricky to set up even if access is available, and typically does not work well because there isn't a single ranking of "best" that meets all circumstances.

Citation needed :)

The use of Accept is not perfect (in the sense that it's hard to extend it as support for formats diverges), but is being actively used by CDNs and other servers. It'd be great to come up with an alternative server-side conneg solution, but Accept is what the industry uses today.

The second method - browser-choice conneg where the content creator explicitly lists the options and the browser chooses among them based on things like screen resolution, supported codecs, etc - works much better. This is what is used for the source element, for @font-face and so on.

It works great for some use cases, particularly the ones where the developer actually cares about the content negotiation. In other cases, where automatic format selection is preferred, these mechanisms don't work quite as well.