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: Wed, 18 Apr 2012 10:41:13 -0700
Message-ID: <CAAWBYDAWFAb+R1y=c4V2pSaUGp8N=YE4gu8eOjE2uies2VHPLw@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Dimitri Glazkov <dglazkov@chromium.org>, Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, Rafael Weinstein <rafaelw@google.com>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
On Wed, Apr 18, 2012 at 8:46 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:
>> When implementing this, making embedded content inert is probably the
>> most time-consuming part and just using a document fragment as a
>> wrapper isn't good enough anyway, since for example img elements load
>> their src even when not inserted into the DOM tree. Currently, Gecko
>> can make imbedded content inert on a per-document basis.  This
>> capability is used for documents returned by XHR, createDocument and
>> createHTMLDocument. It looks like the template proposal will involve
>> computing inertness from the ancestor chain (<template> ancestor or
>> DocumentFragment marked as inert as an ancestor).  It's unclear to me
>> what the performance impact will be.
>
> FYI, now there's <dialog> and a global inert="" attribute so if those
> features stay <template> should presumably just hook into them.

Different concept of 'inertness', unless I'm greatly mistaken.

The @inert attribute turns off all user interaction - mouse, tabs,
access keys, etc. - with the elements in the subtree.

The "inertness" that the template element wants is preventing network
requests and such, so that it's friendly to templating systems that
want to produce "templated" urls in <img>/etc that get some of their
pieces filled in upon instantiation.

~TJ
Received on Wednesday, 18 April 2012 17:42:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:51 GMT