On Tue, 12 Oct 2010 02:12:48 +0200, Philipp Wagner
<[hidden email]> wrote:
> in Mozilla XForms we currently render a xf:input with a bind to an
> integer type as a spinbox (like those:
> http://img.brothersoft.com/screenshots/softimage/s/spinbox.js-212215-1234938073.jpeg; > a textbox with those small up and down arrows). Recently a user
> complained about this behavior, he expected a simple input box (without
> the arrows).
> How do other XForms processors render this type? I tried Orbeon, which
> always displays a simple input box (and I didn't get formsPlayer to
> work, and its website formsplayer.com seems to be down).
Usually they use a simple input box, but I don't see what the problem
could be as long as the spinbox also lets you type a value in.
> I thought about making appearance="full" showing the spinbox with
> arrows, and all minimal and compact only a simple input box.
Using @appearance is a good solution if it is really needed.
We discussed your message today at the Forms WG teleconference and
have a few more suggestions.
Steven Pemberton correctly pointed out that you can use appearance
to control input, and since the up/down buttons are presentation, it
seems appropriate to control them by appearance; however, Steven
also suggested that the WG might consider recommending minimal
to mean a truly minimal appearance (as we do suggest with trigger),
and full might be an even fuller experience, perhaps with a
calculator available. So, again, it looks like the ultimate styling
of presentation may be something best left up to the implementations
using host-language or other facilities.
I noted that not all input controls bound to integers would benefit
from +1 / -1 buttons:
<label>How many bytes of RAM does your computer
Philip Fennell suggested that the up/down controls for discrete
values of integers sounds more like an XForms range control than an
input. So, you might consider using range/@appearance to control
the presentation of range when bound to an integer type.
In summary, it seems that your form authors have a valid point, that
they +1/-1 is not appropriate for all integers, given the unbounded
nature of integers, and while Steven is correct that your XForms
implementation can interpret the appearance attribute to control any
presentation interaction, it may be that the best bet is to migrate
the +1/-1 to range bound to integer (and its restrictions) and let
the form author specify the @appearance there. The range control
would of course be free to examine the range attributes (start, end,
step) and offer additional affordances; for example, f range were
small and step=1, the up/down buttons would be useful, but for
moderate range (say, 0-1000000), an odometer style is often popular,
where the control would be populated with a set of digits that span
the allowed range, and each digit is separately manipulable.