-
Notifications
You must be signed in to change notification settings - Fork 408
Suggested changes styling #1989
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,3 +7,13 @@ | |
| @gh-background-color-red: #dc3545; | ||
| @gh-background-color-purple: #6f42c1; | ||
| @gh-background-color-green: #28a745; | ||
|
|
||
|
|
||
| // diff colors ----------------- | ||
| // Needs to be semi transparent to make it work with selections and different themes | ||
|
|
||
| @github-diff-deleted: fade(hsl(353, 100%, 66%), 15%); // similar to .com's hsl(353, 100%, 97%) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so cool. I really want to learn more about css colors.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If possible, it's best to only use the UI and syntax theme variables. Then it should look ok in all themes. But sometimes making an exception is fine too. 😬 In this case, it felt better to use the .com colors for the diff and not "success" and "error". But it needed to be semi transparent to make the selections visible underneath. Less has a bunch of functions to tweak colors, like fade() to make an existing color more transparent. I also have been using mix() sometimes. For example .class {
background-color: mix(@text-color, @base-background-color, 10%);
}mixes |
||
| @github-diff-added: fade(hsl(137, 100%, 55%), 15%); // similar to .com's hsl(137, 100%, 95%) | ||
|
|
||
| @github-diff-deleted-highlight: fade(hsl(353, 95%, 66%), 25%); // similar to .com's hsl(353, 95%, 86%) | ||
| @github-diff-added-highlight: fade(hsl(135, 73%, 55%), 25%); // similar to .com's hsl(135, 73%, 81%) | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume we don't have much control over the markup that is coming from the GitHub API?
.js-suggested-changes-blobshouldn't be used for styling, but it seems like the best identifier to scope "suggested changes". Also, the class names from .com could change anytime and might break the styling in Atom.I'm ok with shipping this as is, but it might be good to add a TODO or file an issue to communicate that this solution is somewhat fragile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I thought about how styling based on this classname is fragile 😦
On the plus side, no functionality would be broken...it would just look janky again.
The "right" way to do this is to identify "suggested changes" comments based on data attributes that come from the graphQL api (which is probably possible, but I haven't looked at the schema.) . Then we apply our own classname.