[whatwg] repetition model

On Fri, 25 Jun 2004, Avi Bryant wrote:
>>>
>>> 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].
>>
>> Other hacks? There are exactly two hacks. The search for [id], and the
>> initial [] to prevent the search for [id].
>
> It started as one.  Then we realized it required two.  Who knows if
> there'll be any more?

If more are needed we can reconsider, but for now it is just two.


> But that's not really my point.  Two is bad enough.

Well, the proposals so far all seem like just as much hacks to me.
Sugestions have included only doing certain attributes, using unique
strings, appending string automatically, etc -- all are just as dodgy
IMHO, and none are actually as powerful.


>> How do you distinguish the "end of group" marker from an actual value?
>> This is at least as much of a hack as the [] thing.
>
> The [] thing has to be implemented by the UA, and has to be part of the
> spec, and is universal.  My workaround is just that - a workaround,
> only needed in certain circumstances (nested repeats combined with
> broken CGI libs), needing no additions to the spec, and where each
> developer can choose the "end of group" marker as they please, to be
> something arbitrarily unlikely to occur as an actual value.

Unlikely but not guarenteed impossible.


> Anyway, I think the later suggestion to just auto-append .13.5 and so
> on to name attributes is probably a better one.

The problem is you might not only want to do it to names. You might want
to do it to certain IDs, template attributes, or even inside values or (in
certain obscure and rare but still quite fun cases) in event handler
script attributes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 26 June 2004 10:18:54 UTC