- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 10 May 2012 08:31:41 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Yehuda Katz <wycats@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
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