Re: [whatwg] Please reconsider: Set restricted palette for input type=color
On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela wrote: 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, 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. Agreed that we should fix this, but note that is for additional or pre-suggested options. The idea is that the user still has choice so the other days should be selectable too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Please reconsider: Set restricted palette for input type=color
Markus Ernst wrote: Searching for implementations of input type=color, I found that Opera actually implemented the color picker quite similar to my suggestion. It's a rather nice implementation, and your comments made me test it a bit more, and it indeed makes use of a element if one is associated with the element. Quite nice - it seems to replace the default palette of basic colors. I am just mildly disappointed at the lack of color names there, as I expected that using, say, would make the user inteface show the names "red", "green", and "black" for the colors, at least on mouseover, but it doesn't. I'm not saying that the implementation is nonconforming; just that it would be better if it somehow used the label attributes as labels for the colors, instead of just showing colored spots and color codes. (It's really an accessibility issue too. If I were colorblind and wanted to buy a car in a web shop that prompts for my color preference, I should be able to select a color by name, instead of being forced to decipher some #... codes.) I personnally would like a possibility to hide the "Other..." button, but this is not really a need. Well it would be a real need in the use case I mentioned, or in general a context where a color choice is to be made between a limited set of colors as prescribed by the availability of some product or item in some colors only. 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 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, 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. I'm not suggesting that such an implementation be made the norm (though it might be descriptively mentioned), but if the "exclusive" attribute (under some name) is added, then I guess it should affect the normative part. That is, user agents should be required to verify that the value is one of those listed. Technically the restriction could be implemented in different ways, but a good-quality implementation would prevent the choice of a non-allowed value at any phase. Is it possible to spec Opera's behaviour as a standard for color picking UIs? Hopefully not... We should avoid making specific implementations the norm, though something like Opera's behavior, with some enhancements, might the _described_ as suggested or intended typical behavior. An alternative approach would show the basic color palette (either the default one or a -generated one), plus a "More colors" button, as visible in the initial state, making it easier to see the options and make a quick choice. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Please reconsider: Set restricted palette for input type=color
Am 07.03.2011 18:27 schrieb Markus Ernst: Reading 4.10.7.1.15 on the "Color" state of the input element, I miss a possibility how to define a set of allowed colors. For other states of the input element there are such possibilities, such as setting min, max and step attributes for input type=date. As UAs are encouraged to provide a user interface, such as a color picker, there should be a way to define a limited set of colors to be included in the picker. Use case: 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. Possible solution: Slightly strengthen the impact of the list attribute for this input type. If there is a suggestion source element with one or more valid colors, color pickers are required to only display the colors specified there. Searching for implementations of input type=color, I found that Opera actually implemented the color picker quite similar to my suggestion. If there is a suggestion source element, Opera displays a color palette with the colors listed there, and an "Other..." button that leads to the detailled color picker. I personnally would like a possibility to hide the "Other..." button, but this is not really a need. Opera's behaviour makes it possible to provide a consistent validation message, saying something like: "Please choose one of the suggested colors. Sorry, other colors are not allowed here." Is it possible to spec Opera's behaviour as a standard for color picking UIs?
[whatwg] Please reconsider: Set restricted palette for input type=color
Reading 4.10.7.1.15 on the "Color" state of the input element, I miss a possibility how to define a set of allowed colors. For other states of the input element there are such possibilities, such as setting min, max and step attributes for input type=date. As UAs are encouraged to provide a user interface, such as a color picker, there should be a way to define a limited set of colors to be included in the picker. Use case: 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. Possible solution: Slightly strengthen the impact of the list attribute for this input type. If there is a suggestion source element with one or more valid colors, color pickers are required to only display the colors specified there. Rationale: 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. 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. - 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 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 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).
