[whatwg] Web forms 2, input type suggestions

[Benjamin Joffe]

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-0001.htm>