From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Protesilaos Stavrou Newsgroups: gmane.emacs.devel Subject: Re: Major changes to the Modus themes (modus-operandi, modus-vivendi) Date: Sat, 06 Mar 2021 19:23:27 +0200 Message-ID: <87czwcfb74.fsf@protesilaos.com> References: <8735x8ha3e.fsf@protesilaos.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15768"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 06 18:24:37 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lIafN-0003yZ-Au for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 18:24:37 +0100 Original-Received: from localhost ([::1]:40166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIafM-0001ed-D2 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Mar 2021 12:24:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIaeN-0000mS-9k for emacs-devel@gnu.org; Sat, 06 Mar 2021 12:23:35 -0500 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:50825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIaeK-0006JN-OT for emacs-devel@gnu.org; Sat, 06 Mar 2021 12:23:35 -0500 X-Originating-IP: 94.46.225.161 Original-Received: from kronos (unknown [94.46.225.161]) (Authenticated sender: public@protesilaos.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 5A7941BF204; Sat, 6 Mar 2021 17:23:28 +0000 (UTC) In-Reply-To: (Stefan Kangas's message of "Sat, 6 Mar 2021 10:18:32 -0600") Received-SPF: none client-ip=217.70.183.201; envelope-from=info@protesilaos.com; helo=relay8-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266087 Archived-At: On 2021-03-06, 10:18 -0600, Stefan Kangas wrote: > Protesilaos Stavrou writes: > >> A few months ago the themes 'modus-operandi' and 'modus-vivendi' became >> part of Emacs. These "Modus themes" are designed to meet the highest >> accessibility standard for legibility (WCAG AAA), which is quantified as >> a minimum 7:1 rate of contrast in relative luminance between any given >> combination of background and foreground colours. In short: every piece >> of text we support should be readable. > > Could we use these principles to improve the default Emacs look? > I'm not necessarily saying that we should overhaul all faces to look > like the modus themes, but perhaps there are some glaring usability > issues we could fix. We could, though I am not sure we should: there probably are a lot of users who are content with the current styles. Perhaps though there are some isolated cases that we could tweak color values in a spirit of not "breaking" things. New faces are always easier in that regard. What I think would be more impactful in the long run is to incorporate this principle for the :distant-foreground face property (perhaps with a concomitant option to set a contrast ratio target, say, 7:1). Now it relies on 'color-distance' which does not guard against certain legibility issues, though it still has its uses. Of course this is easier for me to write---I cannot actually implement it, especially if it involves C. > BTW, what about the relative luminance difference between adjacent > colours? Is this something covered by the WCAG AAA, or an aspect you > have otherwise looked into? Short answer: no, proximity is not accounted for. So a green piece of text and a red one presented next to each other will still be checked relative to their respective background and not as green:red. Long answer: + To achieve a constant contrast against any given background means that all foreground colors are fairly close to each other in terms of their lumaninance. This is by virtue of them standing at about the same distance away from the background they are compared with. We can test this statement with shades of red and green against white: (modus-themes-contrast "#b60000" "#fff") ;; 7.02 (modus-themes-contrast "#006800" "#fff") ;; 7.04 (modus-themes-contrast "#b60000" "#006800") ;; 1.002 + To design for contrast in luminance that accounts for proximity means that we must make compromises on the extent of the color palette. Let us lower our target from 7:1 which is the AAA standard to 4.5:1, so AA. We have still created the same scenario as above: (modus-themes-contrast "#ee0000" "#fff") ;; 4.53 (modus-themes-contrast "#008a00" "#fff") ;; 4.53 (modus-themes-contrast "#ee0000" "#008a00") ;; 1.00000 + To push the contrast between two designated foreground colors well above 1:1 we must be prepared to render text that is virtually unreadable, ceteris paribus. Check, for example, how pure yellow and a shade red contrast well with each other and then notice how the yellow compares to the white background: (modus-themes-contrast "#ad0000" "#ffff00") ;; 7.04 (modus-themes-contrast "#ffff00" "#fff") ;; 1.07 + Assuming we find some subset of colors that can (i) be fairly legible, even at a lower target than 7:1, and (ii) maintain a constant rate of difference in luminance between all possible combinations, we still have to face practical problems: - Suppose that we have an appropriate blue and a yellow. We want to colorise Org's TODO keywords. We use yellow for the keyword and blue for the heading, or vice versa. Do we also have an appropriate green for the DONE state that is equally good against yellow and blue? (I think that is not possible) And what about varying levels of headings? Should they all be blue or whatever? This means that we will likely put our selves in scenaria where there are too many constraints for us to deliver something usable. I am not ruling out the possibility that a design along those lines is possible. Though do not expect it to be easy and do not assume that relative luminance is the right criterion---especially when you as a designer do not control every single aspect of those interfaces (or rather every possible combination of the relevant faces). Those granted, what I do is to apply colors with contrasting hues next to each other. This is not about relative luminance, just hueness. So something that has more red in it next to something that is more blue. Such a task is not exact science and I am willing to address any shortcomings (it is why I posit that design of this sort stands at the intersection of art and science). > I know I reported a bug (that you promptly fixed) where the difference > was too small for comfort in one case. Admittedly this is the only > problem with the modus themes I've seen so far. And I am prepared to fix other such cases, notwithstanding those that have been reviewed over the last few months. There was another case with diffs, which typically assign removed and added states to variants of red and green respectively. While this is expected, those combinations are not suitable for red-green color deficiency. So I provided the option for deuteranopia in the 'modus-themes-diffs' variable. Report with screenshots here: . >> The version that was in Emacs until recently was 0.13.0. In trunk we >> now provide the latest release: 1.2.3. > > Thanks! Looking forward to start using this. You are welcome! -- Protesilaos Stavrou protesilaos.com