Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

html/template: provide a way to specify the initial escaping context (JS or CSS) when parsing #8762

Open
bradleypeabody opened this issue Sep 17, 2014 · 3 comments

Comments

@bradleypeabody
Copy link

commented Sep 17, 2014

There is currently no way (that I am aware of) to specify the initial escaping context
(JS or CSS, or other?) when parsing a template using html/template.

The use case where this would be useful is when treating JS or CSS files as templates. 
In these cases, it would seem to make sense to be able to call Template.Parse() with an
initial escaping context, telling it to treat this as a JS (or other) file.  Some
example use cases for treating JS or CSS files as templates are to inject translated
text into them (JS), or dynamically inlining images as data urls (CSS).

To work around this using the current system, you get something like this:
http://play.golang.org/p/J-21ux0gLE

As you can see, having this as a template:

 //<script>
 (function(){console.log("hello")})()
 {{jsraw "//"}}</script>

is rather crufty.

It would make much more sense to lose the script tag trickery and instead when we parse,
do something like this:

 t, err := t.Parse(jsInput, template.TypeJS)
@robpike

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2014

Comment 1:

Mike: Any opinion on this?

Labels changed: added release-none.

Owner changed to mikesamuel.

Status changed to Accepted.

@gopherbot

This comment has been minimized.

Copy link

commented Sep 19, 2014

Comment 2 by mikesamuel:

I think that a coarse-grained mechanism would be fine.  JS, CSS, or HTML seems a
reasonable level of granularity.
I'm concerned that if we try to expose the whole context object publicly, then we risk
confusing users, expand the API unnecessarily, and possibly paint ourselves into a
corner should the languages change in radical ways (string templates in JS) or some
weird zero-day arrives.
@griesemer

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2014

Comment 3:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.