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