Skip to content

fix(transcript): make tool cards visually distinct without hover#2948

Merged
2 commits merged into
nesquena:masterfrom
Sanjays2402:fix/2867-tool-output-distinct
May 26, 2026
Merged

fix(transcript): make tool cards visually distinct without hover#2948
2 commits merged into
nesquena:masterfrom
Sanjays2402:fix/2867-tool-output-distinct

Conversation

@Sanjays2402

Copy link
Copy Markdown
Contributor

The tool-card border was so faint at rest that the cards melted into surrounding assistant prose once the cursor left the conversation. Issue #2867 reports the same thing: distinction only on hover, not at rest.

This bumps the resting border to --border-muted and adds a 2px left edge. Hover still escalates to --border2. No layout change, no DOM change, no JS.

Verified locally: loaded a session with mixed tool calls + final answer on the light theme. Tool cards are now identifiable at a glance, not just on hover. Re-checked the dark theme and the sienna/catppuccin/hepburn skins (which already override .tool-card with their own border-color) — those skins keep their existing behavior because their override has higher specificity.

Refs #2867

The tool-card border-subtle was so faint that the cards visually melted
into the surrounding prose once the cursor left the conversation. Bumps
the resting border to --border-muted and adds a 2px left edge so a tool
output row reads as metadata at a glance, even on light skins where
border-subtle is barely visible. Hover still escalates to --border2.

Verified by loading a session with mixed tool calls and assistant prose
on the light theme and confirming the tool cards are now identifiable
without mousing over them.

Refs nesquena#2867
@nesquena-hermes

Copy link
Copy Markdown
Collaborator

Summary

Thanks for the patch @Sanjays2402 — the resting-state contrast bump is exactly the shape #2867 was asking for, and the choice to escalate on hover rather than abandon hover entirely is a nice touch. I read the diff (CHANGELOG.md + static/style.css:2408-2409) end-to-end and pulled the PR worktree.

There is one concrete regression I want to flag before this lands: the new border-left on .tool-card overrides the subagent indicator.

Code reference

The existing subagent indicator at static/style.css:2324-2325:

/* Subagent cards: indented with accent border */
.tool-card-subagent{border-left:2px solid var(--accent-bg);margin-left:8px;}

That class is applied in static/ui.js:6721-6723 whenever a tool call is a subagent step:

const isSubagent=tc.name==='subagent_progress';
const cardClass='tool-card'+(tc.done===false?' tool-card-running':'')
                +(isSubagent?' tool-card-subagent':'');

The PR's new rule at static/style.css:2408 is:

.tool-card{background:var(--surface-subtle);border:1px solid var(--border-muted);
           border-left:2px solid var(--border-muted);border-radius:var(--radius-card);...}

Both selectors have specificity (0,1,0), so source order wins. .tool-card-subagent is at line 2325, the new .tool-card rule is at line 2408 — later. That means for a subagent card, .tool-card's border-left: 2px solid var(--border-muted) overrides .tool-card-subagent's border-left: 2px solid var(--accent-bg), and the accent-colored "this is a subagent" stripe disappears. The margin-left:8px; indentation survives, but the visual cue contributors rely on to tell subagent calls apart from main-agent tool calls is gone.

Diagnosis / Recommendation

Two equally cheap fixes — pick whichever you prefer:

Option A — bump the subagent selector's specificity:

.tool-card.tool-card-subagent{border-left:2px solid var(--accent-bg);margin-left:8px;}

That moves it to specificity (0,2,0) and wins over the plain .tool-card rule regardless of source order.

Option B — move the existing .tool-card-subagent rule below the new .tool-card rule (i.e. relocate it from ~line 2325 to just after the .tool-card-running block around line 2410). Source order alone then wins.

Option A is the more robust one — if anyone later adds another .tool-card border-left override above it, A still wins where B would break again.

While you're in there: please also verify the .tool-card-running state still reads as "running" on the new resting border. .tool-card-running only sets border-color (not border-left), so the left edge in the running state will pick up --accent-bg-strong from the cascade — should be fine, but worth a screenshot in the PR description alongside the rest, since you already have the test setup loaded.

Test plan

After the fix:

  1. Load a session that has both a regular tool call and a subagent step (anything that triggers delegate_task will produce subagent_progress rows).
  2. Confirm regular tool cards show the new muted left edge.
  3. Confirm subagent cards show the accent-colored left edge (the existing visual indent).
  4. Hover one of each — both should escalate to --border2 on the non-left edges without disturbing the left stripe.
  5. Spot-check the four skins with their own .tool-card overrides (sienna at L162-169, catppuccin L217-222, hepburn L259-265, geist-contrast L393+ with !important). Sienna/catppuccin/hepburn don't override border-left so they will pick up the new rule too — likely fine, but worth a quick look. Geist-contrast uses border:none!important; so it's unaffected.

LGTM otherwise — small, contained, no DOM or JS change, and the CHANGELOG entry is well-scoped.

@Sanjays2402

Copy link
Copy Markdown
Contributor Author

Good catch on the cascade collision, fixed in 6dd6bce. Went with Option A (.tool-card.tool-card-subagent at 0,2,0) so future .tool-card border-left overrides keep losing to the subagent accent.

@nesquena-hermes

Copy link
Copy Markdown
Collaborator

Merged in Release DJ / v0.51.138 (stage-batch20 — 7-PR ultra-safe batch with PRs #2948 #2949 #2950 #2960 #2972 #2975 #2982).

Thanks @Sanjays2402! 🚢

franksong2702 pushed a commit to franksong2702/hermes-webui-fork that referenced this pull request May 27, 2026
# Conflicts:
#	CHANGELOG.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants