- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 31 Aug 2010 01:36:26 +0000 (UTC)
On Sun, 8 Aug 2010, Tantek ?~Gelik wrote: > > the 6 new datetime <input> types are quite useful for a variety of > use-cases but could use 2 more that fit in with the current set. > > In addition to current new absolute types of "date", "week", "month", it > makes sense to add type="year" as well for choosing a year value. Why? > And in addition to the current new relative type of "time", it makes > sense to add type="month-day" as well (for a inputting a month and a day > without a year, e.g. for a birthday without birth year, or for entering > custom annual holidays). Is this common? Do you have examples of pages doing this? On Mon, 9 Aug 2010, Kit Grose wrote: > > The field being four digits long doesn't restrict its contents to four > digits only. I suppose you do raise an interesting concern; should the > "year" field also permit the entry of BC/AD? If so, that might > invalidate the ability to use a number field; you'd need to use a > validation pattern on a standard text field. On Mon, 9 Aug 2010, Ben Schwarz wrote: > > While creating an input that works for every use case you can think of > sounds like a good idea, I'd like to question weather a user would ever > *enter a date* that would require the inclusion of BC/AD. It all depends on the use cases. Without use cases, there's no way to evaluate the proposals. On Mon, 9 Aug 2010, Brett Zamir wrote: > > How about a pull-down for Wikipedia which lets you choose the year or period? Doesn't wikipedia handle this fine today? > Or a charting application which looks at trends in history. Do you have any examples? > While some uses may be more common than others, I personally favor going > the extra kilometre to allow full expressiveness for whatever ranges are > allowed. Completeness is not a good design strategy. :-) You end up with lots of things that need implementing that are not well tested and end up being quite buggy. On Mon, 9 Aug 2010, Andy Mabbett wrote: > > It took only seconds to find: > > http://www.guernsey.net/~sgibbs/roman.html > > which requires (for some dates) entry of 1, 2, and 3-figure and BC > years. I couldn't figure out how to enter any BC years there. For AD years it seems to be fine -- and indeed, unless we provide a Julian calendar widget, that page would never be able to use our work anyway. It is well outside the 80% use case target. > Likewise: > > http://www.smart.net/~mmontes/ec-cal.html > > "Please enter a year after A.D. 325" This page seems to be fine as is; why would you need a new input control for this? On Mon, 9 Aug 2010, Marshall Eubanks wrote: > > What I would recommend is, in addition to the datetime input types, an > optional type=<Calendar> (e.g., type=""Gregorian"), which could be > ignored or used, as the circumstances required. It's not clear what this would do. Wouldn't the user be the one who should pick the calendar? Nothing stops a browser from exposing the date widget as a Julian Day calendar widget. On Mon, 9 Aug 2010, Ryosuke Niwa wrote: > > I'd just say that there might be a demand for this feature in Japan (if > localized properly) because all official government document needs to > dated with "era name" (http://en.wikipedia.org/wiki/Japanese_era_name). > Some banks even implement their internal database systems using "era" > system, and it's always cumbersome for humans to convert between "era" > and Gregorian year. On Mon, 9 Aug 2010, Ian Fette (?~B??~B??~C??~C~U?~B??~C~C?~C~F?~B?) wrote: > > And niwa-san, on every document I've ever filled out for the Japanese > government, I've always written 1985??? instead of ??????60??? and it's > yet to cause me any problems ;-) I do understand that there are some > sites that want it written in the traditional form, but these seem to be > precious few and far between, and frankly are not the sites I would > expect to find HTML5 form input elements on anyways if the US government > is any indication of moving to new standards... On Tue, 10 Aug 2010, Ryosuke Niwa wrote: > > But there are users who don't know how to convert from "????xx??" to > year 19xx (like my parents and grandparents who has to spend at least > half a minute recalling their birth years in Gregorian calendar), and > only remember their birth years in ????xx. Some people even buy a > conversion table and keep it in their wallet just so that they can > convert between two systems. Forcing them to remember their birth years > in 19xx isn't user-friendly and simply a poor UI localization. For <input type=date>, I would definitely expect Japanese UAs to offer this kind of feature. Once this takes off, if it would be helpful in Japan, we can definitely extend the feature to type=year if people often need to specify years in one format and have trouble remembering how that format maps to the other. I don't know how common that is. On Sun, 8 Aug 2010, Tantek ?~Gelik wrote: > > * this semantic gives browsers the opportunity to present a "year" > picker control that is styled in appearance consistently with other > datetime inputs (rather than just a number input) Is there any indication that browsers want this opportunity? (Why would they make their input control be styled differently?) > * this semantic gives robots the opportunity to understand that a form > takes time based information rather than just a number (if for example > robots perform time based form submissions/searches on our behalf at > some point) They're going to need to know what kind of year it is (birth year? year an album had its millionth sale? expiration year of a cookie?) to make the UI in any way sane, so just having type=year isn't going to cut it. On Tue, 24 Aug 2010, Martin Janecke wrote: > > Future browser could offer a calendar tool to fill input fields that > have a date semantic. While this would be appropriate, it would not be > appropriate to offer a calendar tool for other integer data e.g. an > input field that asks the user for his monthly income in USD. Why would you want a calendar tool for a year? On Tue, 24 Aug 2010, Andrew Hayward wrote: > > "Future browser" issues aside, it's entirely plausible that a browser > might allow me to drop events (from my calendar software, for example, > or just something else semantically a 'date' on the web) onto a > 'date'-identified input field, extracting the relevant pieces of > information and filling as appropriate. Yes, but why for a year? Would you ever really drag and drop an event rather than just type the year? On Tue, 24 Aug 2010, Christoph P?per wrote: > > > > Why is it useful to declare this semantic to the browser? What > > functional difference do you envision compared to a field that accepts > > an integer (?)? > > - Input two-digit year, transmit four-digit year. Do sites really want to support two-digit years? Other than for credit card expiry dates, I really don't remember the last time I entered a two-digit year. > - Input year name or number in a different system (including > ?AD?/?BC?/?CE?, emperor eras etc.), transmit proleptic Gregorian year > number. (Some calendar eras share their definitions of year length and > start, some are close enough to be considered equivalent in practice.) Non-contemporary dates aren't in the most common 80% of use cases, and all the pages that people have cited showing such cases have always needed far more features than we'd likely provide, so I'm not sure this is compelling. Are any browsers interested in implementing such a feature? On Mon, 9 Aug 2010, Ryosuke Niwa wrote: > > All popular calendar systems should be supported. What is the reason we > restrict ourselves to Gregorian calendar? We first start small, catering for the biggest block of use cases, and then add more features as we get experience showing how people use it. On Tue, 10 Aug 2010, Jonathan Castello wrote: > On Tue, Aug 10, 2010 at 1:53 PM, Ryosuke Niwa <ryosuke.niwa at gmail.com> > wrote: > > On Tue, Aug 10, 2010 at 1:38 PM, Aryeh Gregor > > <Simetrical+w3c at gmail.com> wrote: > >> > >> For simplicity, there?should be exactly one format submitted to the > >> server, so that the server doesn't have to implement every major > >> calendar system on the off chance it has some user whose browser is > >> configured to submit dates in the Thai solar calendar or something. > >> The browser is free to implement whatever UI it likes, though -- the > >> Japanese version of a browser might accept Japanese eras for years, > >> the Hebrew version might accept the Jewish calendar, whatever. > > > > Right, that's what I meant. ?But to implement that, we need to know > > that certain text field is accepting "year", not a 4-digit number. > > Each UA can then implement a year picker suitable for its users. > > That's probably the most convincing point for adding a "year" type I've > heard so far. I'd agree with a "year" type just based on that. Allowing Japanese-locale users enter Japanese eras instead of Gregorian years does seem like the most compelling use case presented so far. I don't know that it's compelling enough to justify adding it now, though, before we've seen how well the last set of input type additions are used. On Mon, 9 Aug 2010, jim at eatyourgreens.org.uk wrote: > The V&A's collections search uses a dropdown menu to select BC/AD on the > date fields: http://collections.vam.ac.uk/ > > There is no standard way to do this so you'll find that each > institution, with a searchable historical collection online, has > probably implemented searching by year in its own fashion. I can see the > value in agreeing on some standardised way of entering historical years > into forms. If they all do it in their own fashion, do they each have the same use case? Or do they have different needs? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 30 August 2010 18:36:26 UTC