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

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