flowchartsman / clarion Goto Github PK

The terminal has only received tentative treatment, and the colors there are still based off of the base theme (WHITE). The terminal is the one place where the lack of color might prove too heavy of a lift, so we may need to consider allowing colors there or providing a less stringent theme variation that allows for it, since many developers are likely to keep a terminal open at all times

Bold strings are fine in Go and other languages, because they provide a good landmark for when things are happening, but they are an absolute chonky mess in JSON. Whether it's a more specific textmate rule or one using semantic highlighting, this needs to be fixed.

Could call out specific locations to take shots from to demonstrate theme features.

Currently these are broken with semantic highlighting: dotnet/vscode-csharp#3864

Several theme colors require alpha to work properly so that they don't obscure content. Others might be better served by background variations, such as currently-highlighted line.

Need to reconsider the ∆E for these and/or eliminate dark variants entirely, using only 8 colors.

By conforming to WCAG-AA, the conceptual colors are readable against theme backgrounds, but this might not be strictly necessary, since many of the places they might appear will be in decorations or badges, and these should stand out more from the black foreground color. It might be a good idea to have the concept colors represent the base color and then derive a WCAG-compliant readable version.

EOT

The CIELAB lightness translation to generate background/foreground color variants feels a little hackish and arbitrary. Foreground variants, especially, are kind of useless
Consider:

• lightness-weighed CIEDE2000
• translation through HSV or CIE-LCh°
• something even better?

Please weigh in if this is in your wheelhouse

I would like to make this issue a discussion for the possibility of a dark background / light text theme and whether it is possible at all according to the guiding principles in this project.

I am curious if it conflicts with any of the principles, or if there may be good scientific reason to avoid a dark theme, or if you have any input in general on this topic since I have read conflicting non-scientific opinions on this topic.

Anecdotally, in my experience dark themes seem to have a positive effect on eye strain for long viewing periods with emissive and transmissive displays (dependent on ambient lighting), and on reflective or transflective displays it appears to have a negative effect.

Additionally light text on a dark background seems to make it harder to discern bold text depending on the specific font and font-weights, I wonder if maybe additional guidelines for font-weight may also be a topic of interest for this project.

The placeholder image swatches and text samples are a stopgap only; they should all be generated just like the themes. Because mktheme is Go, there's a decent image generation library already available, and routines could be written to generate nice swatches and samples of combinations of the various text colors and background colors to be imbedded directly in the docs.

The theme is still in its early days, and now that it's mostly styled, I have to be honest that the orange and yellow variants are not as pleasant to look at as the peach. Yellow, especially. Readability is great and all, but there's probably more research to be done on the intersection between readability and reduced eyestrain.

There are quite a few borders that could use cleanup or elimination, specifically around the currently-highlighted line. The dividing lines are probably also way too high contrast, so they should be softened or eliminated where possible.

It might be good to have a concept color for "focus" or "current" to represent an object of particular, immediate focus. Or just make "notice" better as per #1

WCAG AA contrast requirements allow a relaxed contrast ratio of 3:1 for "large-scale" text, which is defined as "at least 18 point or 14 point bold" (emphasis mine). Given that 14pt is not outside of the realm of "normal" for most users and Clarion can control the use of bold text by default, it might be enough to relax the contrast requirements for colored text in at least the main editing area, provided the stipulation that the user would need to use this font size for maximum accessibility and contrast.

This requires some careful thought, as clarion still seeks to avoid unnecessary syntax highlighting as much as possible for coding, and the areas where this might prove the most immediately functional (i.e. visual diff displays) might suffer from the forced imposition of bold font weight.