html/template: compact HTML output

[balasanjay]

To minimize bytes over the wire, some people run their templates through an HTML
minifier before feeding them to html/template. Since html/template is parsing the HTML
anyways, it would be nice if it did this automatically.

There are several "safe" filters that can be applied to HTML that make it
smaller but functionally identical.
See http://code.google.com/p/page-speed/source/browse/lib/trunk/src/pagespeed/html/ for
some ideas.

Note: This is a long term feature request, not a bug report.

[rsc]

Comment 1:

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

Owner changed to builder@golang.org.

Status changed to Thinking.

[moraes]

Comment 2:

Some inspiration:
https://developers.google.com/closure/templates/docs/concepts#linejoining
It is based on some simple conventions, something very Go-ish imo.

[moraes]

Comment 3:

Just some brainstorm. Still taking the idea from Closure Templates, simplifying it a bit:
- Parsing process must accept a configuration/flag to turn on compact mode. Off by
default, so nothing that exists change. I'm not sure where this flag is set.
- When the flag is on, lines are joined using same Closure heuristics: "if the join
location borders a template or HTML tag on either side, the lines are joined with no
space. If the join location does not border a template or HTML tag on either side, the
lines are joined with exactly one space".
- A special action {{sp}} inserts an space for two lines that would otherwise be joined
without any space.
- No need for the {{nil}} tag used in Closure; simply merge lines with the desired
spaces if that is needed.
Inline JavaScript may require some more thoughts.

[rsc]

Comment 4:

Labels changed: added go1.1maybe.

[extemporalgenome]

Comment 5:

A special flag for indented output would also be useful.
In either case, special care must be given to 
. Worse yet is that any tag may be 
css-styled as preformatted text. a single newline should of course never be replaced by
a single space, unless you want to save an extra bit in compression.
As long a you're parsing html, a {{pre}} template tag could cause all text inside the
immediate parent tag to maintain its content precisely. Multiple instances of {{pre}} in
the same html subtree would be idempotent.

[robpike]

Comment 6:

Labels changed: removed go1.1maybe.

[rsc]

Comment 7:

Labels changed: added go1.2maybe.

[rsc]

Comment 8:

Labels changed: added feature.

[robpike]

Comment 9:

Labels changed: added go1.3maybe, removed go1.2maybe.

[robpike]

Comment 10:

Labels changed: removed go1.3maybe.

[rsc]

Comment 11:

Labels changed: added go1.3maybe.

[rsc]

Comment 12:

Labels changed: removed feature.

[rsc]

Comment 13:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 14:

Labels changed: added repo-main.

[balasanjay]

This is a dupe of #20879; I'm going to go ahead and close.

Probably worth revisiting when the stdlib can be versioned, but until then, the conclusion on that bug seems right to me.