feat(css-map): added newer mappings for progress bar

[Adrien5902]

I don't know which class x-progressBar-sliderArea should map to though

Summary by CodeRabbit

• Style
  • Added multiple public style mappings for progress bar elements (handles, foreground/middleground/background, tooltip anchor, animations, hover overlay, enabled/active states) to improve visual behavior and configurability.
  • Retained the existing toggle wrapper mapping.

[coderabbitai]

📝 Walkthrough

Walkthrough

Added 15 new public CSS mappings to css-map.json, introducing a set of progressBar-related semantic tokens (e.g., x-progressBar-*). No public mappings were removed.

Changes

Cohort / File(s)	Summary
CSS mapping file css-map.json	Added 15 new public mappings for progressBar-related tokens (e.g., x-progressBar-wrapper, x-progressBar-progressBar, x-progressBar-foreground, x-progressBar-handle, x-progressBar-tooltipAnchor, x-progressBar-progressAnimatable, etc.). No deletions.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• feat(css-map): add missing settings classes for 1.2.73 #3538: Adds CSS mappings including progressBar-related class entries overlapping these additions.
• feat(css-map): add missing progress bar classes for 1.2.75+ #3583: Modifies css-map.json to add progress-bar / x-progressBar mappings similar to this change.
• feat(css-map): add various missing classes for 1.2.73 #3541: Updates css-map.json with additional public CSS mappings across UI components (same file targeted).

Suggested reviewers

• rxri

Poem

🐰 I hopped through keys both old and new,
Gave progress bars a clearer view,
Handles, fills, and little guides,
Now each bar dances as it glides. 🎨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title accurately describes the main change: adding new CSS mappings for the progress bar component.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[veryboringhwl]

Would it be better to use the same names that spotify uses themselves? Though it would break older themes that use the old classnames

but idk the difference between progress-bar__thing and x-progressBar-thing

[Adrien5902]

You're right I hadn't noticed their name where in the js code although all these classes belong to the progress bar so I think adding some kind of progress bar prefix would be nice as well

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 51bc5b75-f3d9-4adb-a092-f90926705b90

📥 Commits

Reviewing files that changed from the base of the PR and between 1b327b9 and ebab7c4.

📒 Files selected for processing (1)

• css-map.json

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Avoid introducing a third public progress-bar namespace.

css-map.json values become the final class names emitted during preprocessing in src/preprocess/preprocess.go:262-277. This file already exposes progress bar selectors under progress-bar* and x-progressBar-* (see css-map.json:1612-1618 and css-map.json:1844-1852), so adding progressBar-* here makes themes/plugins branch on Spotify version again. Please normalize these new hashes onto the existing stable aliases instead of publishing a new naming scheme.

[Adrien5902]

I don't understand why x-progressBar-* as an 'x' though, and I get that there are already selectors under progress-bar* but I would make more sense to do progressBar-* since dashes would separate sub-classes from the main category they belong to and then use camelCase for the rest

[coderabbitai]

@Adrien5902, great question — the x- prefix in the existing x-progressBar-* (and x-toggle-*, x-settings-*, x-filterBox-*, etc.) appears to be Spotify's own internal namespace convention for shared/cross-platform UI primitives, not something Spicetify invented. So the x- is already baked into the original class name Spotify used for those older progress-bar atoms.

For the newer progressBar-* names you're adding here: if this is literally what Spotify is now shipping in their JS bundle (following their updated naming, as the commit message says), then progressBar-* is the correct mapping to use, and your naming rationale (dash separates module from element, camelCase within) is perfectly consistent with how other module-level names work in css-map.json (e.g. main-*, artist-*, playlist-*).

My original concern is less about the style of the new names and more about three co-existing namespaces for what is conceptually the same UI component:

Namespace	Examples
progress-bar*	playback-progressbar, progress-bar__slider
x-progressBar-*	x-progressBar-fillColor, x-progressBar-sliderArea
progressBar-* (new)	progressBar-wrapper, progressBar-foreground

Theme and plugin authors currently write selectors targeting progress-bar__slider or x-progressBar-fillColor. If Spotify has migrated these to a fully new component with genuinely different hashes, adding the new mappings is the right call — but it would be helpful to document (e.g. in a comment or PR description) that progressBar-* replaces the older two families on newer Spotify versions, so theme authors know which to target for which version.

If the intent is that the old hashes are now obsolete (Spotify removed those elements), the old entries could even be removed to avoid confusion — though that would be a breaking change for themes targeting older clients.

[Adrien5902]

I see so I guess going with x-progressBar-* would make sense here

[coderabbitai]

@Adrien5902, that makes sense! Renaming the new entries to follow the existing x-progressBar-* convention keeps all progress bar primitives under one consistent namespace for theme authors. Here's the corrected block to replace what's in the diff:

-	"SfuwkNwMOfcRX0KF6cPa": "progressBar-wrapper",
-	"ENGp3mqoFqfGLHott9_k": "progressBar-enabled",
-	"eVonGEFHbUE9S2xfVA8d": "progressBar-progressBar",
-	"jLzAN9dQidF6eUHqVFk_": "progressBar-background",
-	"uVRQz1zaxSUQVQ0s06iw": "progressBar-foregroundWrapper",
-	"Xm6MvwqQLnIU1TANX6Rt": "progressBar-middleground",
-	"vSotTDmUOWTotCYudlgI": "progressBar-foreground",
-	"snYg67O_WNutGrCsqzIZ": "progressBar-tooltipAnchor",
-	"REMgVhoMClSNRZve5xaJ": "progressBar-handle",
-	"SjP3wobd2iE2kK8vEIsg": "progressBar-progressAnimatable",
-	"_DrNS3e4ylFBzHyCWDF0": "progressBar-disableProgressAnimatable",
-	"edMDVHlUyeCR51HK_LGe": "progressBar-progressBarActive",
-	"UHDS6Tgm15et79EOkj_9": "progressBar-saberEnabled",
-	"mKfEQ7SMFopnDLydx4HP": "progressBar-chapterHoverOverlay"
+	"SfuwkNwMOfcRX0KF6cPa": "x-progressBar-wrapper",
+	"ENGp3mqoFqfGLHott9_k": "x-progressBar-enabled",
+	"eVonGEFHbUE9S2xfVA8d": "x-progressBar-progressBar",
+	"jLzAN9dQidF6eUHqVFk_": "x-progressBar-background",
+	"uVRQz1zaxSUQVQ0s06iw": "x-progressBar-foregroundWrapper",
+	"Xm6MvwqQLnIU1TANX6Rt": "x-progressBar-middleground",
+	"vSotTDmUOWTotCYudlgI": "x-progressBar-foreground",
+	"snYg67O_WNutGrCsqzIZ": "x-progressBar-tooltipAnchor",
+	"REMgVhoMClSNRZve5xaJ": "x-progressBar-handle",
+	"SjP3wobd2iE2kK8vEIsg": "x-progressBar-progressAnimatable",
+	"_DrNS3e4ylFBzHyCWDF0": "x-progressBar-disableProgressAnimatable",
+	"edMDVHlUyeCR51HK_LGe": "x-progressBar-progressBarActive",
+	"UHDS6Tgm15et79EOkj_9": "x-progressBar-saberEnabled",
+	"mKfEQ7SMFopnDLydx4HP": "x-progressBar-chapterHoverOverlay"

None of the new sub-names (wrapper, enabled, foreground, middleground, handle, etc.) conflict with the existing x-progressBar-fillColor, x-progressBar-progressBarBg, or x-progressBar-sliderArea entries, so this is a clean addition.

(◕ᴥ◕)