Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 9:13 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, May 9, 2012 at 8:14 PM, Yehuda Katz <wycats@gmail.com> wrote:
>> On Wed, May 9, 2012 at 10:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> I think it's much better to prioritize developers over implementers
>>> here and let implementers and spec writers tackle the complexity that
>>> comes with context-free parsing. I think the proposals here, and the
>>> fact that jQuery has implemented context-free HTML parsing, proves
>>> that it is technically possible.
>>
>> I agree. It also illustrates that the idea of the API is intuitively
>> understood by developers.
>
> Does jQuery support SVG here though? Because that is where it gets
> cumbersome. But maybe that is not much of a problem in practice. Maybe
> we should support context="svg" for that use case once it comes up?

Not yet, it doesn't.  It doesn't even *fully* support HTML, just a
useful subset, likely for performance reasons - running all the
regexes before you can fall through to "just use a <div> for the
context" case can add up.  This is of no importance to a parser-based
solution, of course.

Still, requiring an explicit context declaration *at all* defeats most
of the purpose of the API.  Again, if we don't auto-detect SVG (so
that "<rect>" just parses as HTMLUnknownElement by default), we
haven't gained much, since authors will *still* have to wrap their
code in a regex-based detector if they expect to ever use SVG.  (An
optional context declaration that lets you determine which way the
tagname conflicts go is fine, of course.)

~TJ

Received on Thursday, 10 May 2012 06:32:31 UTC