[whatwg] repetition model

[Avi Bryant]

On Fri, 25 Jun 2004, Ian Hickson wrote:

> I do agree that the [id] stuff is somewhat dodgy. I really am at a loss of
> how to do a better solution, though. And it does work quite well.

In other words: it's a useful hack.  No argument there, as long as we
agree that it would be nice to find something that *isn't* dodgy.

> > Effectively you're upping the meta level:  parts of the document are no
> > longer HTML, but a description of how to produce HTML.
>
> HTML4 already has this (<object declare>).

That's similar to having a a template without [id], but it doesn't set a
precedent for macro expansion at all.  <object declare> still treats the
DOM as a semantic tree rather than as bits of text to be manipulated byte
by byte, as the repetition model does.  That's the part I find offensive.
(Though at least the semantic rape is confined to attribute values).

> I agree that the []-prefix hack is a hack. Do you have a better solution?

My point is that the [id] hack necessarily begets other hacks, which is
just further evidence of its hackishness.  The only better solution is to
get rid of [id].

> This is an interesting point. It means that if the author doesn't want any
> of the [id] nonsense, he need simply not put an ID on the template, and
> then that entire part of the model is simply ignored.

I don't generally buy into that kind of argument.  That way lies C++.  An
author may be able to confine themselves to a subset of the spec, but a
browser vendor can't, and neither can a documentation writer, etc, all of
which is going to indirectly affect the author even if he doesn't
personally need the feature.  If we can get rid of it wholly, we should.

> There are cases where having uniquely numbered rows really helps with
> the server-side processing (for example, some CGI libraries merge all
> the values with the same name into one array, keeping the relative order
> between individual control names, but losing the overall order that the
> names came in).

So, the problem is that with nested repeats you could end up with
something like this (simplified):

<div>
<input name="customer" value="cust1">
<input name="account" value="account1">
<input name="account" value="account2">
</div>

<div>
<input name="customer" value="cust2">
<input name="account" value="account3">
</div>

And on the server you'd have

customer=[cust1,cust2]
account=[account1, account2, account3]

with no way to tell which accounts went with which customers.

For people with CGI libs like that, one easy workaround would be this:
after each set of repeats of a template, insert hidden fields with the
same name as each input and and "end of group" marker value.  For example:

<div>
<input name="customer" value="cust1">
<input name="account" value="account1">
<input name="account" value="account2">
<input name="account" type="hidden" value="--------">
</div>

<div>
<input name="customer" value="cust2">
<input name="account" value="account3">
<input name="account" type="hidden" value="--------">
</div>

Then you end up with:

customer=[cust1, cust2]
account=[account1, account2, --------, account3, --------]

Which would be trivial to assemble into the proper nested groups on the
server side.

> This is especially important with nested repeats, where
> the "add" button has to refer to a template that has been repeated.
> Templates are identified by IDs, so you need a unique ID for each
> repeated template. (There's an example of this in the spec.)

If buttons referred to templates by name instead of ID, this wouldn't be a
problem - they would just be hooked up to the closest template of the
right name (and I'm pretty sure we could find a suitable definition of
"close").