Repository navigation
feat(preset-wind4): add scrollbar width and color utilities - #5343
Conversation
✅ Deploy Preview for unocss ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
| ['scrollbar-thin', { 'scrollbar-width': 'thin' }], | ||
| ['scrollbar-none', { 'scrollbar-width': 'none' }], | ||
|
|
||
| [/^scrollbar-(thumb|track)-(.+)$/, function* ([, part, body], ctx) { |
There was a problem hiding this comment.
We also need to add parsing for the size.
There was a problem hiding this comment.
Happy to add it, but I want to check which "size" you mean, since the two readings pull the PR in quite different directions.
1. Sizes for the WebKit scrollbar parts, like unocss-preset-scrollbar's scrollbar-w-*, scrollbar-h-* and scrollbar-radius-* / scrollbar-(thumb|track)-radius-*. Those write --scrollbar-width / --scrollbar-height and apply them through ::-webkit-scrollbar selectors.
One thing to weigh if that's the intent: ::-webkit-scrollbar styling is ignored once the element has a standard scrollbar-width or scrollbar-color, which is what scrollbar-thin and scrollbar-thumb-* in this PR set. That's the reason the community preset gates the two behind its compatible option. So combining them in one preset means scrollbar-w-2 scrollbar-thin silently drops the width. In current UnoCSS the WebKit parts are also already reachable without new rules, e.g. [&::-webkit-scrollbar]:w-2.
2. A parsed value for scrollbar-width itself, replacing the three static rules with something like:
[/^scrollbar-(?:width-)?(.+)$/, ([, w], { theme }) => ({ 'scrollbar-width': h.bracket.cssvar.global(w) })]so scrollbar-[thin] and scrollbar-$my-width work alongside scrollbar-auto|thin|none. The property only accepts auto | thin | none per spec, so a length there is invalid CSS, and the pattern needs care not to shadow scrollbar-gutter-* or scrollbar-thumb-*.
My own preference is to keep this PR at Tailwind v4.3 parity (scrollbar-width keywords plus thumb/track colors) and do the WebKit part sizes as a follow-up, where the interaction above can be handled properly. But it's your call. Tell me which one you want and I'll push it.
There was a problem hiding this comment.
Added the size parsing in 67b718f: scrollbar-(w|h)-<length> and scrollbar-(track-|thumb-)?radius-*, following unocss-preset-scrollbar, applied to the ::-webkit-scrollbar* pseudo elements.
- Length parsing follows preset-wind4's value semantics:
scrollbar-w-4→calc(var(--spacing) * 4), while explicit units (scrollbar-w-2px), brackets (scrollbar-h-[3rem]) and cssvars (scrollbar-w-$var) pass through as-is. scrollbar-radius-*accepts theradiustheme (scrollbar-radius-sm→var(--radius-sm)) plusfull, and sets both thumb and track;scrollbar-(track|thumb)-radius-*targets a single part.- Since a rule can't retarget its own selector, the pseudo-element selectors come from a new
scrollbarvariant (variants/scrollbar.ts, same$-prefixed internal-rule pattern asplaceholder), so the utilities also compose with variants (md:scrollbar-w-4works).
That picks reading 1 from my earlier question. The standard-vs-WebKit interaction I mentioned still applies — WebKit part styling is ignored once standard scrollbar-width/scrollbar-color is set on the element — which is the same trade-off the community preset makes.
6b65708 to
0b5ed63
Compare
Add `scrollbar-(w|h)-*` and `scrollbar-(track-|thumb-)?radius-*` parsing following unocss-community/unocss-preset-scrollbar, applied to the `::-webkit-scrollbar*` pseudo elements. Length values follow preset-wind4 semantics (spacing scale, units, brackets, cssvars), radius values follow the `radius` theme. The pseudo-element selectors are applied by a new `scrollbar` variant using the same `$ `-prefixed internal-rule pattern as `placeholder`. Co-Authored-By: Claude Code <[email protected]>
|
The size parsing requested in the inline review is now present in the current head. The existing |
|
@zyyv the size parsing is in 67b718f. |
Thanks for submitting the update; I'll review it carefully later. |
|
commit: |
Description
Tailwind CSS v4.3 added
scrollbar-{auto,thin,none}andscrollbar-thumb-*/scrollbar-track-*(tailwindlabs/tailwindcss#19981, #20019).preset-wind4already has thescrollbar-gutter-*utilities from the same release (#5224), but not these. This PR adds them torules/scrolls.ts.scrollbar-auto/scrollbar-thin/scrollbar-nonesetscrollbar-width.scrollbar-thumb-<color>/scrollbar-track-<color>set--un-scrollbar-thumb/--un-scrollbar-trackandscrollbar-color: var(--un-scrollbar-thumb) var(--un-scrollbar-track). This matches Tailwind's output. Both variables are registered with@property(<color>, initial value#0000) and get the usual properties-layer fallback, the same as Tailwind's--tw-scrollbar-*. That way, setting only one of the two still gives a validscrollbar-color.colorResolver, so theme colors,/50alpha, arbitrary values,$varandcurrent/transparent/inheritall work. There are alsoscrollbar-(thumb|track)-op-<n>rules, like the other wind4 color utilities (accent-op-*,caret-op-*,ring-op-*).Notes:
scrollbar-apart fromscrollbar-gutter-*, and those still work. The communityunocss-preset-scrollbarusesscrollbar-(thumb|track)-color-*and-radius-*. Neither of those parses as a color, so these new rules don't match them. Itsscrollbar-thin/scrollbar-noneemit the samescrollbar-widthdeclaration.scrollbar-(thumb|track)-$colorsand the opacity variants.Tests
test/assets/preset-wind4-targets.ts. The regenerated snapshot only changes for the new entries.test/preset-wind4.test.tsthat covers the@propertyoutput and the preflight fallback.pnpm build, thenpnpm vitest run: 100 files, 731 passed / 3 skipped.tsgo --noEmitpasses, andeslinton the changed files passes.This PR was written with help from Claude Code, and I reviewed it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01QBWFWqjbUQGS1c9LsM2bxX