[whatwg] restricted palette for input type=color
ian at hixie.ch
Wed Nov 21 19:39:42 PST 2012
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>
What kind of credit card do you have? <select name=cc>...</select>
> Anyway, 220.127.116.11.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
> > > - 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg