It would become unusable for general-purpose text templating[0], and would either break interspersing dynamic text ("this is {{ name }}" with name=Bob would be rendered as "this isBob") within static text or would need a semantic understanding of HTML.

And even then the presence or absence of whitespace in HTML does have rendering impacts (though I don't remember one offhand — aside from linebreaks — it's been a long time since I last hit one), so the template author must be able to control it and importantly to keep whitespace present between static and dynamic items.

[0] html/template is a relatively thin layer over text/template with built-in XSS security where the original does "raw" output by default

I just think that a simpler solution would be to always ignore the first line break after the range begin and end tags. I can't really see the case where that would cause an issue, if you REALLY do need the "extra" line break just put it inside the range.

Whitespaces shouldn't be touched, just parse them though and don't process them.

That would make the templates look more like those of Django and Jinja2, which most seem comfortable with.

Funny that you mention Jinja.

This is actually a feature that's been in Jinja forever that I've always wanted in Go's text/template

http://jinja.pocoo.org/docs/dev/templates/#whitespace-contro...

> Whitespaces shouldn't be touched, just parse them though and don't process them.

That's what html/template does by default, the point of the addition is this can be inconvenient as you may want whitespace for source readability but can't have whitespace in the output.

> That would make the templates look more like those of Django and Jinja2, which most seem comfortable with.

The behaviour outlined here is the same as jinja's: output text nodes as-is by default (whitespace and all), specify `-` to trim whitespace on the corresponding side of a template item.

Whitespace inserts a text node in the DOM. I think.

Whitespace is text, yes?

The general philosophy in the Golang ecosystem is to enable powerful and expressive tools wherever possible without introducing magic. While one might typically want the latter expression to automatically strip whitespace, what happens when you do want the whitespace?

This is a problem I have in my Jade (aka Pug) templates, which trims whitespace around the contents of each element by default -- and there, I have to append `#{' '}` HTML literals at the end of lines in order to assert whitespace where I need it. But overall, the whitespace-trimming in Jade is great becuause it's a targeted, somewhat-opinionated tool, contrary to Golang standard library.

If you need/want templating to work differently, though, there's no reason to not use some other template library. Or you could fork the standard library, make modifications to suit your needs, and use that instead. It's very easy to do that with Go.

The point is that it depends on your definition of "expected". I'd rather have my library act in a well-defined way that can be stated as succinctly as possible.

The problem then is what whitespace do you keep and what do you ditch? The default behavior you want is to maintain everything inside. But I agree the - tag seems like a really inelegant hack.

The default behavior has to be backwards compatible, so there was only one serious option.

What? They could have done any number of things. They could have added a parameter "-trim" that's more clear than the "-" alone. They could have made it "8<" that looks like a little pair of scissors. Or they could have actually spent some time thinking of a good idea instead of those ones that are about as a bad as the one they went with.

The idea they went with, which was one of the ones I proposed, is used in a variety of open source projects, so it had the advantage of being somewhat familiar and vetted. And what I meant to say is that they had to modify things in a backward compatible way, which means keep whitespace by default and trim with new syntax.

That ticket was created by me, and yes, treating whitespace like that would obviously break plain text templates and anything else where whitespace is significant. Remember that Go templates are for more than just html. What about generating CSV files for example? Plaintext emails? I use it for generating Go code, so the whitespace is sometimes significant (to terminate a line of code) but moreover careful control of whitespace is necessary to get readable code.

Sometimes you want the whitespace, sometimes you don't. So both are not the same.