Display, Position, Visibility, and Z-Index
Purpose and Scope
This page groups the layout utilities that control an element’s box participation, positioning context, visibility, stacking, and overflow behavior. In day-to-day Tailwind CSS authoring, these are the classes you reach for before solving spacing, flex, grid, or animation problems: block, inline-flex, hidden, relative, absolute, sticky, invisible, overflow-hidden, z-10, and related inset utilities establish where an element exists and how it can affect surrounding content. The official documentation presents many of these as separate layout pages, but they share the same mental model: a class candidate is detected, compiled by the core package, and emitted as a small CSS declaration set. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json
The repository evidence for this page is intentionally about the public compilation and integration surface rather than a hand-authored table of every utility. The tailwindcss package describes itself as a utility-first CSS framework and exports the core stylesheet entry points, including index.css, preflight.css, theme.css, and utilities.css. Its TypeScript entry point exposes the compiler machinery that parses CSS directives, imports stylesheets, builds a design system, and compiles candidates into final CSS. That matters for layout utilities because display, position, visibility, overflow, inset, and z-index classes are not consumed through a separate subsystem; they are ordinary candidates in the same build pipeline as color, typography, and responsive variants. Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json
Relevant Source Files
packages/tailwindcss/src/index.ts— Core compiler entry point. It imports AST helpers, CSS import substitution, design-system construction, candidate compilation, CSS functions, theme handling, variants, and walking utilities used by Tailwind’s build pipeline.packages/tailwindcss/package.json— Public package metadata and exports for thetailwindcsspackage, including CSS entry points and JavaScript/TypeScript module entry points.package.json— Root workspace scripts for building, testing, linting, integration testing, and running playgrounds that exercise the packages together.packages/@tailwindcss-browser/src/index.ts— Browser runtime used by Play CDN-style workflows. It creates a compiler, readsstyle[type='text/tailwindcss']blocks, injects the main import when needed, and builds CSS in the page.packages/@tailwindcss-cli/src/index.ts— CLI executable entry point. It parses root,build, andcanonicalizecommands and routes build flags to the command implementation.packages/@tailwindcss-node/src/index.ts— Node-facing integration entry point. It re-exports compile, optimization, instrumentation, path, and source-map helpers and registers ESM cache behavior when supported.
Utility Reference
Display utilities decide whether an element creates a block box, inline box, flex container, grid container, table box, list item, contents participation, or no box at all. The official display reference includes classes such as inline, block, inline-block, flow-root, flex, inline-flex, grid, inline-grid, contents, the table display family, list-item, and hidden. It also includes accessibility-oriented sr-only and not-sr-only, which expand to multiple declarations rather than a single display rule. Use display utilities when choosing the element’s formatting context or when completely removing it from layout with hidden, which maps to display: none.
Position utilities establish how an element is placed in the document and whether offsets can apply. The official position reference includes static, relative, absolute, fixed, and sticky. static follows normal flow and ignores offsets, while relative stays in normal flow but creates a positioning reference for absolutely positioned descendants. absolute removes the element from normal flow and positions it against its nearest positioned ancestor, fixed positions against the viewport, and sticky behaves like normal flow until a scroll threshold is crossed. In Tailwind usage, these classes usually combine with inset utilities such as top-0, right-4, bottom-full, left-auto, inset-0, inset-x-2, or arbitrary values when the generated design system allows them.
Visibility utilities are deliberately different from display utilities. The official visibility reference includes visible, invisible, and collapse. invisible hides the element with visibility: hidden while preserving its layout slot, so neighboring elements behave as if the hidden element still occupies space. By contrast, hidden is a display utility and removes the element’s box from the layout tree. collapse is especially useful for table rows, row groups, columns, and column groups because it can hide those structures without disturbing the sizing of the rest of the table in the same way. This distinction is important when toggling content for interaction states or responsive breakpoints.
Z-index and overflow utilities complete this layout family because they control what happens after an element has a box and a positioning relationship. Z-index utilities such as z-0, z-10, z-auto, negative values, and arbitrary values are meaningful when stacking contexts and positioned elements interact. Overflow utilities such as overflow-hidden, overflow-auto, overflow-scroll, overflow-visible, and axis-specific forms decide whether overflowing content is clipped, scrollable, or allowed to paint outside its box. These classes are often combined with relative, absolute, inset-0, sticky, and responsive or state variants to build overlays, clipped media cards, sticky headers, and scroll containers.
System-to-Code Mapping
At source level, the key concept is the candidate. A candidate is a class-like token that Tailwind can compile into CSS after scanning source content or receiving an explicit build list. The core entry point imports compileCandidates and the variant system, then exposes compile-time behavior around CSS parsing, @import, @theme, @apply, @variant, plugin/config compatibility, and design-system construction. Layout utilities flow through that same general mechanism: relative, overflow-hidden, or z-10 are treated as candidates that can be combined with variants such as responsive breakpoints, hover states, or dark mode. Sources: packages/tailwindcss/src/index.ts
The package export map explains how users arrive at the compiler or prebuilt CSS layers. The default tailwindcss export points to the package’s TypeScript source in development and built library files for publishing, while CSS subpath exports expose the main stylesheet and separate preflight, theme, and utilities files. For this page’s utilities, the most important exported CSS entry is tailwindcss/utilities, because that is the layer where generated utility rules belong. The full index.css entry lets installations import the standard stack without assembling each layer manually. Sources: packages/tailwindcss/package.json
Integrations do not define a second vocabulary for layout utilities. The CLI, browser runtime, and Node integration all hand work to the Tailwind compiler or the package exports. The CLI entry point accepts a default build invocation or an explicit tailwindcss build command, plus canonicalize for candidate-list normalization. The browser runtime imports tailwindcss, creates a compiler from page stylesheets, injects @import 'tailwindcss' when no import is present, and tracks classes already seen on the page. The Node package re-exports compile and optimization helpers for build-tool integrations. Sources: packages/@tailwindcss-cli/src/index.ts, packages/@tailwindcss-browser/src/index.ts, packages/@tailwindcss-node/src/index.ts
Execution Flow Across Runtimes
In a project build, the usual flow starts with CSS that imports Tailwind, commonly through @import 'tailwindcss'. The compiler parses that CSS, resolves imports through the provided loader, applies compatibility hooks where needed, builds a design system, and produces CSS for the candidates discovered by the surrounding integration. When markup contains relative z-10 overflow-hidden, each class enters candidate compilation and produces a rule in the utilities layer if it is valid for the current design system. Variants wrap or transform those generated rules, so md:block, hover:visible, or dark:fixed use the same core candidate with additional variant behavior. Sources: packages/tailwindcss/src/index.ts
In a CLI workflow, the packages/@tailwindcss-cli/src/index.ts executable is the user-facing dispatcher. Running tailwindcss --input app.css --output dist.css or tailwindcss build --input app.css --output dist.css routes to the build command after parsing shared help and build options. The file also shows that canonicalize is a first-class command, which is useful for tooling that wants stable candidate output. For layout utilities, the CLI does not need special flags: if source detection finds absolute, inset-0, overflow-auto, or z-50, the build path is responsible for asking the compiler to include those rules. Sources: packages/@tailwindcss-cli/src/index.ts
In the browser runtime, Tailwind runs without a Node build step. The runtime looks for style elements whose type is text/tailwindcss, concatenates their contents, observes those sheets, and injects an import of the main Tailwind stylesheet if the author did not provide one. It then calls tailwindcss.compile with browser-specific stylesheet and module loaders and rebuilds when stylesheets change. This is the same authoring model used by Play CDN-style examples: putting classes like grid, hidden, sticky, or overflow-x-auto in the document can produce usable CSS in the page while the runtime tracks new classes incrementally. Sources: packages/@tailwindcss-browser/src/index.ts
Practical Usage Patterns
Choose between hidden, invisible, and sr-only based on the behavior you need, not simply on whether something should be seen. hidden removes the element’s display box and is appropriate for responsive layout switches such as hidden md:block. invisible keeps spacing intact, which makes it useful for measurement, alignment, and transitions where the surrounding layout should not jump. sr-only visually hides content while keeping it available to assistive technologies, and not-sr-only reverses that expanded declaration set. Because these utilities can be variant-prefixed, a common pattern is to expose content at a breakpoint or interaction state without changing the underlying markup.
Position, inset, overflow, and z-index utilities are usually composed in small clusters. A modal backdrop might use fixed inset-0 z-50, an image card might use relative overflow-hidden, and a badge might use absolute top-2 right-2. The important implementation detail is that Tailwind sees each class independently and then emits separate rules that the browser composes through the normal CSS cascade. If a class appears to have no effect, inspect the underlying CSS semantics first: offsets do not affect static elements, z-index depends on stacking contexts, and overflow clipping can be changed by ancestors as well as by the element itself.
Testing and Operations Signals
The root workspace scripts show how maintainers validate behavior across packages: pnpm test runs Rust tests and Vitest, pnpm test:integrations runs the integration suite, pnpm test:ui targets UI tests for the core and browser packages, and pnpm build builds the monorepo while excluding playgrounds. These commands are operational signals for layout utilities because the correctness of a class like sticky, collapse, or overflow-hidden depends on the shared compiler and integration contracts continuing to work in Node, browser, CLI, and build-tool contexts. Sources: package.json
For contributors or advanced users debugging a layout utility, start by reproducing the class in the smallest runtime that matches the issue. Use the CLI for generated CSS inspection, the browser runtime for Play CDN behavior, and Node-facing integrations when a framework plugin is involved. Then confirm whether the problem is CSS semantics, candidate detection, variant composition, or integration loading. Related next pages are styling-with-utility-classes for candidate fundamentals, responsive-design for breakpoint variants, hover-focus-and-other-states for state variants, and tailwindcss-package-api for the compiler surface.