Let a selection show through an inline code chip
Selecting a sentence highlighted every word of it except the ones in backticks. An inline span's background is part of the text's own drawing and the selection rectangle is drawn underneath it, so an opaque chip hid the selection completely -- and there is no way to draw it over instead, since the order is the text node's. The chip's fill is 60% now: measured on the emulator, unselected it is #161622 against a #1E1E2E page, so it is still a clear step down, and selected it moves to #3C344F, which is the whole point. This is what Iris's screenshot was showing. A fenced block was never affected -- its background is on the box around the text rather than on spans, so the selection lands on top of it, which is why it looked fine when I went looking. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
1fc0f5c129
commit
aa6d9b256e
2 files changed
+18
-9
No files matched your search
@@ -5,14 +5,6 @@ one in place when it turns out to need a decision.
|
||||
|
||||
## App — transcript
|
||||
|
||||
- [ ] Text inside code blocks does not highlight when selected. **Measured, and
|
||||
it does** — the selection is drawn, but over the near-black surface a code
|
||||
block and a tool's output sit on, Material's default 40%-alpha tint
|
||||
composites to a barely-there smudge, much weaker than the same selection
|
||||
over a reply. The app now states its own selection colours
|
||||
(`AiAppSelectionColors`), which took the fill from #5B4C73 to #776394 on
|
||||
that surface. Worth confirming this was the complaint rather than a
|
||||
selection that draws *nothing* on the phone.
|
||||
- [ ] Messages received from other agents are inconsistent — sometimes they
|
||||
appear, sometimes they don't. **Needs a rig.** Read the code rather than
|
||||
measured: a live Claude session only learns of a peer message from the
|
||||
|
||||
@@ -368,7 +368,15 @@ private fun MarkdownRoot(
|
||||
// exactly a card's own fill, so a fenced block inside a tool call had no
|
||||
// background at all and one in a reply read as a step *up* out of the page.
|
||||
codeBackground = rawSurface,
|
||||
inlineCodeBackground = rawSurface,
|
||||
// The same colour, but let through. An inline span's background is part of the
|
||||
// *text's* own drawing and the selection rectangle is drawn underneath it, so an
|
||||
// opaque chip hides the selection completely: selecting a sentence highlighted
|
||||
// every word of it except the ones in backticks, which is a difference in
|
||||
// appearance the reader has no way to account for. Translucent, the selection
|
||||
// shows through and the chip still reads as one step down from the page -- there
|
||||
// is no way to draw it over the selection instead, since the order is the text
|
||||
// node's.
|
||||
inlineCodeBackground = rawSurface.copy(alpha = INLINE_CODE_ALPHA),
|
||||
// The same tint a code block gets, rather than the renderer's 2%-alpha default:
|
||||
// two adjacent tints that differ by a fiftieth read as one flat block on a phone,
|
||||
// so the table would have had a border-less grid and nothing saying where it began.
|
||||
@@ -711,3 +719,12 @@ class ParsedReplies {
|
||||
ready.clear()
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* How much of the inline-code chip's fill is its own colour, the rest being whatever it sits on.
|
||||
*
|
||||
* High enough that the chip is still a clear step down from the page, low enough that a selection
|
||||
* under it changes what the chip looks like. Both halves are the point: at 1.0 the chip was the
|
||||
* only part of a selected sentence that did not look selected.
|
||||
*/
|
||||
private const val INLINE_CODE_ALPHA = 0.6f
|
||||
Reference in new issue
Block a user