[whatwg] HTML5 Input (Color)

[Tab Atkins Jr.]

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>
> escreveu:
>>
>> 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
>> English.
>>
>> 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
>> language-independent.
>
> "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".
http://en.wikipedia.org/wiki/String_(computer_science)


>> (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
> list.
> 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.

~TJ