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

Avoid minifying MIME types in type attribute #545

Closed
icpmoles opened this issue Dec 3, 2022 · 2 comments
Closed

Avoid minifying MIME types in type attribute #545

icpmoles opened this issue Dec 3, 2022 · 2 comments

Comments

@icpmoles
Copy link

icpmoles commented Dec 3, 2022

Hi, while using Hugo I stumbled upon this wrong behavior of the minifier, it minifies the string of the codec specified in the source element while it's not supposed to.

Example input

<video width="320" height="240" controls>
 <source src="movie.mp4" type="video/mp4; codecs="av01.0.05M.08"">
</video>

Intended behavior:
<video width=320 height=240 controls><source src="movie.mp4" type="video/mp4;codecs="av01.0.05M.08""></video>

Actual behavior:
<video width=320 height=240 controls><source src="movie.mp4" type="video/mp4;codecs="av01.0.05m.08""></video>

(notice the M/m)

The HTML Spec for MIME types is based on the RFC 6381 that requires the codec string to be case sensitive.

It's possible to see how switching case in the codec strings breaks the codec support:
Open media-mime-support test and paste in the input box various codec strings like av01.0.00H.12 and av01.0.00h.12 etc., in the latter the test will return a negative result.

Reading in the past issues this seems a known problem already encountered by other users that was supposed to be fixed after #270 but it looks like this edge case was missed.

@tdewolff
Copy link
Owner

tdewolff commented Dec 5, 2022

Thanks for the indepth issue, should be resolved now!

tdewolff added a commit that referenced this issue Dec 5, 2022
@tdewolff
Copy link
Owner

tdewolff commented Dec 5, 2022

See https://www.rfc-editor.org/rfc/rfc6838 for the reason why it was implemented this way though, it specifically states that parameter values should be case-insensitive. It seems to me that only string contents should be case sensitive, I've adjusted accordingly.

Anyways, is your HTML attribute valid with the nested double quotes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants