GNU bug report logs -
#30295
CSS mode colour highlighting makes text hard to read
Previous Next
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Tue, 30 Jan 2018 16:57:02 UTC
Severity: minor
Done: Simen Heggestøyl <simenheg <at> runbox.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30295 in the body.
You can then email your comments to 30295 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30295
; Package
emacs
.
(Tue, 30 Jan 2018 16:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Richard Copley <rcopley <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 30 Jan 2018 16:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In CSS mode, the value "green" or "#0f0" or "rgba(0,255,0,0.5)" is
displayed with a white foreground and a 100%-green background, which
is difficult to see.
A white foreground is chosen on even lighter colours, for example,
"#5e5" and "#87e087".
See functions css--contrasty-color in textmodes/css-mode.el and
color-distance in src/xfaces.c, and
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25525>, and
<https://www.compuphase.com/cmetric.htm>.
If the color-distance is to be used, the appropriate formula is:
(if (> (color-distance name "black") (color-distance name "white"))
"black" "white")
That formula still maps "green" to "white", but it does at least map
lighter colours such as "#38e038" to "black".
For what it's worth, in my inexpert opinion it makes more sense to
compare the luma against that of mid-grey as Tom originally proposed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30295
; Package
emacs
.
(Thu, 01 Feb 2018 21:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 30295 <at> debbugs.gnu.org (full text, mbox):
> In CSS mode, the value "green" or "#0f0" or "rgba(0,255,0,0.5)" is
> displayed with a white foreground and a 100%-green background, which
> is difficult to see.
>
> A white foreground is chosen on even lighter colours, for example,
> "#5e5" and "#87e087".
>
> See functions css--contrasty-color in textmodes/css-mode.el and
> color-distance in src/xfaces.c, and
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25525>, and
> <https://www.compuphase.com/cmetric.htm>.
>
> If the color-distance is to be used, the appropriate formula is:
>
> (if (> (color-distance name "black") (color-distance name "white"))
> "black" "white")
>
> That formula still maps "green" to "white", but it does at least map
> lighter colours such as "#38e038" to "black".
>
> For what it's worth, in my inexpert opinion it makes more sense to
> compare the luma against that of mid-grey as Tom originally proposed.
Indeed, luma is more suitable than mid-grey, customizing
‘list-colors-sort’ to “luminance” shows that distinguishable colors with
the black foreground start closer to the beginning of the color list.
Or we could use both luma and distance like in ‘shr-color-visible’
with two customizable options:
‘shr-color-visible-luminance-min’ and
‘shr-color-visible-distance-min’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#30295
; Package
emacs
.
(Thu, 01 Feb 2018 23:04:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 30295 <at> debbugs.gnu.org (full text, mbox):
On 1 February 2018 at 21:17, Juri Linkov <juri <at> linkov.net> wrote:
>> If the color-distance is to be used, the appropriate formula is:
>>
>> (if (> (color-distance name "black") (color-distance name "white"))
>> "black" "white")
[...]
>> For what it's worth, in my inexpert opinion it makes more sense to
>> compare the luma against that of mid-grey as Tom originally proposed.
>
> Indeed, luma is more suitable than mid-grey, customizing
> ‘list-colors-sort’ to “luminance” shows that distinguishable colors with
> the black foreground start closer to the beginning of the color list.
I think you and I are in agreement, but to clarify (just in case), the
two options I was talking about were:
1: Choose black if the colour is closer to white than black, in the
color-distance metric (like the Lisp expression I wrote).
2 (better): Choose black if the colour's luma is greater than the luma
of mid-grey, where by mid-grey I meant "#808080", and where I don't
particularly mind what "luma" means.
Eli also mentioned the idea of using the complementary colour (see
#25525) but that can look quite unpleasant due to chromostereopsis,
depending on the surrounding colours. Colour-blind people might also
find it difficult (I'm not sure).
> Or we could use both luma and distance like in ‘shr-color-visible’
> with two customizable options:
> ‘shr-color-visible-luminance-min’ and
> ‘shr-color-visible-distance-min’.
Thanks, a trove of useful functions are in "shr-color.el" and
"color.el". Using color-rgb-to-hsl and extracting the luminance would
make for readable code for option 2.
Reply sent
to
Simen Heggestøyl <simenheg <at> runbox.com>
:
You have taken responsibility.
(Mon, 15 Jun 2020 20:14:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Richard Copley <rcopley <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 15 Jun 2020 20:14:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 30295-done <at> debbugs.gnu.org (full text, mbox):
The problem with these colors should now be fixed with Mattias' recent
changes in commit 68ae6faa7f1b4c348740667f98fbf1d1ce5a7979 on
master. Closing.
-- Simen
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 14 Jul 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.