-
Notifications
You must be signed in to change notification settings - Fork 31
Different file format for the same resource #28
Comments
That will not currently work. We do not have a mechanism to avoid loading of content based on supported mime types. @igrigorik - It might be a good idea to start a use-cases document where we document all the supported and unsupported use-cases by On top of what @bramstein mentioned, we also have |
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 :) |
@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: @bramstein nice writeup! One clarification...
No. Preload is MUST fetch. Prefetch is a MAY fetch :) |
@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 |
@yoavweiss hmm, I think we're talking about two slightly different workflows.. The In other words, I think we're agreement? :) |
@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? |
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 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)".
|
Why not reuse
|
Is there anything new on this? |
@Cerberooo - This was addressed years ago, as the above comments indicate. If your use-case is somehow not supported, please file another issue. |
Thanks for your reply.
I just want to know if it's possible or not by now. |
The 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. |
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?
The text was updated successfully, but these errors were encountered: