Turn the lamp down on a figure, rather than take its paper away - #71
Merged
Merged
Conversation
A figure carries its own white, inside the SVG, where no stylesheet reaches it. On a dark page that is a lit rectangle, and it was the one thing left bright after everything else followed the reader's choice. Taking the white away is not the fix it looks like: the axes, ticks and labels are dark ink, and without the paper behind them they would be dark on dark. That is the same reason `DRAWN_ON_WHITE` exists here — a document is drawn on white whatever the page around it is. So the page dims it instead. `brightness(.85)` makes the paper #d9d9d9. Measured at that value: inside the figure, ink/paper 14.9, axis/paper 7.2, a plotted line 4.4 — all still clear, a line being a graphical object that wants 3 rather than 4.5. Against the card it sits on, 12.3. Chosen by looking at 1.00 / 0.92 / 0.85 / 0.78 side by side on a real figure from the demo registry: 0.92 barely helps, 0.78 muddies the data. The rule rides in the derived dark sheet rather than the injected `<style>`, because that file is already gated by the `media` the control rewrites — so it applies exactly when dark does, and needs no guard of its own. Pinax says the same thing in its own stylesheet for reports rendered from now on; this is for every report frozen before that, which is all of them. A mitigation, not a fix. The fix is figures that are not drawn on white, and that belongs to whoever writes the report. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A figure carries its own white inside the SVG, where no stylesheet reaches it. On a dark page that is a lit rectangle — the one thing left bright after everything else followed the reader's choice.
Taking the white away is not the fix it looks like: the axes, ticks and labels are dark ink, and without the paper behind them they would be dark on dark. That is exactly why
DRAWN_ON_WHITEexists here. So the page dims it instead.Why 0.85
Chosen by looking at 1.00 / 0.92 / 0.85 / 0.78 side by side on a real figure from the demo registry — 0.92 barely helps, 0.78 muddies the data — and then checked:
brightness(.85)#ffffff→#d9d9d9Where the rule lives
In the derived dark sheet, not the injected
<style>: that file is already gated by themediaattribute the control rewrites, so it applies exactly when dark does and needs no guard of its own.Pinax says the same thing in its own stylesheet for reports rendered from here on (QAtlasHub/Pinax.jl#155). This is for every report frozen before that — which is all of them.
A mitigation, not a fix. The fix is figures that are not drawn on white, and that belongs to whoever writes the report.
Version 0.8.6 → 0.8.7.
🤖 Generated with Claude Code