Re: [whatwg] Typed numeric 'input'

2014-08-05 10:14, Christoph Päper wrote:

> You do realize that font size control was just an example?

Well, maybe not quite; the original message discussed font size control 
in detail and did not mention other examples.

> A combined
> widget for number and unit would be useful in many places.

I would expect most applications to decide on a unit or (sub)multiple of 
unit for each quantity. To process the input, the value would normally 
need to be converted to use a specific unit anyway.

> Although
> most of us use metric units exclusively for almost all applications,
> there are still a lot of scenarios where two or more units are
> commonly used – even with the SI some may prefer centimetres over
> millimetres sometimes (or vice versa).

The SI unit of distance is the meter. The centimeter and the millimeter 
are just submultiples of the meter. But I can see that it might be 
useful on some contexts to let the user decide which of these 
submultiples is used, e.g. when specifying dimensions of household 
equipment. This however sounds rather simple: have just one field for 
the number and a dropdown with “mm” and “cm” as alternatives. Even then, 
fixing the unit might actually be better usability (don’t force the user 
make to decisions if there is a reasonable way to avoid that(.

>> An addition to the ways mentioned, the font size control could be
>> simply two buttons, one for increasing and one for decreasing the
>> size, (…)
>
> This seems like a special cased ‘numeric’ or ‘range’ widget and is
> agnostic of units.

It is, and probably therefore favored by many designers. It’s simple, 
often too simple, but I mentioned it just as a common example.

>> The designer needs to decide the internal representation of the
>> font size and to map the alternatives in the UI to that. I don’t
>> see how additions to HTML would significantly help here, even if
>> they happened to match the approach that is selected by the
>> designer.
>
> The point is that some such approaches are possible already, but not
> all. The simple possible solutions are rather clumsy and not very
> user-friendly.

I don’t see anything clumsy with two fields, one for a number, another 
for a unit. If there is any clumsiness, it’s in the idea of making the 
user select the unit. There can be reasons to do so, of course, but in 
such special cases, the UI and the code implementing it needs to be 
tuned according to the special requirements.

> Every author could, of course, just parse all free user input from a
> ‘text’ input server-side, but why shouldn’t browsers sanitize such
> input like they do for other form controls?

Because it is up to the designer to decide what the allowed formats are, 
how errors are handled, etc. The format is generally locale-dependent, 
and localization is poorly handled at present in HTML – it has a vague 
idea of using the system locale, the browser locale, the document 
language locale, or something else. This mess should be cleared up 
before new features requiring localizations are added.

To the extent that general code for handling such issues can be written, 
it should be in libraries and frameworks, rather than as constructs that 
browsers are required to implement.

Yucca

Received on Tuesday, 5 August 2014 07:39:23 UTC