W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] HTML Parsing and the <template> element

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 26 Jun 2012 13:46:31 -0700
Message-ID: <CAAWBYDC_YLmHAVgVjwHHrN55ocNDJXL7RXabuE823KuN0pA3=A@mail.gmail.com>
To: Elliott Sprehn <esprehn@gmail.com>
Cc: Rafael Weinstein <rafaelw@google.com>, Henri Sivonen <hsivonen@iki.fi>, Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>, Simon Pieters <simonp@opera.com>
(Please bottompost! Being a Googler teaches you bad email habits. ^_^)

On Tue, Jun 26, 2012 at 1:34 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
>> > Silly question but why not specify the template element as if it's
>> > contents
>> > were PCDATA, and the document fragment is the "value". Then this whole
>> > thing
>> > isn't really any different than a <textarea>.
>> Because you can't nest <textarea> inside of itself, but we want
>> templates to be nestable.
> Hmm, I might be in agreement with Henri then. Having all these parallel
> trees in the DOM is getting kind of out of control. Now there's the shadow
> DOM trees on every node, and also this nested tree of document fragments
> from <template>. There's a lot of simplicity in the DOM design that's lost
> from these two changes.

The problem is that this is a very theoretical opinion.  In reality,
these parallel trees *already exist*, except they're not DOM, they're
bespoke JS trees that don't interoperate between libraries and have a
decent impedance mismatch with the real DOM APIs, resulting in
significant duplication.

"Let's get rid of these parallel trees" isn't an option.  Our choices
are only "maintain the status quo of multiple layers of DOM
incompatibly stacked on top of each other" or "complicate DOM a bit to
pull those trees into the fold".

Received on Tuesday, 26 June 2012 20:47:20 UTC

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