- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 6 Jan 2011 23:22:44 +0000 (UTC)

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. `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 6 January 2011 15:22:44 UTC