From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.devel Subject: Re: CSS contrast (#30295) (was Re: Heads-up: Emacs 26.1 RC1) Date: Wed, 21 Mar 2018 13:22:37 +0000 Message-ID: References: <83muz2lfo9.fsf@gnu.org> <837eq5lvyx.fsf@gnu.org> <83y3ilk32z.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007d5e270567ec1785" X-Trace: blaine.gmane.org 1521638553 7821 195.159.176.226 (21 Mar 2018 13:22:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2018 13:22:33 +0000 (UTC) Cc: John Wiegley , Tom Tromey , Emacs Development To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 21 14:22:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eydhE-0001vC-JN for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 14:22:28 +0100 Original-Received: from localhost ([::1]:55009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eydjH-00044E-J0 for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 09:24:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eydi7-0002bz-8u for emacs-devel@gnu.org; Wed, 21 Mar 2018 09:23:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eydi5-0004s0-TJ for emacs-devel@gnu.org; Wed, 21 Mar 2018 09:23:23 -0400 Original-Received: from mail-ot0-x235.google.com ([2607:f8b0:4003:c0f::235]:44429) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eydhs-0004hJ-PW; Wed, 21 Mar 2018 09:23:08 -0400 Original-Received: by mail-ot0-x235.google.com with SMTP id x6-v6so4079108otg.11; Wed, 21 Mar 2018 06:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2DcFc8azHZmlgEKxYF65Fk8HriNeWv+s+qX0P37MPc=; b=NRUcbCY8SuWUHcwkfThPHjSl3nGspx5AaDz6M5sjTyaypyMu/V6BibwW2x2ACgX5yM a4CYDRh/vqEu3R5Q7SJX6xDXyeCScqkXs0MpQ29A0j6jUSp1Ps3kECaIGH25a4h4+AP+ A7Wqkj+/MuT/E2LTRSxEcvl5iCSSMsEXm8zo0cb3Ie2+DN1xwYqrqj//Yf5nep0eYEjD tAyIr4MEDrd69c45XMuX+FnZq4V6kcL6VTX/DC9gP1W38EfKYpY/xd4/C3vJrcB5rDDP K9acihC8z93Mhc6Awc6LC8LkpWW8FPMy8sMDNiChaC7FOvuLQQxU0C1I6HR0phOZGwhp Gt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k2DcFc8azHZmlgEKxYF65Fk8HriNeWv+s+qX0P37MPc=; b=F1N2y9z2BTwcegYGVkS8/CiMqoRAkmjcDhwQgUpFd2Z/IzyACgv2F7I+l8cR1x2RDg TClO8/HdZmCJP/AOgELXx5P2RxxwZKJb6Npl+0SWF5Hhz+QYzJpGBFfv31tvyMux299U yLSeFhpuNBudIdwCmP9pZAOdNVhCX6XN7+ITFlbkLcqG+C6xfEIBKGmbQT0TPAwaUtW/ khBg8aqP7JV9og8zE6WRDo5eF5hkCyIef/haSA9Aw3hSGYqTaDQqXvvYvGd6l0E46ynw DSW52FfH2q5HlaEv/rVDNvvavVBK1CgyU2LiUHpP6dN76JTegqljU7lq8x2tgQImtDWE tKGA== X-Gm-Message-State: AElRT7EQgFo4Qk366YWccJHB/BHVktXnIPlPdDm/a1Zj2FydUxFUcpvg VwudTz4kc1q+4oWiQsJH1afTzRRxO/Dp4T/XiX+PV/jv X-Google-Smtp-Source: AG47ELv9m10NP/IH/bFoaQPI9O8iuOrusNgZbBJbAX1BrLKwi8y3+PBhh2Ghrlxm6cFKqm1ZUDToLmVt6BeY4kOF29Y= X-Received: by 2002:a9d:5706:: with SMTP id p6-v6mr12968565oth.88.1521638587586; Wed, 21 Mar 2018 06:23:07 -0700 (PDT) Original-Received: by 2002:a9d:4c87:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 06:22:37 -0700 (PDT) In-Reply-To: <83y3ilk32z.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c0f::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223888 Archived-At: --0000000000007d5e270567ec1785 Content-Type: text/plain; charset="UTF-8" On 21 March 2018 at 12:47, Eli Zaretskii wrote: > > From: Richard Copley > > Date: Wed, 21 Mar 2018 11:34:47 +0000 > > Cc: John Wiegley , Tom Tromey , > > Emacs Development > > > > Is the current criterion (use white text on backgrounds inside a sphere > of a given radius centred on black, in > > the color-distance metric space) a standard way of doing things? > > We do something very similar in frame-set-background-mode and in > tty-color-approximate. I don't see it. You're talking about this? ((>= (apply '+ (color-values bg-color frame)) ;; Just looking at the screen, colors whose ;; values add up to .6 of the white total ;; still look dark to me. (* (apply '+ (color-values "white" frame)) .6)) That is a luminance comparison against 60%, except that instead of computing luminance in any of the usual ways, it simply adds up the R, G and B components. Also note that color-distance is based on a > metric that we didn't invent. Not sure whether it makes that > "standard". > It's this particular way of using color-distance that we appear to have invented. If we didn't then we took it from somewhere else, and someone (Tom?) should know where. And we didn't invent luminance! > I'm not dismissing these arguments, I'm just saying that it's too late > to raise them for what will become Emacs 26.1. We can make those > changes on master, if people agree with your reasoning, or we could > use the contrast criterion there, or something else. Fair enough. > But for the > release branch, the only change I can think of which will allow you to > get what you want in a safe way is the one I proposed: introduce a > customizable threshold. > I don't believe the concept of a sphere centred on black is a useful one in this context, or that allowing the user to vary its radius makes it any better. Thanks. --0000000000007d5e270567ec1785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 21 March 2018 at 12:47, Eli Zaretskii &l= t;eliz@gnu.org> wrote:
> From:= Richard Copley <= rcopley@gmail.com>
> Date: Wed, 21 Mar 2018 11:34:47 +0000
> Cc: John Wiegley <johnw@gnu.org>, Tom Tromey <tom@tromey.com>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Emacs Development <emacs-devel@gnu.org>
>
> Is the current criterion (use white text on backgrounds i= nside a sphere of a given radius centred on black, in
> the color-distance metric space) a standard way of doing things?

We do something very similar in frame-set-background-mode and in
tty-color-approximate.

I don't see it. You're = talking about this?

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 ((&= gt;=3D (apply '+ (color-values bg-color frame))
=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; Just looking at = the screen, colors whose
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; values add up to .6 of the white total
= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = ;; still look dark to me.
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (* (apply '+ (color-values "white&q= uot; frame)) .6))

That is a luminance comparison against = 60%, except that instead of computing luminance in any of the usual ways, i= t simply adds up the R, G and B components.

Also note= that color-distance is based on a
metric that we didn't invent.=C2=A0 Not sure whether it makes that
"standard".

It&#= 39;s this particular way of using color-distance that we appear to have inv= ented. If we didn't then we took it from somewhere else, and someone (T= om?) should know where.

And we didn't invent luminance!

> I'm not dism= issing these arguments, I'm just saying that it's too late
to raise them for what will become Emacs 26.1.=C2=A0 We can make those
changes on master, if people agree with your reasoning, or we could
use the contrast criterion there, or something else.

<= /div>
Fair enough.
=C2=A0
=C2=A0But for the
release branch, the only change I can think of which will allow you to
get what you want in a safe way is the one I proposed: introduce a
customizable threshold.

I don't believe the concept of a sphere ce= ntred on black is a useful one in this context, or that allowing the user t= o vary its radius makes it any better.

Thanks.

--0000000000007d5e270567ec1785--