Color text in markdown
jeppeutzon opened this issue · comments
Hi, thank you for starting this new issue. I would absolutely appreciate that feature. Thank you
+1000, which is a roughly accurate summation of six years worth of continuous +1 posts on issue #369, most of which weren't noticed due to that issue being closed for most of that time. (I'm exaggerating only slightly; the real number is 76 posts)
Please fix this and sunset one of my most popular StackOverflow questions (another +358 upvotes and counting): https://stackoverflow.com/questions/11509830/how-to-add-color-to-githubs-readme-md-file
Color is an important design feature for many CLI tools, including my underscore-cli tool for hacking on JSON data, and thus, it's important to be able to include properly colored output examples in the documentation.
Currently, the ONLY way to accomplish this is with a screenshot:
Screenshots are inferior to natively colored text. Beyond the minor inconveniences of being cumbersome to create / edit / maintain, and slower for browsers to load, screenshots thwart readers from copy/pasting key snippets of text, such as the command that was executed in the screenshot -- this makes the documentation less usable, and the potential work-arounds are all very ugly.
Another use-case from issue #369: There's a reason you support auto-colorization of code blocks --- coloring text is crucial for facilitating our eyes to parse it faster. However, there's no fallback story for tail languages and other structured text formats that aren't in your list.
Many, many projects would benefit from being able to tastefully color the structured text in their documentation.
I am here to add my support to colorization in Markdown. Colors are an essential part of communication and we are in 2021, not in 1981 with monochrome displays.
+2147483647, we need this to happen!
Please, make colors happen!
It is crucial indeed! It's been 7 years for god's sake...
One of examples where color text in markdown is useful is Terraform plan reviews.
Consider attaching Terraform plan into GitHub tickets, issues or pull requests. Having TF plan is useful, makes it easier to review pull request, but.. it is plan text, no colors at all.
You can abuse the support for diff. I pipe it through this function (zsh/osx):
format_plan () {
awk '
/Terraform will perform the following actions:/ { found=1 }
/------------------------------------------------------------------------/ { found=0 }
// { if (found) { print $0 } }
' | (
printf '<details><summary>Plan for %s</summary>\n\n```diff\n\n' "$1" && perl -pe 's/\x1b\[[0-9;]*[mG]//g' | sed -e 's/^\( *\)\([\+-]\)/\2\1/' -e 's/^\( *\)~/!\1/' && printf '```\n</details>'
) | pbcopy
}
At least, GitHub could create a custom attribute (<span data-color="red">Red</span>) for example. This would be great as you don't have to use style attributes anymore anymore. It would be easy to style these with some javascript.
Recap of two hacks methods provided to do this
Images
Diffs
```diff
+ Green
- Red
! Orange
@@ Pink @@
# Gray
...It's okay but no inline text I guess
And we also have those symbols. but we can disguise them by doing + Green + instead of + Green for example
Idk what GitHub is waiting for, all IDE's I use support coloring in MarkDown..
The hacks described above "work", but should really not be considered as a "fix". The solution is way too dirty for that...
It's 2021 guys, we'd like some proper
+ C +
- O -
! L !
@@ O @@
# R #
Splease! 🙏
Damn, I am surprised at how many people have been asking for color to be implemented into the GitHub markdown preview, and how long they have been asking for it w/o reply. When a company is new, they are so quick to cater to a customers needs, but when they get big like GitHub did, they can honestly care less. Its not that I think they should insert color into there markdown engine, but at the very least give a quick one liner reason as to why they won't implement color into MD rendering engine.
If I had to guess as to why they don't implement color, I would say it is because, they are the only one with black and white text & oversized headers. There markdown, generates a README view that is unique onto GitHub. Any of us can look at a dot MD document on GitHub, and know we are reading something in a GitHub repository. It is so unique and custom, that I see editor extensions that generate markdown in the same format as GitHub does. There MarkDown is a unique trademark of there site. Which makes since because I know that, (75% ) or more, of the time I spend in GitHub, is in my own, or someone else's, README.md documents. I believe they are MS now, which are like the contemporary marketing gurus.
EDIT:
Just wanted to point out that using something like
+ some-text +
- some-text -
# some-text #
* some-text *
wont work because most of the syntax you are suggesting is already being implemented in Markdown. You need something unused
like:
Where 1 equals a set of numbers ex(1-8) or (1-4) or whatever...
each number is a different color. It would take some ingenuity to implement. Many of the commonly used shorthand's are alreadt being implemented in contemporary markdown.
Could you please some support for colored text in markdown?
Yes color is important part of communication particularly if you are working on visual components. Please make it possible.
Yes, colors please.
colors would be useful when discussing e.g. the output of RSpec, which uses colors a lot.
Gosh Darn it GitHub, life is no fun without color! Please don't make us read black & white documentation for another 5 years. Give us something to zest our README docs up with. GitHub Markdown feels very archaic, quite honestly, visiting a GitHub README.md doc reminds me of watching I Luv Lucy, except I Luv Lucy was funny at least! Or, actually i just remembered that I Luv Lucy Wasn't funny, but you get the point. GitHub Docs needs color, please give us color, so GitHub stops looking like a 1950's throwback website from an alternate reality where the internet was invented 50 years earlier.
Doesn't have to be HTML tags, you are industry leaders if you think some other option is better. Just set the standard, I'm sure everyone is happy as long as we get colors 😃
maybe a custom extension to the markup language, that makes it possible to use different colors for light/dark/dimmed mode
I need gray colored text to quickly differentiate from author's text and text left in issue/pull request template.
Example: ClickHouse/ClickHouse#26897
The text
By adding documentation, you'll allow users to try your new feature immediately, not when someone else will have time to document it later. Documentation is necessary for all features that affect user experience in any way. You can add brief documentation draft above, or add documentation right into your patch as Markdown files in docs folder.
has to have gray color.
PS. Maybe I will simply use quotation for that purpose.
It's already 2021 and Github still insists on ignoring colors.
Why
give me colors or give me death
This makes me so sad that a feature which is one of the most basic features in any IDE/ is getting no love from Microsoft/github...
Does GitHub not want to add colors, or is it more of a technical or resource issue?
@github should Hoist the colours like a true pirate.
Can we can an answer to this issue please?
It's already 2021 and Github still insists on ignoring colors.
"Already 2021"? I see you're also feeling this:
It would be very nice feature to have !
I think GitHub could allow adding classes ({.class#id}), and then style those classes as necessary. This could allow us to add colored text via text {.red}, and this could open doors for a whole lot of stuff (## h2 {.important}, | Table | Header | {.striped},  {.centered}, [link](link) {.button}, text {.font-handwriting})
Common, Github!
Consider started an official campaign for
LET MARKDOWN COLORS HAPPEN!
React to this to call their attention!
- Colors please! -
- Colors please! -
+( Just give us colors! )+
+( Just give us colors! )+
don't mind me...I'm just another one CRAVING FOR COLORS IN MY README AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA PLEASE!!!!!
❤️ ☮️ 🌈
I'll add my +1 here.
This whole thing seems really odd.
- The original issue was closed by @bkeepers (no longer at GitHub?) less than 10 days after it was opened, without providing a means for the community to follow the progress of the request. Where is the transparency?
- It's been almost 7 years since the original request and almost 7 months since this request opened, with no update or explanation from the GitHub team.
- This is a highly requested feature.
- There are easy solutions to this problem.
I agree with @W3Dojo:
at the very least give a quick one liner reason as to why they won't implement color into MD rendering engine.
GitHub team - pretty safe assumption you have your reasons for not implementing this feature request, but your lack of response is in stark contrast to your Customer Obsessed leadership principle.
Hello Github-staff-people. There is a much requested feature that has gone unnoticed or ignored for years (see above). Not sure who is the right person to alert, so I'm just tagging a few of you and then you can fight it out yourselves. :)
@ashtom @colebemis @dipree @eileencodes @mdo @izuzak @homeles @kdaigle @leereilly @lukehefson
@jeppeutzon looks like I won 🥊 we will have a look. Thanks for bringing it to our attention.
[This] is the Frankenstein screenshot-based README of my project. If it is a matter of github keeping the trademark of B&W (like said by other commenter), I suppose this kind of ugly solution certainly defeats it by large.
Is there any other option other than diff? 😞
- red
+ greenI don't like the idea of adding an extra character for the color: -, +, etc.
Is there any other option other than diff? 😞
- red + greenI don't like the idea of adding an extra character for the color: -, +, etc.
There are other similar kludges (see above) but no proper solution. I don't think any sane person likes the idea of using these kinds of hacks.
(´._.`)\(‘́⌣’̀ ) Colored text will come one day son, one day...
Hey, Github... Colors are cool.
I've sometimes missed the ability to use colors in markdown or readme files, but frankly it's easy to use colors too much. If everyone could color their readme files any way they like, I'm not sure I would enjoy browsing repositories in GitHub as much as I do now. The result might be a rather messy experience.
Maybe colors should be limited syntax highlighting? What I miss is the ability to show a terminal session with colors. Of course this could easily be abused and turn into a hack to color your readme..
It would be great to be able to have colors so we can at least manually render ansi color escape codes to be displayed on github
LOVE COLORS
Please, Color Me!
give us colorrrrrrr
@emiltin we are still investigating. But it's very likely that we won't open the flood gates to define any color. We support multiple themes on GitHub and want to make sure that colored text in Markdown is accessible in any theme. It's unfortunately quite easy to exclude certain groups from being able to access text once it has a fixed color. For instance, when choosing a white font while in dark mode all those on a light theme won't be able to read it. We believe that the most inclusive option is to allow the usage of functional variables. So, rather than describing the exact color, a user would be able to use text color utilities. For example "success" which is defined as #1a7f37 on the "Light" theme and #0566d5 on "Light protanopia". We haven't yet decided on whether or when we will allow to color text in Markdown, but we are actively looking into this and will keep you posted with any updates.
Do you think allowing a subset of colors but making it accessible to anyone would cover most of your use cases?
Hi @dipree, thank you for providing a status, that's appreciated. I personally think it makes a lot of sense to allow functional variables rather than any fixed colors; themes being one good reason.
Syntax coloring in text editors (or websites) follows a similar pattern: You define certain colors and when they are used, rather than fixed colors.
The use-case of showing a terminal session with color in the output might deserve special consideration. For example, how would you (or should you) illustrate a terminal session running the rspec command with some tests being green and others red?
I feel like having access to the named colors in HTML for both foreground and background would be plenty for most people, but I certainly understand the concern when theme coloration come into play.
I suggest adding a requirement of 16 colors to each theme "titled" color_1 to color_16 similar to how 4-bit ANSI color codes are implemented in terminal emulators with themes, keeping in mind that most colors in editors follow the same source and convention.
We definitely need color ....!!!!!
Life without color ... impossible!
COLOR me surprised there are still no colors for Github docs.
Please, please, please, add colors. I understand it does not seem a priority, but in some cases it can really make a difference.
@dipree I really like your proposal, especially for folks who are using a colorblind theme.
Thanks for working on this.
color pls ;)
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 🙇
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
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:
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`**
```
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.
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.
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.
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.
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 🙇
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
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.
The use-case which resulted in me arriving at this thread is building a truth-table, differentiating between when
truemeans negative versus whentruemeans positive (e.g. whenaccount.delinquent?returnstrue, 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?
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!
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.
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.
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!
+1. I would really appreciate this feature as color is essential for my explanations in the README.
A simple and much needed feature. Why is she still missing?
Roses are red
Violets are blue,
Not Github though.
hi @dipree, curious if there's any updates on this, based on the use-cases people provided?
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:
@asllop those issues you have referenced are not solutions to a problem. They are just threads of endless babbling of excuses.
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).
@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.
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.
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.
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:
strongtag (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
rootaccess privilege.
- E.g., This needs a
- 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.
- Additional information.
- For inline-elements:
- Where:
- Markdown files in the repo. Especially
README.md. - Edit: Markdown on the Wiki.
- Markdown files in the repo. Especially
- 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.
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, ...
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.
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.
on the Wiki that github offers.
Indeed! I had forgotten that it was one of the reasons I had stopped using the Wiki. 😄
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 likered,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.
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.
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
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.
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.
Is there any progress?
welcome 2022, still no colors
+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.
Come on Github What happened to you, Just give us the damn colors
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.
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.
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
make colorsmake colors make colors
gibeshaneycolors
uh oh no colrs >:(
pls
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.