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

Yehuda Katz
(ph) 718.877.1325


On Thu, May 10, 2012 at 5:28 PM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Thu, May 10, 2012 at 5:03 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Fri, 11 May 2012, Tab Atkins Jr. wrote:
> >>
> >> For something like this:
> >>
> >> $("<p>Example "+exnum+":</p><p><img
> src="+exsrc+">").appendTo(container);
> >
> > Can we really not come up with anything better? It makes me really sad to
> > think that the best we can do here is to go from a nice structured
> > environment, concatenate our data together into a string, and then
> reparse
> > the string back into structured data to add it to the DOM.
> >
> > I understand that people do this kind of thing all the time, but I've
> > always at least assumed that everyone agreed that it was a necessarily
> > evil because the alternatives were even worse. I had hope when we were
> > discussing Element.create() that maybe we were finally coming up with a
> > workable alternative, but as far as I can tell that never went anywhere
> > and now we're actually talking about adding APIs to _support_
> string-based
> > DOM tree generation as if it's an actually sane way of writing code.
> >
> > Am I really the only one here who thinks this is horrifying?
>
> I find it horrifying, and I'll venture that Yehuda and the author of
> every other templating mechanism does as well -- at least in the sense
> that all of our goal is to generally remove the *need* for page
> authors to have to use innerHTML, by declaring how their views should
> be composed, rather than doing it imperatively.
>

Correct. The Handlebars templating engine, for example, protects against
injection by default. If you create the following template:

  <img src="{{imgSource}}">

the contents of imgSource are automatically escaped before being
concatenated. An explicit opt-out (via triple-mustache) is required in
order to allow unescaped HTML to make its way in.

It is, of course, possible for the output of a template engine to be a
String like "<tr><td>foo</td></tr>". The reason this is a problem is
decoupling: I would prefer if the code that creates my DOM didn't also need
to know about the exact context that another part of the code plans to
insert it into. It is of course possible to pass that information around,
but it is cumbersome and makes it harder to encapsulate concerns.



>
> Libraries exist at a higher leverage point and if *they* do the right
> thing, then a greater number of authors are protected. Adding this,
> makes it easier for libraries (and if I get my way, the platform
> itself) to do this right so that authors can stop constructing DOM
> imperatively altogether.


Yep. My goal is for my users to use templates, and let me insert the
resulting DOM in the appropriate place. Ember.js users virtually never
construct and insert DOM directly, even though they work with HTML rather
extensively.


>
> >
> > --
> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>