[templates] Consider ${foo} instead of {{foo}}

[jdanyow]

Proposal: align the interpolation syntax with JavaScript.

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md

[annevk]

Context: https://tc39.github.io/ecma262/#sec-template-literal-lexical-components.

[matthewp]

The disadvantage to choosing the same syntax as JavaScript is that it makes it more difficult to create templates as template literals in JavaScript (you have to remember to escape them all). For ex:

template.innerHTML = `
  <h1>\${name}</h1>
  <h2>${title}</h2>
`;

Would throw assuming title is not in scope b/c you forgot to escape it. If it were in scope you might be scratching your head as to why the templates were not behaving as you expected.

[kafein]

I think its problematic to use fixed syntax. Programmers should able to set custom interpolation syntax. Some server side templating engines uses nearly same {{ var }} syntax and this may cause conflicts when javascript code mixed with template code.

[rniwa]

I don't think we want to make this configurable. That's one thing this standardization process provides: uniform templating syntax.

If we're going with ${~}, we probably need an alternative syntax so that it could be used inside JS without having to escape as pointed out in #688 (comment). This was pretty much the reason we went with {{~}}.

{~} is also problematic because it appears in CSS, and you'd sure want to be able to embed CSS inside a template.

[tabatkins]

Neither {~} nor {{~}} should cause any problems in CSS, unless I'm very confused.

[rniwa]

<template><style> :host { font-weight: bold; } </style></template> would blow up unless we escape { inside the style element.

[MikeKovarik]

@matthewp that's an edge, just like for example creating webworker from a (blob url) string and creating <script> inside of it that also uses template strings. Yes you can do it, but very little people are going to. And if you do than prepare for the burden of escaping.

We shouldn't surrender to edge cases and introduce yet another syntax and complexity to keep in mind.

[kafein]

{~} is also problematic because it appears in CSS, and you'd sure want to be able to embed CSS inside a template.

It's the problem of template engine developers, they know the css syntax and they must care about interpolation syntax for code compatibility. This situation is different.

[caridy]

I see few issues here:

1. ${x} is problematic because it might give the wrong assumptions. Is that a javascript expression? How is it evaluated? in which context? etc. This will go against users' intuitions in many ways.

2. we need to be very careful about allowing interpolation in UI elements. It is true that for very basic apps that are targeting a single locale, having interpolation in the template will be nice, but for more complex applications, doing interpolation in the template is probably not useful unless that you have one template per locale. How are you going to localize your template? I don't see any mention of this important user-case in the proposal.

3. I rather prefer to go with something very restrictive to begin with, and then relax when we feel more comfortable. few examples that are not clear after reading the proposal: {{ x y }}, {{ x.y }}, {{ x[y] }}, {{ x-y }} and all sort of combinations including spaces, breakline, unicode chars, you name it. Again, is that a JS expression or is it a new language that looks a lot like JS and we will have to specify because it contains new things like nullable? what if we only allow {{x}} and {{x.y.z}}? if they want complex expressions, those should belong to the JS layer of this, in which case they do have getters and setters.

Note: we should not loose the focus, in my opinion, the goal of this proposal to provide a high-performant way to create and updating instances of templates following the principles of EWM. Let libraries to provide the abstractions, the interpolation aspect of it, etc., and focus on the low level pieces. The template is not JS, users should not be confused, it is just HTML.

[rniwa]

@caridy : We wanted to support a very small subset of JavaScript without supporting arithmetic or any other kind of operators but || and . and possibly [~] in the default template processor.

There is no restriction on what a custom template processor could do besides the fact delimiters would always be {{~}} or whatever the syntax we agree upon.

[stramel]

@rniwa

We wanted to support a very small subset of JavaScript without supporting arithmetic or any other kind of operators but || and . and possibly [~] in the default template processor.

One that I end up using fairly often is adding ie. index + 1.

[caridy]

We wanted to support a very small subset of JavaScript without supporting arithmetic or any other kind of operators but || and . and possibly [~] in the default template processor.

That is my biggest concern. Is it absolutely necessary? where do you draw the line between JavaScript and the subset that you want to support? Based on historical discussions at TC39, we have seen people attempting to implement a subset of JS over and over again, no-one has succeed at that (at least that I know of), in fact, most of them ended up supporting the entire thing or disapearing.

Look at handlebars for example:

Identifiers may be any unicode character except for the following:
Whitespace ! " # % & ' ( ) * + , . / ; < = > @ [ \ ] ^ \ { | } ~To reference a property that is not a valid identifier, you can use segment-literal notation, [:{{#each articles.[10].[#comments]}}`

I'm sure @wycats will have some strong opinions about this.

If developers have a way to provide those expressions via abstractions on top of the processCallback or any other similar mechanism to evaluate the expressions, we should be fine. Lets library to compete for the best syntax, just provide the mechanism for the processing of the parts.

[domenic]

See #682 for discussion of the default processor.

[domenic]

At TPAC we agreed that we would not be OK moving forward with a syntax that requires escaping when using in conjunction with JS. (As demonstrated so succintly by @matthewp's #688 (comment).)

Note that we weren't set on double-curlies, but single-curlies and dollar-curlies are striaght out, by this criteria.

Further discussion of the default processor can be done in #682.

As such, let's close this.