-
Notifications
You must be signed in to change notification settings - Fork 24
Parsable MIME type is going away #113
Comments
The processing of I'll be happy to switch preload (as well as HTML's image processing) to any definition of that term that you prefer. |
So you just want to match |
The reason I brought up
I'm not sure what you mean by that. Can you elaborate? |
I think I still don't understand your requirements. What |
I don't think there's a true use case to avoid loading As an aside, it's not clear to me from updating the source set algorithm what should be done with e.g. |
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, |
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. |
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 |
In whatwg/mimesniff#36 I'm changing some of the fundamentals around MIME types. It'll be called a "MIME type" or "MIME type record" now.
I'm also not super happy about the term "supported by the user agent" which I think Preload is the only consumer of:
text/javascript
supported?The text was updated successfully, but these errors were encountered: