Color.toWeb & Color.toHexString

[Pavel Safrata]

Hi Richard,

On 10.7.2012 18:27, Richard Bair wrote:
> Hi Pavel,
>
> On Jul 10, 2012, at 7:50 AM, Pavel Safrata wrote:
>
>> Hello,
>> based on Jira issue
>> http://javafx-jira.kenai.com/browse/RT-22400
>> I propose the following new methods to Color class (targeting Lombard):
>>
>>
>> public String toWeb()
>>
>> This method will return the simplest string representation of the color using one of the following notations:
>>
>> #rrggbb
>> rgb(r, g, b)
>> rgba(r, g, b, a)
>>
>> The resulting string, when passed to Color.toWeb(), will produce an eqivalent color.
> I like the idea that color.equals(Color.web(color.toWeb())).
I think this is a must.
>
> How do we determine which format is going to be returned by toWeb? I think it should be consistent (ie: pick one to use all the time). Otherwise it becomes arbitrary and folks cannot easily parse the results or do what they need with it.

We use the simplest possible format. If all the components are integers 
and the color is fully opaque, we can use the classic #rrggbb format. If 
the values need decimal numbers, we need to use rgb(r%, g%, b%). If the 
opacity is non-one, we need rgba(r, g, b, a) in case of integers and 
rgba(r%, g%, b%, a) in case of decimals. The only format that can 
accommodate all possible colors is the last one. We can use it always, 
just to me
Color.ANTIQUEWHITE.toWeb() = "#FAEBD7"
looks more natural than
Color.ANTIQUEWHITE.toWeb() = "rgba(98.039215%,92.15686%,84.31373%,1.0)"
If you use the predefined colors, you can always do with the simple 
format and you don't need to deal with the CSS3 complex formats.
Who's going to parse it? I think that either our Color or some web 
engine. Both can parse all the formats. The result of the simple colors 
would be parseable also by old CSS engines, so it has the advantage of 
backward compatibility for basic colors. Another considerable advantage 
is much better human readability for the simple colors.

I'm not firmly opposed to your suggestion but those are my reasons that 
make me like the varying results better. What do you think?

>
>> public String toHexString()
>>
>> This method will return a string rrggbb without the leading hash. It will ignore opacity and will round the values to the nearest color that can be represented with such string. An example of use is displaying a web-based color value in a color picker.
> Why remove the #? What is the use case for toHexString()?

I did mention the use-case: "displaying a web-based color value in a 
color picker". If it's displayed in an editable field, you usually don't 
want the hash there. Moreover, strictly speaking, a string beginning 
with hash is not really a hex string, so in this case we should use a 
different name (something like toNearestSimpleWebColor).

Thanks,
Pavel

>
> Richard