Not an answer to your question, but FYI we deliberately don’t support colors in our standard editor, because the naive way to implement would result in copy-paste errors when people copy their google doc over to the LessWrong editor. (i.e. I believe it pastes in text as “explicitly black” rather than “non-colored” and links as “blue”, overwriting LW’s default green links)
I think there are occasional places where colored text would be preferable but it’s unfortunately tricky to make it usable-when-actually-important without screwing things up a lot of other times.
It’s probably been brought up before, but colors are also not a particularly accessible feature for those who cannot perceive them. There are some easy (partial) solutions [1] that can result in this being less of an issue, but simply not supporting colors is certainly the easiest. Monospace is supported in markdown using the code ticks; perhaps it would be useful to be able to explicitly specify serif, sans, and script fonts as well? (Perhaps we already can and I just haven’t noticed?) With the four font types, times three formatting options (bold, italic, normal), we’d have 12 available “colors” that should all be pretty easy to differentiate. I suspect that many would already be more than it’s easy for most readers to keep track of anyway, so it should be more than enough.
[^1] Allowing bright orange and dark blue provides a high-contrast color set that can be distinguished by most individuals with various types of color-blindness. Standard and inverted are also easy for most sighted persons to see. Still, that even leaves out those without sight unless their screen readers are set up to detect those signals.
(LessWrong dev here)
Not an answer to your question, but FYI we deliberately don’t support colors in our standard editor, because the naive way to implement would result in copy-paste errors when people copy their google doc over to the LessWrong editor. (i.e. I believe it pastes in text as “explicitly black” rather than “non-colored” and links as “blue”, overwriting LW’s default green links)
I think there are occasional places where colored text would be preferable but it’s unfortunately tricky to make it usable-when-actually-important without screwing things up a lot of other times.
It’s probably been brought up before, but colors are also not a particularly accessible feature for those who cannot perceive them. There are some easy (partial) solutions [1] that can result in this being less of an issue, but simply not supporting colors is certainly the easiest. Monospace is supported in markdown using the code ticks; perhaps it would be useful to be able to explicitly specify serif, sans, and script fonts as well? (Perhaps we already can and I just haven’t noticed?) With the four font types, times three formatting options (bold, italic, normal), we’d have 12 available “colors” that should all be pretty easy to differentiate. I suspect that many would already be more than it’s easy for most readers to keep track of anyway, so it should be more than enough.
[^1] Allowing bright orange and dark blue provides a high-contrast color set that can be distinguished by most individuals with various types of color-blindness. Standard and inverted are also easy for most sighted persons to see. Still, that even leaves out those without sight unless their screen readers are set up to detect those signals.