html/template: execute adds blanks

[gopherbot]

by Knyaginin:

package main
import (
    "strconv"
    "html/template"
    "net/http"
)

type Page struct {
    Port int
}

func hRoot(w http.ResponseWriter, r *http.Request) {
        t, _ := template.ParseFiles("Root.html")
        port, _ := strconv.Atoi(r.FormValue("port"))
        p := &Page{Port: port}
        t.Execute(w, p)
}
func main() {
    http.HandleFunc("/", hRoot)
    http.ListenAndServe(":9980", nil)
}

/*Root.html*/
<div>{{.Port}}</div>

What is the expected output?
<div>1234</div>

What do you see instead?
<div> 1234 </div>

Which operating system are you using?
centos 6.4

Which version are you using?  (run 'go version')
go version devel +772d46cd8fd1 Sat Apr 20 17:20:58 2013 -0700 linux/amd64

[robpike]

Comment 1:

Labels changed: added priority-soon, removed priority-triage.

Owner changed to @robpike.

Status changed to Accepted.

[robpike]

Comment 2:

Unable to reproduce. Plus it's incomprehensible - where does 1234 come from?. Marking as
Invalid, but if you can give a reproducible example, feel free to reopen.

Status changed to Invalid.

[minux]

Comment 3:

can't reproduce either.
also can't reproduce the standalone test case: http://play.golang.org/p/W9Wpz0NLO1

[gopherbot]

Comment 4 by Knyaginin:

Error is difficult to reproduce, and maybe it depends on the template. Source code in
attachments.

Attachments:

1. Administrator.html (1423 bytes)
2. admin.go (515 bytes)

[robpike]

Comment 5:

OK, I can reproduce it now, but I observe that if we use text/template it doesn't
happen. So it's a problem with html/template.

[minux]

Comment 6:

smaller standalone test: http://play.golang.org/p/bE7bMu73dG
as the added blanks are in the scripts, is it a big deal?

[robpike]

Comment 7:

http://play.golang.org/p/x5VkIAyi3t is even shorter.
It needs the javascript escaping, which means it's caused by javascript escaping. I'm
not sure it's actually wrong and will find out.

Status changed to Accepted.

[gopherbot]

Comment 8 by Knyaginin:

http://play.golang.org/p/-qdFFKF-kI minimal version.
Оther scripts, too.
In general, the scripting language is not known, so in my opinion it is necessary to
give content <script></script> as is.

[gopherbot]

Comment 9 by mikesamuel:

That's intentional because
    x-{{-1}}
should not lead to the token sequence
    "x" "--"(decrement) "1"
instead of the probably intended
     "x" "-"(binary -) "-"(unary -) "1"
Also the guarantee the IS escaping functions provide is
http://golang.org/src/pkg/html/template/js.go#L133
   133 // jsValEscaper escapes its inputs to a JS Expression (section 11.14) that has
   134 // neither side-effects nor free variables outside (NaN, Infinity).
and allowing token merging would mean that the simplest sub-expression into which an
interpolation happens could have free variables not in (NaN, Infinity).
It's done at http://golang.org/src/pkg/html/template/js.go#L183
   183 // Prevent IdentifierNames and NumericLiterals from running into
   184 // keywords: in, instanceof, typeof, void
   185 pad := isJSIdentPart(first) || isJSIdentPart(last)
   186 if pad {
   187   buf.WriteByte(' ')
   188 }
If there's a strong use case for merged tokens then content.JS should allow a safety
hatch.  If the concern is over output-size, then it should be possible to determine
whether the
Most of the token merging cases shouldn't affect JS that is likely to appear in a
template -- there are few places in a JS program where two identifiers/numbers can be
adjacent; but there's some interest in TC39 for moving towards a less punctuation heavy
syntax.

[gopherbot]

Comment 10 by mikesamuel:

Status changed to WorkingAsIntended.