On Thu, May 10, 2012 at 5:03 PM, Ian Hickson <i...@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. 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. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
