Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Implement a specification that standardizes Dracula theme #232

Closed
dsifford opened this issue May 28, 2017 · 32 comments
Closed

RFC: Implement a specification that standardizes Dracula theme #232

dsifford opened this issue May 28, 2017 · 32 comments
Labels
🤔 discuss Something needs to be discussed to move forward or reach a resolution

Comments

@dsifford
Copy link
Member

dsifford commented May 28, 2017

  • Start Date: 2017-05-28

Summary

There has been some desire from the community (#192) and myself to create a global standardization for Dracula Theme's syntax highlighting across the host of implementations.

Motivation

I regularly use two different text editors with the Dracula Theme enabled when working (Vim and Visual Studio Code). When switching between these editors, the differences in syntax highlighting often is jarring and disorienting.

In an ideal situation, I would be able to seamlessly transition between editors without noticing a change in the syntax highlighting.

Detailed design

An initial specification for this RFC can be found here: https://dsifford.github.io/dracula-spec/

A fully spec-compliant implementation of this can be found here: https://github.com/dracula/visual-studio-code

Drawbacks

There will be some work involved in achieving full compliance across all the implementations. It likely won't even be possible for this.

However, having a detailed guide of the recommended and agreed-upon patterns for theme implementers will greatly enhance the probability that theme implementations are, at the very least, closely similar to the others.

Unresolved questions

This initial specification was put together with primarily my own opinions on the color patterns that I like. I'd prefer to have this issue open for a while and collect the thoughts of as many implementers as possible and revise the spec with these opinions. Proceeding in that manner will keep it as democratic as possible and (hopefully) keep everybody happy with the final decision.

@zenorocha
Copy link
Contributor

This looks great @dsifford, thanks for this first iteration! I think it has a lot of potential.

Some ideas:

  • What do you think of moving this content to draculatheme.com? We could create a new page called "Spec".
  • What do you think of having some examples so people can visually see what those rules are? Maybe we could start applying this spec on the highlight.js theme and use that on the site.

@dsifford
Copy link
Member Author

Thanks @zenorocha

Agree with all your thoughts. And I fully admit that the spec file currently isn't very usable without examples. Just wanted to be sure the idea was going to be well-received before spending more time on it!

How do you suggest we proceed from here? Want me to PR the spec files?

@zenorocha
Copy link
Contributor

Great! I just added support for markdown rendering and syntax highlight with Highlight.js: dracula/draculatheme.com@faff17f

I also added Dracula's CSS theme so you can see how the examples would look like. Now that we have this infrastructure in place you can start adding the spec file. Some additional styling will be necessary, but we can improve that after the content is there.

@dsifford
Copy link
Member Author

Beautiful! Taking a look at it now.

@dsifford
Copy link
Member Author

@zenorocha I wrote the above spec in spec-markdown. Do you suggest we not go that route?

@dsifford
Copy link
Member Author

dsifford commented May 30, 2017

Also, I'm not exactly sure why, but I can't get metallic to render highlighted code after just a few lines. Any ideas?

Would be nice to have several test cases to look at when looking at the highlightjs css.

Edit: Just kidding. It appears that highlightjs just doesn't play nicely with typescript. Switched to javascript and it seemed to work.

Edit 2: After playing around with c++ and other typed languages in highlightjs, I'm not super keen on the idea of using highlightjs as an exemplary model of the spec. Because the scopes are so narrow, the result of adding in as much of the spec as I can will still result in a grossly incorrect picture of what it should be using TextMate scopes or some other format. Example being that types and keywords have the same scope, so int main() { return 0;} as an example, both int and return would be cyan, which is wrong. In that case, I think it should be pink, but that's wrong from the perspective of being an example.

Can we instead just use screenshots?

@zenorocha
Copy link
Contributor

Ohhh I see, no problem. Should we try CodeMirror before going with screenshots? https://github.com/codemirror/CodeMirror/blob/master/theme/dracula.css

@dsifford
Copy link
Member Author

Sure, we can give that a shot I suppose.

@dsifford
Copy link
Member Author

@zenorocha Just checked out codemirror. The theme they have is probably as close as it's going to get already, but still way off because it doesn't allow customizations as fine-grained as textmate.

Codemirror has no way of telling the difference between functions, classes, variables, etc so they all get scoped to cm-variable. From a textmate perspective, this is incorrect, but I understand the limitations.

Still not super keen on the idea of using that as an example, but I'll defer that decision to you. I think the spec should define colors as fine grained as possible and then offer a "fallback chain" of colors to use in these sorts of circumstances.

So for example:

User-defined entities

Classes: Cyan -> Green
Functions: Green
Variables: Foreground -> Green

... etc, etc, etc

@zenorocha
Copy link
Contributor

Ohh man, looks like all these syntax highlighters are very limited. Let's go with screenshots then, it's harder to maintain if changes are made, but it's better than nothing.

@dsifford
Copy link
Member Author

dsifford commented Jun 1, 2017

@zenorocha Came across ace editor and I think that will be the ticket if you can get it to work with metalsmith.

https://github.com/ajaxorg/ace

It appears that ace has a relatively solid agreement between its scopes and textmate scopes. They even provide a tool to convert between the two!

@dsifford
Copy link
Member Author

dsifford commented Jun 1, 2017

Also, I forgot about Monaco editor which will allow us to literally drop in the syntax from visual-studio-code

@marcdeop
Copy link

First of all, thanks for creating this RFC, I think this is very much needed.

I will talk about the terminal (ANSI) colors as I have been working for a while on my own set of colors for tmux and powerline and I have been having issues on making them work properly on the two terminals that I use (konsole [KDE] and iterm2 [OSX] ).

The problem that we face is that the "essential" colors for ANSI are just 15 ( 0 to 15 on ANSI) and we need to treat carefuly the second 8: most (if not all) terminal applications relay on the basic 16 ANSI colors to stablish the colorschemes that they use.

That being said, in the standard Dracula palette there are 12 colors ( really 11 as "Current Line" and "Selection" are the same), so we need to do some sacrifices somewhere.

In the current version of the RFC, I see:

  • 1,2,3,5 and 6 ANSI colors match the colors from the Dracula palette.
  • 4 (AnsiBlue) is being replaced by the Purple from the Dracula palette.
  • 15 (AnsiBrightWhite) is being replaced by the Foreground from the Dracula palette.
  • Rest of the colors are custom versions trying to be "bright" versions of the 0-7 colors.

What I propose:

  • 0 be 282a36 ( Background on the Dracula palette)
  • 8 be 44475a ( Current Line/Selection on the Dracula palette)

With this approach we will keep colors very similar to the original ANSI and we will only be missing two colors from the Dracula palette. Furthermore, I will propose also to add two colors to the RFC:

  • 61 to be 6272a4
  • 215 to be ffb86c

So terminal applications that support more than the basic 16 colors can use the Orange and Comment from the Dracula palette.

I attach screenshots of the konsole colorscheme ( NOTE: colors here start on 1, not 0 as ANSI) and tmux and powerline apps running on konsole ( with the color definition also included) ( notice that the themes are not finished but are in good enough shape to use them as example):

dracula_ansi_konsole
tmux_powerline_dracula_ansi

@dsifford
Copy link
Member Author

@marcdeop The ANSI colors in the RFC document were taken directly from https://github.com/dracula/xresources.

Your ideas sound great to me, but I think we should rope @Aszarsha into this convo for the sake of continuity/uniformity.

Thanks for the feedback!

@dsifford
Copy link
Member Author

dsifford commented Aug 7, 2017

@marcdeop Circling back to this... I think your suggestions are a great. I'm interested in trying this out in the VSCode implementation.

Can you do me a favor and write colors0-16 (and also the extended 256 colors) in tabular format so I can see them all in one place? I went to go try this just now in my terminal and its a bit confusing to figure out what colors should be what..

So, in other words, can you fill these tables out?

ANSI Colors

Color Name Hex
color0
color1
color2
color3
color4
color5
color6
color7
color8
color9
color10
color11
color12
color13
color14
color15
color16

Extended Colors

Color Name Hex
... ...

(For copy/paste purposes ...)

### ANSI Colors

Color Name | Hex 
--- | ---
`color0` | 
`color1` |
`color2` |
`color3` |
`color4` |
`color5` |
`color6` |
`color7` |
`color8` |
`color9` |
`color10` |
`color11` |
`color12` |
`color13` |
`color14` |
`color15` |
`color16` |

### Extended Colors

Color Name | Hex 
--- | ---
... | ...

Thanks in advance!

@marcdeop
Copy link

I apologize for the delay, I was out on a business trip this past week.

You are totally right, all this colours and positions end up being a bit confusing ;-)

So here is what my current Konsole theme uses, following my proposal:

ANSI Colors

Color Name Hex
color0 #282a36
color1 #ff5555
color2 #50fa7b
color3 #f1fa8c
color4 #bd93f9
color5 #ff79c6
color6 #8be9fd
color7 #bfbfbf
color8 #44475a
color9 #ff6e67
color10 #5af78e
color11 #f4f99d
color12 #caa9fa
color13 #ff92d0
color14 #9aedfe
color15 #f8f8f2

Extended Colors

Color Name Hex
color61 #6272a4
color215 #ffb86c

@teddybradford
Copy link

teddybradford commented Feb 5, 2018

@marcdeop I've been trying these colors out in my terminal theme and like it a lot.

Out of curiosity, how were the bright colors chosen? Were they generated using a formula (e.g. +15% brightness) or were they chosen by eye?

Also, where does the gray color7 come from?

@marcdeop
Copy link

I didn't choose this colors. They are based on the RFC that is posted in this discussion and, furthermore, it also says where the colors come from:

This initial specification was put together with primarily my own opinions on the color patterns that I like.

@teddybradford
Copy link

Sorry, @marcdeop! My question should have been aimed at @dsifford: I was just wondering, was there a systematic way that the additional colors were generated (which would be fun to see documented if so), did you pick ones simply based on what looked good to you, or did you use a combination of those two methods?

@dsifford
Copy link
Member Author

dsifford commented Feb 10, 2018

@teddybradford To be honest, I can't recall how the ansi bright colors were chosen. The base scheme came from the table in this repo.

Color 7 most likely came from tweaking the color several times until people using the vscode integrated terminal stopped opening issues about it. IIRC, that color was one of the most problematic in terms of contrast ratio.

Edit: Just kidding. It appears that color 7 was taken using @marcdeop's suggestion.

@teddybradford
Copy link

@dsifford Ah, okay. Thanks for commenting on that!

I also took a stab at a color scheme for the ANSI colors, which provides a bit more contrast between base and highlight colors. To come up with the dark/light variations of the Dracula theme colors, I added or subtracted rgb(32, 32, 32) from each color. This way the hue always remains the same between the base and the highlight color, and the difference in lightness between base and highlight colors is consistent across each color.

You can take a look at the color scheme here: https://codepen.io/teddybradford/full/XZeRvg/

Let me know what you think!

@dsifford
Copy link
Member Author

@teddybradford Looks great to me. Any chance you can diff the old scheme vs your scheme side by side and post it in this thread?

Also, if you're a VSCode user, please send a PR for this in that repo. 👍

@teddybradford
Copy link

teddybradford commented Feb 14, 2018

@dsifford I went ahead and added a diff of your old color scheme and my new proposed one. I also slightly changed the method of choosing the alt color; instead of adding/subtracting rgb(32, 32, 32), I added/subtracted rgb(33, 36, 42). This value stems from the RGB difference between the Dracula theme background color and the Dracula theme selection color--the difference of which is rgb(11, 12, 14). I tripled that to increase contrast between the colors. And now the alt color addition/subtraction isn't as arbitrary!

Anyway, the link for the diff and color updates is the same as before: https://codepen.io/teddybradford/full/XZeRvg/

Edit: I tripled the rgb(11, 12, 14) value; previously I had only doubled it. The increased contrast allows for more versatility on lower screen brightnesses.

@teddybradford
Copy link

@dsifford I'll make a PR for the VSCode repo, too. :)

@teddybradford
Copy link

teddybradford commented Feb 15, 2018

I updated the diff again and tripled the rgb(11, 12, 14) value; previously I had only doubled it. The increased contrast allows for more versatility for lower screen brightnesses.

@bezvoshchuk
Copy link

Hello Community!
Can I find somewhere something like "colour's explanation"? E.g. some folder inside my project is dark-blue or file is yellow... what does it means?
Thank you in advance.

@oswaldoacauan
Copy link
Member

Any updates? (:

@NoahTheDuke
Copy link

Is this the issue to bikeshed about color decisions?

@m-dango
Copy link

m-dango commented Jan 5, 2019

I'd personally prefer a color other than foreground for variables if possible. Foreground doesn't stand out too well, especially not with string interpolation (white + yellow).

Is there a reason foreground is used over any other colors in the spec?

@hacknug hacknug added the 🤔 discuss Something needs to be discussed to move forward or reach a resolution label Jun 28, 2019
@hacknug
Copy link
Member

hacknug commented Jul 2, 2019

Someone mentioned in #318 that comments were hard to read when highlighted. Guess this would be the right place to discuss that?

@ianyepan
Copy link

I love this thread and the idea behind it. It's been a while since the last comment, is there any updates so far?

zenorocha added a commit that referenced this issue Mar 23, 2020
@zenorocha
Copy link
Contributor

The spec is now official! 🎉

I'm going to close this issue for now, but feel free to start new discussions about each color over here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤔 discuss Something needs to be discussed to move forward or reach a resolution
Development

No branches or pull requests

10 participants