Confusing colors in projects

[giblet22]

Can we change either the color of invalidated or the color of the priority area? They're both the same shade of red and someone could interpret a priority area as invalidated and may choose to not map it.

[althio]

I very much agree.
This is similar to old-TM2 issue hotosm/osm-tasking-manager2#501

I think all colors should be revisited.
Also noted in #608
See some brainstorming with old-TM2 color scheme in hotosm/osm-tasking-manager2#500 (comment)

[Paarmita]

@althio @giblet22 Can I work on this issue?

[bgirardot]

@Paarmita Hi, yes, you can work on this if you want. Thank you very much! Please let us know if you stop working on it and I will put it in progress now.

[Paarmita]

@bgirardot Ya, I would like to take this up.

[bgirardot]

@Paarmita How are you with CSS? we use something call SASS to generate CSS, but it is essentially CSS. We for sure need some pure CSS changes.

[verdy-p]

SASS is just a basic macrolanguage that simplifying the design of CSS, using a "containment" syntax which is simpler to manage that long lists of CSS selectors.
Basically it does not change the individual CSS style properties, but how we can "scope" them (CSS selectors have a global effect and have to be localized using additional identifiers which are sometimes hard to design properly, or require unmanaged collections of CSS class names.

SASS is stuitable for writing generic libraries for generic reusable objects and scope them properly for integrating them in other pages using other CSS/SASS designs.

I had always thought that CSS should standardize the SASS extension, but the SASS extension implies a new syntax for {containment} that breaks all existing conforming CSS parsers, and the containment rules are not exactly the same as standard "inheritance" rules of CSS.

So in fine, it is another styling language, from which CSS can be generated on the fly by a preprocessor acting like a macro-preprocessor with local parameters. The generated CSS uses then generated selector names, which are mostly unpredictable and it's not easy to alter what SASS produces if you tweak the identifiers it uses to write your CSS styles. Once you start using SASS, you have to continue using it (the names generated by SASS preprocessing can be isolated using a sorty of namespacing prefix to avoid them to collide with names designed with CSS only): this namespacing option should be used without using the SASS default which is valid only when SASS is the only styling language used everywhere in the site design.

SASS also slightly alters some CSS properties, it can translate some of them to compatible ones (e.g. adding browser-specific prefixes such as -ms-, -webkit-, or -moz-, or using workaround to support various levels of implementation of CSS. But we can live without this addition, and web design libraries offer better ways to manage that, using browser detection mechanisms to generate only the CSS level they understand (this is the case if you use common frameworks like jQuery or similar which also hide the details about Javascript language features, or level differences in native implementations of the DOM API).

But for this problem here: only changing some colors, this should not be complicate to just change the existing SASS styles, unless the existing SASS code is already ill-designed and was not rationalized to facilitate the integration (and adaptation to various viewing devices with different capabilities, such as small mobile screens, interactive TVs, tablets, projectors, tactile tablets and screens, accessibility features such as zooming preferences for text only or global zooming, or different sets of supported fonts with different metrics, or presentation modes such as "daily vs. nightly" and adaptation to monochromatic rendering, printing, deuteranopy and color vision problems...).

Very often sites use distinctions in the green-yellow-red palette which are hard to distinguish, or use insufficient contrast differences, or sometimes use too many distrinctions in color saturation (human eyes will not distingfuish easily more than 3 saturation levels: full saturation/color vivid; median/pale/dark; and desaturation i.e. monochromatic greys), but will distinguish about 5 lightness levels (including black and white which have no saturation and no hue distinction at all). The hue distinction should avoid the sector between red and green, except if there's difference of lightness/contrast or differences of saturation levels).

Roughly this allows no more than 10 distinct colors (including white, black, and two levels of greys) for any schematic diagram or text. This leaves only 2 vivid colors and 4 pale/dark colors, preferably in the hue range between blue and red, or blue and green, but not alll the three vivid colors except if one is significantly desaturated or contrasted.

[bgirardot]

@Paarmita Gah, my apologies yet again, that message from me about css/sass was not supposed to be directed toward you, but another contributor.

[pantierra]

Closing this in favour of the follow up issue #1257. I brought the initial request into the follow up conversation.