Consider adding support in WebIDL for defining template tags

[littledan]

The ES6 feature of tagged template strings has recently been catching on in JavaScript. We may want to add Web APIs which define template tags in the near future, e.g., for Trusted Types, to test literal-ness (cc @koto) or for a built-in version of something like the parsing part of lit-html (cc @justinfagnani).

Would it make sense to add support to WebIDL to add template tags? What would that look like?

[saschanaz]

Something like template identifier = return_type (/* arguments... */); where arguments correspond to expressions?

[littledan]

A couple missing things there:

• you may want to overload an interface or operation to be able to act as a template
• we need to define how the template object is turned into a WebIDL-level thing

[saschanaz]

AFAIK tagged template functions are just functions, so we may just need a way to define general global (or module level) functions.

[littledan]

You can make global functions by defining operations in a global interface. For modules, see https://github.com/heycam/webidl/issues/592 .

[domenic]

Is there something preventing you from just using the normal operations syntax for template tags?

[littledan]

@domenic Well, you'd need to take it in as an object and use a bunch of ECMAScript operations to get the template object, right?

[domenic]

Wouldn't just ReturnType someTag(sequence<DOMString> parts, TypesInteropolated interpolated...) work? Then you'd get two Infra lists, parts and interopolated, each of which have the correct Web IDL type.

[littledan]

Yeah, that could work for some things. Some additional things that would be nice to do in a template tag:

• associate something with the template object (e.g., to reduce overhead the second time it's called; maybe this would typically be an unobservable optimization though)
• use the "raw" Array
• check whether the object passed in is "really" a template object

[justinfagnani]

Slightly off-topic for webidl, but since you tagged me: I think the most interesting future direction is for JS to allow host-defined tags that are not identifiers so that the host can switch parsers for the template literal contents before evaluating any JS.

We're running out of syntactic space, but imagine that:

let title = (text) => #html`<h1>${text}</h1>`;

invoked the host-defined parser for #html at parse time, and at eval time invoked the associated host-defined tag function, but instead of a template object as the first argument, the first argument is an object produced by the host-defined parser.

[littledan]

Possible place to follow up on this idea: https://github.com/littledan/proposal-reserved-decorator-like-syntax