Re: XForms Basic

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.


>> 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?


>> 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).


> 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.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 8 December 2003 09:22:43 UTC