Skip to content

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

Closed

Description

@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>.

Activity

  1. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

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

  2. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

    This also applies to <style type>.

  3. changed the title [-]<script type> and MIME type parameters[/-] [+]<style type>/<script type> and MIME type parameters[/+] on Sep 7, 2017
  4. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

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

  5. domenic commented on Sep 7, 2017

    @domenic
    Member

    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.

  6. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

    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.

  7. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

    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.

  8. domenic commented on Sep 7, 2017

    @domenic
    Member

    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.

  9. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor

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

  10. annevk commented on Sep 7, 2017

    @annevk
    MemberAuthor
  11. domenic commented on Sep 7, 2017

    @domenic
    Member

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

  12. self-assigned this
    on Sep 7, 2017
  13. added 2 commits that reference this issue on Sep 8, 2017
    509e84f
    34d65dd
  14. annevk commented on Sep 14, 2017

    @annevk
    MemberAuthor

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

  15. added a commit that references this issue on Sep 14, 2017
    9c612ac
  16. added a commit that references this issue on Jan 8, 2019
    771c5b0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions