[whatwg] <input type=color>
ian at hixie.ch
Tue Nov 25 19:48:07 PST 2008
On Sat, 14 Jul 2007, Martin Atkins wrote:
> Benjamin Joffe wrote:
> > Have the following possible values for the TYPE attribute been considered
> > for the INPUT element?
> > type="color"
> > The user agent would display an appropriate colour picker and would send a
> > hexidecimal string represting that colour to the server.
> I like this idea. It's simple and it's something I've implemented (and
> seen implemented) dozens of times.
On Sat, 14 Jul 2007, Sander wrote:
> I like this one too. It should have an pallet attribute that defines the
> color pallet. I'm not shure how though, cause on one hand I'd like to be
> able to choose easily from standard pallets, but on the other hand I'd
> like the option to create custom pallets. Perhaps pallet="custom"
> combined with a datalist could be an option here.
I've made list="" and <datalist> apply to type=color, but not given any
control over the actual range of colours allowed, so users can pick any
opaque sRGB color.
On Sat, 14 Jul 2007, Sander Tekelenburg wrote:
> Same here. A use case I can imagine is an authoring tool that let's users
> create CSS rules. Simply clicking the wanted colour avoids the risk of
> (syntactically) incorrect color values.
> However, to make it complete it would have to work both ways: if the
> form defines a color (<input type="color" value="#66f">), that colour
> should be presented s selected by the UA's color picker. Perhaps that's
> something to leave entirely up to the UA, but I'd like it better if the
> at least suggests that they may do.
I've required the value="" to set the initial value.
> I wonder what the fallback mechanism should be though. What should UAs
> that do not/can not provide a color picker do?
type=text fallback seems to work ok for this.
> Could be useful if you'd need to allow the user to choose only from a
> limited list of options, yes. If there already is a standard that
> describes colour palettes, that might be useful. If not, this might be
> too complicated.
If you really want a specific set of colours, use <select>.
On Sat, 14 Jul 2007, Andrew Fedoniouk wrote:
> There are many possible implementations for different purposes.
> Here is one of color selectors we use in HTML:
> I think it is not realistic to define all of them in single
> specification - too many different use cases.
I've made the spec say the control is a color well, leaving the details of
the color picker to the UA.
> I would define some generic extensible mechanism for inputs rather than
> defining particular input type=foo.
See XBL2 for this.
On Mon, 16 Jul 2007, Lachlan Hunt wrote:
> Martin Atkins wrote:
> > Lachlan Hunt wrote:
> > > http://www.haymespaint.com.au/haymes/colourcentre/
> > > http://www.ficml.org/jemimap/style/color/wheel.html
> > > http://wellstyled.com/tools/colorscheme2/
> > These are some rather contrived examples.
> How can you possibly call them contrived, when they are real world
> examples of colour selection applications?
I haven't made type=color suitable for color-specific applications that
have rather specific needs (e.g. picking Pantone colors, or colors in a
specific color space, or whatnot).
On Mon, 16 Jul 2007, Martin Atkins wrote:
> Applications for exploring colour spaces already have a satisfactory
> solution, as in your examples. Since their focus is on colour selection
> they implement a more elaborate UI that fits their purpose exactly.
> Likewise, applications such as Google Calendar implement their own UI
> for exploring the calendar rather than relying on the UI provided by
> <input type="date">
Right. But Google Calendar could use type=color for the color widget
instead of rolling their own as they do now.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg