Thanks. So you mean the response MIME of server right?
-
-
Replying to @aminpakseresht @rauschma and
From my article on dynamic import(): https://developers.google.com/web/updates/2017/11/dynamic-import … Although browsers support other MIME types, only `text/javascript` should be used for JavaScript: https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages …pic.twitter.com/9mrCYDVd0n
1 reply 0 retweets 9 likes -
Replying to @mathias @aminpakseresht and
But isn’t text/javascript obsolete? I’ve always thought application/javascript is the most correct MIME type for JavaScript.
1 reply 0 retweets 0 likes -
Replying to @valtlai @aminpakseresht and
That’s not the case. See the links in my previous tweet for the explanation.
1 reply 0 retweets 1 like -
Replying to @mathias @aminpakseresht and
Hmm
If you google, everyone says that application/javascript is the correct one. See also: https://tools.ietf.org/html/rfc4329#section-8 …1 reply 0 retweets 0 likes -
1 reply 0 retweets 0 likes
-
Replying to @valtlai @aminpakseresht and
I don’t know what else to tell you. Browsers support other MIME types as well. But the HTML Standard recommends text/javascript and actively recommends against other MIME types, per my earlier link.
2 replies 0 retweets 0 likes -
Mathias, how is that for json? I believe we use application/manifest+json in the web app manifest - would you recommend us to change that?
1 reply 0 retweets 0 likes -
Replying to @kennethrohde @valtlai and
Per https://w3c.github.io/manifest/#media-type-registration …, the MIME type for a manifest is application/manifest+json. Don’t change a thing :)
1 reply 0 retweets 1 like -
Yes, I know, I am a co-editor of that spec :-) We based it on "application/json"
1 reply 0 retweets 0 likes
I guess my point is that RFCs don’t always end up matching reality. WHATWG and most W3C standards do, by design, as they’re usually updated once the spec and reality diverge.
-
-
Replying to @mathias @kennethrohde and
A similar example is UTF-8. Its RFC describes a version that supports code points up to U+7FFFFFFF. In reality, Unicode stops at U+10FFFF and that’s what real-world UTF-8 implementations support nowadays. TL;DR https://encoding.spec.whatwg.org/#utf-8 > original UTF-8 RFC
0 replies 1 retweet 4 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.