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/the-input-element.html Multipage: http://www.whatwg.org/C#attr-input-type-keywords Complete: http://www.whatwg.org/c#attr-input-type-keywords Comment: Why aren't placeholders available on Date/Time fields? It seems to me they should. Posted from: 213.103.207.56 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30
This report wasn't that specific. Sent it through the comment form on the website and didn't realize it would end up as a bug report. Anyway, my point is that placeholders are missing from date/time type fields. In their current incarnation in most browsers these fields look the same as textfields. Thus, it would be useful to allow placeholders on them, just like other text fields.
Related to bug 12868. Bug 12781 comment 1 is relevant. The question is, are there going to be a significant number of browsers around that support placeholder but not date/time inputs? If we expect that all such browsers will be gone within a year or two, it doesn't seem worth allowing this. On the other hand, it's harmless in browsers that do support the type. I think it makes sense to allow attributes like maxlength and placeholder on all the new input types for now, and say that browsers must ignore them if they actually support the type. It would be fallback content for legacy browsers, like the contents of <video> or whatever. In a few years we can revisit and make them obsolete, once there's no reason to use them anymore.
mass-move component to LC1
*** This bug has been marked as a duplicate of bug 12868 ***