- From: Benjamin Joffe <canvasgame@gmail.com>
- Date: Wed, 8 Aug 2007 22:18:13 +0200
I am not so concerned about the location inputs I suggested but colour is a clear must. The recent introduction of a colour picker into one of the major javaScript libraries (YUI) [0] indicates that there is a demand for this sort of input control. [0] http://developer.yahoo.com/yui/colorpicker/ On 7/16/07, Martin Atkins <mart at degeneration.co.uk> wrote: > > Lachlan Hunt wrote: > > Martin Atkins wrote: > >> Lachlan Hunt wrote: > >>> http://www.haymespaint.com.au/haymes/colourcentre/ > >>> http://www.ficml.org/jemimap/style/color/wheel.html > >>> http://wellstyled.com/tools/colorscheme2/ > >> > >> These are some rather contrived examples. > > > > How can you possibly call them contrived, when they are real world > > examples of colour selection applications? > > > >> The first is asking users to select real-world (i.e. paint) colours, > >> while > >> this proposal was for screen colours in RGB format. (At least, that > >> was my understanding based on the reference to six-digit hex encoding.) > > > > I think it indicates a limitation with the proposed solution, and a > > perfect example of why we need to start with *problems* and *use cases* > > instead of solutions. We need to devise a solution that fits the use > > cases, not reject use cases that don't fit the solution. > > > > > Applications for exploring colour spaces already have a satisfactory > solution, as in your examples. Since their focus is on colour selection > they implement a more elaborate UI that fits their purpose exactly. > > Likewise, applications such as Google Calendar implement their own UI > for exploring the calendar rather than relying on the UI provided by > <input type="date"> > > However, applications whose focus is not on dates or colours but which > still need to accept such values as inputs benefit from commodity > controls; the specifics of how these controls are implemented matter > little as long as they produce results in a suitable format for > processing by the application. > > A web search for "DHTML Colour Picker" (US or UK spelling) turns up > hundreds of distinct implementations of an RGB colour picker widget, > which indicates to me that there is a clear need for such a thing. > However, I cannot find any general-purpose DHTML colour widgets for > selecting paint colours that could be classed as reusable components, so > I'm left to assume that this is a very speciality need which needs to be > custom-developed in each case. > > In short, I am not rejecting use cases that don't fit the solution, I'm > rejecting use cases that do not fit the scope of the problem as I see > it. You may percieve the problem differently, of course. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070808/badf8d81/attachment.htm>
Received on Wednesday, 8 August 2007 13:18:13 UTC