W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Please reconsider: Set restricted palette for input type=color

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Tue, 8 Mar 2011 13:26:56 +0200
Message-ID: <5CFD5F04A8944D5596D65E5FAFEDD2F7@JukanPC>
Markus Ernst wrote:

> Searching for implementations of input type=color, I found that Opera
> actually implemented the color picker quite similar to my suggestion.

It's a rather nice implementation, and your comments made me test it a bit 
more, and it indeed makes use of a <datalist> element if one is associated 
with the <input type=color> element. Quite nice - it seems to replace the 
default palette of basic colors.

I am just mildly disappointed at the lack of color names there, as I 
expected that using, say,

<input type="color" id="favcolor" name="favcolor"
   value="#ff0000" list="colorlist">
 <datalist id="colorlist">
    <option value="#ff0000" label="red">
    <option value="#00ff00" label="green">
    <option value="#000000" label="black">

would make the user inteface show the names "red", "green", and "black" for 
the colors, at least on mouseover, but it doesn't. I'm not saying that the 
implementation is nonconforming; just that it would be better if it somehow 
used the label attributes as labels for the colors, instead of just showing 
colored spots and color codes. (It's really an accessibility issue too. If I 
were colorblind and wanted to buy a car in a web shop that prompts for my 
color preference, I should be able to select a color by name, instead of 
being forced to decipher some #... codes.)

> I personnally would like a possibility to hide the "Other..." button,
> but this is not really a need.

Well it would be a real need in the use case I mentioned, or in general a 
context where a color choice is to be made between a limited set of colors 
as prescribed by the availability of some product or item in some colors 

I guess this would then have to be an attribute of datalist, making it 
possible to restrict the set of available choices whenever a datalist is 
used. How about "exclusive"? I would expect this to be reasonably easy to 
implement and potentially useful for other <input> types, too.

For example, consider a date picker. Quite often, whether trying to make 
dates or selling flights, there is a known set of (non-consecutive) days 
that are possible, so we would like to write, say,

<input type="date" id="date" name="date"
   value="2011-04-01" list="datelist">
 <datalist id="datelist">
    <option value="2011-04-01" label="April 1st">
    <option value="2011-04-08" label="April 8th">
    <option value="2011-04-09" label="April 9th">

This is currently conforming, though no browser seems to make use of the 
datalist. A good implementation would open up a calendar for April, with 
only days 1, 8, 9 selectable and day 1 highlighted. Many existing 
applications use such interfaces, so there is apparent need for them.

I'm not suggesting that such an implementation be made the norm (though it 
might be descriptively mentioned), but if the "exclusive" attribute (under 
some name) is added, then I guess it should affect the normative part. That 
is, user agents should be required to verify that the value is one of those 
listed. Technically the restriction could be implemented in different ways, 
but a good-quality implementation would prevent the choice of a non-allowed 
value at any phase.

> Is it possible to spec Opera's behaviour as a standard for color
> picking UIs?

Hopefully not... We should avoid making specific implementations the norm, 
though something like Opera's behavior, with some enhancements, might the 
_described_ as suggested or intended typical behavior. An alternative 
approach would show the basic color palette (either the default one or a 
<datalist>-generated one), plus a "More colors" button, as visible in the 
initial state, making it easier to see the options and make a quick choice.

Yucca, http://www.cs.tut.fi/~jkorpela/ 
Received on Tuesday, 8 March 2011 03:26:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC