Different file format for the same resource #28

Closed
bramstein opened this Issue Aug 5, 2015 · 9 comments

Projects

None yet

3 participants

@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
Contributor

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
Contributor

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
Member

@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
Contributor

@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
Member

@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
Contributor

@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
Member

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
Contributor

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 igrigorik closed this Aug 21, 2015
@alanorth alanorth referenced this issue in alanorth/hugo-theme-bootstrap4-blog Nov 14, 2016
Closed

prefetch of web fonts #11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment