This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12868 - forms: Allow placeholder="" for color and date/time types
Summary: forms: Allow placeholder="" for color and date/time types
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: 2016 Q1
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
: 13169 (view as bug list)
Depends on:
Reported: 2011-06-03 01:26 UTC by rasamassen
Modified: 2017-07-21 14:40 UTC (History)
17 users (show)

See Also:


Description rasamassen 2011-06-03 01:26:01 UTC
Per the definition ( 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.

 <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>
Comment 1 Tab Atkins Jr. 2011-06-04 01:11:00 UTC
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.
Comment 2 Edward O'Connor 2011-06-16 22:17:33 UTC
I agree with Tab that <input type=number> is a sufficiently different case from the others, and have separated it into its own bug:
Comment 3 Edward O'Connor 2011-06-16 22:20:27 UTC
Updated the bug title to match new scope.
Comment 4 Ian 'Hixie' Hickson 2011-06-16 22:43:55 UTC
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.
Comment 5 Michael[tm] Smith 2011-08-04 05:04:46 UTC
mass-moved component to LC1
Comment 6 Ian 'Hixie' Hickson 2011-08-11 21:15:23 UTC
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).
Comment 7 Ian 'Hixie' Hickson 2011-08-14 06:22:27 UTC
*** Bug 13169 has been marked as a duplicate of this bug. ***
Comment 8 Michael[tm] Smith 2013-01-30 07:52:17 UTC
This bug was cloned to create HTML WG bug 19072.
Comment 9 Ian 'Hixie' Hickson 2013-10-01 23:23:16 UTC
(Punting, pending Firefox implementing type=color.)
Comment 10 Ian 'Hixie' Hickson 2014-09-30 17:18:07 UTC

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.

Continuing to punt given the current situation.
Comment 11 Ian 'Hixie' Hickson 2014-09-30 17:29:01 UTC
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...
Comment 12 Anne 2017-07-21 14:40:41 UTC
If still desired, please file a new issue against