The repetitive need to apply text-sm for visual consistency degrades DX

[cihad]

First of all, thank you for this incredible project. It has significantly improved how we build modern interfaces.

I'd like to open a discussion about a Developer Experience (DX) friction point regarding typography. Specifically, the heavy reliance on the text-sm utility class to maintain the default shadcn aesthetic.

I have attached an image where I analyzed the typography sizes across various UI elements:

• 🔴 Red outlines: Elements that use text-sm (14px).
• 🟢 Green outlines: Elements that use other sizes (text-xs, text-base, text-lg, etc.).

As seen in the visual, the vast majority of the UI (inputs, labels, descriptions, badges, list items) is built around the text-sm size.

The Problem:

Because standard web projects default to 16px (text-base), whenever we developers build custom layouts, text blocks, or wrappers alongside shadcn components, we are constantly forced to manually add className="text-sm" to our own elements just to achieve visual consistency with the library.

Having to constantly type text-sm everywhere:

1. Makes the codebase noisy and repetitive.
2. Leads to inconsistent UIs if a developer simply forgets to add text-sm to a standard <p> or <div>, making it look awkwardly large next to a shadcn Input or Label.
3. Hurts the overall Developer Experience because we are fighting the browser's default font size to match the library's aesthetic.

Proposed Solution:

Instead of treating text-sm as a utility class that needs to be applied everywhere, we should make 14px the actual default and clean up the component code.

1. Remove text-sm from components:
Strip out the hardcoded text-sm classes from all component files (Input, Label, Button, Card, etc.). Let them inherit the font size naturally.

2. Update the default base font to 14px:
During the shadcn-ui init process, the library could modify the tailwind.config.js to override the default text-base

Why this is better:

• Cleaner Code: We no longer have to type text-sm on every single custom element we create.
• Cleaner Components: The shadcn component files themselves will have shorter, cleaner className strings.
• Better DX: Everything is visually consistent out-of-the-box. We only need to use typography utility classes (like text-xs or text-lg, as seen in the green outlines) when we actually want to deviate from the standard look.

Would love to hear the maintainers' and community's thoughts on this approach!

[abhayclasher]

This is an excellent observation. The "friction" comes from the fact that shadcn/ui is designed with a highly specific aesthetic that favors 14px (text-sm) for almost all content-heavy elements, while the browser/Tailwind default remains 16px.

While we wait for potential core changes, a robust way to solve this at the project level (and avoid the text-sm noise) is to override the default base font size in your CSS or Tailwind config.

The CSS Solution (Global)

Instead of forcing every element to be text-sm, you can set the base size on your :root or body. Since Tailwind's relative units (rem) usually derive from the root 16px, you can shift the scale:

@layer base {
  html {
    font-size: 14px; /* Sets 1rem to 14px */
  }
}

The Tailwind Config Solution

If you want to keep the root at 16px but make "base" text 14px (effectively swapping text-base and text-sm), you can remap them in your tailwind.config.js:

theme: {
  extend: {
    fontSize: {
      base: ['0.875rem', { lineHeight: '1.25rem' }], // 14px
      lg: ['1rem', { lineHeight: '1.5rem' }],       // 16px
    },
  },
}

Why text-sm is explicitly applied in components:

The library currently hardcodes text-sm into components to ensure they are design-system-pure. If a component relied on inheritance, its look would break the moment it was placed inside a container with a different font size (e.g., a "hero" section). Explicitly applying text-sm makes the components predictable and isolated.

However, your point about shadcn-ui init optionally setting the base to 14px is a great suggestion for the CLI, as it would align the "user land" code with the "library land" aesthetic from day one.