- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 22 Nov 2012 03:39:42 +0000 (UTC)
- To: Markus Ernst <derernst@gmx.ch>
- Cc: whatwg@lists.whatwg.org
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 22 November 2012 03:58:55 UTC