Re: [css4-color] HLC <= CIE-La*b*

On Mon, Nov 21, 2011 at 6:53 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Nov 21, 2011 at 6:06 AM, Kevin Bortis <kevin@bortis.ch> wrote:
>> On Tue, Nov 15, 2011 at 3:56 PM, Christoph Päper
>> <christoph.paeper@crissov.de> wrote:
>>>  hlc(<angle>, <percentage>, <percentage>)
>>>
>>>  hlc(240deg, 80%, 15%)
>>>  hlc(0.667turn, 0.8, 0.15)
>>>  hlc(267grad, 204, 38) …
>>
>> Degrees are the only practical solution here. I don't know anyone who
>> is using turns for color angles. The only other solution would be rad,
>> but this is not practical because PI is a never ending floating point
>> number.
>
> In practice, people use degrees, sure.  That doesn't mean that it's a
> good idea to force people to use degrees, and also to hide the fact
> that you're using degrees by using a unitless number instead.
>
> Just allowing <angle> is simple and easy, and makes it obvious what the unit is.

Your right. Nevertheless people are used to using the degree schema,
because computer software like Photoshop are using it. Also the
formulas to convert between color spaces are based on the scheme
degree, value, value. See sample formulas on
http://www.easyrgb.com/index.php?X=MATH

>
>
>> I also don't like the percentage value. The reason is, that someone
>> has to define the 100%. At the moment, the limit on lightness is
>> around 92, but could be improved in the next years. I think that
>> percentage values are great for color correction command like "darken
>> this color 20%", but are not very useful in color definition. The same
>> problem would be at the chroma value, there is theoretically no limit
>> in this number.
>
> The <percentage> types doesn't imply a range from 0% to 100%.
>
> Again, hiding the unit behind a unitless number is an anti-pattern.
> If it's a percentage of some maximum value, it should be a percentage
> (even if the maximum value isn't obtainable).  Percentages are also
> appropriate if there is merely a useful reference value that an author
> would want to use a fraction of - gradients use percentages in this
> manner, where it's a fraction of the length of the gradient-line, and
> percentages less than 0% and greater than 100% are perfectly fine.
>
> I haven't yet learned enough of hlc to know if either of these apply,
> but unitless values in general make me cringe, especially given the
> history of "unitless" numbers in colors.
>
>
>>>> To extend the color pallete from the current sRGB color space. A new CIE-L*C*h color pallette should be created
>>>
>>> Maybe, but a user-friendly verbose systematic one, not reusing the stupid X11 names and values.
>>>
>>>> em { color: rgb(aliceblue) }
>
> I agree with the desire for a new color palette that's not based on
> the idiotic X11 scheme.  This idea has history stretching back a
> decade, to when the 'color' property was first being debated in CSS.
> I support reopening those discussions and coming up with a sane color
> palette designed around base colors and optional keywords like "light"
> or "very dark", etc.  I'm neutral as to whether we define this in
> terms of hlc or some other color scheme, because I don't know enough
> about the merits, but having perceptually even palette would be nice.
>

Yes, that's for sure. WTF is aliceblue :)

Creating a color palette with CIE-HLC is very easy, because the color
space is evenly distributed around the human eyes color reception.
Take a color every 5 or 10 degrees and evenly step down the chroma and
lightness value. This would give 150 to 1500 evenly distributed
colors. Although something like that would also be possible with the
hls system in the sRGB space.

>
>>>> em { color: aliceblue 1 }    /* aliceblue = #F0F8FF, alpha 1 */
>>>
>>> That’s unnecessary and not backwards compatible.
>>
>> Most browsers are ignoring the "1". The inclusion of rgb() and rgba()
>> in the current CSS spec is a mistake in my eyes. First you define a
>> color and then tell the browser to add transparency to it. Defining
>> two function for every possible color definition is not a very good
>> solution ( rgb(), rgba(), hsl(), hsla()....).
>
> Browsers don't "ignore the 1" - they drop the declaration entirely,
> because it's currently a syntax error.
>
> Using a second function ending in an "a" is established practice and
> seems okay to me.  It doesn't seem to be a a huge win to just pull the
> alpha out of the function and put it next to the color instead, and
> there are compat problems, as I explain below.
>
>> Why should it be impossible to add the possibility for such color
>> definitions as: { color: aliceblue 0.5 } in the level 4 color module?
>
> It's not impossible, but I already know of one place where it's
> ambiguous - <color-stop> definitions in gradients are defined as
> "<color> && [<length> | <percentage>]?".  If <color> is changed to be
> an opaque color + a number, then the color-stop "red 0" is ambiguous -
> is it fully-transparent red with an auto location, or is it
> fully-opaque red located at 0?  If <color> also allows percentages,
> then any position specified in percentages is ambiguous.
>
> In general, it's best for core value types to be single tokens for this reason.
>
> ~TJ
>

Received on Monday, 21 November 2011 19:48:05 UTC