- From: Brian Kardell <bkardell@gmail.com>
- Date: Fri, 27 Apr 2012 14:09:46 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Clint Hill <clint.hill@gmail.com>, public-webapps@w3.org, Ojan Vafai <ojan@chromium.org>, Dimitri Glazkov <dglazkov@chromium.org>, Kornel Lesinski <kornel@geekhood.net>
I was just wondering if everyone (most especially the editors) is good with Tab's distinctions (included below)... Most importantly: The stuff that an awful lot of people are (today anyway) calling "templates" (as he explained, a foreign language embedded in HTML which in this case just happens to be describing some DOM) belongs in <script> tags - that is not the intent of the <template> element. The intent of the <template> element rather is described well below I think, so I won't even try to summarize, but it's "not that". Tab, jump in if I have misrepresented what you were saying... On Wed, Apr 25, 2012 at 8:15 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell <bkardell@gmail.com> wrote: >> Tab, are you saying: a) fixing that in script apis for document fragment or >> something is an ok solution to this, or that b) this means text templates >> should use <template> or c) it should be the goal to kill string templates >> altogether? > > I just talked with Ojan in person, because we were talking past each > other with the terms we were using. I now understand what he was > saying! > > When we say "string-based templating", we're really saying "I want to > embed an arbitrary foreign language into HTML". That language happens > to be a templating language, but the exact purpose you're putting it > to is irrelevant for our purposes here. For this, <script type=foo> > is not only a satisfactory existing solution to this, but it's the > *correct* solution to this - that's precisely what <script> is > designed to do. > > I was confusing this term with the idea of "programmatic DOM creation > that doesn't suck". Right now, the "right" way to create a fragment > of HTML is to use a lot of document.createElement() and > el.appendChild(). This sucks. Instead, everyone wants to just write > a string containing HTML and parse it, like what innerHTML and jQuery > do. For this, Raf's proposal works great - it lets you use the > "innerHTML API" without having to employ hacks like jQuery uses to > ensure that things parse in the right context. > > Related closely to this is stuff like a Web Component that wants to > fill itself with a DOM fragment. Right now, you're required to do > that within script. This sucks, partially because of the > aforementioned existing suckiness with DOM building. Even once we fix > that with Raf's proposal, it will still suck, because it means that > Components are required to run script to build themselves, even if > their DOM structure is totally static and doesn't depend on outside > data. We want <template> to help us solve this problem, by letting us > send HTML structure *in HTML* and potentially hook it up to a > component declaratively, so components don't need to run script unless > they're actually doing something dynamic. Parsing the contents of a > <template> "correctly" requires the same mechanism that Raf is > proposing. > > Somewhat further away, we have another proposal, MDV, which *is* > intending to replace the basic functionality of the current > "templating" libraries. It takes something representing an inert DOM > structure with holes punched in it for data to fill in, hooks it up to > a JS object full of data, and pops out a fragment of "real" DOM with > all the holes filled in. This is obviously useful when done purely > via script (the popularity of templating libraries attests to that!), > but there's intriguing design-space around *declarative* > templating/iteration, where you just declare a template in markup, > tell it how to fetch a data source to use, and it handles the rest for > you. No script required! This is very similar to the "no-script > Components" use-case, and so it would be nice to reuse <template>. > Even if we use a differently-named element, the parsing problems are > identical, and we still need something like Raf's proposal to solve > them. (Even ignoring the pure-declarative case, being able to ship > your templates in the page HTML and just grab them with script when > you want to use it seems useful.) > > > A "text template" like handlebars (in other words, a foreign language) > should be able to use a significant fraction of the stuff that MDV > provides. It will have to parse itself into a DOM structure with the > "holes" set up manually, but once you've done so it should be able to > be used in many of the same contexts. This has nothing to do with the > <template> tag, though, because it's not *trying* to parse as HTML - > they should use <script>. > > This isn't *completely* ideal - if you are *almost* fine with the > functionality that MDV provides, but need just a little bit more, you > either have to switch from <template> to <script> (which isn't > trivial), or embed your extra functionality in the HTML via @data-* or > something, which may be a bit clumsy. We'll see how bad this is in > practice, but I suspect that once MDV matures, this will become a > minor problem. > > ~TJ
Received on Friday, 27 April 2012 18:10:16 UTC