Re: XForms Basic

Ian Hickson wrote:

>On Mon, 8 Dec 2003, Daniel Brooks wrote:
>  
>
>>What still doesn't make sense is why you bother making it a multitoken
>>field when you could just use two attributes.
>>    
>>
>
>Global attributes are expensive. Don't forget that these attributes can
>apply to _every_ single element. Keeping all the repeat stuff in one
>attribute makes it easier to manage.
>
>  
>
>>A multitoken field means that everyone that deals with the attribute has
>>to parse it for himself.
>>    
>>
>
>The DOM interfaces provide DOM attributes to make this unnecessary, at
>least on the client side.
>
>
>  
>

Well, you do have a point there. Just how expensive is a global 
attribute? It seems like you're trading a trivial amount of memory for a 
trivial amount of cpu time.

You still have to acknowledge the cost to tools programmers who have to 
account for a non-standard attribute type, and authors who have to learn 
it, etc. It seems like it'd just be easier to go with two attributes.

Also, I seem to have forgotten to mention that the second parameter for 
the repitition template (called index, but really just a count of the 
copies of the template) isn't really needed in the source, it could be 
exposed simply as a dom attribute. That, and you never specify that it's 
supposed to be decremented when you remove a copy of the template. 
That's either a simple omission, or it's just used as a way to make sure 
the next repitition block gets a unique index. The former is easily 
fixed, but I'm not sure the latter will work. For example, if I specify 
the index on a repitition block in my xhtml source code, I can easily 
make it larger than the current index on the template, which will result 
in duplicate index numbers when more repitition blocks are added by the 
user. Either way it's hard to tell because the purpose of the number 
isn't explicitly stated.

>>>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?
>>    
>>
>
>Because it is needed by people using forms. It is very related to forms as
>far as authors go, it is only independent as far as implementations go.
>
>  
>
>>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.
>>    
>>
>
>The DOM interfaces already enable authors to implement this pretty easily,
>but I don't know how you would do this declaratively. Any ideas?
>
>
>  
>

Sure, just make <form> something that knows which of it's children are 
selected, and draws them appropriately. Something like this:

...
<table>
  <form id="foo">
    <tr repeat="template" id="row">...</tr>
  </form>
</table>
<input type="add" template="row" form="foo">
<input type="move_up" template="row" form="foo">
<input type="move_down" template="row" form="foo">
...

Obviously the <form> tag would be a bit different than we use today, and 
you wouldn't be able to put it in the <head>, it'd have to go places 
it's never been allowed but where people have always put it anyway, etc.

I'm sure there are plenty of details to work out in that situation, but 
it is 5 am :)

>>>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.
>>    
>>
>
>Why? I don't see how this is ever a problem (other than it probably being
>terrible UI).
>
>
>  
>

Right, it just makes a terrible UI.

>>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.
>>    
>>
>
>Take a look at the interfaces again, specifically:
>   http://www.hixie.ch/specs/html/forms/web-forms#labels
>...which I just added.
>
>  
>
Yes, that is awesome. Really, I don't know why I didn't think to ask for 
something like that. It's probably unnecessary, but I think you should 
specify that the list is in document order.

db48x

Received on Tuesday, 9 December 2003 05:36:21 UTC