UX Bug: TableNameButton lacks distinct hover state when already active

[MH4GF]

Self Checks

• [x] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [x] I have searched for existing issues search for existing issues, including closed ones.

Version Type

Web Version (liambx.com)

Steps to reproduce

1. Open any ERD in the web application
2. Notice a table is highlighted in the left pane (active state)
3. Hover over the already highlighted table name button
4. Observe that the hover color is the same as the active highlight color

https://github.com/user-attachments/assets/e57e2f43-133c-43c9-b36c-f269560a27d8

Expected Behavior

When hovering over an already actively highlighted table name in the LeftPane, it should show a different background color than the regular active state. This provides better visual feedback to the user that the element is both active AND being hovered.

Actual Behavior

Currently when hovering over an already highlighted (active) table name, there is no visual distinction between the hover state and the active state. The hover effect uses the same background color as the active state, which creates a confusing user experience.

Additional Context

The issue is in the TableNameMenuButton component located at: frontend/packages/erd-core/src/features/erd/components/ERDRenderer/LeftPane/TableNameMenuButton/

In TableNameMenuButton.module.css, we have:

.active {
  background: linear-gradient(
      0deg,
      var(--primary-accent-overlay) 0%,
      var(--primary-accent-overlay) 100%
    ), var(--pane-background-active);
}

However, there's no specific styling for the combined active+hover state.

Recommended fix: Add a new CSS class (e.g., .active:hover) with a slightly different background color to provide visual feedback when hovering over an already active item.

.active:hover {
  background: linear-gradient(
      0deg,
      var(--primary-accent-overlay-hover) 0%,
      var(--primary-accent-overlay-hover) 100%
    ), var(--pane-background-active-hover);
}

This would require adding the new CSS variables to the theme, but would significantly improve the user experience by providing clear visual feedback.

[MH4GF]

@kumanoayumi What do you think? Is this an omission in the implementation?

[kumanoayumi]

@MH4GF Yes, it seems like there's an omission in the implementation. I believe the following approach would be appropriate in this case.

Recommended fix: Add a new CSS class (e.g., .active:hover) with a slightly different background color to provide visual feedback when hovering over an already active item.

.active:hover {
  background: linear-gradient(
      0deg,
      var(--primary-accent-overlay-hover) 0%,
      var(--primary-accent-overlay-hover) 100%
    ), var(--pane-background-active-hover);
}

This would require adding the new CSS variables to the theme, but would significantly improve the user experience by providing clear visual feedback.

[MH4GF]

@kumanoayumi Thank you! I'll leave this issue open as a good first issue.

[khiroshi-win]

Could you please tell me what colors I can add to --primary-accent-overlay-hover and --pane-background-active-hover?

[kumanoayumi]

@khiroshi-win

Please use rgba(29, 237, 131, 0.20) for var(--primary-accent-overlay-hover). Also, sorry about the confusion — the background color of the underlying pane, var(--pane-background-active), can stay as it is :ok_woman:

.active:hover {
  background: linear-gradient(
      0deg,
      var(--primary-accent-overlay-hover) 0%,
      var(--primary-accent-overlay-hover) 100%
    ), var(--pane-background-active);
}

Design Preview (Figma Prototyping)

https://github.com/user-attachments/assets/ef39edbf-339e-45b8-be06-5ca24ec66a94

[khiroshi-win]

I updated the CSS and it works fine on my end. I pushed the updated code, so please review it again.