Utilities

.truncate

Single-line ellipsis. Requires a constrained width (flex item with min-width: 0, or explicit max-width).

.visually-hidden / .sr-only

Hide visually while keeping the element in the accessibility tree. Use for icon-only button labels, form hints read by screen readers, and the polite live regions announce() writes into.

Why ui.css overrides the vendor styles

Open Props' utilities sheet resolves this class to inline-size: 0; block-size: 0; overflow: hidden. ui.css redefines it immediately after the import as the conventional clipped-1px box — position: absolute; width: 1px; height: 1px; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap — which is also, declaration for declaration, the rule accordion() and tree() inject for their own live regions. The physical width/height win over the imported logical inline-size/block-size on source order at equal specificity, in both Chromium and Firefox — so the override has to stay after the import to keep winning. public/open-props/ is vendored and left untouched, so the correction lives here.

The zero-size box has two problems. One was measured in the browser; the other is reported by accessibility sources:

• Measured. A box with no inline-size wraps its text to one word per line — Chromium lays out "ZERO SIZED MESSAGE" as three inline text boxes where the clipped 1px box gives one. This layout can cause words to run together when read aloud. The white-space: nowrap rule prevents the wrapping.
• Reported, not reproducible here. WebAIM states that an element with no height or width "is typically removed from the flow of the page, so most screen readers will not read it", and NVDA only stopped treating a zero-size control as invisible in browse mode in its 2026.1 release. Safari additionally will not focus a zero-dimension element.

In the tested Chromium and Firefox versions, a zero-size element remains in the accessibility tree without an ignored reason. The problems concern assistive technology and text layout. A live region has no visible fallback, so a failed announcement leaves the user without feedback.

.fade-up-and-in

Entry animation — fades in while sliding up. Applies on element mount.

.border-between-inline / .border-between-block

Draw a border between sibling children without a trailing one: the rule sets border-inline-start-width — border-block-start-width for the -block variant — from --border on every child but the first.

The utility only sets border width. --border holds a length, not the border shorthand: a shorthand value is invalid for a width property, so the declaration is thrown away and the width falls back to the initial medium — which can produce an unintended divider, or no divider if no border style is set.

You must set the border style as well: without one, the used width is 0, and neither the utility nor the normalize layer declares a border-*-style, so declare the style and color on each child. Declare them as longhands, the way the demo does — the border-inline-start shorthand resets the width too, and from an inline style that reset outranks the utility's rule.

.gradient-border

Decorative gradient frame, drawn as a border-image. The rule is three declarations: border-width: var(--size-3), border-image-slice: 1, and border-image-source: var(--conic-gradient-3).

The class alone draws no border for two reasons. There is no --conic-gradient-3 in the loaded token set — Open Props names its gradients --gradient-1 … --gradient-30, several of which are conic — so the source resolves to none. And with no border-style the used border width is 0 regardless of border-width. Supply both on the element: border-style: solid; --conic-gradient-3: var(--gradient-11), or set your own border-image-source and skip the class.

See also

• Conventions — why this codebase avoids utility classes for component styling.
• Open Props — Utilities — the full upstream utility list (not all are loaded; see /open-props/extra/utilities.css).