Re: [whatwg] Typed numeric 'input'
Jukka K. Korpela jkorp...@cs.tut.fi: 2014-08-04 20:06, Christoph Päper wrote: Imagine a text layout GUI made with HTML. It would probably feature a font size selection control. There are different ways to do such a thing: There are, and they are preferred in different ways by different people, as programmers or as end users. This is why any solution, in addition to introducing considerable complexity into HTML, would be used for a small fraction of potential use cases only. You do realize that font size control was just an example? A combined widget for number and unit would be useful in many places. 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). Not to mention US localisation. 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. 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. 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?
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
[whatwg] Typed numeric 'input'
Imagine a text layout GUI made with HTML. It would probably feature a font size selection control. There are different ways to do such a thing: 1 input type=number min=0 id=value!--unit implied-- 2 input type=text id=value pattern=\d+([.,]\d+)? *(pts?|px|mm)\.? 3 input type=number min=0 id=value input type=text id=unit pattern=(pt|px|mm) 4 input type=number min=0 id=value select id=unitoptionpt/optionoptionpx/optionoptionmm/option/select There are, of course, more possible units and one might want to supply a ‘datalist’ with suggested predefined values, e.g. datalist id=TeXsizes11 option value=6 label=tiny option value=8 label=script option value=9 label=note option value=10 label=small option value=11 label=normal option value=12 label=large option value=14 label=Large option value=17 label=LARGE option value=21 label=huge option value=25 label=Huge /datalist Most desktop word processor GUIs use something like option 2, by the way, some always expect points and hence only provide solution 1 or just a drop-down list of predefined values. It’s not possible, however, at least as far as I know, to strongly associate the two controls in options 3 and 4 (i.e. for number and unit) with each other, so UAs could employ a native widget for typed values. When the user changes the unit, such a widget could either keep the numeric value or convert it accordingly. This is what I’d like to propose, but am not sure yet how. Although it makes sense to store value and unit together and convert on demand, they are more often converted into a purely numeric format, which usually will result in rounding errors (e.g. all those A4 PDFs that claim a page size of close to but not exactly 210 mm × 297 mm) unless a very small base unit is chosen. For length units used with font sizes, this might be EMU, half-point, twentieth-point etc. – let’s assume EMUs with 12700 emu/pt and 36 emu/µm. Since TeX uses the classic pica point (0.166 in/pc) instead of the simple DTP point (12 pc/in) the above ‘datalist’ would look like this (if striving for unnecessary precision) datalist id=TeXsizes11 option value=75895.2 label=tiny option value=101193.6 label=script option value=113842.8 label=note option value=126492 label=small option value=138508.74 label=normal option value=151790.4 label=large option value=182148.48 label=Large option value=218578.176 label=LARGE option value=262293.8112 label=huge option value=314752.57344 label=Huge /datalist But how could the accompanied ‘input’ support multiple views (i.e. conversions) onto this unified representation, and without exposing it to the user? The first solution I came up with is a ‘units’ attribute as follows: input type=number min=0 id=value list=TeXsizes11 units=pt: 12700; px: 16933.33; mm: 36000 The HTML4 fallback, however, would be horrible, because users would be exposed to EMU, which they absolutely must not be. Therefore one of the units would have to be selected as a default. input type=number min=0 id=value list=TeXsizes11 units=pt: 0.75; px: 1; mm: 2.126 This could be done with a more verbose, but reusable ‘datalist’ instead: input type=number min=0 id=value list=TeXsizes11 units=lengthunits datalist id=lengthunits option value=0.75 label=pt title=point option value=1 label=px title=pixel option value=2.126 label=mm title=millimetre /datalist ‘units’ could also be called ‘scale’. If, however, we would prefer a variant with 2 form elements that may be joined (option 3, 4) instead of a single complex one (based on 2) as shown above, we’d need a way of associating them with each other. input type=number min=0 id=value units=unit input type=text id=unit pattern=(pt|px|mm) input type=number min=0 id=value input type=text id=unit pattern=(pt|px|mm) for=value data value=#value unit=#unit input type=number min=0 id=value input type=text id=unit pattern=(pt|px|mm) /data data type=value unit!--indicate order-- input type=number min=0 id=value input type=text id=unit pattern=(pt|px|mm) /data These lack a possibility to specify conversion factors. That might be achieved by data type=value factor input type=number min=0 id=value select id=unit option value=0.75 label=pt option value=1 label=px option value=2.126 label=mm /select data As I’m said, I’m not sure what’s the best solution, but HTML should have a typed numeric input element with conversion capabilities.
Re: [whatwg] Typed numeric 'input'
2014-08-04 20:06, Christoph Päper wrote: Imagine a text layout GUI made with HTML. It would probably feature a font size selection control. There are different ways to do such a thing: There are, and they are preferred in different ways by different people, as programmers or as end users. This is why any solution, in addition to introducing considerable complexity into HTML, would be used for a small fraction of potential use cases only. An addition to the ways mentioned, the font size control could be simply two buttons, one for increasing and one for decreasing the size, possibly with keyboard shortcuts and possibly a button and/or shortcut for resetting the size to the default. And many others. As I’m said, I’m not sure what’s the best solution, but HTML should have a typed numeric input element with conversion capabilities. 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. Yucca
