[whatwg] restricted palette for input type=color

[Ian Hickson]

On Thu, 3 May 2012, Markus Ernst wrote:
> Am 03.05.2012 00:50 schrieb Ian Hickson:
> > 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.).
> 
> It is actually an input field that requires a valid color to be entered; 
> whether it is presented as a color picker or a select box may be up to 
> the UA. I don't see any consistency in having to use different HTML 
> elements whether the selection of colors is defined by the UA (e.g. 
> showing a picker with all colors of the web palette) or by the author.

The difference is the same as the difference between:

   What kind of credit card do you have? <input type=text name=cc>

...and:

   What kind of credit card do you have? <select name=cc>...</select>


> Anyway, 4.10.7.1.15 of the spec states in the bookkeeping details that 
> the @list content and IDL attributes apply to input type=color - if I 
> understand this correctly, it addresses my proposal.

That provides a list of suggestions but doesn't restrict the input to only 
those values.


> > > - 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.
> 
> The CMS I know are shipped with TinyMCE or KHTML or whatever rich text 
> editors. They usually provide a color picker with a predefined set of 
> colors (iirc it is mostly the web palette) by default, which is 
> non-trivial to override or customize; IMHO this is the reason why 
> customized color pickers are not widely used. There are definitely use 
> cases for them.

Ah, fair enough.

Anyway, I don't disagree that there's a use case. It's already handled, 
using <select>. The thing that isn't handled is making it look more like a 
colour picker, and that's to be handled by Web Components.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'