[whatwg] restricted palette for input type=color
ian at hixie.ch
Wed May 2 15:50:03 PDT 2012
On Mon, 7 Mar 2011, Markus Ernst wrote:
> A content management or blog system for a corporate website allows to
> set font and background colors. The designers define allowed color sets
> the way that the corporate design guidelines are respected, and that the
> text is always readable - e.g. three light color shades for backgrounds,
> and two corporate colors and black for text.
You don't really need a colour picker for that... it's more a <select>
than a colour picker. Or a series of radio buttons. If the presentation is
more the concern, then we should probably rely on Web Components to solve
the problem (styling a <select> with a new presentation, e.g.).
> While searching the list archives, I found a message from Ian Hickson:
> He suggested to use a select element for the purpose of a restricted
> color set.
Good to know I'm consistent. :-D (I wrote the reply to the above paragraph
before reading this paragraph!)
> Here's why I think it would be worth to reconsider this position:
> - A select element would display color names or values instead of
> showing the colors, which does not make it a suitable UI for choosing
That's a presentation issue, though. We should let CSS and/or Web
Components fix that; we shouldn't add new semantics for each desired
> - Restricting the color palette is actually almost as common a task, as
> defining start and end dates of a date picker, and for sure more common
> than defining a step in a date picker. Now we have the benefit of this
> specialized color input element, it is a pity if it lacks customization
The step in the date picker is something that was basically supported just
because we had to define what step="" did anyway since we had it for
I don't disagree that it might make sense to limit the colour palette
(e.g. "only things with a brightness greater than 50%") for type=color.
But that's a different use case, and a different feature, than the one
> - The fact that most CMS do not have restricted color sets so far, does
> not mean there is no demand for it, but rather shows the difficulty of
> customizing tools such as TinyMCE. It is a hassle for CMS implementors
> (who are often not highly skilled JS programmers), if they are expected
> to respect corporate design guidelines.
I don't follow. Right now (before type=color is widely implemented) it's
easier to provide a limited set of colours than all colours. Surely then
we should see more CMSes have restricted colour sets if it's a matter of
> - I assume that restricting a color set in an existing color picker is
> not too hard to implement (of course I have no evidence for this
That's, generally speaking, not a concern.
On Tue, 8 Mar 2011, Jukka K. Korpela wrote:
> 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.
It certainly exists. How common it is, I don't know. It's a subset of
sites with date pickers, which itself is a pretty small subset of sites
with forms, which is a subset of pages.
It's definitely something worth keeping in mind though as we look to
where we might extend this feature. I haven't added it yet, because we're
still not at a point where these form controls are very mature.
If anyone wants this particular feature prioritised, a good way to start
would be documenting existing sites that have date pickers that do this
kind of thing.
On Wed, 9 Mar 2011, Jukka K. Korpela wrote:
> <Select> is generic, like <input type="text">, as opposite to <input
> type="date">, <input type="color"> etc. So an implementation cannot
> implement <select> in a content-aware way, like a date or color picker,
> but it can (and hopefully will, but it is not required to) implement
> e.g. <input type="date"> with associated <datalist> as a date picker
> with some dates highlighted and possibly (when the proposed new
> "exclusive" attribute is used) all other dates grayed out.
This isn't a complete picture. Sure, browsers won't automatically render a
<select> in a manner specific to the data type of the values. But with
some CSS and Web Component definitions, that can be changed. A <select>
with countries could render as a map, a <select> with dates as a custom
calendar, a <select> with colours as a custom colour picker.
The point is that at the HTML level, the <select> element has the right
semantics: pick one from a list. What is is presented as is a separate
concern for a higher level of the stack.
On Wed, 9 Mar 2011, Diogo Resende wrote:
> I was thinking.. what about allowing big time spans, like: from April
> 1st to June 30th? Giving that the date has "-" as date element
> separators we could not use YYYY1-MM1-DD1-YYYY2-MM2-DD2. Couldn't this
> be useful? Even more common might the usecase where a date must be from
> some date onward (or until some date). How is this addressed?
If you just have one time spam, <input type=date> already supports that.
On Wed, 9 Mar 2011, Diogo Resende wrote:
> That is perfect for 1 date scope. What if I have a meeting to schedule
> in a month (eg. March) and (according to other meeting attendees) the
> meeting can only happen from 10-15, 19, 20-28 and 30. Do I have to make
> a data-list with every possible day? What if I would like to set a
> future event that cannot happen on weekends?
That's a pretty complex widget. I don't know that we'd want an HTML
primitive to support this kind of thing; it might be best to just let
authors develop their own for that.
On Thu, 10 Mar 2011, Aryeh Gregor wrote:
> <input type=date pattern=2011-03-(1[0-59]|2[0-8]|30)>
That's pretty crazy, using a string pattern matching tool to do
range-checking on structured numeric data. :-P
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg