lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New function css-color (accompanying x11-color) (issue 570690043 by


From: Urs Liska
Subject: Re: New function css-color (accompanying x11-color) (issue 570690043 by address@hidden)
Date: Tue, 4 Jun 2019 10:53:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Am 04.06.19 um 00:13 schrieb address@hidden:

https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm
File scm/color.scm (right):

https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678
scm/color.scm:678: (define css-color-list
Is there anything new in this list or are all entries always alias?

I checked and saw that the following CSS colors are *not* in the X11 list:

CSS Color names not defined in X11 colors:

aqua

crimson

fuchsia

indigo

lime

olive

rebeccapurple

silver

teal

*Most* of the others are basically defined identical, with the differences being rounding errors. However, there are a number of real differences, AFAICS it's the discrepancies described in https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme

...
Ofcourse this leads to identical definitions for css-color and x11-color
and x11-color would return a color even for p.e. Darkblue (wrongly
cased).
I can't imagine a problem, though

I'm not totally sure about the best way to proceed here. I agree that it's not a terrific idea to duplicate all those color definitions.

However, especially given the number of differences there should be explicit access methods for both color models. What might be a reasonable approach is:

 * Have one long list of shared color definitions, basically the
   existing one plus entries for the list above (I assume we can ignore
   the rounding errors issue)
 * For each color model have a list of *names* and a list (doesn't have
   to be a *separate* list) of definitions for colors that don't match
   the shared-colors list. For X11 this would *only* be the names list.
   (The determination of colors that need special definitions should be
   done once during development, not at runtime.)
 * When asking for a color it is first checked if it is in the color
   model's extension list, then in the shared list (and then fall back
   to black)
 * Given that the X11 colors Wikipedia entry states that the
   capitalization of X11 color names isn't handled consistently I
   suggest that we totally ignore casing (keep the CamelCase names in
   the manual but state that colors can be requested case insensitively)

What do you think?
Urs


reply via email to

[Prev in Thread] Current Thread [Next in Thread]