Suggested changes styling #1989
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1989 +/- ##
==========================================
+ Coverage 92.12% 92.13% +<.01%
==========================================
Files 188 188
Lines 10806 10807 +1
Branches 1581 1581
==========================================
+ Hits 9955 9957 +2
+ Misses 851 850 -1
Continue to review full report at Codecov.
|
| @@ -58,4 +58,86 @@ | |||
| vertical-align: middle; | |||
| } | |||
|
|
|||
|
|
|||
| // Suggested changes | |||
| .js-suggested-changes-blob { | |||
There was a problem hiding this comment.
I assume we don't have much control over the markup that is coming from the GitHub API?
.js-suggested-changes-blob shouldn'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.
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.
|
I tried to add
Maybe not super necessary once it would be possible to apply the suggested change, but currently it's probably annoying having to retype the line. |
| // 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.
so cool. I really want to learn more about css colors.
There was a problem hiding this comment.
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 10% of the text color with the background color -> making the new background color slightly darker with light themes or slightly lighter in dark themes.
| @@ -58,4 +58,86 @@ | |||
| vertical-align: middle; | |||
| } | |||
|
|
|||
|
|
|||
| // Suggested changes | |||
| .js-suggested-changes-blob { | |||
There was a problem hiding this comment.
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.
|
Ok, let's merge this as is. |
Description of the Change
This styles the suggested changes in review comments.
Screenshot/Gif
Alternate Designs
N/A
Benefits
Looks less broken. Easier to see what the suggestion is.
Possible Drawbacks
The diffs use the same colors for dark and light themes again. This could make certain themes look less optimized.
Applicable Issues
Closes #1970
Metrics
N/A
Tests
Documentation
N/A
Release Notes
N/A
User Experience Research (Optional)
N/A