<style type>/<script type> and MIME type parameters

[annevk]

Firefox ignores them, Chrome and Safari require them to not be present. I vastly prefer Chrome and Safari behavior as that allows for just string matching here.

Live DOM Viewer test: <script type=text/javascript;x>w(1)</script>.

[annevk]

(Note that valid parameters, such as text/javascript;charset=utf-8, don't make any difference.)

[annevk]

This also applies to <style type>.

[annevk]

(Somewhat related to ongoing research over at whatwg/mimesniff#30.)

[domenic]

I'm pretty sure for script at least the spec requires them not to be present or else it's treated as a data block. Definitely will be good to add tests.

[annevk]

It doesn't really. It says "MIME type" and "valid MIME type", both of which include parameters as far as I can tell. So there's all sorts of problems here for sure.

[annevk]

Ah, but the processing model does call for an ASCII case-insensitive match of a JavaScript MIME type, so we got that going for us.

[domenic]

Determine the script's type as follows:

If the script block's type string is an ASCII case-insensitive match for any JavaScript MIME type, the script's type is "classic".

and then in the definition of JavaScript MIME type,

When examining types to determine if they represent supported languages, user agents must not ignore MIME parameters. Types are to be compared including all parameters.

We could do some cleanup to make things clearer, but I think at least from the processing model side, we're covered.

[annevk]

Yeah, and for <style> we're not covered due to being overly generic which you filed an issue on already.

[annevk]

Firefox bug for <script type>: https://bugzilla.mozilla.org/show_bug.cgi?id=1397822.

[domenic]

I can work on the spec side of this for script and also style de-genericization today.