- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Thu, 14 Apr 2011 14:23:50 +0300
Henri Sivonen wrote: > The the requirements you cite apply to what goes over the wire and > appears in the DOM. The browser may provide a comma-base UI for > manipulating the value that is stored and transfered using a period. I see... thanks for the clarification. Yes the description is very general and allows user interfaces of many kinds. > It does mean that the degradation story in browsers that don't support > the numeric form input types is worse for locales that don't use the > period as the decimal separator. In general with the new input types, we have the problem that when they are not supported but degrade to <input type="text">, the user would need instructions on data format, e.g. saying that decimal point be used or that a color be specified as #hhhhhh - and these would look stupid when they are not needed. But this can probably be handled reasonably using scripts that test for the support first. Or maybe it would be more robust, transitionally, to include the instructions and <input type="text"> in markup, with client-side scripting then trying to set the state to, say, "number", and when successful, removing the instructions (or replacing them with some different instructions). >> On the other hand, would it be useful to _allow_ localization so >> that a browser _may_ interpret a comma as a decimal separator? > > No. Having "may" in processing rules is a recipe for > non-interoperability. As far as I can see, such operations _are_ allowed by the current formulations. The browser may use various mechanisms for letting the user to specify a number, and this includes permissive processing of written numbers, as long as the browser ultimately generates a valid number (or raises an error). > I think the main problem is triggering the decimal separator mode (or > the order of numeric day and month for that matter) on the UI locale > rather than the locale of the page, Well that's certainly at least _one_ of the problems. And we might ask whether a browser should use the _system_ settings, as they should probably be expected to best reflect the user's real preferences. > Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. > treat the language as a locale Mapping languages to locales is a guessing game, in addition to all the other problems involved. The problems look rather complicated, but at least I now understand the issue better. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Thursday, 14 April 2011 04:23:50 UTC