Managing Duplication in HTML

A common complaint from developers new to Tailwind is: "My HTML is cluttered with repeating classes! If I have 10 identical buttons, do I have to copy-paste 15 classes on each?"

No. There are two primary solutions to manage duplication, and understanding when to use each is crucial.

Strategy 1: Component-Driven Design (Recommended)

In modern web frameworks (React, Vue, Svelte, Angular, Next.js), you don't copy-paste raw HTML. You wrap the elements inside a reusable component.

Here is a React component example:

// 1. Define once
export const Button = ({ children, onClick }) => {
  return (
    <button 
      onClick={onClick}
      className="bg-teal-600 hover:bg-teal-500 active:bg-teal-700 text-white font-semibold py-2 px-4 rounded-lg shadow transition-colors"
    >
      {children}
    </button>
  );
};

// 2. Reuse cleanly anywhere
<Button onClick={submit}>Enroll Now</Button>
<Button onClick={cancel}>Cancel</Button>

Strategy 2: Using @apply (Traditional CSS approach)

If you are not using a component-driven framework (e.g., you are writing plain HTML/PHP pages), you can extract repeated styles into a CSS file using Tailwind's @apply directive.

In your CSS file:

/* input.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer components {
  .btn-primary {
    @apply bg-teal-600 hover:bg-teal-500 active:bg-teal-700 text-white font-semibold py-2 px-4 rounded-lg shadow transition-colors;
  }
}

Now, in your HTML you can write:

<button class="btn-primary">Enroll Now</button>

Why @apply is an anti-pattern (Use sparingly)

Although @apply looks comforting, overusing it is discouraged because:

• You lose the design constraint. It is easy to write custom properties next to @apply declarations, breaking the design scale.
• CSS files grow again. Extracting everything defeats the build-time optimization of JIT where only used classes are included.
• State modifiers become verbose. Writing hover or responsive states requires custom selectors again.

Only use @apply for global element overrides (like rich-text content rendered from markdown/database where you don't control the HTML tags), never for general layout components like cards or navigation bars.

Practice task

In the editor below:

1. Examine the mock component design. Simulating component-level refactoring, clean up the duplicate classes of the tags by giving them all identical class structures: inline-block px-2.5 py-0.5 rounded-full text-xs font-bold mr-2 mb-2.
2. Give the main card container a clean, unified rounded corner schema rounded-2xl and padding p-6.