This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html Multipage: http://www.whatwg.org/C#date-state Complete: http://www.whatwg.org/c#date-state Comment: A "date-optional-state" should be available, for when the specifity of the date is unknown. This would give the user the option of selecting a year, month, or day. Any additional requirements (e.g. required month) can be taken care of with [pattern]. Would be just like "date-state", but parameters on end would be optional (e.g. "YYYY[-MM[-DD]]"). Optionally, "0"s could be used, rather than omitting (e.g. "YYYY-00-00" or "YYYY-MM-00"). Example use case: Published Date for books. Publishers sometimes only list a month (esp. when published on different days across time zones), but more detail is preferred. Two inputs ("Month" and "Date") is not possible as it requires a script for validation ([required] for both locks form) and people try to fill out all form fields (duplicates is confusing). Using [pattern] as-is is not a solution as it does not present the user with a date picker. Posted from: 24.231.239.6 by bfrohs@gmail.com User agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
I have marked this LATER so that we can look at this again once browsers have caught up with what we've specified so far.
Can you elaborate on use cases, ideally with a reference to a page that does something like this so I can study how they expect the UI to work?
bfrohs: Please see comment 2.
(In reply to comment #2) > Can you elaborate on use cases, ideally with a reference to a page that does > something like this so I can study how they expect the UI to work? Apologies for the delay, this got lost in my own personal abyss known as email. We went ahead and used a plain text input that expects "YYYY-MM-DD" or "YYYY-MM" format. All validation is done server-side, and if a date that doesn't match the required format is sent, PHP's `strtotime()` function is run on the provided text, and if it can read it as a valid date, the user is asked if that's what they meant to provided. For example, if "January 2013" was provided, `strtotime("January 2013")` would be called and the user would be asked if they meant "2013-01-01". It isn't ideal by any means, but it gets the job done. --- Had I had the time to work on a JavaScript date picker, I would have done something like "<- January -> | <- [2013] ->" with the dates listed below like "date" does, where "January" was a link that could be clicked just like any of the days, "<-" and "->" were buttons that would (in|de)crement the month, and 2013 could be an input box to change the year by a large amount easily.
Right but what is the use case? That is, why do you need a field where some of the data isn't necessary? I'm just trying to get an idea of where to start researching this kind of thing to work out what the requirements are.
(In reply to comment #5) > Right but what is the use case? That is, why do you need a field where some > of the data isn't necessary? I'm just trying to get an idea of where to > start researching this kind of thing to work out what the requirements are. As mentioned in the original report: > Example use case: Published Date for books. Publishers sometimes only list a month (esp. when published on different days across time zones), but more detail is preferred. With that said, although we'd prefer to have the exact date that a book was published (e.g. YYYY-MM-DD), publishers/authors can't always provide this information. Sometimes they don't have the information readily available. Other times the book hasn't been published yet, and while the year or month is set in stone, the month or day hasn't been yet. Instead of forcing them to provide either an *exact date* or *nothing*, it's beneficial to be able to allow them to provide a partial date instead (e.g. YYYY-MM or YYYY). Using two different fields for this purpose would confuse users and be more difficult to achieve on the server's side of things. As a side note, it is rather common in the book industry for the day to be left out from the published date, even on sites such on amazon.com: http://www.amazon.com/dp/1585421464 - Includes day: > Publisher: Jeremy P. Tarcher/Putnam; 10 Anv edition (March 4, 2002) http://www.amazon.com/dp/0961392142 - Does not include day: > Publisher: Graphics Pr; 2nd edition (May 2001)
Hm, interesting. So this is basically a form control that could be anything from type=number (just a year) all the way to type=datetime (a year, month, day, hour, minute, second, time zone offset), and you don't necessarily know which... I wonder how common this is. If it's pretty rare, it might be best to let authors make their own widgets with Web Components for it. If it's common, we should support it. Book publication dates are one case (year-month or year-month-day, it seems?). Are there others?
Yes, year-month or year-month-day, although I'm sure year by itself could be necessary at times for some. This format also applies to movie/show release dates: http://www.imdb.com/title/tt0111495/releaseinfo (Note USA release date is missing the day). Also, a "year-month-day" or "year-month-day hour:minute" is another common use, specifically for scheduling events/reminders in the future: Google Calendar has an "All Day" checkbox when creating a new event that, when checked, hides the second input box for the time for the start/end. Facebook Events do something similar, but instead of a checkbox, they simply allow you to leave the time input blank. Their date input has a clickable calendar and their time input is a text field that drops down a list of times in 5 minute increments (after you begin typing a time). In the "Work and Education" of Facebook profiles, you have the ability to enter year, year-month, or year-month-day. Initially, it's presented as a year select, then you can click "Add month" to choose a month from a second select, then you can click "Add day" to choose a day from a third select. So, like you suggested, an element that could handle every variation from only the year to the full date would be incredibly useful, so long as it had a minimum amount required (e.g. year-month) and a maximum amount allowed (e.g. year-month-day).
Hm, interesting cases, thanks. A lot of these cases have explicit UI; it might make sense to just let authors use the existing controls with buttons to switch between them. But I agree that would be somewhat ugly if browsers are willing to implement a single control instead...
Please file a new issue at https://github.com/whatwg/html/issues/new if there's still interest.