Your understanding of the spec is incorrect.  The *value* of the color input is a color in 6-digit hex format.  The presentation of a color input should be a standard color-palette picker, similar to what every drawing program uses.

(In reply to comment #1)
> Your understanding of the spec is incorrect.  The *value* of the color input is
> a color in 6-digit hex format.  The presentation of a color input should be a
> standard color-palette picker, similar to what every drawing program uses.

No, I didn't misunderstand. Allowable values are in hex, regardless of device used to set the value. 

And most drawing programs allow you to specify color formatting. And transparency.

Your statement is technically correct, but still shows that you're misunderstanding the basic issue.  The formatting of the @value has no relevance to the user, any more than the precise data structure exposed by a file input does.  The input exposes a widget that allows the user to choose the color, and then serializes that color in some fashion for storage in the DOM.

A browser is free to expose any input method they would like for color inputs.  The color palette is recommended, but if they wish to offer more "advanced" inputs, such as letting the user input a color directly in rgb or hsl or by name, that's perfectly fine too.  All of these are directly convertible into a 6-hexit RGB value without significant dataloss.  The limitations on the field that you reference in your original comment do not exist.

I don't understand what you mean by "most drawing programs allow you to specify color formatting".  My drawing programs expose multiple methods of *entering* a color, yes.  They don't expose anything about color *formatting*, though, as serializing a color is an irrelevant concern.

Maybe you were misled by the temporary incomplete implementation of some of the input types in Webkit browsers?  They did temporarily turn on constraint validation for some input types without also supplying the appropriate input widgets, which caused some confusion similar to what you're expressing about the "usability" of only allowing the user to enter hex colors.  The input was never intended to act like a restricted text input.

(In reply to comment #3)
> Your statement is technically correct, but still shows that you're
> misunderstanding the basic issue.  The formatting of the @value has no
> relevance to the user, any more than the precise data structure exposed by a
> file input does.  The input exposes a widget that allows the user to choose the
> color, and then serializes that color in some fashion for storage in the DOM.
> 
> A browser is free to expose any input method they would like for color inputs. 
> The color palette is recommended, but if they wish to offer more "advanced"
> inputs, such as letting the user input a color directly in rgb or hsl or by
> name, that's perfectly fine too.  All of these are directly convertible into a
> 6-hexit RGB value without significant dataloss.  The limitations on the field
> that you reference in your original comment do not exist.
> 
> I don't understand what you mean by "most drawing programs allow you to specify
> color formatting".  My drawing programs expose multiple methods of *entering* a
> color, yes.  They don't expose anything about color *formatting*, though, as
> serializing a color is an irrelevant concern.
> 
> Maybe you were misled by the temporary incomplete implementation of some of the
> input types in Webkit browsers?  They did temporarily turn on constraint
> validation for some input types without also supplying the appropriate input
> widgets, which caused some confusion similar to what you're expressing about
> the "usability" of only allowing the user to enter hex colors.  The input was
> never intended to act like a restricted text input.

Actually, I believe the Webkit implementation is still in effect? Unless there's another bug where it was removed.

Regardless, following is a description of using one color picker, the YUI 2 Color Picker Control:

http://developer.yahoo.com/yui/colorpicker/#using

Notice how much control a web developer or designer has? And this is just one from the many we can choose from.

Most color pickers provide a great number of UI customizations. Whether to show the hex value, whether to just show colors, how to display the colors, whether to show the RGB values--whether to enable input of a hex or RGB value directly. Alpha transparency support. 

This color picker gives us none of this. None. Zero, zip. You get what the browser companies give you, and that's it. 

So no, it fares poorly, abysmally, compared to what we have had in the last six years since the color picker input type was first proposed.

(In reply to comment #4)
> Actually, I believe the Webkit implementation is still in effect? Unless
> there's another bug where it was removed.

It may still be around in the public builds, but I'm fairly certain it's gone in higher channels, which means it'll disappear as autoupdate proceeds.

> Regardless, following is a description of using one color picker, the YUI 2
> Color Picker Control:
> 
> http://developer.yahoo.com/yui/colorpicker/#using
> 
> Notice how much control a web developer or designer has? And this is just one
> from the many we can choose from.
> 
> Most color pickers provide a great number of UI customizations. Whether to show
> the hex value, whether to just show colors, how to display the colors, whether
> to show the RGB values--whether to enable input of a hex or RGB value directly.
> Alpha transparency support. 
> 
> This color picker gives us none of this. None. Zero, zip. You get what the
> browser companies give you, and that's it. 
> 
> So no, it fares poorly, abysmally, compared to what we have had in the last six
> years since the color picker input type was first proposed.

Color pickers, like date pickers, offer the potential of quite a lot of UI customization.  In practice, date pickers don't need that level of UI customization to be perfectly usable for the vast majority of authors.  I believe color pickers are the same.  As long as the color picking doesn't suck, I'll be more than happy to just use it.

As with date pickers, authors who really do want advanced control over the widget's display can continue to use javascript-based implementations like they do today.  I strongly believe that the fraction who will go to the effort of doing so when they could instead just write <input type=color> in their pages will be minuscule.

(In reply to comment #5)
> (In reply to comment #4)
> > Actually, I believe the Webkit implementation is still in effect? Unless
> > there's another bug where it was removed.
> 
> It may still be around in the public builds, but I'm fairly certain it's gone
> in higher channels, which means it'll disappear as autoupdate proceeds.
> 
> > Regardless, following is a description of using one color picker, the YUI 2
> > Color Picker Control:
> > 
> > http://developer.yahoo.com/yui/colorpicker/#using
> > 
> > Notice how much control a web developer or designer has? And this is just one
> > from the many we can choose from.
> > 
> > Most color pickers provide a great number of UI customizations. Whether to show
> > the hex value, whether to just show colors, how to display the colors, whether
> > to show the RGB values--whether to enable input of a hex or RGB value directly.
> > Alpha transparency support. 
> > 
> > This color picker gives us none of this. None. Zero, zip. You get what the
> > browser companies give you, and that's it. 
> > 
> > So no, it fares poorly, abysmally, compared to what we have had in the last six
> > years since the color picker input type was first proposed.
> 
> Color pickers, like date pickers, offer the potential of quite a lot of UI
> customization.  In practice, date pickers don't need that level of UI
> customization to be perfectly usable for the vast majority of authors.  I
> believe color pickers are the same.  As long as the color picking doesn't suck,
> I'll be more than happy to just use it.
> 
> As with date pickers, authors who really do want advanced control over the
> widget's display can continue to use javascript-based implementations like they
> do today.  I strongly believe that the fraction who will go to the effort of
> doing so when they could instead just write <input type=color> in their pages
> will be minuscule.

No, I don't think so. I don't think people are going to be interested in yanking what they have now, just to incorporate something that is inferior. Remember, we've had this as a packaged JS UI control for some time now. 

Most color picking will be a drop down list of a given set of colors. It's only with the rare graphics app, such as the color picker incorporated into Drupal that needs anything more. And it already has something incorporated. 

When you have applications that already use JS, such as the drawing program you mention, they don't get anything by trying to incorporate a declarative color picker. Especially if the people are also working with canvas or SVG.

We'll have to disagree on this.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see tab's comments

http://www.w3.org/html/wg/tracker/issues/132

http://lists.w3.org/Archives/Public/public-html/2010Dec/0121.html