Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different file format for the same resource #28

Closed
bramstein opened this issue Aug 5, 2015 · 13 comments
Closed

Different file format for the same resource #28

bramstein opened this issue Aug 5, 2015 · 13 comments

Comments

@bramstein
Copy link

@bramstein bramstein commented Aug 5, 2015

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
Copy link
Contributor

@yoavweiss yoavweiss commented Aug 6, 2015

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
Copy link
Contributor

@yoavweiss yoavweiss commented Aug 8, 2015

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
Copy link
Member

@igrigorik igrigorik commented Aug 11, 2015

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

@yoavweiss yoavweiss commented Aug 17, 2015

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

@igrigorik igrigorik commented Aug 18, 2015

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

@yoavweiss yoavweiss commented Aug 19, 2015

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

@igrigorik igrigorik commented Aug 19, 2015

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
Copy link
Contributor

@yoavweiss yoavweiss commented Aug 20, 2015

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

@Cerberooo
Copy link

@Cerberooo Cerberooo commented Nov 18, 2018

Is there anything new on this?

@yoavweiss
Copy link
Contributor

@yoavweiss yoavweiss commented Nov 19, 2018

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

@Cerberooo
Copy link

@Cerberooo Cerberooo commented Nov 19, 2018

Thanks for your reply.

That will not currently work.

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

@yoavweiss
Copy link
Contributor

@yoavweiss yoavweiss commented Nov 19, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.