Different file format for the same resource

[bramstein]

I'm curious how this would work with web fonts and other resources that can have multiple file formats. Let's say this gets adopted by modern browsers, how would I ensure that only the correct font format is preloaded? Would this work?

<link rel="preload" href="font.woff" type="application/font-woff" as="font">
<link rel="preload" href="font.woff2" type="application/font-woff2" as="font">

[yoavweiss]

That will not currently work. We do not have a mechanism to avoid loading of content based on supported mime types.
With that said, maybe we should. (and maybe we should reserve type for that purpose regarding the type vs. as debate)

@igrigorik - It might be a good idea to start a use-cases document where we document all the supported and unsupported use-cases by preload and the Resource Hints.

On top of what @bramstein mentioned, we also have srcset style preloading which we discussed in the past but I don't think we ever documented.

[yoavweiss]

http://www.bramstein.com/writing/preload-hints-for-web-fonts.html is a great use case description for web font preloading. Thanks @bramstein for writing it down :)

[igrigorik]

@bramstein @yoavweiss the content-negotiation case should be handled by specifying custom Accept headers, which is something we've discussed before.. Concretely, you'd do something like: <link rel="preload" href="font.woff2" fetch-settings="{headers: {Accept: application/font-woff2}}" as="font">. This extends outside of preload as well... /cc @annevk

@bramstein nice writeup! One clarification...

It’s im­por­tant to point out that these are hints and not de­mands. Browsers can — and will — ig­nore them in cer­tain cases.

No. Preload is MUST fetch. Prefetch is a MAY fetch :)

[yoavweiss]

@igrigorik while I agree content-negotiation can take care of this issue for some users, it won't answer all the use-cases. Specifically, serving fonts from static servers (S3, gh-pages, etc) would be at a disadvantage here.

Specifically regarding your example, it shouldn't include the Accept header value in markup, as it is something that would change from browser to browser. I think the Accept header value should be determined by the value of as (or its future replacement).

[igrigorik]

@yoavweiss hmm, I think we're talking about two slightly different workflows.. The fetch-settings route I suggested is specifically for the case where you want to force the UA to fetch a particular content-type (e.g. woff2 or particular image format). If, on the other hand, you just want the UA+server to pick the optimal variant than as is sufficient: for fonts the UA should advertise support for woff/woff2 via Accept and let the server respond with appropriate resource.

In other words, I think we're agreement? :)

[yoavweiss]

@igrigorik: I think we're in agreement regarding the content-negotiation parts. Do you agree that we should address this case also for cases where content-negotiation is not a viable option?

[igrigorik]

Depends on what you mean by "address" :)

In the simplest form, if you can't re-use the same URL + content-negotiation to pick the right format, then you need to rely on distinct URLs, and nothing stops you from specifying any URL you want via Link or <link>.

That said, I think what you're alluding to is conditional fetching... which, to me, is a whole separate topic. In theory that's what media queries are for - e.g. for the use case @bramstein highlighted you want something like "@supports(woff2)".

• Preload should respect me media queries
• Media queries should allow you to run relevant @supports test to do conditional fetching

[yoavweiss]

Why not reuse type for the purpose of conditional loading?

For external resource links, the type attribute is used as a hint to user agents so that they can avoid
fetching resources they do not support. If the attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type, e.g. the empty string). If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. If the UA does not support the given MIME type for the given link relationship, then the UA should not obtain the resource

[igrigorik]

@yoavweiss addressed in #29, see: https://rawgit.com/w3c/preload/processing/index.html#dfn-appropriate-times

[Zauberbutter]

Is there anything new on this?

[yoavweiss]

@Cerberooo - This was addressed years ago, as the above comments indicate. If your use-case is somehow not supported, please file another issue.

[Zauberbutter]

Thanks for your reply.

That will not currently work.

I just want to know if it's possible or not by now.

[yoavweiss]

The type attribute works with preloads, but it does not enable you to exclude older, supported formats. That means you currently can preload the woff2 variant only in supporting browsers, but you won't be able to preload the woff variant only in browsers that don't support woff2 (since that variant is supported in newer browsers as well).

My advice is to use preload only for the latest format, which should probably cover most users by now. Older browsers will not get this optimization, but are likely to not support preload either, so that's most probably fine.