Youtube shortcode broken in 0.139.4?

{{< youtube 0HBGSarA6n4 >}}

Hugo 0.139.3:

[...]
src="https://www.youtube-nocookie.com/embed/0HBGSarA6n4?autoplay=0&controls=1&end=0&loop=0&mute=0&start=0"
[...]

Hugo 0.139.4:

[...]
src="https://www.youtube-nocookie.com/embed/0HBGSarA6n4?autoplay=0&amp;controls=1&amp;end=0&amp;loop=0&amp;mute=0&amp;start=0"
[...]

src looks like no place for &amp;s to me.

How is it broken?

{{< youtube
  id=0RKpf3rK57I
  autoplay=true
  start=15
  end=25
>}}

Works great.

No, it doesn’t. It butchers the separators in the URL params and makes them HTML-escaped (&amp; instead of &), so the URL doesn’t make sense anymore.

Please closely examine the examples of correct (0.139.3) and incorrect (0.139.4) behaviour I’ve provided.

Why is that a problem?

Because for the iframe tag (that youtube shortcode produces), the src attribute is supposed to contain a URL.

And while the query part of URI is not well defined in standarts, it is universally recognized that the query delimiter should be an ampersand (&). You are correct in that this is not set in stone, but I’m unaware of any implementations that would treat the five symbols &amp; combined as a query delimiter.

Putting aside your previous comment for a moment, did you try the example I provided?

{{< youtube
  id=0RKpf3rK57I
  autoplay=true
  start=15
  end=25
>}}

The behavior you are seeing is Go’s html/template package doing its thing:
https://go.dev/play/p/dQ41N5k0BwY

Yes, I did. The query delimiters end up being &amp; with that shortcode, too; no change from a simple {{< youtube 0RKpf3rK57I >}} (other than the additional parameters being set to non-default values).

Perhaps. I don’t see how it changes the fact that 0.139.4 produces incorrect HTML where 0.139.3 produced correct HTML.

I think what’s going on here is a preference, not a broken function or a bug.

All browsers treat &amp; in iframe src as a delimiter. There is also no official ruling on & in that attribute, mostly because it leaves the interpretation of the query to the receiving entity:

The query part of a URI in your link actually has a little table next to it that talks about & and ; as delimiters.

Its syntax is not well defined, but by convention is most often a sequence of attribute–value pairs separated by a delimiter.

It’s the task of the receiving “processor” of that information in the URL to sanitize it.

As far as I could test on the iframes I have in my projects, any map/video/embed provider interprets &amp; as & or as a delimiter. I remember times in my early days as a developer (last century) when some browsers had issues with URL-encoded attributes. Those were treated as browser bugs back then.

2 Likes

Actually, there is, and it’s related to what is called an “ambiguous ampersand”.

This will fail HTML5 validation:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
<iframe src="https://example.org?a_x=1&b-x=2&c;x=3"></iframe>
</body>
</html>

You need to do this instead:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
<iframe src="https://example.org?a_x=1&b-x=2&amp;c;x=3"></iframe>
</body>
</html>

Or do what Go’s html/template package does: encode all of them:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
<iframe src="https://example.org?a_x=1&amp;b-x=2&amp;c;x=3"></iframe>
</body>
</html>

Within an HTML attribute, separating query string key-value pairs with &amp; is rarely required, but it is never wrong.

HTML4 References:

HTML5 References:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.