Closed Bug 974175 Opened 6 years ago Closed 6 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
firefox29 --- fixed
firefox30 --- fixed

People

(Reporter: jwatt, Assigned: jwatt)

References

Details

Attachments

(1 file)

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".

ebrahim@gnu.org 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
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.)
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.
(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).
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
(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?
> 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.
(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 !
Attached patch patchSplinter Review
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.
Attachment #8378353 - Flags: review?(ehsan)
Attachment #8378353 - Flags: review?(ehsan) → review+
https://hg.mozilla.org/mozilla-central/rev/03598731cb2a
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Blocks: 844744
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
Attachment #8378353 - Flags: approval-mozilla-aurora?
Attachment #8378353 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(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
You need to log in before you can comment on or make changes to this bug.