Repository navigation
fix(core): dark-surface colors for links, h6, code and mark (#23) - #24
Merged
Merged
Conversation
On a dark Theme only the default text color followed the theme; the built-in link (#1976D2), h6 (#6B7280) and pre>code (#0550AE) colors measured 4.1, 3.9 and 2.5:1 against #121212, and the inline code / mark chips were bright light blocks on a dark page. StyleResolver.darkSurface swaps those UA colors for variants that keep >= 4.5:1 (link 8.5, h6 7.4, pre code 9.6 on #121212; code 7.2 and mark 6.9 on their own dark chips). HyperViewer enables it when the effective default text color is light, i.e. judged by the text color rather than the Theme: a dark Theme with a dark textColor (a white pane) keeps the light-surface palette, a light Theme with a light textColor gets the dark one. Off by default, so light output is unchanged. Author CSS and inline styles are applied after and still win; an <a> without href is untouched. Tests (test/dark_ua_colors_test.dart): contrast of the resolved style per element on page and card surfaces, the exact light palette, the white-pane and dark-pane cases, toggles, author CSS precedence, the compute() isolate path, markdown, and a pixel test. Mutation-checked.
Contributor
|
| Fixture | Budget (ms) | Median (ms) | P95 (ms) | |
|---|---|---|---|---|
| ❌ | simple_paragraph |
8 | 16 | 29 |
| ❌ | mixed_inline |
10 | 14 | 14 |
| ❌ | float_layout |
12 | 14 | 27 |
| ❌ | table_20_rows |
14 | 42 | 61 |
| ✅ | cjk_ruby |
14 | 9 | 11 |
| ❌ | large_article |
16 | 33 | 63 |
One or more fixtures exceeded the 16 ms budget.
Flutter
3.41.5· ubuntu-22.04
Informational, does not block merge: CI runners use software
rendering and are 2-3x slower than the devices the budgets are
calibrated for. Compare against the base branch; if a fixture
regressed relative to it, profile with:
flutter test benchmark/layout_regression.dart --reporter expandedand check _performLineLayout / _buildCharacterMapping for
any new O(N²) or O(N log N) paths introduced in this PR.
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.
Fixes #23.
Problem
In 1.11.0 only the default text color followed a dark
Theme. The built-in link,<h6>and<pre><code>colors were still light-surface constants, measuring 4.1 / 3.9 / 2.5 : 1 against#121212(<pre><code>fails even the 3:1 large-text bar), and the inline<code>/<mark>chips were bright blocks on a dark page.Change
StyleResolver.darkSurface(defaultfalse) swaps those UA colors for dark-surface variants, applied right after the UA style so author CSS and inline styles still win. An<a>withouthrefis untouched.#64B5F6#121212, 7.5 on#1E1E1E<h6>#9CA3AF<pre><code>#79C0FF<code>#79C0FFon#262C36<mark>#FDE68Aon#5C4A00HyperViewerturns it on when the effective default text color is light, not when the theme is dark. That choice matters: the migration guide tells people to usetextColor: Colors.black87for a white pane inside a dark app, and a theme-based switch would put light blue links on white. LightTheme+ lighttextColor(a dark pane) gets the dark palette. Light output is unchanged.Not touched:
<blockquote>,<kbd>, table headers keep their light backgrounds (their text stays readable via the 1.11.0 contrast guard; they remain light blocks on a dark page). Documented in the README and CHANGELOG; say if you want that as a follow-up.Verification
test/dark_ua_colors_test.dart: per-element contrast on page and card surfaces; the exact light palette; the white-pane and dark-pane cases; theme toggle; author CSS / inline precedence; thecompute()isolate path; markdown; one pixel test.mainlocally). Light-mode pixels must be unchanged.