Color text in markdown

[jeppeutzon]

@bkeepers : FYI people are continually asking for coloured text in this closed issue:

https://github.com/github/markup/issues/369

[Maszk18]

Csak

2021. október 15., péntek dátummal JeonHyeong Lee @.***> ezt írta:

Feltétlenül szükségünk van színre .... !!!!!

- Ezt azért kapja, mert feliratkozott erre a szálra. Válaszoljon közvetlenül erre az e -mailre, tekintse meg a GitHubon https://github.com/github/markup/issues/1440#issuecomment-944687452 , vagy iratkozzon le https://github.com/notifications/unsubscribe-auth/AVWRGUYFOCDPRA6265ZLJRTUHCMLJANCNFSM4XHISBTA . Trial értesítések útközben a GitHub Mobile iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 vagy Android rendszerhez https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

[hamedhomaee]

Life without color ... impossible!

[psully1]

COLOR me surprised there are still no colors for Github docs.

[AndRossi]

Please, please, please, add colors. I understand it does not seem a priority, but in some cases it can really make a difference.

[dmyersturnbull]

@dipree I really like your proposal, especially for folks who are using a colorblind theme. Thanks for working on this.

[MystixCode]

color pls ;)

[nasserHm]

في اثنين، ٨ نوفمبر، ٢٠٢١ في ١٩:٢٣، كتب MystixCode @.***

:

color pls ;)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/github/markup/issues/1440#issuecomment-963323107, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATORMDZ6PUWZQJJPTOU6ZO3UK72OZANCNFSM4XHISBTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[dipree]

Hey everyone! While this appears to be something simple at first it turns out to be a rather complex undertaking with tons of implications to consider. We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why". Thank you 🙇

[emiltin]

Our use-case is creating good technical documentation for our projects on GitHub. Our documentation consists of markdown files which often includes example of command-line session that rely on colors.

For example when you use rspec to run tests, the output is colored to show which tests pass or fails and makes the output much easier to scan. But currently we can only shown this as black/white on GitHub e.g:

https://github.com/rsmp-nordic/rsmp_validator/blob/master/docs/pages/running.md#running-tests-1

Resorting to images is unacceptable; you can't copy the text, colors don't follow the rest of GitHub, high maintenance, etc.

Terminal output with colors include ANSI escape codes. If each theme on GitHub defined ANSI colors, a syntax highlight block could use ANSI escape codes to color the output. So a block like this taken directly from a terminal session would be shown with colors defined by the current GitHub theme. Typically 32m is a green color, but if you're viewing with a color theme like "protanopia" it could be e.g. blue.

# Some markdown file

Here's an example from the terminal:

```shell
% bundle exec rspec spec/site/tlc/signal_plan_spec.rb:110

Run options:
  include {:locations=>{"./spec/site/tlc/signal_plans_spec.rb"=>[110]}}

Site::Traffic Light Controller
  Signal Plan
<0x1b>[32m    dynamic bands are read with S0023
<0x1b>[0m

Finished in 0.09212 seconds (files took 0.5257 seconds to load)
<0x1b>[32m1 example, 0 failures<0x1b>[0m
\```

If showing all ANSI colors is too permissive, maybe ANSI codes could be mapped to a smaller set of functional colors, e.g. green tones => success red tones => error yellow tones => warning

[Rikj000]

Hey everyone! While this appears to be something simple at first it turns out to be a rather complex undertaking with tons of implications to consider. We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why". Thank you 🙇

Good colored documentation is the use-case! 😄
For example I use colors to highlight warnings & notes:

• Colored WARNING example on ReadTheDocs
• Back/White WARNING example on GitHub

Both are written in the same MarkDown file, used a HTML <span style="color: ..."> tag,
only difference is that GitHub can't parse the provided orange color:

**<span style="color:darkorange">WARNING:</span> To disable TimeFrame-Zoom just use the same candles for `timeframe` & `backtest_timeframe`**

[invidian]

For me, in style guides like https://github.com/uber-go/guide/blob/master/style.md#verify-interface-compliance, I think it would be much better to be able to use red/green to emphasize which example is good and which is bad.

[lagerholm]

Hey everyone! While this appears to be something simple at first it turns out to be a rather complex undertaking with tons of implications to consider. We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why". Thank you 🙇

Have you tried reading code without colors? Not that nice? Well the same applies for documentation although maybe not that many colors ;) But it greatly helps the readability to have some colors for things that are more important so that they "pop out". Same with PRs and comments. Having colors to highlight certain patterns helps lessen the cognitive load when reading and understanding a text.

[xarich]

For me, in style guides like https://github.com/uber-go/guide/blob/master/style.md#verify-interface-compliance, I think it would be much better to be able to use red/green to emphasize which example is good and which is bad.

I fully agree => change color of "table header lines text" to Red for Bad and Green for Good. Only workaround yet: add ✔ or ❌to the texts.

[AndRossi]

Here is yet another scenario: in research, code and documentation are (finally!) becoming relevant to the peer review process. Reviewers visit the repository of our research projects to verify the feasibility and reproducibility of our experiments. Having nice, easy-to-read documentation is clearly a requirement here, and colors can be very helpful in that regard.

Moreover, when a paper undergoes a major revision, the authors are usually requested to highlight the parts they have modified; the standard way is to color them in blue. Right now, if during a major revision we also update our GitHub documentation, we cannot highlight its modified parts, which is annoying.

I know this is a very, very specific scenario; I am just reporting here my experience as a PhD student.

If you need a more practical example just look at the comment by @xarich , just above mine. It contains an URL: the fact that the URL is colored in blue makes it stand out, increasing the readability of the whole post. That is exactly the effect that we, as a community, would like to achieve.

[GiuseppeChillemi]

Hey everyone! While this appears to be something simple at first it turns out to be a rather complex undertaking with tons of implications to consider. We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why". Thank you 🙇

@dipree

My need for color is to emphasize parts of the text when something important needs attention. Also, I would use colors to create a style with meaning in my texts: annotations in blue, essential chapters would be marked as green, and options as orange. In scientific Markdown texts, I would use color for numbers, where I want to mark whether the result is right (green) or wrong (red). I would use it in companies for simple MarkDown made reports, to warn when results are different than expected and attention is needed. Describing the result of a command line, I would mark the args which I am describing, either in code and in text Also, in the documentation code, I would mark those parts that are outdated, and warn about dangerous operations. When writing about the new version of the Red compiler (a programming language I use), I would mark the differences between the old and the new version. In text tables, I would emphasize a particular value or text in an XxY cell or an entire ROW. Again, writing about Red languages, I would mark it as blue each time I write about "Contexts", which is one of the most difficult topics, which really makes the difference over other languages, so anyone reading the documentation searching for an explanation could immediately find that particular argument.

If you need more examples, I could write down some others.

Regards, Giuseppe Chillemi

[AdrianTP]

The use-case which resulted in me arriving at this thread is building a truth-table, differentiating between when true means negative versus when true means positive (e.g. when account.delinquent? returns true, which means that account will be excluded from eligibility for access to a new feature). Being able to highlight a true in red and a false in green (or at least the table cells themselves) would be incredibly useful in this regard. Unfortunately I cannot think of an implementation which would not be incredibly ugly and cumbersome to use in this specific scenario. One of the benefits of Markdown is that it's easy to read the content and style and "compile" it in your head, and I cannot imagine how colour information could be included in this case without cluttering the Markdown and making mental parsing that much more difficult.

[paquinmathieu]

The use-case which resulted in me arriving at this thread is building a truth-table, differentiating between when true means negative versus when true means positive (e.g. when account.delinquent? returns true, which means that account will be excluded from eligibility for access to a new feature). Being able to highlight a true in red and a false in green (or at least the table cells themselves) would be incredibly useful in this regard. Unfortunately I cannot think of an implementation which would not be incredibly ugly and cumbersome to use in this specific scenario. One of the benefits of Markdown is that it's easy to read the content and style and "compile" it in your head, and I cannot imagine how colour information could be included in this case without cluttering the Markdown and making mental parsing that much more difficult.

I was thinking that something like this would be very readable

<color:red>TEXT</color:red> 
or
<red>TEXT</red>
or
<r>TEXT</r>
or
?!RED[TEXT]
or
!?RED TEXT !?RED

What do you guys think?

[interglobalmedia]

I am also here to add my support. I teach and have course content in markdown which is all monochrome. It would be great to be able to add color or even highlight words in the markdown to make reading the content easier! In addition, having monochrome color is not very accessible. Thanks!

[KEINOS]

If the basic reason for the color text's rejection is because of the theme color balance, I think it is a good reason.

Especially for color vision deficiency point of view. 3 of my colleague has this deficiency and often complains of <font color="*"> tag usage in the CMS'.

Since my use-case of red color text is to warn the user something, how about adding a note kinda tag for info, alert, warn instead. And letting the design team handle the color?

Something like:

// inline: **[<type>]...**

- Note that **[info]this method works from version 2** and above.
- Note that **[warn]this method will deprecate soon** and gone in v3.
- Note that **[alert]this method was deprecated**! Use v5 instead.

// block: via syntax highlight
```note:warn
This is a warning to the user.

Any style that won't affect the non-supported markdowns,  as below.

---

- Note that **[info]this method works from version 2** and above.
- Note that **[warn]this method will deprecate soon** and gone in v3.
- Note that **[alert]this method was deprecated**! Use v5 instead.

```note:warn
This is a warning to the user.

---

Edit: I forgot to mention this. 👉 +1 The intention of this comment was just to offer an alternative to color text since it seemed to be making no progress, and I personally am in favor of introducing color text.

[duck-dev]

I totally agree with all that has been said. Since there are already some examples, I wouldn't like to repeat what has already been said. But to keep it universal: Colors make it alive. Of course, you can play with other elements, but often those colors really make a difference. It makes a finally rendered Markdown file a lot more pleasant to look at, alive and just makes it look better. I'd love to see a very similar system to using a span in HTML (<span style="color:xxxxxx">Text</span>), which supports hexadecimal representations of a color and perhaps also common nonsystematic names for colors.

That's my contribution. I hope we can enjoy this feature very soon. + 1 on that!

[quadrismegistus]

+1. I would really appreciate this feature as color is essential for my explanations in the README.

[boris-gu]

A simple and much needed feature. Why is she still missing?

[bossie]

Roses are red Violets are blue, Not Github though.

[emiltin]

hi @dipree, curious if there's any updates on this, based on the use-cases people provided?

[asllop]

Hey everyone! While this appears to be something simple at first it turns out to be a rather complex undertaking with tons of implications to consider. We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why". Thank you 🙇

To support syntax highlighting for languages not supported by Linguist (custom languages). A proper way to define in-repo highlighting rules would be a better option, but in the absence of this, a general coloring feature is an ok option. Custom syntax highlighting is an old request, look at the following issues for reference:

https://github.com/github/linguist/issues/2598 https://github.com/github/linguist/issues/2627

[windbeneathyourwings]

@asllop those issues you have referenced are not solutions to a problem. They are just threads of endless babbling of excuses.

[5nafu]

Hi @dipree

We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why".

For us, one of the use cases (beside the colored "warning" already mentioned) is to be able to better visualise values to be changed in user documentation.

Consider this snippet from one of our READMEs:

Create a GitHub Secret with this context (replace/modify clusters[0].cluster.server, contexts[0].context.namespace & users[0].user.token ):

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: <endpoint>
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    namespace: <namespace>
    user: default-user
  name: default
current-context: default
users:
- name: default-user
  user:
    token: <authorization token>

It would be great if one could color-code the values that the user needs to replace (<endpoint>, <namespace> & <authorization token> in this example).

[dipree]

@emiltin from the comments we identified two problems one is about having more options to better highlight text in Markdown, which we are still exploring. So far, the idea is to introduce three options, ==highlight==, ++positive++ and --negative--. The other problem is around custom syntax highlighting which won't be solved by the before mentioned. We are considering that separately.

[mguinness]

This is somewhat unrelated, but it would be great if there was a way to render ANSI color text in markdown. I wonder if there could be a way to enable the plugin for shell/console to use something like ansi2html.js to output colorized HTML.

[pyorot]

I feel like the priorities are somewhat backwards here; you could just allow fixed colours to address the problem most people have instead of enquiring into exactly why they need it. It's easy to just warn against using fixed colours in the docs rather than forbidding them like a nanny. Then once you've allowed the bad practice, do some research to figure out a good practice alternative that you can recommend.

I personally just want to use colours of my choice and check they work on default light and dark themes. Like red, green, blue, plenty good enough for me.

[KEINOS]

We see that there are a couple of use cases described already but it would help us tremendously if everyone could precisely explain their particular use case to highlight text keeping in mind the "what", "where" and "why".

Hi, @dipree! Thank you for asking! Here's my use case.

• What:
  • For inline-elements:
  • strong tag (bold) with color variation.
  • For block-elements:
  • Box area with background color and nice-to-see-color text.
  • Target usage:
  • Additional information.
    • E.g., As an alternative, we provide docker images to run them in a container.
  • Alert.
    • E.g., This needs a root access privilege.
  • Warning.
    • E.g., DO NOT include your access token here.
    • E.g., This update WILL delete all your settings.
    • E.g., We DO NOT support IE.
• Where:
  • Markdown files in the repo. Especially README.md.
  • Edit: Markdown on the Wiki.
• Why:
  • If the document is long, non-native English speakers may not immediately understand what is meant. Like me. The colored text provides a kind of "tl;rd" and is therefore very useful for reading the whole document.

[Rikj000]

So far, the idea is to introduce three options, ==highlight==, ++positive++ and --negative--.

@dipree, this does not address the issue at hand here! We'd like to be able to properly color our text!
Not by using 3 very limited predefined options, which is an easy, but non-sufficient work around to "solve" this issue!

We want the freedom to choose whichever color for individual parts of our MarkDown files!
Through both HEX codes and through pre-sets for common colors like red, blue, purple, ...

[emiltin]

So far, the idea is to introduce three options, ==highlight==, ++positive++ and --negative--.

@dipree, this does not address the issue at hand here! We'd like to be able to properly color our text! Not by using 3 very limited predefined options, which is an easy, but non-sufficient work around to "solve" this issue!

We want the freedom to choose whichever color for individual parts of our MarkDown files! Through both HEX codes and through pre-sets for common colors like red, blue, purple, ...

arbitrary hex codes would look bad, and have accessability issues, as soon as you change color theme on github. that's the reason for working with functional codes (like warning, positive, etc) instead of raw color codes.

[luigiMinardi]

• Where:

  • Markdown files in the repo. Especially README.md.

Another good place to use those target usage's said by you is on the Wiki that github offers. Although is not used by many, its very important for those who do use it to have this ways to explain for the user exceptional behaviors and really important things.

[KEINOS]

@luigiMinardi

on the Wiki that github offers.

Indeed! I had forgotten that it was one of the reasons I had stopped using the Wiki. 😄

[Ch41r05]

So far, the idea is to introduce three options, ==highlight==, ++positive++ and --negative--.

@dipree, this does not address the issue at hand here! We'd like to be able to properly color our text! Not by using 3 very limited predefined options, which is an easy, but non-sufficient work around to "solve" this issue! We want the freedom to choose whichever color for individual parts of our MarkDown files! Through both HEX codes and through pre-sets for common colors like red, blue, purple, ...

arbitrary hex codes would look bad, and have accessability issues, as soon as you change color theme on github. that's the reason for working with functional codes (like warning, positive, etc) instead of raw color codes.

The question is why not both? Having functional codes sure are useful when accounting for github color theme, but I guess that should be an available choice for the user to make instead of a predetermined little set of colors since foreseeing use cases isn't that easy.

[emiltin]

The question is why not both? Having functional codes sure are useful when accounting for github color theme, but I guess that should be an available choice for the user to make instead of a predetermined little set of colors since foreseeing use cases isn't that easy.

I would prefer GitHub to look consistent across repositories, rather that allowing people to choose arbitrary colors, because I think that makes it easier for everybody to quickly scan and understand readme files and documentation. For me GitHub is primarily about the content, not design. The design is important, for sure, including colors, but should subtly support the content, not be become the focus.

I also think arbitrary colors could often lead to repos that don't work well with different GitHub themes, or are hard to access for color blind people. Designing a custom color scheme that look good and also works well for color blind people, across the different GitHub color schemes is not a trivial task.

[asllop]

The design is important, for sure, including colors, but should subtly support the content, not be become the focus.

I don't think adding colors will make the design the focus, actually may improve the readability of certain contents.

And regarding different themes and color blind people, why not just create equivalences? It's what the graphic terminals do in Linux or macOS: color codes have different actual colors assigned depending on the selected theme. For example, in the macOS terminal, code 30 which is black as default, becomes white when applied to a text in the "Pro" theme.

EDIT: Just for ref, ANSI color codes and how to use them in a terminal: https://misc.flogisoft.com/bash/tip_colors_and_formatting

[luigiMinardi]

And regarding different themes and color blind people, why not just create equivalences?

Well I don't know much about how the color equivalences work on the back, but I think that if it was that easy to do with all the colors, the Auto Dark Mode for Web Contents from Chromium flags and many other auto dark-mode tools would work much better by default don't it? Cuz right now (as much as I know) most of it basically inverts the colors of everything and it isn't something that you really wan't to have in some cases.

When emiltin says:

should subtly support the content, not be become the focus.

I think he means that github is not a website for designers by main feature, what I mean is, the github will not put all of its effort into making a good tool to translate colors between multiple themes independently of the theme or color choosen.

Also new features means new bugs and more job to do, the more complex it is, the harder will be to mantain. As it is not the focus of the platform, I think we just need a good palete of color options that work functionally and help with the description of the programs we build here.

[asllop]

Well I don't know much about how the color equivalences work on the back, but I think that if it was that easy to do with all the colors, the Auto Dark Mode for Web Contents from Chromium flags and many other auto dark-mode tools would work much better by default don't it? Cuz right now (as much as I know) most of it basically inverts the colors of everything and it isn't something that you really wan't to have in some cases.

Nobody said we have to support all colors in the visible spectrum. Actually, supporting the basic 8/16 ANSI ones should work for most use cases.

[Masoudahmadi304]

1440از گوشی هوشمند Samsung Galaxy ارسال شده است.

-------- پیام اصلی --------از: Andreu @.> تاریخ: ۲۰۲۲/۳/۱۹ ۱۷:۵۰ (GMT+03:30) گیرنده: github/markup @.> گیرنده کپی: Subscribed @.***> موضوع: Re: [github/markup] Color text in markdown (#1440)

Well I don't know much about how the color equivalences work on the back, but I think that if it was that easy to do with all the colors, the Auto Dark Mode for Web Contents from Chromium flags and many other auto dark-mode tools would work much better by default don't it? Cuz right now (as much as I know) most of it basically inverts the colors of everything and it isn't something that you really wan't to have in some cases.

Nobody said we have to support all colors in the visible spectrum. Actually, supporting the basic 8/16 ANSI ones should work for most use cases.

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/github/markup/issues/1440#issuecomment-1073018560", "url": "https://github.com/github/markup/issues/1440#issuecomment-1073018560", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[ZeroOnePro]

Is there any progress?

[LordNoteworthy]

welcome 2022, still no colors

[ZayshaaCodes]

+1 Please and thank you! What saddens me is the time and effort people put into trying to get them to implement a feature is enough to have implemented the feature several times over.

[BadagalaAdarsh]

Come on Github What happened to you, Just give us the damn colors

[lbfalvy]

If you want to adapt the presentation to the current Github theme, the correct solution would be to define "positive", "negative", "code-(keyword|number|string|local|global|constant|function|operator|comment|what-have-you)", "highlight", "important", "extra" and other colour labels, maybe applied using a span with a data-attribute, with a focus on adding as many labels as colours used by Github. Once other platforms also start adding colour support authors can apply multiple colour labels to support multiple competing standards since an unrecognised data-attribute does not affect the style, and then these platforms can also seamlessly update the set of supported labels while breaking as little existing code as possible.

[lbfalvy]

These contextual labels have the additional advantage that they can be assigned aria labels too. Ignoring what is easily one of the oldest feature requests on your product doesn't help accessibility.

[AndRossi]

I read the comments of a few users worried that adding color support to the GitHub markdown would raise accessibility issues, or make pages look bad. I understand these concerns; I believe that an easy solution could be a limited (but comprehensive) palette.

However, I would also like to point out that the responsibility of keeping repositories "good" lies on the shoulders of repository owners, not on GitHub's. The fact that some users would misuse colors is not a reason to avoid colors completely, because other users would make great use of them to enhance their documentation and make their repos clearer.

In a way, this is similar to how users, today, can write bad documentation in their readme and wikis. If they do, we, as a community, can just open issues notifying they need to correct or improve their repos.

As an extreme example, if we thrashed colors just because some users could misuse them, we would also have to thrash the possibility to open issues, because malevolent users may use this feature to write insults and slurs 😄

Finally, some competitors of GitHub have already added support for colors in their markup languages (e.g., GitLab), with apparently no bad consequences

[shayneoneill]

make colorsmake colors make colors gibeshaneycolors

uh oh no colrs >:(

pls

[sigmasaur]

So far, the idea is to introduce three options, ==highlight==, ++positive++ and --negative--.

If I interpret the three options correctly, I'd suggest a fourth one acting as the opposite of ==highlight== for writing notes that are less important than the rest and may be omitted during the read, which is my use case.