- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 18 Apr 2012 10:41:13 -0700
- 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 UTC