Re: XForms Basic

Ian Hickson wrote:

>On Sat, 6 Dec 2003, Daniel Brooks wrote:
>  
>
>>>>It also might be nice to be able to for a repeate block to be a copy
>>>>of a template that isn't a sibling.
>>>>        
>>>>
>>>Maybe, but that would be hard. I've yet to actually see a use case for
>>>that one.
>>>      
>>>
>>Seperate it into two attributes, template="true" and repeat="templateid"
>>or something like that.
>>    
>>
>
>No need for the expense of multiple attributes, the attribute is already a
>multitoken field.
>
>
>  
>
>>As for a use case, wouldn't nesting repeat blocks keep the inner one
>>from working?
>>    
>>
>
>No, I was careful to make that work.
>  
>

Oh, I see. The inner template gets copied into each repetition of the 
outter. That makes sense.

What still doesn't make sense is why you bother making it a multitoken 
field when you could just use two attributes. A multitoken field means 
that everyone that deals with the attribute has to parse it for himself. 
This includes the UA, the webpages themselves, and chrome level stuff 
like page info. Plus you have to specify new parsing rules about leading 
whitespace and extra trailing tokens and so on. Seperating it into two 
normal attributes simplifies it for everybody and reduces the number of 
places that will parse it incorrectly.

>>Obviously page info would need to list the template and repeated blocks
>>seperately.
>>    
>>
>
>Obviously? Why would anyone care? (Then again, I've often wondered that
>about some of our current Page Info features.)
>  
>
>>HTMLFormFields.templateElements gives me the controls in the template,
>>which is good. I'd like to be able to get an array of HTMLCollections to
>>represent the repeated blocks though.
>>    
>>
>
>Repeated blocks aren't associated with forms necessarily. You can repeat
>anything you like.
>
>
>  
>
Ah. In that case, there's no reason for the form tab to single the 
information out. In fact, it begs the question: why is this in a spec 
about forms?

In fact, rereading the section makes me wonder just how good the idea 
is. Obviously it's something that'd be great to have, but I think the 
execution isn't quite right. In the typical example of a multirow form 
(a purchase order, or whatever) each row ends up with a 'delete this 
row' button, a 'move up' button and a 'move down' button. In order to 
move a particular row down by three rows, you have to click it's 'move 
down' button, move the mouse down a row, click the 'move down' button, 
move the mouse down a row and then click the 'move down' button a third 
time before it's there. What is really needed is a way to put the 
buttons off to the side, so that a particular row can be selected, then 
a single move down button clicked on three times, with no movement in 
between.

Perhaps checkboxes to indicate the selection, or use the normal 
click-and-drag text selection to indicate which row(s) to move. Or, 
horror of horrors, putting everything inside a <select size=""> field. :)

>>Can you nest forms? I'm pretty sure you couldn't in XHTML and I didn't
>>read anything in this proposal, so I guess not. I hope not :)
>>    
>>
>
>Yes, you can. Well, more to the point, the form attribute means that forms
>can be intertwined.
>
>  
>
Well, as long as you can't nest the actual <form> nodes 
(<form><input/><input/><form><input/><input/></form></form>), then I 
don't have a problem with it.

In either case, if all I'm concerned about is page info I can leave it 
up to the UA to decide which control goes with which form. It does mean 
that I have to do a little extra work to find all the <label>s for the 
controls; the current page info code assumes that <label>s are always 
descendants of the <form>. It'll probably just have to grab a list of 
all <label>s in the document instead of just those in the <form>. 
Backtracking up the descendant tree won't work, because it won't catch 
<label for="foo">Foo</label><input id="foo"/> and so on.

db48x

Received on Monday, 8 December 2003 08:39:22 UTC