I’m not sure if there is something that can be done here. I remember others mentioning it the past in previous betas. I’m not sure what the response was.
It is really difficult to work when working on a site with a dark background. Things like choosing a layout or finding the image icon on the preview are extremely difficult to see.
The image below is creating a new section and has the “Choose a layout” options in it…
I brought this up several times in the past. Alexander did provide the following CSS to make things a little better until they officially fix this issue:
:root {
--c-global-preview-receiving: rgba(255,255,255,.425);
}
Should be applied to Global CSS.
From this thread: Dark background
Thanks. I’ll add that.
Would be helpful if it was “fixed” though as I’m sure this is a pain point for new users, less experienced users or users using X.
Even just a toggle in theme preferences that switches the current CSS with this CSS would be helpful. That way we can choose.
But then what if you use both dark and light backgrounds on the same site? The best solution would be automatic detection of dark/light background colors and the UI adjusting accordingly.
A toggle like you suggest would be one step better than having to manually enter the CSS though, until something more robust is in place.
You are 100% correct. I suspect that would potentially be more complex.
We had contrast detection in at one point in Cornerstone (many years ago), but at least at the time, it was a huge performance drain on sites and slowed down the page building experience immensely. There might be something we could look into here again at some point, but getting in contrast detection isn’t something we’re planning on doing for this beta cycle.
That being said, try this bit of CSS instead:
:root {
--c-global-preview-receiving: rgba(128, 128, 128, 0.66);
}
The previous snippet you referenced is a pure white with alpha applied. This will work great on darker backgrounds, but is just the inverse of the problem brought up here initially. The color I’ve just given you is essentially the “most middle gray” in the color spectrum, with a slight amount of alpha applied so that it somewhat blends with the background. This will work for the vast majority of use-cases, and certainly works very well at the extremes of the spectrum:
I am going to go ahead and put this into the next release cycle for you all to play around with, but you can try it yourselves using the value I provided above. Again, this won’t solve absolutely every edge case…specifically if you’re happening to work on a very gray layout right in that range…but this should be a vast improvement for roughly 98% of the situations you find yourself in.
Additionally, try adding this:
:root {
--b-stripes: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4IiBoZWlnaHQ9IjgiPgogICAgPHBhdGggZD0iTS0yIDEwTDEwIC0yWk0xMCA2TDYgMTBaTS0yIDJMMiAtMiIgc3Ryb2tlPSJyZ2JhKDEyOCwgMTI4LCAxMjgsIDAuNjYpIiBzdHJva2Utd2lkdGg9IjIiPjwvcGF0aD4KICAgIDwvc3ZnPg==), url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMDAlIiBoZWlnaHQ9IjEwMCUiPgogICAgPGxpbmVhckdyYWRpZW50IGlkPSJnIiB4Mj0iMSIgeTI9IjEiPgogICAgPHN0b3Agc3RvcC1jb2xvcj0idHJhbnNwYXJlbnQiPjwvc3RvcD4KICAgIDxzdG9wIG9mZnNldD0iMTAwJSIgc3RvcC1jb2xvcj0idHJhbnNwYXJlbnQiPjwvc3RvcD4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8cmVjdCB3aWR0aD0iMTAwJSIgaGVpZ2h0PSIxMDAlIiBmaWxsPSJ1cmwoI2cpIj48L3JlY3Q+CiAgICA8L3N2Zz4=);
}
You might need an !important at the end of that…that deals with the interaction styles in the preview as you drag in an Element.
Again, these changes will be available in the next Beta, I am simply providing them here for you to test early if you would like.
Thanks!
If I knew what to target, I’d try the Photoshop’s blend mode of Difference, and see how it holds up.
In CSS, it is mix-blend-mode: difference;.
In PSD, I’m getting this:
The only area where it doesn’t work is the 50% gray. But that can be solved by using some color shade. It takes some time to tune it in.
Glad to hear it, @JvP!
@Misho, I actually tried using mix-blend-mode in addition to the color changes mentioned above, but the problem is that mix-blend-mode only works with blending an element with its immediate parent. Using this on the layout picker works great because it’s a direct child of the Section and if you change the Section background-color, the mix-blend-mode on the layout picker can respond to these changes.
Unfortunately, for other instances where the “receiving” color is applied, it is deeply nested within the markup and won’t always respond to changes up the tree.
For instance, if you have added 4 empty Columns to a Row, the empty Column styles are inside the Column itself, so if I put mix-blend-mode on that, it would only respond to color changes on the Row Element, but not the Section. I have some thoughts here, but they would require some bigger structural changes on how all of those styles are applied and it gets unwieldy very quick.
Thankfully, I think the “middle gray” technique provided above will help with 98% of the situations and be a very solid middle-ground for now.
In case anyone comes back to this thread, I thought I’d go ahead and provide a bit more context here regarding how mix-blend-mode works, as I uncovered some things while working on another reported issue from a user, that simply turned out to be a nuance of how CSS works. With regards to the --c-global-preview-receiving and --b-stripes changes mentioned above, this will still be the implemented fix for the issues brought up in this thread. Although my findings below show that we could use mix-blend-mode to create some more dynamic color contrasts for empty Columns, Cells, and Divs, upon further testing the method used above is simply more clear and concise with less outliers, and solves 99.9% of the situations as discussed. That being said, in case you desire to know more about how mix-blend-mode works and how you can get a deeply nested Element to blend with styling up the document tree, the following is a response I gave to another support staff member on our internal issue tracker. I’m simply pasting it here to provide a little insight on this matter.
Spent a while looking into this, because I was always under the assumption that mix-blend-mode only worked with its immediate parent. Upon further investigation, it seems that is not true, but there are some caveats. mix-blend-mode can work on a deeply nested Element all the way up the tree as long as a stacking context is not created. This can happen in a couple different ways:
z-index other than auto anywhere in the middle of the tree.transform anywhere in the middle of the tree.filter anywhere in the middle of the tree.backdrop-filter anywhere in the middle of the tree.opacity value of less than 1 anywhere in the middle of the tree.As long as none of this is happening throughout the tree on the way to the nested Element, it appears that mix-blend-mode should work in a situation like the one described above. The main issue I found with that scenario was that the Row’s z-index was set to 1 by default, which was a holdover from how we used to do things when the builder was first put together, but we’ve been slowly trying to remove unnecessary z-index declarations as they create tons of issues like this unless managed carefully.
To address this specific thread, I have made sure that the Row’s default z-index is set to auto moving forward, so as long as nothing in the list above is implemented, this should work for users moving forward.