11449 2010-12-01 13:57:45 +0000 The current specification and implementation of <input type="date"> using yyyy-mm-dd format will be unacceptable to many of our corporate customers. Also, only allowing times in <input type="date"> to be in 24 hour clock will cause serious delays in our b 2011-08-04 05:03:21 +0000 1 1 1 Unclassified HTML WG LC1 HTML Canvas 2D Context unspecified Other other RESOLVED NEEDSINFO http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian ayg dbaron ian jackalmage kornel mike mounir philipj public-html-admin public-html-wg-issue-tracking shelleyp public-html-bugzilla oldest_to_newest 42957 0 contributor 2010-12-01 13:57:45 +0000 Specification: http://dev.w3.org/html5/spec/Overview.html Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: The current specification and implementation of <input type="date"> using yyyy-mm-dd format will be unacceptable to many of our corporate customers. Also, only allowing times in <input type="date"> to be in 24 hour clock will cause serious delays in our being able to implement HTML 5. On many occasions we have had Large USA Corporates and Government departments insisting on the use of 12 hour clock due to the lack of penetration of 24 hour clock into the USA. Both date and time inputs should have the option to use a variety of international formats (not just the browser locale) otherwise, many developers will have no alternative but to continue using an <input type='text'>, a javascript based calendar popup and javascript-based validation. Posted from: 78.33.209.10 42958 1 philipj 2010-12-01 14:47:20 +0000 Surely this is a presentation issue which should be addressed using CSS? Maybe a date-format property which takes a formatting string of some kind? 42960 2 kornel 2010-12-01 16:25:17 +0000 It's not the first time I see someone confused about format of date UI and internal date representation. I think the spec needs to have big flashing banner that says "This is format submitted to the server. Browsers are not required to *display* it like that, and can use localized date format in the UI." 42961 3 jackalmage 2010-12-01 18:26:33 +0000 As Kornel says, the specified format is the format that the *data submitted to the server* must be in. It has absolutely nothing to do with the actual display of the date or time; browsers are free to display them to the user in whatever format they wish. 42963 4 shelleyp 2010-12-01 18:50:08 +0000 The original request was for the web developers to be able to determine the date and time format, not have it be controlled by the browser. 42964 5 kornel 2010-12-01 19:16:39 +0000 (In reply to comment #4) Sorry if I misunderstood. In that case, why is it important to override implementations? I'm assuming that browsers will read preferred date format from system's locale, so Large USA Corporates and Government departments would get date displayed in mm/dd/yyyy format and 12-hour time automatically. 42966 6 shelleyp 2010-12-01 20:04:47 +0000 (In reply to comment #5) > (In reply to comment #4) > > Sorry if I misunderstood. > > In that case, why is it important to override implementations? > > I'm assuming that browsers will read preferred date format from system's > locale, so Large USA Corporates and Government departments would get date > displayed in mm/dd/yyyy format and 12-hour time automatically. I'm not the original filer. Unfortunately, it's one of those from the inline comments, which means the person is now disconnected from what is happening with their request. I hope they follow up on the discussion. I believe, though, that what you're saying is not what the original filer was asking. They were asking for the ability to specify something other than have the browser default to system locale. At least, that's how I read: "Both date and time inputs should have the option to use a variety of international formats (not just the browser locale)..." 42969 7 ayg 2010-12-01 20:14:02 +0000 Shelley is right -- I think the contributor was confused about display vs. internal formats, but he's still asking for the ability to choose specific output formats other than the browser locale. This is probably a good feature to have, but as Philip says in comment 1, it's probably a CSS thing. 42972 8 jackalmage 2010-12-01 21:36:06 +0000 (In reply to comment #7) > Shelley is right -- I think the contributor was confused about display vs. > internal formats, but he's still asking for the ability to choose specific > output formats other than the browser locale. This is probably a good feature > to have, but as Philip says in comment 1, it's probably a CSS thing. I don't believe that can be reliably inferred from the OP. The OP had the standard confusion between displayed value and submitted value. The request for more control over the displayed value is sufficiently vague that it can easily be interpreted to be satisfied by the existing spec text. However, if we assume that the OP *was* asking for direct author control over the display of dates and times, then, well, that's a horrible idea. The entire *point* of the datetime inputs is to offer the display in whatever fashion the user most desires. Giving control over this to the author defeats that and is directly and explicitly bad for i18n. If I were European and was used to seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm used to other sites leaving the displayed value to the default so the browser respects my locale conventions. 42998 9 ayg 2010-12-02 17:52:38 +0000 (In reply to comment #8) > However, if we assume that the OP *was* asking for direct author control over > the display of dates and times, then, well, that's a horrible idea. The entire > *point* of the datetime inputs is to offer the display in whatever fashion the > user most desires. Giving control over this to the author defeats that and is > directly and explicitly bad for i18n. If I were European and was used to > seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer > setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm > used to other sites leaving the displayed value to the default so the browser > respects my locale conventions. I think consistency within a site is much more expected and valuable than consistency between sites, for things that visually appear to be part of the site. More generally, lack of styleability is a clear deficiency of the new HTML5 inputs compared to existing solutions, and we might need to give authors a lot of control before the inputs will be widely used. However, I don't think there's any way to say for sure what's needed until browsers have basic implementation down. In all likelihood, there will be some companies or governments that demand some particular formatting, but it will probably be the same formatting that their browser uses by default, and they won't realize people in other locales will see things differently, so they won't care. I'd reclose the bug as LATER, but I'm not actually sure people other than the editor should really be resolving bugs that aren't clearly garbage. 43002 10 shelleyp 2010-12-02 19:13:02 +0000 (In reply to comment #9) > (In reply to comment #8) > > However, if we assume that the OP *was* asking for direct author control over > > the display of dates and times, then, well, that's a horrible idea. The entire > > *point* of the datetime inputs is to offer the display in whatever fashion the > > user most desires. Giving control over this to the author defeats that and is > > directly and explicitly bad for i18n. If I were European and was used to > > seeing dates as "DD/MM/YYYY", I would *not* want an ignorant American developer > > setting the displayed value to use the format "MM-DD-YYYY", *especially* if I'm > > used to other sites leaving the displayed value to the default so the browser > > respects my locale conventions. > > I think consistency within a site is much more expected and valuable than > consistency between sites, for things that visually appear to be part of the > site. More generally, lack of styleability is a clear deficiency of the new > HTML5 inputs compared to existing solutions, and we might need to give authors > a lot of control before the inputs will be widely used. > > However, I don't think there's any way to say for sure what's needed until > browsers have basic implementation down. In all likelihood, there will be some > companies or governments that demand some particular formatting, but it will > probably be the same formatting that their browser uses by default, and they > won't realize people in other locales will see things differently, so they > won't care. > > I'd reclose the bug as LATER, but I'm not actually sure people other than the > editor should really be resolving bugs that aren't clearly garbage. I agree that it is difficult to determine author and developer acceptance of the form controls until we have wider implementation. We still do not have a date implementation in the two browsers people use most, Firefox and IE, and the implementation in the other browsers is still undergoing change. A LATER status would enable us to re-visit this issue once there is wider implementation. 43003 11 shelleyp 2010-12-02 19:16:43 +0000 One quick PS Of course, at a later time, it is going to be difficult to get any changes into the spec, or implementations. In addition, there is a very real possibility that developers and web site authors will just reject the HTML5 form elements (or many of them) in favor of existing libraries, making acceptance of even changed specs and implementation that much less guaranteed. In the end, if the people don't use the HTML5 functionality, because it's too restricting or too inflexible, it doesn't matter who implements what. 44063 12 contributor 2011-01-11 00:13:56 +0000 Checked in as WHATWG revision r5761. Check-in comment: Date/time form controls: Add notes saying that the UI doesn't have to match the submission format. Some day we'll add graphics to make it more obvious, but for now I don't want to bias implementations. http://html5.org/tools/web-apps-tracker?from=5760&to=5761 44064 13 ian 2011-01-11 00:20:57 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: see above. Rationale: I've tried to clarify the spec as suggested in comment 2, but beyond that I don't understand exactly what is being requested here. Original poster: please feel free to reopen the bug as described in the "EDITOR'S RESPONSE" paragraph above. Others: please file new bugs if you have specific ideas or suggestions stemming from the discussion above. 52642 14 mike 2011-08-04 05:03:21 +0000 mass-move component to LC1