- 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>
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