Open kbolino opened 2 years ago
Well, I just discovered an interesting wrinkle that could undermine some of the suggestions: there doesn't seem to be a good rule to escape the things you put inside of comments
@kbolino I'm not clear: are you retracting the proposal?
No, at least not without some kind of resolution (even if it is merely to finally document this behavior). I thought a bit on this last night, and putting some of the other ideas along with that unfortunate discovery together, I'd propose a middle-ground solution:
Define a template option htmlcomments
which takes one of the following values:
remove
(= default
) which corresponds to the current behaviorerror
which causes an error to be returned (ideally by the Parse*
functions, i.e. as early as possible) if an HTML comment is present in the templateallow
which enables HTML comments to pass through to rendered output, but Execute
will still fail with an error if a value substitution inserts --
or >
into a comment blockI have no idea how feasible this solution is, but could do some code research into whether it would be possible.
We have interest in resolution of this issue - can we help with resolving this? Currently we stumbled upon this issue because we are using html/template for mail templates where <!--[if IE 8]>
html comments are used - unfortunately they are breaking without that fix currently.
So we are interested in the implementation of the proposal and could even help with it if necessary :)
I'm also struggling with this behaviour, similarly to https://github.com/golang/go/issues/54380#issuecomment-1999816747
I'm using html/template with an email program and use of <!--[if mso | IE]><![endif]-->
comments is being stripped out of my HTML that I generate, causing broken emails for outlook users :roll_eyes:
Is there much likelihood that this proposal is going to be followed up?
-- EDIT -- Or if anyone has suggestions for a workaround that would be amazing!
Here's an adaptation of the suggestion from the StackOverflow answer, which seems to work fine in the playground:
const src = `<html><body>
<div>Some <b>HTML</b> content</div>
{{ ifmso }}
<div>Microsoft Outlook Only</div>
{{ endif }}
</body></html>`
func main() {
t := template.Must(template.New("").Funcs(template.FuncMap{
"ifmso": func() template.HTML { return template.HTML(`<!--[if mso|IE]>`) },
"endif": func() template.HTML { return template.HTML(`<![endif]-->`) },
}).Parse(src))
t.Execute(os.Stdout, nil)
}
Caveat emptor: The docs for template.HTML
specifically say not to use it for unterminated comments, so YMMV. I created an updated version which attempts to inject HTML and instead gets proper escaping, so this hack doesn't seem to break the HTML parser state. You may want to pick better names because the more I read this thing I wrote the more endif
looks like a template language keyword (it's not) rather than a custom function. Some upper case might help.
The right solution here of course is to bully Microsoft as much as possible into dropping its antiquated email rendering engine, and/or getting clients off of Microsoft Outlook. But that is beyond the scope of what Go can address.
If Go could get users off of Outlook it would truly be a marvel 😅
The trouble I had is that I'm using MJML to generate my email html templates and it isn't simple (nor very nice for the next dev) to have to go through and replace the comments it applies with the something like you've suggested. But I appreciate that for a lot of situations that is a decent workaround.
Thanks!
Background
The
html/template
package completely strips HTML comments from the rendered output. This is apparently intentional (#14256) but is not documented (#28628). The best summation of the rationale I could find comes from the mailing list:To wit, "these types of comments" seems to refer to old-school conditional comments like
<!--[if lt IE 9]>...<![endif]-->
. I don't know if these comments even do anything anymore on modern browsers, and a quick Google search wasn't very revealing.The canonical solution to this problem seems to be to use the
template.HTML
type to wrap "trusted" strings. For example, there's this StackOverflow answer recommending this approach. However, this means that only way to use comments literally in the template is via function-call indirection, e.g.:This also imposes the limitation that comments cannot have injected values within them.
Rationale for Change
I contend that based upon my own and a number of others' experiences, this behavior is unexpected. First of all, there are uses for comments besides affecting the browser's behavior (e.g. including debugging info useful to the developer). Second, many will have never seen or used IE "conditional comments" in no small part because IE is (almost) dead. Third, if the rationale for this behavior is to address the specific concern of conditional context confounding the auto-escaping mechanism, then I would think that only those comments which raise that issue would be stripped, not all comments. Fourth, of course, is the total lack of documentation of this behavior in the package itself.
There is another proposed "solution" already which is to fall back to using
text/template
but that is obviously a dangerous regression as then one gives up on all the benefits ofhtml/template
.Though server-side manipulation of HTML is falling by the wayside in favor of script-heavy web apps doing extensive DOM manipulation client-side, the
html/template
package is not deprecated, and all browsers still (mostly) support "Web 1.0" sites that have minimal or no scripts.Finally, the package documentation does say the following:
Whereas the policy of stripping comments seems to contradict this maxim.
Thus I believe this unintuitive behavior is ripe for change, albeit ideally in a backwards-compatible way.
Possible Paths
comment
function that takes a string argument, escapes it properly for the body of a comment, surrounds it with comment markup, and finally wraps the result intemplate.HTML
, this way you could at least inject values safely but indirectly withprintf
Any of the above suggestions could also be gated, e.g. with
template.Option
, to improve backwards compatibility.