summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-hub/src/meshbay_hub/static/style.css
diff options
context:
space:
mode:
Diffstat (limited to 'packages/meshbay-hub/src/meshbay_hub/static/style.css')
-rw-r--r--packages/meshbay-hub/src/meshbay_hub/static/style.css10
1 files changed, 10 insertions, 0 deletions
diff --git a/packages/meshbay-hub/src/meshbay_hub/static/style.css b/packages/meshbay-hub/src/meshbay_hub/static/style.css
index 5748b2d..f426f8d 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/style.css
+++ b/packages/meshbay-hub/src/meshbay_hub/static/style.css
@@ -58,6 +58,16 @@
the leftover from a pointer/touch interaction, never accessibility. */
:focus:not(:focus-visible) { outline: none; }
+/* A third, separate mechanism from :hover/:focus above, found live
+ 2026-08-26 (screenshots): Android Chrome's own tap-highlight flash —
+ never disabled anywhere in this file — filled a tapped round button
+ (music-player-btn's "next", which carries no state class at all) with a
+ solid colour that stayed until another element was tapped. Left at its
+ default, this shade is drawn from the OS accent colour on many Android
+ builds, which is why it read as "the app's own blue", not an obviously
+ foreign highlight. Unrelated to real hover/focus — safe to kill outright. */
+*, *::before, *::after { -webkit-tap-highlight-color: transparent; }
+
body {
font-family: system-ui, -apple-system, sans-serif;
background: var(--bg-base);