[whatwg] restricted palette for input type=color

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: 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017482.html 
> 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 
> colors.

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 
presentation.


> - 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 
> potential.

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 
numbers.

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 
given above.


> - 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 
difficulty.


> - 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 
> assumption).

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">
> </datalist>
> 
> 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.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 2 May 2012 15:50:03 UTC