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

On Wed, Apr 18, 2012 at 2:31 PM, James Graham <jgraham@opera.com> wrote:
> On Wed, 18 Apr 2012, Dimitri Glazkov wrote:
>
>>> Wouldn't it make more sense to host the template contents as normal
>>> descendants of the template element and to make templating APIs accept
>>> either template elements or document fragments as template input?  Or
>>> to make the template elements have a cloneAsFragment() method if the
>>> template fragment is designed to be cloned as the first step anyway?
>>>
>>> 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.
>>
>>
>> Right, ancestor-based inertness is exactly what we avoid with sticking
>> the parsed contents into a document fragment from an "inert" document.
>> Otherwise, things get hairy quick.
>>
>
> I am also pretty scared of tokenising stuff like it is markup but then
> sticking it into a different document. It seems like very surprising
> behaviour. Have you considered (and this may be a very bad idea) exposing
> the markup inside the template as a text node, but exposing the
> corresponding DOM as an IDL attribute on the HTMLTemplateElement (or
> whatever it's called) interface?

This seems like a neat idea -- though I haven't thought about this in depth yet.

:DG<

Received on Wednesday, 18 April 2012 21:55:30 UTC