W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 9 May 2012 19:51:59 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
cc: Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
Message-ID: <Pine.LNX.4.64.1205091949200.9926@ps20323.dreamhostps.com>
On Wed, 9 May 2012, Jonas Sicking wrote:
> I think having to provide a context every wherewhere you want to
> parse HTML is creating very bad developer ergonomics.

You wouldn't have to provide it everywhere. The vast majority of the time, 
the default "body" context is fine.

> I think the proposals here, and the fact that jQuery has implemented 
> context-free HTML parsing, proves that it is technically possible.

I don't think look-ahead and magically determining the parse mode from a 
preparse of the string is really a sane solution. It doesn't handle all 
cases (e.g. it doesn't handle the <style> example I gave), and it results 
in very weird results ("very bad developer ergonomics") for cases like 
"1GB of text followed by <caption>" vs "1GB of text followed by <coption>" 
(where the former loses the text and the latter does not).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 May 2012 19:52:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC