-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Comments
This looks great @dsifford, thanks for this first iteration! I think it has a lot of potential. Some ideas:
|
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? |
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. |
Beautiful! Taking a look at it now. |
@zenorocha I wrote the above spec in spec-markdown. Do you suggest we not go that route? |
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 Can we instead just use screenshots? |
Ohhh I see, no problem. Should we try CodeMirror before going with screenshots? https://github.com/codemirror/CodeMirror/blob/master/theme/dracula.css |
Sure, we can give that a shot I suppose. |
@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 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
... etc, etc, etc |
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. |
@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! |
Also, I forgot about Monaco editor which will allow us to literally drop in the syntax from visual-studio-code |
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:
What I propose:
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:
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): |
@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! |
@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
Extended Colors
(For copy/paste purposes ...)
Thanks in advance! |
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
Extended Colors
|
@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 |
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:
|
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? |
@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. |
@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! |
@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. 👍 |
@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. |
@dsifford I'll make a PR for the VSCode repo, too. :) |
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. |
Hello Community! |
Any updates? (: |
Is this the issue to bikeshed about color decisions? |
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? |
Someone mentioned in #318 that comments were hard to read when highlighted. Guess this would be the right place to discuss that? |
I love this thread and the idea behind it. It's been a while since the last comment, is there any updates so far? |
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: |
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.
The text was updated successfully, but these errors were encountered: