- From: Clint Hill <clint.hill@gmail.com>
- Date: Mon, 23 Apr 2012 20:42:08 -0700
- To: public-webapps <public-webapps@w3.org>
I'd like to weigh in on this topic as it is something that I'm involved in at work as well. Could you maybe explain further "parsing the template contents as HTML Š can contain sub templates"? If you take this example: <template> <div><!-- A little markup //--></div> <template><!-- subtemplate markup //--></template> <div><!-- A little more markup //--></div> </template> Are you saying there is 1 Node that has a 3 children? If "yes" what benefit does that bring that inert tags doesn't? On 4/23/12 8:25 PM, "Rafael Weinstein" <rafaelw@google.com> wrote: >Yes. I think this issue is a distraction. > >Using the script tag for encoding opaque text contents is a hack, but >it works as well as it can. AFAIC, The main drawback is that the >contents cannot contain the string "</script>". This will be the case >for any new element we came up with for this purpose. > >If someone has an idea for how to do better than this and why it's >worth doing, please speak up. > >Part of the point of parsing the template contents as HTML is exactly >so that template contents can contain subtemplates. It's a universal >feature of templating systems and needs to be well supported. > >On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: >> Why don't we just use script elements for that then? >> >> >> On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan <sadan.yuval@gmail.com> >>wrote: >>> >>> You musn't forget what we're not planning for. Templates can be great >>>for >>> so many applications - generating code (JSON, Javascript), generating >>> plain-text or otherwise formatted (markdown, restructured text, etc.) >>> content and much more. I don't think templates should be parsed by DOM >>> unless explicitly requested. The simplest scenario should also be >>>supported >>> imho, that is <script type="text/html"></script>-ish markup with >>>access to >>> textContent. >>> >>> >>> On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein <rafaelw@google.com> >>> wrote: >>>> >>>> On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov >>>><dglazkov@chromium.org> >>>> wrote: >>>> > 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. >>>> >>>> I think there are two orthogonal issues here: >>>> >>>> 1) Are the contents of the template element (a) parsed, context-free >>>> in a separate document which lacks a browsing context, or (b) simply >>>> processed as text. >>>> 2) Where are the contents of the template element put. >>>> >>>> (I'm separating these because James' proposal is about the second, not >>>> the first). >>>> >>>> I think there's a disconnect here between what seems strange to us a >>>> UA implementors and what isn't strange at all to webdevs. In a way, >>>> the goal here is exactly to create a mechanism which is strange in >>>> this way. >>>> >>>> Effective, every web app that does client-side templating is totally >>>> used to this idea: E.g. I want to ship fragments of DOM structures >>>> inside my document to the client, but have those fragments exist >>>> *outside* the DOM constructed for that document for all practical >>>> purposes (rendering, traversal, resource loading, selector matching, >>>> etc...). >>>> >>>> This goal of this feature is provide webdevs with a supported >>>> mechanism to do this which lacks the pitfalls of the available hacks. >>>> >>>> Assuming (1) is uncontroversially (a), then the idea to re-serialize >>>> the parsed content and append it is a text child to the template >>>> element would resolve our worry about the contents living outside the >>>> DOM being strange, but it has the downside that nearly all uses will >>>> immediately re-parse. >>>> >>>> [Dimitri addressed the problem with (1) being (b) earlier in the >>>> thread, if anyone is interested]. >>>> >>>> > >>>> > :DG< >>>> >>> >> >
Received on Tuesday, 24 April 2012 03:42:43 UTC