There doesn't seem to be an API change here, so I don't think this has to go through the proposal process. Unless I'm missing something.

How about detecting first, whether quoting and/or escaping is needed at all, and foregoing it otherwise?

One of the first pieces of Go code I ever wrote was for this exact purpose:

1. Replace all ampersands with & entities.

2. Determine, whether the attribute value needs to be quoted, i.e. whether it contains quotable (any of " ' ` = < or >) and/or whitespace characters.

   If not, we're done here, return the string as it is (after having escaped &s).

3. Pick the quote (single or double) that is less prevalent in data, escape that.

   This avoids turning foo with value "b""a""r" into foo=""b""a""r"" when it can be foo='"b""a""r"'.

4. Wrap the escaped value in the opposite quote and return.

It does take at most two passes over the string (one to detect quotables and to pick a quote, other to emit escaped quote), but IMO the benefit balances the cost.

@ianlancetaylor

There doesn't seem to be an API change here, so I don't think this has to go through the proposal process. Unless I'm missing something.

This will definitely break some tests so I am proposing this change to weigh with you all if this looks like it is worth the cost. If you think it would make it clearer that this is not an API change I can rename this to be a normal feature request rather than a proposal.

@antichris Thanks for the suggestion. One of the reasons I am proposing this is to simplify the logic in this package and make it more consistent. While your proposal would indeed make escaped strings shorter it would definitely make the logic more complex and the rendered HTML less consistent. Unless you can find a common use case that foresee a big amount of quotes in an HTML attribute value I'd rather keep it simpler and always use the same quotes. Does this make sense to you?

@empijei OK, thanks.

I support this. html/template is meant to be secure and easy to use, not to allow ultimate control over how the generated HTML looks like (as opposed to how it behaves). If we can generate output that is equivalent but is safer and simpler, sounds great.

@empijei

Unless you can find a common use case that foresee a big amount of quotes in an HTML attribute value, I'd rather keep it simpler and always use the same quotes.

I got two right off the top of my head: data:image/svg+xml URIs and JSON data. For an example of the latter, you can view the source of this very page and look for the optimizely-datafile meta tag: nearly 40% of its content are " entities. I'd say that's significant. The SVG URIs also suffer under current implementation escaping < and > (which don't mean anything special when quoted, therefore require no escaping).

And then there's also inline style and scripts (on<event> and such), of course, but people are supposed to be using single quotes in CSS and JS. Also, people are supposed to avoid using inline stuff in general, but it's not like many care to.

[..]
And then there's also inline style and scripts (on<event> and such), of course, but people are supposed to be using single quotes in CSS and JS. Also, people are supposed to avoid using inline stuff in general, but it's not like many care to.

You're, of course, right. However inlining resources is unavoidable for certain common cases, e.g.: e-mails.

Does it make sense to introduce a new function to the API to be more opinionated in these specific cases? Providing more context by exposing a slightly richer API might: keep the logic simpler, allow to stay backwards compatible yet provide to the proposal.

The reason I'm pitching in is because of #42506 which might be solved by hitchhiking on this issue

To make sure I understand, is the concern purely a matter of readability and size of the generated HTML, or are there cases where this would cause semantic changes or breakage?