Mastodon: Add light theme to web UI

[marrus-sh]

Right now Mastodon displays using a dark theme, which understandably a lot of people like (and it does a lot to visually distinguish Mastodon from, say, Twitter). However, it would be nice if there was a profile setting for both light and high-contrast display modes, configurable in user preferences. The rationale for these are as follows:

• light: Emoji, as well as some images (does Mastodon support image transparency?), are designed for rendering on a white background. Emoji like those in the following image often do not feature outlines and can be difficult to see on Mastodon currently. This may not bother some users, but this presents a readability concern for those who frequently make use of such emoji.

  

  (The final four emoji were displayed as text despite being followed by U+FE0F in my input… might this be a separate issue? I haven't tested though and it's possible there was something wrong on my end.)

• high-contrast: See Issue #126. This can be the same as light if light meets contrast requirements; on the other hand, having both light and dark high-contrast modes might be preferable.

There are other potential solutions for these issues (adding a white text-shadow on hard-to-read emoji and improving contrast on the main website skin, perhaps), but I know some people are partial to the current look of the site and separate display modes seems like the best way to keep everyone happy.

[marrus-sh]

It should be noted that EmojiOne offers text renderings (Project B&W) for their emoji as well—I don't know how easy this is to access, but it's possible that setting $client->imageType to svg_bw could fix the emoji display problem by letting emoji inherit their color from the text. Of course, I'm sure many users prefer their emoji in colour so this would likely need to be a toggle (or something that only happens for problematic emoji) at least.

Note: This might not be as easy as it seems, as you would need the SVGs to inherit their fill from currentColor. This means that they need to be inserted as <svg> (not <img>) elements, something I'm not sure EmojiOne supports, and CSS like the following must be provided:

    svg.emoji-one {
        color: inherit;
        fill: currentColor;
    }

SVGs included in <img> elements do not, as far as I'm aware, have any means of accessing the color of the surrounding context, and so these emoji would appear as black—the opposite of what is desired. An alternative approach would be to use the black-and-white SVGs (or, in this case, PNGs) to apply a mask to a white background, but I feel like browser support for anything like that would be very iffy. Finally, it might be possible to somehow add an XML stylesheet to the SVGs server-side, which would allow them to be used in <img> elements as normal.

In sum, I think using black-and-white SVGs is a less robust solution to the emoji readability problem, but it might be preferable if maintaining a single sitewide theme for all users is a priority.

[swaldie]

Referencing #126 here since this encompasses the desire for a high contrast view of Mastodon.

[duckinator]

Just adding a note here that that the WCAG 2.0 guidelines for use of color (1.4.1) and contrast (1.4.3) offer a useful way to quantify how good of a job you're doing of making things easily distinguishable. Copy/pasted here for convenience:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

http://leaverou.github.io/contrast-ratio/ is my preferred tool for checking contrast, since it allows you to interactively tweak it and see the results.

[maieul]

I agree: it is very hard to use mastodon, because of the contrast…

[wavebeem]

I think it would be best to just look at all the contrast issues from a11y and fix them.

https://chrome.google.com/webstore/detail/tota11y-plugin-from-khan/oedofneiplgibimfkccchnimiadcmhpe?hl=en

+:100: on a light theme though for sure. I have a hard time reading Mastodon at work where we have extremely bright office lights.

[ashkitten]

I've been working on this issue myself and came up with a series of changes I think are very nice. They provide a lot more contrast without sacrificing much (any?) design quality. Here's the before/after pics:

Code changes are over at https://github.com/TootCat/mastodon/tree/ui-tweaks

[jpdevries]

In https://github.com/tootsuite/mastodon/pull/1587 I've added CSS Variables support for our Sass color variables. I think this is a big step towards making the process of theming itself more accessible (no knowledge of CSS selectors needed), as well as support accessible themes that respond to things like High Contrast Media Queries.

[wavebeem]

Anybody good at server side feel like they could add a settings dropdown for a theme selector? Working on a light theme is top priority for me, and I'd love to take a crack at the CSS for that, but I don't really know how to get started on the backend reqs here.

[Cassolotl]

Another internet friend today is wondering about joining Mastodon and asked their followers if Mastodon had a dark-on-light theme, because light-on-dark messes with their eyes. They're not visually impaired as far as I know - they're a calligrapher by trade. So I had to tell them no, and refer them to this year-old feature request and the only dark-on-light instance I know (framapiaf). I'm gonna be surprised if they stick around, though. :S

[skiant]

Heya!

I'm currently working on a Light theme, I've tooted about it over there: https://icosahedron.website/@Skiant/98971068973408187

The progress is quite slow at the moment because I don't have much free time but I'll make sure to publish it as soon as I get it in an acceptable state.

[skiant]

Howdy again. After a few fixes to the most obvious broken things, I've got a very rough draft of the theme ready to be tested. If you want to try it out, ask your instance admin to set it up : https://github.com/skiant/mastodon-light-theme

⚠️
I really didn't had the time to do a proper round of testing yet so I expect a lot of things to be broken at the moment. Please report any issue you might have on my repo and I'll do my best to have them fixed in a timely manner.

[moshpirit]

There's a small problem with the light theme: the mastodon down the drawer has a white background, it should be transparent: at least on mastodon.social

[rugk]

Is it planned to get this light theme support i9nto Mastodon? I hope yes, because otherwise it is very bad, not only because it has to be supported by instance admin, but also because it has to be maintained separately and so on…

So please get it into Mastodon straight now…

[trwnh]

The way I see this, right now server-side themes require admins to install them. If a user wants to use a certain theme, they would either have to convince their admin to add a .scss file to the available styles (like https://github.com/skiant/mastodon-light-theme mentioned above), or they would have to inject custom CSS with something like Stylish or Stylus (like, shameless plug, https://github.com/trwnh/mastodon-flat-css does).

The limitations of both of these methods are that they fundamentally require users to depend on someone else to create the theme. This may be a bit ambitious or forward-thinking, but why not expose the variable colors so that users can enter a custom RGB/hexcode (like I added for https://userstyles.org/styles/153362/mfc-mastodon-flat-css under "customize settings")? Perhaps under an "Appearance" tab in settings/preferences.