[whatwg] <input type=number> without keyboard editing

[Ian Hickson]

On Mon, 1 Nov 2010, TAMURA, Kent wrote:
>
> A team in Google tried to use <input type=number> for a product, and 
> they decided not to use it. What they needed was a control to select an 
> integer from a specific integer range such as 1 - 16. The number type 
> control in Opera and WebKit allow a user to input out-of-range value 
> even if the control has min=1 and max=16 attributes. It's not a good UI 
> and the reason why they doesn't use type=number.
> 
> They need a number control which
>  - doesn't allow any keyboard / cut&paste operations and
>   So, a text field part is read-only, but the spin-buttons work.
>  - always has a valid value.
>   "required" by default, and sanitization algorithm may be different.
> 
> I'm not sure how to solve this issue.  Introducing new content attribute 
> or another number type?

That's a very odd set of requirements. Can you tell us more about the use 
case? (Are there any controls in native OSes that operate that way?)


On Mon, 1 Nov 2010, Jonas Sicking wrote:
> 
> Do you really want to disallow keyboard editing, or do you just want to 
> disallow entering an out-of-range number? The latter should be prevented 
> by a proper implementation of <input type=number>. If that is not the 
> case in webkit or opera then I suggest you file bugs on those 
> implementations.

Browsers are allowed to let authors enter out-of-range numbers; indeed one 
can imagine situations where the default value might be out of range (e.g. 
a form saying "your previous choice is no longer valid, select a new 
value" when some business logic constraints change). However, the UA is 
indeed required to make sure the value is always numeric (or the empty 
string).


> If you really want to disallow editing then maybe what you want is 
> <input type=range>. If not then I'm wondering how common that type of 
> input widget you are requesting is. It might not be common enough that 
> it really warrants direct support in HTML. You can always use javascript 
> to build such a widget, ideally in combination with <input type=number>.

Indeed, without knowing more of the use case it's hard to say one way or 
the other.



On Tue, 2 Nov 2010, Aryeh Gregor wrote:
> 
> If the user enters a value of 100 in <input type=number max=50>, then
> it seems perverse to tell them "The maximum allowed value is 50" so
> they have to go back and fix it.  It makes more sense to just
> automatically clamp it to 50.

Either behaviour is allowed. That's mostly a quality-of-implementation 
issue.


> The spec is trying to say as little as possible about UI here, so that 
> browsers can experiment.  A browser where "Suffering from an 
> underflow"/"overflow"/"step mismatch" never occurred would be 
> conforming.  So I don't think we need implementations to concur at this 
> point -- they should be trying stuff out and seeing what works in 
> practice.  If they converge on particular conventions like this, then 
> the conventions can be added to the spec at that point.

Indeed.


On Sun, 7 Nov 2010, Aryeh Gregor wrote:
> On Thu, Nov 4, 2010 at 8:55 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > 
> > Not firing the input event would likely break scripts too...

I don't see how it could break scripts at this stage, since it's still 
very early days.


> The input event is not guaranteed to be fired on every keystroke anyway 
> [...]

The 'input' event only fires when the underlying /value/ changes, per 
spec, so if the UA isn't updating the underlying /value/ for out-of-range 
inputs, then the event doesn't fire.


On Sun, 7 Nov 2010, ddailey wrote:
> 
> [...] The problem is vaguely related to a question of mathematics: while 
> an ordinary base n writing system allows the expression of any number, 
> n, using log (n) digits, some systems that are equally efficient have 
> the added benefit (?) that individual numbers may be expressed in more 
> than one way. Ordinary bases have exactly one expression per number and 
> all numbers are expressible. Some systems might easily express certain 
> numbers using log (log (n)) digits, but might not be able to express all 
> numbers. (for example, the expression "2^(2^n)" expresses the n digit 
> number (base 2) that it represents , using only log (log (n)) digits ). 
> Is there a system of expression more efficient that ordinary base n for 
> writing all numbers? Suppose there is a writing system S that encodes 
> all numbers, n, expressible in S, using at most log(log(n)) digits. If 
> such a system is not possible then there must be a smallest number Q 
> that is not expressible within that system. Let us express that number 
> using the symbol "Q" which takes one digit.
> 
> If we had a control which allowed the entry of any large integer more 
> quickly than through a numeric keypad, then would this not be a good 
> widget? Likewise, the question of optimizing the "color picker" 
> interface so that a human can choose "precisely" (modulo psy) a 
> predetermined color (in RGB, HSV, or CIELAB space) in the least amount 
> of time, has not, I would claim, yet been optimized. I think the optimal 
> solution would involve throttles in an intrinsically toroidal space.

This is the kind of experimentation I hope we will see in browsers with 
things like type=number.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'