You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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?
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
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
andav01.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.
The text was updated successfully, but these errors were encountered: