refactor: remove class shortcuts

[essenmitsosse]

This remove a few unnecessary UnoCSS shortcuts as follows:

• Add a Card component and remove card and card-interactive shortcut
• Add SkeletonInline and SkeletonBlock components and remove skeleton shortcut
• Remove these single-use shorts and inline their atomic classes:
  • code-block
  • input-base
• Remove unused shortcuts:
  • divider
  • section

There are some more Uno shortcuts that can be removed, but they need a little more care and probably their own PR. Those were the easy wins.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 1, 2026 1:30pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 1, 2026 1:30pm
npmx-lunaria	Ignored		Feb 1, 2026 1:30pm

[garthdw]

LGTM

[danielroe]

can I ask what the motivation is for this? does it improve performance or reduce the amount of emitted css or markup?

[essenmitsosse]

@danielroe This relates to your answer to my question

Main benefits:

• Dropping unused classes to clean up code (I assume they would be removed by tree shaking anyway)
• I usually find a mix of atomic utility classes and custom classes harder to maintain, because you loose some benefits of the utility classes. This goes after the philosophy of Tailwind to model style reuse via components. While there are many benefits, for me the two biggest advantages are:
  • makes it easy to cupple behavior with style in those components
  • improves discoverability and introspection — figuring out where a CSS class is used is messy at best, but every decent IDE should be able to tell you where a component is used
• avoid future naming conflicts

Currently I found it a bit hard to figure out, where some styles where coming from, and simplifying the ways components can be styled across the code base would improve DX imho.

Like I said in the initial PR message: This isn't a complete change, there are some other shortcuts, that can also be moved into components, but I wanted to get the easy ones out of the way and would open individual PRs for the more complex cases.

Should the mixture of atomic utility classes and shortcuts be a deliberate design decision, this PR can probably be closed.