Re: E4H and constructing DOMs

On Mar 9, 2013, at 5:29 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Mar 9, 2013, at 3:59 PM, Brendan Eich wrote:
>> 
>>> Ojan Vafai wrote:
>>>> I would imagine that some folks on this list would be resistant to having the default handler be one that produces a DOM instead of a string. Could we have a browser-provided html handler that does E4H style parsing and not have a default handler at all? That way, the simplest code path for developers is to use the browser-provided handler and they have to go out of their way to do something else, but we still leave the door open for other use-cases/handlers (e.g. contextually parsed html).
>>>> 
>>>> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // parse error
>>>> header.appendChild(html`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // E4H style parsing
>>>> header.appendChild(myspecialhtmlparser`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // template strings as currently proposed
>>>> 
>>>> The only thing we lose here I think is an easy way to do multiline strings in JS.
>>> This is a productive suggestion. Thanks -- we will discuss it at next week's Ecma TC39 meeting, I've added it to the agenda.
>> 
>> and a plausible name for the tag handler that only does simple string interpolation is: String
>> 
>> In other words it is just an overload on the String constructor (assuming we make sure that callsite objects are recognizable) and you would use it like:
>>    console.log(String`Welcome ${ firstName } ${ lastName }!`);
> 
> No, the idea Ojan put forth is that the tag-less form should call a default handler other than String, in browsers. Specifically it would do a checked form of HTML parsing that threw if interpolations were not complete and well-formed subtrees.

Platform specific processing for tag-less string templates would be terrible for cross platform interoperability. It means, for example any code containing a tag-less string template would not be interoperable between, for example, browsers and node.js servers

That sort of platform-dependent behavior is a real language design anti-pattern if you care about interoperability.

Allen

Received on Sunday, 10 March 2013 01:45:59 UTC