- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 26 Apr 2012 10:11:02 -0700
- To: Yuval Sadan <sadan.yuval@gmail.com>
- Cc: public-webapps@w3.org
On Thu, Apr 26, 2012 at 9:43 AM, Yuval Sadan <sadan.yuval@gmail.com> wrote: > I totally misread the purpose of templates beforehand -- <template/>s act > more like a mixin rather than a fill-in. It also reflects in what Tab wrote > that it's still vague how the two notions - that of text templates and that > of mixins for building components - are to be mixed together, if at all. Maybe. I'm not interested in trying to cut through more terminology at this point, particularly when its subtly different from what I know of "mixins" from class-based languages and "mixins" from SASS. I explained the goals in my previous email; that should be clear enough, and you can chop it up into terms you're familiar with on your own. > Re the use as mixins - <template/>s put together two different ideas. > On on hand, it looks like a content-generating/replicating scheme, such as a > CSS content:"", or the proprietary CSS -moz-element:[3] properties. In that > sense, <template/> seems to take these a step further. From the spec[1]: (Tangential note: -moz-element() was a proprietary experiment, but it's since been specced. I've punted it from Image Values level 3 to level 4, as it had some problems that would have delayed the level 3 snapshot unduly, but it's still there.) Less tangential note: the use of 'content' is seductive - it *seems* right and natural, but it has a lot of failings. Most particularly, it's not well-defined (because the behavior normally isn't observable) exactly when a CSS property stops matching. In particular, if an element switches an attribute from "foo='bar'" to "foo='baz'", and there were rules for both [foo=bar] and [foo=baz] applying the same 'content' rule, did it stop matching sometime in between? Or was it continuously maintained? Both interpretations are sensible. With Components, and the fact that they can have side-effects, you can tell the difference between these two, and they have substantially different implications for how you need to design Components. So, we rejected the use of 'content' (or the similar 'binding' from XBL) early on, for these reasons. Shadow DOM shouldn't be attachable through CSS, at least not without significant restrictions that remove the problems I noted. >> One reason for creating a document fragment is to clone it multiple times >> to create repeating items that vary in some content, but have common basic >> structure of across all instances. > > I see the content as being the DOM, and the common basic structure as the > functional *design* around it. If repeated data was to be a semantic part of > content, I would imagine it would have been incorporated in the tree. > > On the other hand, it seems <template/>s are trying to answer the same need > as XML: giving an alternative for semantic structuring of the document > without loosing the ability to add functionality. Again from the spec: >> >> something that allows developers declare arbitrary DOM subtrees in the >> document markup. > > I realized as I'm writing this that <template/>s come from XBL so I > shouldn't be surprised. > > So I think these points still need some thought: > - should functional design detail be embedded in the document? It looks like > this might be subset of HTML targeting solely user-interactive web-apps. If > it is, it should either be left to another mechanism to solve than the DOM, > or we might encourage attaching these <template/>s as external files (there > is no mention of a <template src=""/> attribute) Why *not* use DOM? We're trying to create a template for producing DOM, and it seems we should self-host if possible, as it means we won't have to reinvent a lot of API surface. There's a point when this becomes untenable (for example, XSLT is far past that point), but the plans for now don't seem to ambitious. Loading templates from a remote document is on the menu eventually, but it's not necessary to solve right now. > - existing techniques have DOM fragments hidden with style="display:none;" > and then replicating them programmatically. What benefits do <template/>s > present? That the fragment is inert, and the declarative nature of insert > points and such. If these are the advantages, then we can add an inert="" or > template="" attribute that any <div/>. Enriching HTML with useful elements > is good, but creating a new subset for the purpose of inert content and > insert points brings a lot of logic to the browser-side. I think HTML 5 is > more about being simple and direct. That's not enough. In addition to the inertness, there are parsing implications. We'd like, for example, for a Component to substitute for a <tr>. To do so, its contents should be <td>s. If you just put a <td> in your document, though, outside of the table context it expects, the tag gets thrown away (the contents stay behind). Like I pointed out, this is the exact same problem that jQuery has when it wants to allow authors to make calls like $('<td>foo</td>') - they have to actually reach into the string, figure out what the appropriate context is, and create it themselves, so they can then set .innerHTML on it to their string and let the HTML parser work on it. In addition, having the inertness attached to an attribute has some bad effects. For example, what happens if you temporarily remove it? Does everything become live again, and start firing off requests as appropriate? What if you immediately put it back? What happens to the pending requests? Linking this behavior to a tagname, which is a static quality of a node, avoids these issuses. Finally, naming things upfront makes HTML easier to read. <section> is better than <div class='section'> at least partially just because it's shorter and clearer. The situation is similar for <template> vs <div inert> or similar. > - how does this answer the need to separate functional design/layout from > semantic structure? This seems to replace techniques the such as XML+XSLT > or XBL to render content as you wish. From the XBL spec [2]: >> >> XSLT operates on a static DOM, permanently replacing that DOM for >> rendering. XBL, on the other hand, transparently transforms the DOM for >> rendering while leaving the underlying structure intact, and dynamically >> reflects changes to the underlying DOM in the transformed rendering. > > In light of what I wrote about, why should this functionality be replicated > to the HTML realm (as the specs say) and not used by it? The specs are > missing this motivation. XBL may be used alongside CSS and scripts, instead > of merging them inside HTML. XSLT is an abomination. ^_^ No one should wish to inflict that beast on more of the web. XBL and XBL2 are both broken in subtle ways. I point out one such way above - XBL2 relies on the 'binding' CSS property, but attaching a binding can have observable side-effects, and it's not defined precisely when a property starts or stops applying. There are more issues, but as I said, they're subtle, and require a pretty deep understanding of the details of the XBL2 spec, and even then are kinda hard to explain. Suffice to say that we, Dimitri especially, have thought on this long and hard, and are engineering Components to have as many of the good qualities from XBL2 as possible (and there were plenty!) while avoiding the pitfalls we've found. ~TJ
Received on Thursday, 26 April 2012 17:11:57 UTC