Enable preload to download variable fonts only in supporting browsers

[o-t-w]

It would be nice to add the ability to test for variable font support so that a variable font can be requested only in browsers that support it and not in ones that don't.
Something like:
<link rel="preload" href="fonts/source-sans-variable.woff2" as="font" type="font/woff2-variations" crossorigin="anonymous">
would match the new @font-face syntax:
@font-face { font-family: 'sourcesans'; src: url('source-sans-variable.woff2') format('woff2-variations'); }

[yoavweiss]

The use-case makes sense, and the preload mechanisms are already there (as you mentioned in your examples).

What we need is to define dedicated MIME types for the "variations" variants of the font formats, so that supporting browsers would preload the variable fonts .

@svgeesus - I believe you know something about fonts and MIME types. How can we make this happen?

[svgeesus]

Related w3c/csswg-drafts#633

[plehegar]

it doesn't look like the mime type solution would work here. One alternative would be to add a css-support attribute to with a syntax that accepts the same as @supports. But that would mean that one can put a descriptor in @supports, which isn't the case today.

[yoavweiss]

@plehegar why wouldn't a mime type solution work?

[yoavweiss]

@plehegar friendly ping :)

[o-t-w]

Any update on this?

[Munter]

My take on why a mime-type resolution won't work:

Let's say I have preload for both woff2 and variable fonts, in order to still provide a fast loading experience for older browsers:

<link rel="preload" href="font.woff2" type="font/woff2">
<link rel="preload" href="variable-font.woff2" type="font/woff2-variations">

A variable-font capable browser would download both files since woff2 is supported, as well as the variable font.

What a CSS-like @supports implementation would give us is the ability to use :not() to create exclusive preload of only one of many possible files. It would still feel like a hack, but at least it would allow you to manually implement the behavior that the CSS @font-face block does.

In the completely ideal case, seen from a font perspective alone, I should be able to just declare that these files are all alternative forms the same content, and you should choose the best one. In the same way as in the @font-face block. I can see why that probably wouldn't give enough value outside of fonts to become a standards implementation.

[o-t-w]

@Munter

<link rel="preload" href="font.woff2" type="font/woff2">
<link rel="preload" href="variable-font.woff2" type="font/woff2-variations">

A variable-font capable browser would download both files since woff2 is supported, as well as the variable font.

Yes people might do this, which would be wasteful and bad. I think it is important to not degrade the performance of less-capable browsers by making them download a large variable font they can't make use of, whereas not preloading a regular font for them feels reasonable to me.

Its possible to use preload to do wasteful things already. e.g. you could preload both jpeg and webp images and only use the webp ones.

While it's nice to entirely prevent developers from making bad performance decisions, best practices for using preload can be documented and made clear to developers through blog posts/resources etc.

[Munter]

@o-t-w

Yes people might do this, which would be wasteful and bad

I'm sorry, preloading a font for a browser is in no way bad. The standards not being capable of expressing the ability to preload an older format for an older browser is what is problematic. Even though it may seem reasonable to you to leave any current generation browser behind, I disagree with you that a standards body should take such a stance.

There should be a way to preload relevant formats for the current browser in a declarative non-javascript way, while not preloading irrelevant formats. If there is any place to be ideological it's here

[yoavweiss]

@Munter - the issue you're raising seems like a separate one. You'd like to be able to preload based on type, but combine more complex logic than what type currently allow. (e.g. "load if type A is supported and type B is not supported")

That seems like a legitimate missing use-case for preload, as well as other <link> related primitives (e.g. load one stylesheet that uses webp BG images for supporting browsers and load another, using JPG images for non-supporting ones. Or for fonts, include different stylesheets for browsers supporting variable fonts.)

Currently the best way to tackle such complex logic is on the server-side using accept headers. If variable fonts had their own MIME type, browsers could advertize their support, and enable server side differential serving.

If you are interested in a client-side way to do that, it seems like opening an issue with the HTML spec and describing your use-case there is the best route to get such generic support.

[ghost]

Munter wrote:

A variable-font capable browser would download both files since woff2 is supported, as well as the variable font.

That is not correct, because "A web font is only downloaded when it is used in a CSS selector that matches a DOM connected node"

@yoavweiss Can I ask you, take the following code example:

<link rel="preload" href="font.woff2" type="font/woff2">
<link rel="preload" href="variable-font.woff2" type="font/woff2-variations">

Would the Browser only preload a single file from the above code example or preload both?

[yoavweiss]

A browser that supports both types will preload both. Preload doesn't wait for the font to be used before it downloads it, otherwise it wouldn't make much sense (as it wouldn't kick off the download before the regular CSS mechanisms will)

[ghost]

@yoavweiss Quick question, W3c have changed their spec with CSS Fonts Module Level 4, as per here: https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing

The old method for variable fonts was this:

@font-face {
 font-family: 'Gentium';
 src: url(gentium-var.woff2) format('woff2-variations'),
      url(gentium-static.woff2) format('woff2');
}

The new way is this:

@font-face {
 font-family: 'Gentium';
 src: url(gentium-var.woff2) format('woff2' supports variations),
      url(gentium-static.woff2) format('woff2');
}

With regards to Preloading variable fonts how do we write the new type now?

Would it be like this?

<link rel="preload" href="variable-font.woff2" type="font/'woff2' supports variations">

[yisibl]

I suggest adding supports attribute to <link> to match CSS specifications:

<link rel="preload" href="variable-font.woff2" as="font" type="font/woff2" supports="variations">
<link rel="preload" href="COLRv1-font.woff2" as="font" type="font/woff2" supports="color(COLRv1)">

This can also be used in video:

<link rel="preload" href="cat.webm" as="video" type="video/webm" supports="VP9">
<link rel="preload" href="cat.webm" as="video" type="video/webm" supports="H.264">

See also: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs#common_codecs

IMO, a general solution should be sought, not just fonts.

[svgeesus]

@plehegar why wouldn't a mime type solution work?

A MIME-based solution would duplicate the existing functionality of supports and would therefore require additional spec text to clarify the precedence if both methods of doing the same thing are used together and say different things.

A MIME-based solution would be a clear way forward for server-choice classical conneg (Accept header, q factors, server decides what to send) but is not needed for the more modern browser-choice conneg (content creator describes the actual options available, browser picks the best one and requests it).

[yoavweiss]

A MIME-based solution would duplicate the existing functionality of supports

Can you clarify which "supports" you were referring to? The link is just pointing at this issue.

[svgeesus]

Ah the CSS supports feature got changed and is now tech(). So this example would use a variable font if supported and a static one if not:

@font-face {
    font-family: "Trickster";
    src: 
      url("trickster-var.otf") format(opentype) tech(variations),
      url("trickster-static.otf") format(opentype);
}

[svgeesus]

I suggest adding supports attribute to to match CSS specifications:

Yes, though now it would be a tech attribute instead. But taking the same values that CSS tech() does

[yoavweiss]

Discussion continues at whatwg/html#7888