[whatwg] HTML5 Input (Color)
Tab Atkins Jr.
jackalmage at gmail.com
Wed Jul 28 22:07:36 PDT 2010
On Wed, Jul 28, 2010 at 9:57 PM, Leonardo Dutra <psy.leodutra at gmail.com> wrote:
> Em 28 de julho de 2010 18:05, Tab Atkins Jr. <jackalmage at gmail.com>
>> 2010/7/28 Leo Dutra ™ <leodutra.br at gmail.com>:
>> > Hello, everyone.
>> > I were asking myself about HTML5 input with type "color". I'm a
>> > brazillian
>> > developer and I see a huge problem with the new input type. The problem
>> > is
>> > that RGB color names are expected to be written in English. This is not
>> > a
>> > good, or even, usability.
>> There is no official list of localizations of the standard sets of
>> colors. It kind of sucks for people for whom English isn't their
>> first language, but nearly all programming languages are based on
>> Further, once you start giving aliases for some languages, it becomes
>> hard to justify not giving aliases in *every* language. This isn't
>> very sustainable.
> Yes, nearly all programming langs were written and based on English. But
> this is not a development tool, IDE or language... it's the presentation to
> the non-dev user, and it should be easy and independant of language. Don't
> stuck the usability of the World Wide Web in some few countries that has
> English speaking users, or it'll not take advance.
<input type=color> isn't supposed to be something you type colors into
in the first place. It's supposed to be a color-picker in the
traditional sense. Also, color names (the ones you're complaining
about) aren't supposed to be valid values for <input type=color>
anyway. Webkit is violating the spec right now - the only valid
values should be 6-digit hex colors, of the form #rrggbb.
>> > I'd like input type="color" to work for any
>> > language without "porting acrobatics". So I have a new idea.
>> > What about a color picker, and no more langs? ARGB or RGBA (with option
>> > to
>> > restrict to RGB, maybe other restriction patterns). It's independent of
>> > language, easy to implement and much more usable. Social themes, HTML5
>> > slide
>> > sites, RIAs, and all. Imagine the power of picking any color natively
>> > and
>> > send a 0xff00ff00ff to the server.
>> > It's still draft, and time to don't twist the web again.
>> <input type=color> is *supposed* to expose a color picker. That was
>> its entire point, actually. Webkit-based browsers don't do it right
>> now, and just expose the validation part, where it requires a valid
>> color. Just wait a bit for the browsers to finish up their forms
>> support, and you'll see a proper color picker there, completely
> "The input element represents a color well control, for setting the
> element's value to a string representing a simple color." - HTML5 Draft
> What does "String" means?
"string" is a common computer science term meaning "a sequence of characters".
>> (Also, btw, <input type=color> will only allow selecting RGB colors.
>> If you want the A, you have to handle it yourself, perhaps with an
>> <input type=range>.)
> I think implementing a <input type="color" value="0xff00ff00ff" /> or <input
> type="color" value="255,255,255,1" /> or similar it's better than a internal
> The Universe has infinite colors. Human can see from red to violet. And now,
> with rgb names, less. RGB names it's a bad way of picking colors.
Whether it's a good way of picking colors or not is irrelevant. It's
an *incorrect* way for <input type=color> to work.
> I say we MUST have a color picker and a date picker (calendar). It's not
> hard and carries much more freedom for development and usability.
I agree. Luckily, so does the HTML5 spec.
More information about the whatwg