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.

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

The point is that some such approaches are possible already, but not
all. The simple possible solutions are rather clumsy and not very

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.


Reply via email to