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
