8000 Valueless crossorigin attribute shouldn't be removed · Issue #81 · wilsonzlin/minify-html · GitHub
[go: up one dir, main page]

Skip to content

Valueless crossorigin attribute shouldn't be removed #81

Closed

Description

<link crossorigin ...> is equivalent to <link crossorigin="anonymous" ...>, but running that through minify-html results in <link ...>, which is not equivalent.

As per MDN:

Setting the attribute name to an empty value, like crossorigin or crossorigin="", is the same as anonymous.

and

By default (that is, when the attribute is not specified), CORS is not used at all.

I believe that https://github.com/wilsonzlin/html-data/blob/8e8f101df1641b50307d44e1469aad0fd2256e4a/data/data.json#L1091-L1110 needs to be changed, but I'm not entirely sure how that project's data is generated.

Without this change, minifying valid HTML written as <link rel="preload" crossorigin ...> will lead to, e.g., opaque preload responses that can't be used. (GoogleChrome/web.dev#7770)

Activity

  1. wilsonzlin commented on Apr 26, 2022

    @wilsonzlin
    Owner

    Thanks for raising, I've made the changes into html-data. It turns out the React type definitions that the data is derived from does not consider crossOrigin a boolean attribute, which is why it considers the empty string redundant by default. This may be a bug in the types declaration, or intentional (e.g. force use of empty string). The fix will be part of the next version of minify-html.

    I also had a look into the <meta> tag problem mentioned in the same linked issue, but couldn't immediately reproduce it (I quoted around the attribute value as the source input and minify-html did not remove the quotes). I'd be happy to look into it here (or in a new issue) as it does seem unexpected.

  2. jeffposnick commented on Apr 26, 2022

    @jeffposnick
    Author

    I was able to resolve the <meta> tag problem by opting-in to

    {
      do_not_minify_doctype: true,
      ensure_spec_compliant_unquoted_attribute_values: true,
      keep_spaces_between_attributes: true,
    }

    in our JavaScript configuration, so I'm not as worried about it.

    (As an aside, I see that there's a spec_compliant configuration initializer exposed in the Rust interface, but it's not clear whether the JavaScript bindings' createConfiguration() ends up calling that or not. Is there a difference between calling createConfiguration() with the options supplied above and using the spec_compliant initializer in Rust?)

  3. wilsonzlin commented on Jun 21, 2022

    @wilsonzlin
    Owner

    Awesome, good to hear that the issue is resolved. Version 0.8.1 also fixed the crossorigin attribute handling so it should no longer happen; let me know if it works on your end.

    I've now updated the README to mention the options to keep the output spec-compliant more clearly. The spec_compliant method in Rust simply sets those fields in Cfg to true, and keeps the rest at false, so it's the same as providing them explicitly to createConfiguration() as you have described.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0