[whatwg] Proposal for a combined input control

[Ben Meadowcroft]

> -----Original Message-----
> From: whatwg-whatwg.org-bounces at lists.whatwg.org
> [mailto:whatwg-whatwg.org-bounces at lists.whatwg.org] On Behalf
> Of Hallvord Reiar Michaelsen Steen
> Sent: 23 July 2004 23:26
> To: Jim Ley
> Cc: whatwg at whatwg.org; ben at benmeadowcroft.com
> Subject: Re: [whatwg] Proposal for a combined input control
>
>
> On 23 Jul 2004 at 22:37, Jim Ley wrote:
>
> > > This control would be useful for entering long numbers such as
> > > credit card info or serial numbers, input focus could
> automatically
> > > pass to the next box in the group to speed up data entry.
> >
> > Are there any studies which actually shows this is easier - because
> > the OS IP entry control is the one I have most problems
> with, I find
> > the auto-focusing really hard to use.
>
> The auto focus in the IP dialog IS hard to use - because the computer
> doesn't take into account that some parts of the IP address
> frequently have less than 3 digits. So, sometimes we want to move the
> focus after one or two digits and there isn't an obvious way to do
> that except using the mouse.

Or just tab to the next input? Anyway auto focusing was just an idea, I
have no particular attachment to it other than I personally like it but I
don't think we should get into a "religious" war over it like people are
doing with labels and the like! I am happy for the auto focusing behaviour
to not be in the spec, if authors want to add it then you could frig it
using JavaScript with the handy new element I've introduced making it easy
to get a reference to any child form elements.

> I think the original suggestion sounds very interesting though. As
> Jim says it would be nice for dates too. I vote for the INPUTGROUP
> element although I think for backwards compatibility we should just
> let the UA submit all three inputs separately. The servers have to
> deal with that anyway for legacy so there's very little gain in
> making life more complicated for the UA with some patterns for
> combining the values.

I understand your point with legacy browsers. I think we could submit the
underlying values with the constructed value as well without any issues. I
understand why you would like to keep the client simple, however I think
that we should allow constructed values and allow the input group to
expose a value property in the DOM to enable us to do things like specify
required status or validation pattern on a per input group basis than for
each individual component of the group, if desired. After constructing the
value internally then it might as well be available for submission by the
form.

Yes it may make the server form handling more difficult in some cases but
not excessively so, in semi pseudo code (guess the server-side language)
it is only one extra conditional statement:

if (request.getParameter("date") != null)
{
   someObj.setDate(request.getParameter("date"));
}
else
{
   /* normal handling */
}

Anyway I think the advantages of exposing the result as one value (whether
submitted or just client side) make certain things easier as a developer.
For example constructing xml documents on the fly from form values becomes
a lot simpler as we can declare the constructed value rather than
programmatically calculating it.

Legacy free comments follow, look away now: For a quite specific use case
constructing an XML document with an element whose content is a date time
value in the format "yyyy-MM-dd HH:mm" requires you to only query one form
element for the value where as if we had separate inputs for the day,
month, year, time etc we would have to query 4 or so and then construct
them into a pattern. Sure it's a specific use case, and one that many UAs
won't support anyway, but for those that do it could be quite useful IMO.

--
Ben Meadowcroft
http://www.benmeadowcroft.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20040724/a5d62743/attachment-0001.bin>