Re: E4H and constructing DOMs

On Mar 7, 2013, at 10:43 AM, Ian Hickson wrote:

> On Thu, 7 Mar 2013, Allen Wirfs-Brock wrote:
>> 
>> There is no reason an implementation (or a platform standard) couldn't 
>> define a well known tag function that processes a well specified syntax 
>> (eg, HTML)
>> 
>>   HTML`<label><input type="checkbox" name={name}
>>              checked?={checked} disabled?={!enabled}/> {label}</label>`
>> 
>> such that a JS implementation could recognize the tag usage at 
>> compile-time and statically check the syntax of the statically provided 
>> portions of template strings that use that tag.  Alternatively, a 
>> lint-like processor could could recognize such tags and produce 
>> diagnostics for them.
> 
> If this:
> 
>   <script>
>     alert('test');
>     HTML`<a></b>`
>   </script>
> 
> ...would sometimes alert "test" and sometimes not, based purely on whether 
> the browser defined this well-known tag function, then that's a reason 
> why it couldn't happen.
> 
> If, on the other hand, you're saying we could require that browsers 
> implement such a thing, then that's more interesting. The syntax is not 
> quite as clean as E4H's, but maybe it's clean enough that it's ok?

Presumably you could require browser based implementations to implement and statically check your tag.  That is probably a less onerous requirement for you to try to impose than your own non-ES standard language extension. 

Personally, I doubt if it makes much difference to actual web developers whether this sort of error occurs when processing the <script> tag or when the template literal is evaluated.  They are both dynamic errors.  Any serious developer is going to validate such things prior to deployment, hence the lint solution is almost as good.

> 
> Are there any browsers that have implemented quasis, or that are comitted 
> to implementing quasis? If we're to reserve a prefix like this, we should 
> do it sooner rather than later, so we don't get forced into particular 
> compat constraints.

They're are an accepted part of ES6 of which all the major browser developers contribute to. They are also, at this point fully specified. In TC39 we don't standardize at the piece-mill level and the general understanding is that all participating implementations intend to conform to have gets approved as the ES6 standard.

Here'sthe firefox bug to implement them https://bugzilla.mozilla.org/show_bug.cgi?id=688857 .  Now that there is a solid spec. they will probably be implemented this year. 

There is no reason you shouldn't be working from the assumption that Template Strings are on track to be a standard JS feature and start spec'ing how the browser platform want to use them.

Allen