Jan Mikoláš
Glossary
Tailwind CSS
Tailwind CSS provides utility classes such as flex, gap-4 and md:grid-cols-2 that developers compose into component styles. It does not replace CSS knowledge, it is not a ready-made component library, and its precise configuration and build depend on the project version and integration.
Short definition
CSS properties are composed from small, named utilities.
Utility-first means that instead of creating a .product-card class with many declarations, HTML or a component can combine small classes for layout, spacing, colour and typography. Tailwind still generates ordinary CSS; the browser has no special Tailwind runtime.
A utility class is not an inline style. A class refers to a reusable CSS rule, supports pseudo-classes, media queries and design tokens, and can be reused. A style attribute instead puts declarations directly on one element and participates in the cascade differently.
Problem it solves
Composing a consistent interface without an expanding layer of one-off selectors.
Tailwind reduces repeated naming of CSS classes and can keep spacing, colours and breakpoints on a predefined scale. The benefit depends on a team sharing tokens and component rules rather than choosing arbitrary values independently.
- responsive product cards, forms and administration dashboards
- state variants such as hover, focus-visible, disabled and aria-selected
- a shared scale of colours, typography, spacing, breakpoints and other design tokens
- component frontends where markup and visual variants change together
- generating a limited CSS output from classes detected statically in source files
Practical example
A responsive button with a visible focus indicator
The classes describe layout, colours and states on one element. sm:w-auto applies from the sm breakpoint upwards, while the unprefixed width applies to the smallest viewport too. focus-visible provides a visible state for keyboard navigation. disabled changes presentation but does not enforce server-side permission for the action.
The example must still be assessed against web accessibility requirements. Contrast, zoom resilience and use of the correct HTML button element do not appear automatically merely because the framework is present.
HTML
<button
type="submit"
class="w-full rounded-lg bg-blue-700 px-4 py-2 text-sm font-semibold text-white
hover:bg-blue-800 focus-visible:outline-2 focus-visible:outline-offset-2
focus-visible:outline-blue-700 disabled:cursor-not-allowed disabled:opacity-50
sm:w-auto"
>
Uložit objednávku
</button>How it works
From classes in source code to the resulting CSS.
The exact command depends on the integration, but the principle is shared by the current Tailwind CSS 4 series.
- Framework import An input stylesheet commonly imports Tailwind with @import "tailwindcss".
- Theme variables The @theme directive defines design tokens such as a custom colour, font or breakpoint and exposes matching utilities or variants.
- Source detection The build scans source files as plain text for complete class names; a dynamically constructed string may not be detected.
- CSS generation The CLI, PostCSS or Vite integration processes the input and produces CSS containing the required utilities.
- Browser The browser loads the resulting stylesheet and applies standard CSS rules including the cascade, media queries and states.
Main parts and principles
Utilities, variants and the theme form a shared interface language.
Tailwind does not prescribe the structure of React or PHP components. It provides a CSS API usable in different template and component systems.
Utility classes
Each usually expresses a limited set of declarations such as display: flex, padding or colour. Arbitrary values cover exceptions but should not replace well-designed tokens.
Responsive variants
Prefixes such as sm: and lg: activate a utility from a breakpoint. The default approach is mobile-first, so an unprefixed class also applies at the smallest widths.
State variants
Prefixes such as hover:, focus-visible:, disabled:, group-* and data-* apply a rule only in the matching CSS or attribute state.
Theme variables and design tokens
In version 4 the theme is configured primarily in CSS with @theme. Variable namespaces such as --color-* and --breakpoint-* influence available utilities and variants.
Components and custom CSS
A repeated product interface belongs in a real template or frontend component. Complex rules, third-party content and specialised selectors can still use custom CSS.
Dark mode
The dark: variant can respond to the operating-system colour preference or a custom selector. The choice must match how the application actually controls its theme.
Limitations and common mistakes
A shorter route to a style can produce longer, inconsistent markup.
Conditional benefits
- changing a component without searching for a distant selector
- a constrained shared token scale across the application
- responsive and state variants in one notation
- CSS output limited to detected utilities
Risks and common mistakes
- long class lists without an agreed order or component boundaries
- dynamic construction such as text-${color}-600 that source detection cannot see
- an abstraction introduced only to hide a class attribute rather than model a real component
- replacing shared tokens with many one-off arbitrary values
- assuming the framework removes the need to understand the cascade, layout and accessibility
Practical use and comparison
Tailwind organises CSS differently but does not replace CSS.
Unlike a component library, Tailwind does not itself ship a complete button, dialog or table with behaviour and accessibility. The application or a separate UI library provides those components. Unlike Bootstrap, its primary API is not a catalogue of predesigned visual components but a set of low-level utilities.
A utility class is reusable and can react to variants, so it is not equivalent to an inline style. CSS-in-JS generates or manages styles from JavaScript according to a particular library. Tailwind can be used inside a JavaScript component, but its build output remains standard CSS rules.
The build belongs to the wider application build process. The current series provides a separate CLI package, a PostCSS plugin and a Vite plugin. An older project may still use a JavaScript configuration file and different syntax, so an upgrade should not blindly copy an example from a different major version.
Tailwind suits interfaces where a team composes repeated components and wants shared tokens without an expanding collection of one-off names. A small static page with a handful of rules may be clearer with custom CSS and fewer dependencies.
A class list should not automatically be moved into a new component merely because it is long. A component should encapsulate a genuinely repeated interface, state or meaning. For a single exception, direct markup can remain easier to understand.
Responsive variants help implement responsive design, but a useful breakpoint follows the content rather than a particular device name. Long translations, zoom, error states and horizontal overflow still need testing.
Implementation checks
Verify class detection, build output and component behaviour.
A utility is only one part of a frontend change. The resulting interface must work with a keyboard, on mobile and with real data.
- write complete statically detectable class names or map allowed variants explicitly
- keep colours, spacing and breakpoints in the theme when they have system-wide meaning
- verify focus-visible, contrast, disabled states and the semantic HTML element
- test mobile layout, long content and horizontal scrolling
- check documentation for the exact version and build integration during an upgrade
Frequently asked questions
Tailwind CSS in practice
Is Tailwind CSS a component library?
No. It provides CSS utilities and tooling. The application or a separate library must provide complete, stateful and accessible components.
Are utility classes the same as inline styles?
No. Utilities refer to reusable CSS rules and support media queries, pseudo-classes and design tokens. An inline style is a declaration attached directly to one element.
Do I still need to know CSS when using Tailwind?
Yes. Without understanding the cascade, box model, Flexbox, Grid, specificity and accessibility, it is easy to build a brittle interface.
Why was a dynamically constructed class not generated?
Source detection scans files as text and needs to see the complete name. Map application states to complete class names instead of combining fragments.
Does Tailwind configuration always belong in tailwind.config.js?
No. The current version 4 series primarily uses CSS-first theme variables through @theme. Older versions and some migrated projects may use different configuration.
Personal experience
Frontend styles must remain understandable when the component changes.
When developing web applications I connect styling with real data, responsiveness and accessible interaction states.