Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
annevk opened this issue Sep 7, 2017 · 11 comments
Closed

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

annevk opened this issue Sep 7, 2017 · 11 comments
Assignees
Labels
interop Implementations are not interoperable with each other topic: script topic: style

Comments

@annevk
Copy link
Member

annevk commented Sep 7, 2017

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 annevk added interop Implementations are not interoperable with each other topic: script labels Sep 7, 2017
@annevk
Copy link
Member Author

annevk commented Sep 7, 2017

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

@annevk
Copy link
Member Author

annevk commented Sep 7, 2017

This also applies to <style type>.

@annevk annevk changed the title <script type> and MIME type parameters <style type>/<script type> and MIME type parameters Sep 7, 2017
@annevk
Copy link
Member Author

annevk commented Sep 7, 2017

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

@domenic
Copy link
Member

domenic commented Sep 7, 2017

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
Copy link
Member Author

annevk commented Sep 7, 2017

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
Copy link
Member Author

annevk commented Sep 7, 2017

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
Copy link
Member

domenic commented Sep 7, 2017

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
Copy link
Member Author

annevk commented Sep 7, 2017

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

@annevk
Copy link
Member Author

annevk commented Sep 7, 2017

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

@domenic
Copy link
Member

domenic commented Sep 7, 2017

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

@domenic domenic self-assigned this Sep 7, 2017
domenic added a commit that referenced this issue Sep 8, 2017
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
domenic added a commit that referenced this issue Sep 8, 2017
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
@annevk
Copy link
Member Author

annevk commented Sep 14, 2017

Updated the Firefox bug to also cover <style type>.

annevk pushed a commit that referenced this issue Sep 14, 2017
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes whatwg#2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes whatwg#2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to whatwg#2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes whatwg#3022.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interop Implementations are not interoperable with each other topic: script topic: style
Development

No branches or pull requests

2 participants