[whatwg] Web forms 2, input type suggestions

[Martin Atkins]

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.