This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per the definition (http://dev.w3.org/html5/spec/common-input-element-attributes.html#attr-input-placeholder): The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. Dates, numbers, and colors could use placeholders as well to display a brief description of the expected format. Reasoning: Because users aren't as smart as computers; for the date type, a placeholder of "##-##-####" or whatever format is expected by the date input would make a lot of sense. <fieldset> <legend>Mail Account</legend> <p><label>Color: <input type="color" name="hex-value" placeholder="Example: #000000"></label></p> <p><label>Time: <input type="time" name="hours-and-seconds" placeholder="##:##:##"></label></p> <p><label>Time: <input type="time" name="hours-and-seconds" placeholder="Military format"></label></p> <p><label>A large number: <input type="number" name="big" min="1000000" placeholder="94520318359"></label></p> </fieldset>
Color and date are specifically intended to *not* expose a standard text-input box. type=color should expose a dropper or something, and type=date should expose a calendar picker. type=number is a bit different, but the UA should still make it clear by default that it expects a number. You shouldn't have to do anything special by yourself.
I agree with Tab that <input type=number> is a sufficiently different case from the others, and have separated it into its own bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12974
Updated the bug title to match new scope.
I don't really understand what a placeholder would look like for type=color or the date-related types. Will have to examine how browsers implement these types to see if it makes sense.
mass-moved component to LC1
Marking REMIND for now. Gotta wait for Firefox to implement them and to see if WebKit's UI changes to be more like Opera's or not. Will reopen in ~6 months (feel free to do it for me if I am late in doing so — I do check the REMINDs every few months).
*** Bug 13169 has been marked as a duplicate of this bug. ***
This bug was cloned to create HTML WG bug 19072.
(Punting, pending Firefox implementing type=color.)
Update: Firefox and Chrome both have basically the same implementation for type=color, for which placeholder="" makes no sense. WebKit and IE (10) still don't seem to support it. Chrome implements all the date-related ones except type=datetime, and for none of them would a placeholder work. iOS Safari does some stuff with some of the widgets, and the placeholders could be used given how they do it. Firefox, IE, and WebKit still don't seem to support the date-related ones on desktop. Firefox Android doesn't either. They all do type=number and show a placeholder, as the spec allows. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3220 Continuing to punt given the current situation.
Correction, kbrosnan points out that actually Firefox on Android does do something when you tap the text fields. So Firefox on Android supports them more or less like iOS Safari does: they're buttons (though they look like text fields) that pop up UI. They actually do support placeholder="" on them currently. It's hard to know what to do if half the implementations show the placeholders and half don't. On the one hand, if they show them, it makes sense to allow them to be specified! On the other, if an author is relying on them to be shown, a user might get lost if the information isn't shown, and then the author will blame the browsers, even though IMHO it's perfectly reasonable not to show them...
If still desired, please file a new issue against https://github.com/whatwg/html/issues/new.