974175 - Consider not using grouping separator characters when displaying <input type=number>'s value

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jonathan Watt [:jwatt]]

When implementing <input type=number> I decided to display the value to the user using the grouping separator (generally a separator marking the thousands columns) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as "1,234".

[e-mail] points out in bug 866457 comment 7 that this isn't so great when <input type=number> is used to allow the user to input a date. Displaying "Year: 2,014" is pretty ugly. Media Wiki uses <input type=number> for year input, for example on:

   https://en.wikipedia.org/w/index.php?title=IRIX&action=history
   https://en.wikipedia.org/wiki/Special:Contributions/newbies

We should consider changing the implementation to stop displaying the internal value using grouping separators.

I should note that we can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators.

I should also have noted that I did get some early feedback that failing to 
include grouping separators in the general <input type=number> case would be 
bad/suboptimal for certain locales, but I can't remember which locales those 
were at this point. If anyone knows of such locales I'd be interested to hear which.

Since both alternatives have downsides I've posted to the whatwg list to solicit some wider feedback:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-February/042034.html

Comment 1

[Jonathan Watt [:jwatt]]

Another argument for stopping displaying the internal value using grouping separators is that it can make the input harder for the user to edit. For example, if the displayed value is "1,234,567,890" an the user wants no change it to "123,456,789" they can't do it just by deleting the "0"; they must correct the positioning of the "," characters too.

Maybe this is a bogus additional argument though, since alternatively we may be able to auto-correct the position of the grouping separator with a bit of work? (I'm not sure that would work for all locales, or even be a nice user experience, though.)

Comment 2

[Jonathan Watt [:jwatt]]

Another argument for stopping displaying the internal value using grouping separators may be that Chrome doesn't do it, although I think that's mostly down to the fact that their localization implementation is a lot more basic than ours.

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Watt [:jwatt] from comment #2)
> their localization implementation is a lot more basic than ours.

Alternatively, "sucky and pretty buggy" (from my testing).

Comment 4

[ebrahim]

https://github.com/wikimedia/mediawiki-core/blob/423c0682c582acaf8f6a6efb335dd34ec2302bcb/languages/Language.php#L3066

1. Some locales like Gujarati do reverse use of comma and dot. That may be problematic or confusing on some cases and I guess that what was you looking at.
2. On MediaWiki number formatter has option of disabling/enabling decimal thousand separator. May having such would be useful input number

Hope to be useful

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to ebrahim from comment #4)
> https://github.com/wikimedia/mediawiki-core/blob/
> 423c0682c582acaf8f6a6efb335dd34ec2302bcb/languages/Language.php#L3066
> 
> 1. Some locales like Gujarati do reverse use of comma and dot.

It's a lot more complicated than that. I believe some locals even have more than one grouping separator (both of which are different to the decimal separator).

> That may be
> problematic or confusing on some cases and I guess that what was you looking
> at.
> 2. On MediaWiki number formatter has option of disabling/enabling decimal
> thousand separator. May having such would be useful input number

I don't think this is something we want to require users to have to set. Besides that what the user actually wants may depend on the semantics of the number control, such as, is it a year, or the number of trees they can see?

Comment 6

[ebrahim]

> I don't think this is something we want to require users to have to set.
> Besides that what the user actually wants may depend on the semantics of the
> number control, such as, is it a year, or the number of trees they can see?
I meant on MediaWiki developers by the context and semantics of a number decide to commafy output or not. Perhaps giving such option to webdevs with something like <input sep="enable|disable"... is good or needed. Of-course I guess for this someone should file bug on w3.

Comment 7

[Jean-Yves Perrier [:teoli]]

(In reply to Jonathan Watt [:jwatt] from comment #5)
> It's a lot more complicated than that. I believe some locals even have more
> than one grouping separator (both of which are different to the decimal
> separator).
And some locales doesn't group 3 by 3, but 4 by 4 !

Comment 8

[Jonathan Watt [:jwatt]]

Attachment: patch

My feeling, given the whatwg list discussion, is that we should disable this. In my opinion the spec should provide a mechanism to do this though.

Comment 9

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/03598731cb2a

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/03598731cb2a

Comment 11

[Jonathan Watt [:jwatt]]

Comment on attachment 8378353 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 844744
User impact if declined: some bad interactions with number controls
Testing completed (on m-c, etc.): landed on m-c yesterday
Risk to taking this patch (and alternatives if risky): very low
String or IDL/UUID changes made by this patch: none

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dcc0c762333c

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #0)
> Since both alternatives have downsides I've posted to the whatwg list to
> solicit some wider feedback:
> 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-February/042034.html

FWIW -- this ^^ URL is now broken, but the conversation is also archived here:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0075.html