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: Thu, 10 May 2012 23:01:02 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
cc: Anne van Kesteren <annevk@annevk.nl>, Yehuda Katz <wycats@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Henri Sivonen <hsivonen@iki.fi>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1205102252160.25792@ps20323.dreamhostps.com>
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
> The innerHTML API is convenient.  It lets you set the entire descendant 
> tree of an element, creating elements and giving them attributes, in a 
> single call, using the same syntax you'd use if you were writing it in 
> HTML (module some extra quote-escaping maybe).
> [...]
> I'll go ahead and anticipate your response of "they should just use the 
> Element.create() API"

That would indeed be my response.

> while Element.create() is great, it solves a different use-case.  Being 
> able to construct DOM from raw HTML is easy to read and write and 
> understand, particularly when it's a static fragment (or a concatenation 
> of mostly static fragments), while Element.create() requires a 
> translation into a JS API with a much different syntax. Element.create() 
> is much more readable and writable when you're making some DOM out of a 
> *lot* of dynamic information.
> In other words, this:
> $("<div class=foo><img src="+foosrc+"></div>")
> is a lot easier than:
> Element.create("div", {class: "foo"}, [ Element.create("img", {src: foosrc}) ]);
> So, that's the use-case for this API.

The idea of building elements using string concatenation is a security 
disaster. What if "foosrc" above contains '" onclick="...' ?

But ok, let's assume that the use case is "create an element and its 
subtree so that you can insert dynamically generated parts of an 
application during runtime", e.g. inserting images in a dynamically 
generated gallery, and security by damned.

If we're going to do that, then we don't need any lookahead at all. We 
should support literally that: parsing one element and its descendants. We 
determine what element is being generatd by looking at the top of the 
string ("<div ..." -> it's a div, "<tr ..." -> it's a tr, etc), and we 
parse until that element is popped from the stack or the end of the string 
is reached. This avoids all the problems with doing magical lookahead.

But I'm very skeptical about creating new APIs to encourage authors to use 
injection-prone, non-type-checked, direct string manipulation in script to 
generate DOM trees.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 May 2012 23:01:29 UTC

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