[whatwg] Re: repetition model
malcolm-what at farside.org.uk
Thu Jun 24 11:43:09 PDT 2004
[Quick note: I was talking about implementation complexity, not user
complexity. I probably should have made that more clear.]
Ian Hickson writes:
>> Personally, I'm not so sure. The logic required to support the
>> repetition model is extremely complex, compared to the rest of the
>> document, so it should need to provide a significant benefit to us
>> (users, authors) for it to be included.
> It looks complex because it is new and all described in the spec. But
> actually it's not really complex, it's just described in a detailed way.
> I'm sure submission is a lot more complicated if you look at the actual
> details to the same level.
Oh, agreed, but compared to the 'other' parts of the spec, which are either
codification of existing practice or incremental advances, the replication
model has got to be the most complex part [to implement].
I was particularly thinking of the interaction between the replication
model, the DOM, events, and so on; I suspect that there are edge cases that
aren't properly defined, simply because the functionality hits a lot of
areas. I will admit that I haven't taken a detailed look at it recently, and
so I'm probably worrying about nothing.
>> [where to use it?]
> I've used hacked-up JS versions of it on sites myself. Bugzilla has an
> example of functionality of this kind:
> It's not used on every site, sure, but there is definitely demand for it.
> (Several people have privately told me that it is the most useful part of
> the spec, in their opinion.)
Ok, I'm not saying there aren't any use cases, just that I couldn't think of
many. Bugzilla did come to mind actually, but I forgot about that bit of
> I know of several sites that use this kind of structure, but most are in
> intranet pages or require user accounts. GMail uses it for when you add an
> attachment, for instance.
Ok, so does Outlook's web front-end, and so does another intranet
application I use. I was trying to think in terms of 'order-entry'-style
forms, whereas the use cases seem to be more address book/file
attachment/general list -type things.
>> I guess it boils down to this: it's really complex, so show me a
>> compelling use case. I'm not against it, just not particularly sure
>> whether I should be 'for' it.
> Why do you think it is complicated? You have a template, and then you
> click "add" to add a new row, and "remove" to remove a row.
For the user, it's fine. No disagreement there. The implementation is what's
complicated. It modifies the DOM based on events, fires events by itself,
and generally has a potential for un-interoperability (is that a word?)
that's higher than any other single feature in the spec.
It also doesn't play nice with non-WF2 UAs. While it will be possible to
emulate some of it with script, we're never going to support it on lynx (or
on IE6 with scripting disabled). I *don't* think this is such a big deal,
because these browsers don't support that kind of functionality anyway, but
it's worth noting that it's the only part of the spec where we explicitly
drop backwards compatibility with legacy UAs.
To be honest, my main concern was the absence (in my head) of obvious use
cases. That sorted, I don't really have any major objections, provided we're
happy about non-legacy compatibility.
More information about the whatwg