Surfaced while hand-consuming buildPaletteCss() output in a framework-free Astro site. Not urgent, and not fixable inside 1.x — filing so it's on the record for a major.
The split
Of the 197 variables buildPaletteCss() emits, 165 are kebab-case and 32 are camelCase:
--vx-accentHover --vx-accentFill --vx-accentFillHover --vx-onAccent
--vx-goodSoft --vx-goodRef --vx-badRef --vx-warnRef
--vx-goodSolid --vx-badSolid --vx-warnSolid
--vx-axisStroke --vx-dotStroke --vx-legendText
--vx-tooltipBg --vx-tooltipText --vx-tooltipMuted
--vx-tooltipBorder --vx-tooltipShadow
--vx-fillHover-{gray,red,pink,grape,violet,indigo,cyan,teal,green,lime,yellow,orange}
--vx-surface-panelHover
It isn't a clean partition by category — it's hybrid within a family:
| kebab |
camel |
same family |
--vx-fill-gray |
--vx-fillHover-gray |
fills |
--vx-surface-border |
--vx-surface-panelHover |
surfaces |
--vx-status-good |
--vx-goodSolid |
status |
Why it matters more now than it did
Inside a React consumer nobody types these — you use VX.accentFill and the JS map is uniformly camelCase, which is correct for JS. The names were an implementation detail.
1.3.0 changes that. dist/tokens.css and tokens:css make the emitted stylesheet a supported product, and docs/FRAMEWORK-FREE.md invites consumers to write CSS against these names by hand. At that point the names are the public API, and a consumer has to remember which side of the split each token falls on — with no rule to derive it from, since neither the category nor the prefix predicts it.
CSS custom properties conventionally follow the CSS property convention (kebab), which is also what the majority here already does.
Suggested resolution
Normalise to kebab in a major, with the camelCase spellings kept as aliases for one minor cycle so consumers get a deprecation window rather than a silent miss (an unknown custom property doesn't error, it just resolves to nothing — which makes this exact class of rename unusually easy to get wrong).
No action wanted in 1.x.
Surfaced while hand-consuming
buildPaletteCss()output in a framework-free Astro site. Not urgent, and not fixable inside 1.x — filing so it's on the record for a major.The split
Of the 197 variables
buildPaletteCss()emits, 165 are kebab-case and 32 are camelCase:It isn't a clean partition by category — it's hybrid within a family:
--vx-fill-gray--vx-fillHover-gray--vx-surface-border--vx-surface-panelHover--vx-status-good--vx-goodSolidWhy it matters more now than it did
Inside a React consumer nobody types these — you use
VX.accentFilland the JS map is uniformly camelCase, which is correct for JS. The names were an implementation detail.1.3.0 changes that.
dist/tokens.cssandtokens:cssmake the emitted stylesheet a supported product, anddocs/FRAMEWORK-FREE.mdinvites consumers to write CSS against these names by hand. At that point the names are the public API, and a consumer has to remember which side of the split each token falls on — with no rule to derive it from, since neither the category nor the prefix predicts it.CSS custom properties conventionally follow the CSS property convention (kebab), which is also what the majority here already does.
Suggested resolution
Normalise to kebab in a major, with the camelCase spellings kept as aliases for one minor cycle so consumers get a deprecation window rather than a silent miss (an unknown custom property doesn't error, it just resolves to nothing — which makes this exact class of rename unusually easy to get wrong).
No action wanted in 1.x.