I recently upgraded from 2.1.54 to 2.1.60. This update includes the smaller top toolbar during reviews which hovers above the card.
My cards were styled with a background image applied to my .card class, and a transparent background applied to #qa. Here’s how it looks in Anki’s editor:
However, the top toolbar is coded as a separate webview (no idea if this is the right word, sorry), and it looks like it only copies the background property from my .card styles and pastes it as inline CSS. So the transparent overlay is missing:
It doesn’t seem I can target this view’s CSS in the editor, either.
I can fix this with some hacky CSS to apply a color over the background image in the .card class styles. However, this feels like an issue with Anki itself that should be fixed, since the card in the editor window should really reflect what it looks like when reviewing, no?
It’s been a separate webview since I started using Anki, which is a few years back. It only became more apparent with the background “chameleon-effect”, which is not perfect yet (and probably won’t be until we unify the webviews). The bottom bar is a separate webview too, btw.
The major challenge we need to overcome is preventing templates from messing with the UI and JS-Python bridge. But we’ll find a way (-> ShadowRoot).
Probably the fastest solution for now would be to apply the darkening effect directly to the image and then re-save it, which should result in it appearing the same up the top.
When I implemented the dynamic toolbar background, I had two choices:
Programmatically take a screenshot of the uppermost part of the card and use that as background for the toolbar widget
Copy the background CSS property to the toolbar and create a seamless transition by offsetting the main webview’s background
Qt isn’t the most flexible framework for graphical stuff and the first approach had several drawbacks. A major one was that you cannot use backdrop-filter: blur on toolbar elements and expect it to work if the background is set on the Qt widget which contains the webview.
I decided to go for the CSS approach. Looking forward, it seemed like the much better option. E.g. I’m currently working on a global background setting that uses the CSS background property - and it essentially uses the same approach without adding much complexity (I’ll publish that PR within the next few days).
If I can find a good way to achieve what you want with CSS, I’ll surely include that in the PR. But if not, I don’t think it is too much to ask deck developers to apply their background to the .card (=body) in order to make the toolbar work. The upcoming PR also adds a blur effect to the complete toolbar area, so it will make the issue you described above a bit less jarring.
