W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] <input type=number> for year input

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 18 Feb 2014 23:59:38 +0000 (UTC)
To: Jonathan Watt <jwatt@jwatt.org>
Message-ID: <alpine.DEB.2.00.1402182342370.31525@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>
On Tue, 18 Feb 2014, Jonathan Watt wrote:
> > 
> > My recommendation would be to just use comma separation
> 
> It would be the appropriate separator(s) for the locale in use, not 
> necessarily the comma, but I'm guessing that's what you meant.

Sure.

> > for numbers greater than 9999. It doesn't help that much for 
> > four-digit numbers, and years beyond four digits often _do_ have 
> > commas, e.g.:
> > 
> >     http://en.wikipedia.org/wiki/Year_10,000_problem
> > 
> > I agree that it's a bit weird (though not particularly wrong) for 
> > four-digit years to have commas.
> 
> Personally I think it's a bit more than a bit weird to have "Year: 
> 2,014". It seems pretty ugly to me, and four digit years are going to be 
> the common case.
> 
> > type=number does seem appropriate for years, though.
> 
> I wonder if it would be that bad to have a 'year' type to compliment the 
> 'month' and 'day' types...

This has come up a few times, but so far the use cases have not been 
compelling enough. This is probably the most compelling use case, but even 
here, I don't know that it's that compelling.

I would be interested in hearing more about the locales where not using 
separators even for four digits is bad/suboptimal. If it wasn't for those, 
I would say that just not using separators for four-digit numbers would be 
an easy and effective solution.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 19 February 2014 00:00:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:16 UTC