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: Scott González <scott.gonzalez@gmail.com>
Date: Thu, 10 May 2012 20:26:53 -0400
Message-ID: <CAO8i3ieysVgPSH5NFdsPUkxGNQ+AFwSQFQASqdgyntV80OPYDA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, May 10, 2012 at 8:03 PM, Ian Hickson <ian@hixie.ch> wrote:

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

I'm not sure why this isn't sane. It's exactly how everyone writes their
code on the server, where the majority of their markup is generated. Raw
HTML with variables is much more human friendly than structured JavaScript
objects and arrays.

Developers are already in the mindset of writing HTML fragments. They do it
everywhere. In a traditional web model, you never run into the context
problem because the server always generates a full page. So even if you're
using nested templates on the server, with some of your templates being
fragments that might require context (say a <tr>), by the time it reaches
the browser it's already concatenated into a full page. As web apps become
more advanced and servers start returning fragments (or the fragments are
just generated directly on the client), then these issues start to crop up.
In the developer's mind, nothing has changed about how to generate the
markup. There's little incentive to switch from strings to
Element.create(), but there's a lot of incentive to stay with strings.
Received on Friday, 11 May 2012 00:27:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC