You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 5, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on May 5, 2022. It is now read-only.
The processing of type with <link rel=preload> should not differ from the processing of type in <picture><source></picture>.
Looking at https://html.spec.whatwg.org/multipage/images.html#updating-the-source-set (step 4.8) it seems to be the case. (HTML just doesn't point at the definition of "supported MIME type" but to "MIME type" itself)
I'll be happy to switch preload (as well as HTML's image processing) to any definition of that term that you prefer.
The reason I brought up <picture> is because that's the one I know requires similar hooks. You're right that <video><source> is similar, and it seems to be using "a type that the user agent knows it cannot render", which would also fit the bill if defined in a way that is not media specific.
What about text/html?
I'm not sure what you mean by that. Can you elaborate?
I think I still don't understand your requirements. What <picture> and <video> need seems much more limited. Again, in OP I brought up text/javascript, which isn't typically seen by the user. Is that something you might preload? I'd think so.
I don't think there's a true use case to avoid loading <link rel=preload as=image type="text/javascript"> or the like. The important thing with type is to avoid loading resources that the UA does not support at all. Is this the part that wasn't clear to you about the requirements for preload? Or is it something else?
As an aside, it's not clear to me from updating the source set algorithm what should be done with e.g. <picture><source srcset=foo type="text/javascript"><img></picture>.
That's probably a good bug to file against "updating the source set".
I was just asking since the current text talks about being able to interpret the resource and present it. But we support some types we don't really present as well. And yeah, type being used with a value that doesn't match as is confusing too. The text should probably clarify that type is being used as a boolean check irrespective of other attributes (or we need to define something more detailed).
I don't think that's a useful thing to have similar to how not having a "parseable URL" is fine. You parse something and then you use it for all kinds of things. You don't continue parsing it for use in a conditional.
@annevk getting back to this. IIUC, what we need here (other than changing the link from "parsable mime type" to "mime type") is to redefine "supported by the user agent" in a way that's not tied to presentation. Does that match your understanding?
I think it also needs to be made clearer when type is involved in the decision making process and how the user agent is to react to different values. E.g., if Chrome were to preload <link rel=preload as=image type=text/javascript>, but Firefox would not, and the specification were to allow either, I think there's a problem.
Activity
yoavweiss commentedon Oct 9, 2017
The processing of
typewith<link rel=preload>should not differ from the processing oftypein<picture><source></picture>.Looking at https://html.spec.whatwg.org/multipage/images.html#updating-the-source-set (step 4.8) it seems to be the case. (HTML just doesn't point at the definition of "supported MIME type" but to "MIME type" itself)
I'll be happy to switch preload (as well as HTML's image processing) to any definition of that term that you prefer.
annevk commentedon Oct 9, 2017
So you just want to match
<picture>? What about<video><source>? What abouttext/html?yoavweiss commentedon Oct 10, 2017
The reason I brought up
<picture>is because that's the one I know requires similar hooks. You're right that<video><source>is similar, and it seems to be using "a type that the user agent knows it cannot render", which would also fit the bill if defined in a way that is not media specific.I'm not sure what you mean by that. Can you elaborate?
annevk commentedon Oct 10, 2017
I think I still don't understand your requirements. What
<picture>and<video>need seems much more limited. Again, in OP I brought uptext/javascript, which isn't typically seen by the user. Is that something you might preload? I'd think so.yoavweiss commentedon Oct 12, 2017
I don't think there's a true use case to avoid loading
<link rel=preload as=image type="text/javascript">or the like. The important thing withtypeis to avoid loading resources that the UA does not support at all. Is this the part that wasn't clear to you about the requirements for preload? Or is it something else?As an aside, it's not clear to me from updating the source set algorithm what should be done with e.g.
<picture><source srcset=foo type="text/javascript"><img></picture>.annevk commentedon Oct 12, 2017
That's probably a good bug to file against "updating the source set".
I was just asking since the current text talks about being able to interpret the resource and present it. But we support some types we don't really present as well. And yeah,
typebeing used with a value that doesn't matchasis confusing too. The text should probably clarify thattypeis being used as a boolean check irrespective of other attributes (or we need to define something more detailed).domenic commentedon Oct 13, 2017
Why would "parseable MIME type" go away? I think it'd be any string/byte sequence for which https://mimesniff.spec.whatwg.org/branch-snapshots/annevk/mime-type/#parse-a-mime-type does not return failure.
annevk commentedon Oct 13, 2017
I don't think that's a useful thing to have similar to how not having a "parseable URL" is fine. You parse something and then you use it for all kinds of things. You don't continue parsing it for use in a conditional.
yoavweiss commentedon Oct 15, 2018
@annevk getting back to this. IIUC, what we need here (other than changing the link from "parsable mime type" to "mime type") is to redefine "supported by the user agent" in a way that's not tied to presentation. Does that match your understanding?
annevk commentedon Oct 16, 2018
I think it also needs to be made clearer when
typeis involved in the decision making process and how the user agent is to react to different values. E.g., if Chrome were to preload<link rel=preload as=image type=text/javascript>, but Firefox would not, and the specification were to allow either, I think there's a problem.Only preload resources with matching type/as attributes
Only preload resources with matching type/as attributes
Only preload resources with matching type/as attributes