[whatwg] Re: repetition model

[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: 
> 
>    http://bugzilla.mozilla.org/query.cgi#chart 
> 
> 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 
functionality. 

>[moved]
> 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. 

Regards,
Malcolm

Received on Thursday, 24 June 2004 11:43:09 UTC