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. 

<br><br>[0] <a href="http://developer.yahoo.com/yui/colorpicker/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://developer.yahoo.com/yui/colorpicker/</a><br><br><div><span class="gmail_quote">

On 7/16/07, <b class="gmail_sendername">Martin Atkins</b> <<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">

Lachlan Hunt wrote:<br>> Martin Atkins wrote:<br>>> Lachlan Hunt wrote:<br>>>> <a href="http://www.haymespaint.com.au/haymes/colourcentre/">http://www.haymespaint.com.au/haymes/colourcentre/</a><br>>>> 

<a href="http://www.ficml.org/jemimap/style/color/wheel.html">http://www.ficml.org/jemimap/style/color/wheel.html</a><br>>>> <a href="http://wellstyled.com/tools/colorscheme2/">http://wellstyled.com/tools/colorscheme2/

</a><br>>><br>>> These are some rather contrived examples.<br>><br>> How can you possibly call them contrived, when they are real world<br>> examples of colour selection applications?<br>><br>>> The first is asking users to select real-world (

i.e. paint) colours,<br>>> while<br>>> this proposal was for screen colours in RGB format. (At least, that<br>>> was my understanding based on the reference to six-digit hex encoding.)<br>><br>> 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.

<br><br>Likewise, applications such as Google Calendar implement their own UI<br>for exploring the calendar rather than relying on the UI provided by<br><input type="date"><br><br>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.

<br>However, I cannot find any general-purpose DHTML colour widgets for<br>selecting paint colours that could be classed as reusable components, so<br>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.

<br><br></blockquote></div><br>