<script>'s language attribute is not whitespace-stripped in actual implementations

[hiroshige-g]

A minor issue:

In the current spec, script language attributes with valid value + trailing whitespaces would be executed, e.g.

• <script language="javascript ">,
• => the script block's type string would be "text/javascript "
• with leading and trailing ASCII whitespace stripped => "text/javascript"
• => JavaScript MIME type essence match => OK

but this whitespace stripping is not performed on Safari/Firefox/Chrome, according to https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/script-type-and-language-js.html.

I think it's better to modify the spec to align with the implementations, like:

• Otherwise, if the script element has a type attribute, let the script block's type string for this script element be the value of that attribute with leading and trailing ASCII whitespace stripped.
• Otherwise, the element has a non-empty language attribute; let the script block's type string for this script element be the concatenation of the string "text/" followed by the value of the language attribute.
• If the script block's type string with leading and trailing ASCII whitespace stripped is a JavaScript MIME type essence match, the script's type is "classic".

[annevk]

Nice find! Willing to create a PR for this?

[Yay295]

I'm not following those tests. It shows both of these passing for all four browsers:
Script should run with type="text/javascript "
Script shouldn't run with language="javascript "

But according to the steps you listed these should both have a type string of "text/javascript" and be valid.

[hiroshige-g]

Sure, I'll create a PR later when I have time.

@Yay295 Right, the WPT's expectation doesn't match with the current spec, and instead matches with the proposed change here.

[hiroshige-g]

Memo: I'll wait for #7876 to land before creating a PR to avoid conflicts.

[domenic]

@hiroshige-g ready to create a PR for this?