Extract common CSS vars#14349
Conversation
ef97781 to
1661ab5
Compare
| // attribution is also dark. Not sure what to do about this. Any thoughts? | ||
| background-color: rgba(255, 255, 255, 0.5); | ||
| font-size: 9px; | ||
| font-size: 0.5625rem; // 9px if base font is 16px |
There was a problem hiding this comment.
Wouldn't it be better to configure this as a percentage of the base font?
There was a problem hiding this comment.
How would I do that?
If I set this to:
font-size: 56.25%;I believe that means 56.25% of the font size of the element's parent. And the element's parent may have a different font size than the base font, right? So we need to use rem to specify this as a percentage of the base font, unless I'm misunderstanding something.
There was a problem hiding this comment.
I suppose both approaches are valid in certain applications and as long as used consistently. However, given that we indeed define everything in terms of the base font size, then perhaps it would be better to use rem units.
| // @mattpap: So I think the 0.5 alpha value is to help this look good no | ||
| // matter what background color is used for the data viz, but this creates | ||
| // contrast issues when the background is dark, and text color of the | ||
| // attribution is also dark. Not sure what to do about this. Any thoughts? |
There was a problem hiding this comment.
Alpha is there to make it see through, so that the annotation doesn't obscure the underlying content too much. I'm not sure what's the best practice to improve contrast issues.
There was a problem hiding this comment.
Yeah, I understand why the alpha value is there. I'm just pointing out that it creates the potential for contrast issues that I'm not sure how to solve.
I wonder if there's a better way to implement attributions - specifically drawing it outside of the plot coordinates. I suppose that part of the point of having attribution happen within the plot coordinates is that it becomes more likely to be included if somebody tries to screenshot just the plot and then shares the screenshot — i.e., it's can function like a watermark for the plot.
I can also look into ways to solve this without changing the placement of attributions — maybe text-shadow will solve the contrast issues - not sure, I'll have to investigate.
| // @mattpap - I don't really like this style of inset focus ring | ||
| // but I guess this should be tackled in a separate PR? | ||
| outline-offset: -5px; |
There was a problem hiding this comment.
Yes, as we discussed in the meeting. In fact, please start an issue for this, so that we have a place to discuss possible improvements.
There was a problem hiding this comment.
| // to something with better contrast against the lightgray | ||
| // background color of the dialog header bar. Should we just | ||
| // change it now? | ||
| --bokeh-ctrl-color: var(--color); |
| // rather than use lighten/darken functions because in light | ||
| // mode we would need to darken but in dark mode we would need | ||
| // to lighten (I think) | ||
| background-color: darken(var(--background-color), 10%); |
There was a problem hiding this comment.
Also we can mix CSS variables with Less functions:
RuntimeError: Error evaluating function `darken`: Argument cannot be evaluated to a color in /home/runner/work/bokeh/bokeh/bokehjs/src/less/dropdown.less on line 42, column 25:
41 // to lighten (I think)
42 background-color: darken(var(--background-color), 10%);
43 }There was a problem hiding this comment.
We may be able to use color-mix() CSS function to replace lighten() and darken(), but even then it would be good to define lighter/darker variants somewhere. However, it looks like #14415 provides enough shades to cover these cases.
| --block-start-border-width: 3px; | ||
|
|
||
| --close-icon-hover-background-color: var(--error); | ||
| // Should these dimensions be px or rem? |
There was a problem hiding this comment.
For now we should keep pixels, but eventually replace them with relative units. Can you start an issue for this?
There was a problem hiding this comment.
| position: absolute; | ||
| background-color: white; | ||
| background-color: var(--background-color); | ||
| // @matpapp - why are these commented out? |
There was a problem hiding this comment.
This should have been removed. Originally Panel was meant to be one thing, but ended up being a different kind of component, for which setting default borders and padding doesn't make sense.
| // @mattpap - these colors should probably be parameterized | ||
| // but I think this is pretty much only used by the examiner, | ||
| // so maybe not high enough priority to fix? | ||
| .bk-nullish { color: #7724c1; } | ||
| .bk-token { color: #881280; } | ||
| .bk-boolean { color: #007500; } |
There was a problem hiding this comment.
You can leave them out for now. These are specific to pretty printing models, properties and values, used primarily in examiner component for the time being.
| background-color: #5f6368; | ||
| // @mattpap - same here, we might need something like "muted color" | ||
| background-color: var(--muted-color); |
There was a problem hiding this comment.
That should probably be just icon color. Looking at the following lines, this may predate SVG images, so I will definitely want this to get migrated to use icons, so everything else, including relevant colors, will be inherited.
There was a problem hiding this comment.
That creates low contrast with the background (2.5:1), so I'd rather not change it to match --icon-color.
| // @mattpap - I couldn't find a good substitute for this color from the colors | ||
| // already defined in base.less. We might need something like "muted | ||
| // background color" | ||
| background-color: var(--muted-bg-color); | ||
| border-color: var(--border-color); |
There was a problem hiding this comment.
This should use the "default" gray (like of widgets' background). The muted appearance comes from opacity: 0.6 for non-dirty properties and if dirty it reverts to 1.0.
There was a problem hiding this comment.
.prop > * {
opacity: 0.6;
}
.prop.dirty > * {
opacity: 1.0;
}| // attribution is also dark. Not sure what to do about this. Any thoughts? | ||
| background-color: rgba(255, 255, 255, 0.5); | ||
| font-size: 9px; | ||
| font-size: 0.5625rem; // 9px if base font is 16px |
There was a problem hiding this comment.
How would I do that?
If I set this to:
font-size: 56.25%;I believe that means 56.25% of the font size of the element's parent. And the element's parent may have a different font size than the base font, right? So we need to use rem to specify this as a percentage of the base font, unless I'm misunderstanding something.
| // @mattpap - I don't really like this style of inset focus ring | ||
| // but I guess this should be tackled in a separate PR? | ||
| outline-offset: -5px; |
There was a problem hiding this comment.
| --block-start-border-width: 3px; | ||
|
|
||
| --close-icon-hover-background-color: var(--error); | ||
| // Should these dimensions be px or rem? |
There was a problem hiding this comment.
| // @mattpap: So I think the 0.5 alpha value is to help this look good no | ||
| // matter what background color is used for the data viz, but this creates | ||
| // contrast issues when the background is dark, and text color of the | ||
| // attribution is also dark. Not sure what to do about this. Any thoughts? |
There was a problem hiding this comment.
Yeah, I understand why the alpha value is there. I'm just pointing out that it creates the potential for contrast issues that I'm not sure how to solve.
I wonder if there's a better way to implement attributions - specifically drawing it outside of the plot coordinates. I suppose that part of the point of having attribution happen within the plot coordinates is that it becomes more likely to be included if somebody tries to screenshot just the plot and then shares the screenshot — i.e., it's can function like a watermark for the plot.
I can also look into ways to solve this without changing the placement of attributions — maybe text-shadow will solve the contrast issues - not sure, I'll have to investigate.
|
|
||
| --bokeh-top-level: 10000; // used for z-index of menus, dropdowns, etc. | ||
|
|
||
| --color: #2f2f2f; |
There was a problem hiding this comment.
Got this off-black color from tooltip text. Eventually, will pull in the gray-900 from #14415.
In this PR, everywhere that was using pure black for text color, I replace with this off-black via var(--color).
| --disabled-background-color: #eee; | ||
|
|
||
| --input-focus-border-color: #66afe9; // rgb(102, 175, 233) | ||
| --input-focus-halo-color: rgba(102, 175, 233, 0.6); // fade(#66afe9, 60%) |
There was a problem hiding this comment.
The set of variables in this file (base.less) is almost exhaustive with respect to this PR but not quite. In particular, in buttons.less and tables.less, there are a number of variables defined in those two files that I chose not to hoist up to this file for now.
The way I see it, in the next PR, I will define all of the colors from #14415 in base.less and use them in buttons.less and other places.
| gap: 1em; | ||
| padding: 5px; | ||
| background-color: lightgray; | ||
| background-color: var(--border-color); |
There was a problem hiding this comment.
As I review my own code, I notice that it looks odd to to set background-color to var(--border-color). However, one could think of the dialog header as a very thick border. But maybe this should be hoisted up at least to the top of the file (as --bokeh-header-bg-color), maybe to base.less. What do you think?
| --block-start-border-width: 3px; | ||
|
|
||
| --close-icon-hover-background-color: var(--error); | ||
| // Should these dimensions be px or rem? |
|
This looks good. It doesn't seem to be breaking anything. Baseline changes are trivial (need updating). |
|
I updated all of the image snapshots and removed all of the "@mattpap" comments or replaced them with "TODO" comments. |
mattpap
left a comment
There was a problem hiding this comment.
This looks good as the first iteration. No major changes in baseline images.
|
Thanks @mattpap I'll merge this into branch-3.8 after the sync on Wednesday |
That's a good idea. I was going to suggest anyway, to not merge immediately and give other time to process this, especially given that this was marked as |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |


Closes #14177