- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Sep 2010 18:38:56 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10581 --- Comment #3 from Tab Atkins Jr. <jackalmage@gmail.com> 2010-09-08 18:38:56 --- 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 8 September 2010 18:38:58 UTC