BetterToolTips: Add option to visually differentiate hidden item attributes

[TheOne-Player]

Describe the feature

Summary
Currently BetterToolTips can reveal hidden tooltips and tooltip components (hidden attributes, hidden enchants, etc.), but there's no way to visually distinguish those hidden fields from normal/visible fields. This makes it hard for developers and users who rely on hiding data to tell which attributes were originally hidden vs. visible.

Why this matters

• Game devs sometimes hide attributes for gameplay or aesthetic/balance reasons, but still need to inspect them during debugging or testing. If hidden and visible attributes are shown with identical styling, it's easy to misread or accidentally expose data as "visible".
• UX clarity: end users and testers should be able to tell at a glance which fields are hidden metadata.
• Accessibility: the differentiation should be usable for colorblind users and screen readers.

Desired behavior
Add a configurable, toggleable way to visually distinguish hidden fields shown by BetterToolTips while preserving the existing functionality to display them. The feature should be optional (off by default), and provide at least one accessible visual differentiation.

Proposed implementation (preferred)

1. Settings
   • Add an option under BetterToolTips settings:
     • "Tooltip", and "Tooltip Components" within the Hide Flags Category (boolean) — existing behavior remains.
     • "Highlight hidden fields" (boolean) — when enabled, visually differentiates hidden fields.
     • "Hidden field style" (options) — color picker + text style (italic, dim, prefix icon) or “use custom CSS”.
2. Visual treatment
   • Default: Render hidden fields using a configurable color + slightly dimmed text (e.g., 70% opacity) and an optional small icon or prefix like "Hidden •".
   • Accessibility: Do not rely on color alone — also add an explicit label/prefix or a small tag (e.g., [hidden]) and expose the property in the element for screen readers.
   • Preserve attribute order — styling only, do not move hidden attributes below visible ones. This avoids disrupting the perceived order of how attributes were added to the item.
3. Advanced / alternative
   • Separator approach: show a "Hidden Tooltips" heading and list hidden Tooltips/tooltip components under it. This is more disruptive and reorders the list, which may be undesirable when attribute order matters.
   • Allow custom CSS or theming for power users.

Acceptance criteria

• New toggle(s) appear in BetterToolTips settings.
• When enabled, hidden fields are visually distinct (color + label/icon or style) while keeping the same order.
• There's an option to customize color/style and a non-color indicator (label or icon) for accessibility.
• Default behavior remains unchanged unless user enables the feature.
• Works across the major UI themes (dark/light) with sensible default color choices and sufficient contrast.

Implementation notes

• If hidden-state is already available in the item data (a flag), simply apply styling to fields with that flag.
• If not, determine how BetterToolTips currently identifies hidden fields and reuse that logic to add a CSS class (e.g., .btt-hidden-attribute) so users can override it via theme/CSS.
• Consider exposing the aria-label attribute for screen readers: e.g., aria-label="Attack Damage: +5 (hidden)".

Examples / mockups

• Inline label: "+5 Attack Damage [hidden]" (text color: #9ec5ff, opacity: 0.9)
• Icon + dim: "🔒 +5 Attack Damage" with color + opacity and title="Hidden attribute"

Before submitting a suggestion

• This feature doesn't already exist in the client. (I have checked every module and their settings on the latest dev build)

• This wasn't already suggested. (I have searched suggestions on GitHub and read the FAQ)

[Frko5000]

So u wrote the whole thing?

[TheOne-Player]

So u wrote the whole thing?

I basically got the general gist of the change we needed (after I noticed I couldn't tell apart between hidden and visible tooltips while I was making equipment for an adventure map), I then asked github copilot to rewrite the issue in a way that made it easier for contributos/developers to implement this.

[Frko5000]

Ah alright ill check this tomorrow