On Mon, Mar 11, 2013 at 10:22 AM, Adam Barth <w3c@adambarth.com> wrote:
> Is there a definition of the html quasis handler somewhere that I can
> study?
>
I don't believe there is. I think that's a whole separate discussion
really. Changing the subject line to match. I'm not really sure what spec
this would go in either. Perhaps it's own.
I see two options:
1. Do E4H style parsing. (http://www.hixie.ch/specs/e4h/strawman)
2. Do <template> style parsing through the regular HTML parser.
Both of these deal with the important case of creating a DOM that doesn't
have an appropriate context element at the root. Specifically,
html`<td>foo</td>` will work for both.
A difficult case is how you parse html`<a>foo</a>` because, without
context, you don't know if that element is an HTML element or an SVG
element. In either case, we'd need to add special syntax like the E4H
syntax for this.
So, the big trade-off is really static error checking versus consistency
with the rest of the platform. Is static error checking worth having the
html quasi parser parse things differently than innerHTML, <template>, etc.?
There are two main bits to E4H style parsing:
1. It doesn't do any fixup, e.g., if you misnest tags you get an error.
2. It allows you to create any DOM you could create from JS even though the
standard HTML parser wouldn't, e.g., html`<div><td>foo</td></div>` would
create exactly 3 nodes, a text node inside a table cell inside a div.
IMO, both of these are positives of E4H style parsing and are what I would
prefer to see happen. The inconsistency with the rest of the platform is
unfortunate, but is outweighed by the benefits.
Ojan