[whatwg] Proposal for a combined input control

[Matthew Thomas]

On 24 Jul, 2004, at 6:59 PM, Ben Meadowcroft wrote:
> ...
>> [mailto:whatwg-whatwg.org-bounces at lists.whatwg.org] On Behalf
>> Of Hallvord Reiar Michaelsen Steen
> ...
>> 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?
> ...

Normally Tab moves to the next control, so having Tab move only to 
another part of the same control is surprising-and-not-in-a-good-way. 
(Mac OS X's datepickers suffer from this problem.)

Even if you made such a control look like multiple controls, that would 
still be surprising-and-not-in-a-good-way, because people would be used 
to other applications where the same data was entered in a single 
field. They may also attempt to Tab forward even though entering the 
last digit in the previous field unexpectedly navigated them forward a 
few milliseconds earlier. (Windows 2000/XP's license key fields suffer 
from this problem.)

So my suggestion is: Just use the pattern attribute.

For example, an application asks for serial numbers of the form 
"7033/031.042". It does this using the pattern attribute: <input 
id="serialnumber" type="text" pattern="[0-9]{4}/[0-9]{3}.[0-9]{3}">. 
(Apologies if I got that regexp wrong. I don't know regexps.)

 From the pattern, a UA can see that:
(1) there are some individual characters that must be present in a
     particular order ("/" and ".", in this case);
(2) those characters are not also allowed anywhere else in the field
     (because doing anything special in that case would be more confusing
     than helpful);
(3) after the width of the parent element, and any width styling applied
     to the form element, are taken into account, there's always going to
     be enough room to show all of the field value at once.

Aha!" the UA thinks. "Therefore I can show this as a segmented field!"

     [    /   .   ]

The three segments could be navigated with the left/right arrow keys; 
and typing the end-character for each non-final segment (in this case, 
"/" when in the first segment, and "." when in the second) would also 
navigate to the next segment. So someone could type the data using 
exactly the same keystrokes as they would on a UA that didn't support 
WF2, and it would still produce the desired result.

Advantages over <inputgroup>:
*   requires no extra effort by authors
*   requires no change of behavior by users used to non-WF UAs
*   requires no extra spec text
*   has focus behavior that is either more consistent with other
     controls than <inputgroup> is (if <inputgroup> would automatically
     move focus) or more efficient (if it wouldn't)
*   doesn't require servers to handle two different modes of submission
*   can be implemented by UA vendors as and when they feel like it.

Disadvantages compared to <inputgroup>:
*   requires smart UAs (to analyze the pattern)
*   shouldn't be used where the segment separator characters are allowed
     in the segments
*   can't be used where the field isn't wide enough to show the
     maximum-length value.

-- 
Matthew Thomas
http://mpt.net.nz/