Cascade & overrides

All of Pretable's grid styling lives in a single cascade layer named pretable, and every default selector is wrapped in :where() so it carries zero specificity. Together these mean your styles win — by layer order, by specificity, or both — without !important or specificity tricks.

"use client";

import { useLayoutEffect, useRef, useState } from "react";

import { PretableSurface } from "@pretable/react";

import "./deep-override.css";

import { columns } from "./columns";
import { tickets, type Ticket } from "./data";

const VIEWPORT_HEIGHT = 220;

export function DeepCssOverrideGrid() {
  const wrapperRef = useRef<HTMLDivElement>(null);
  const [handleWidth, setHandleWidth] = useState<string | null>(null);

  useLayoutEffect(() => {
    const handle = wrapperRef.current?.querySelector<HTMLElement>(
      "[data-pretable-resize-handle]",
    );
    if (handle) {
      setHandleWidth(getComputedStyle(handle).width);
    }
  }, []);

  return (
    <div>
      <p style={{ margin: "0 0 8px", fontSize: 13 }}>
        Click a cell to select it. The header is uppercased and the resize
        handle (hover a column edge) is purple — both plain selectors, no{" "}
        <code>!important</code>.
      </p>
      <div className="cascade-demo" ref={wrapperRef}>
        <PretableSurface<Ticket>
          ariaLabel="Support tickets"
          columns={columns}
          getRowId={(row) => row.id}
          rows={tickets}
          viewportHeight={VIEWPORT_HEIGHT}
        />
      </div>
      <p style={{ margin: "8px 0 0", fontSize: 13 }}>
        The stylesheet above also asks the resize handle for{" "}
        <code>width: 8px</code>. Its computed width is{" "}
        <code>{handleWidth ?? "…"}</code> — the surface writes{" "}
        <code>width: 4px</code> inline, and inline styles beat every stylesheet
        rule.
      </p>
    </div>
  );
}

Every override above is a plain selector with no !important. The last line of the caption is the exception worth reading closely: it's proof, not a claim, that a width on the resize handle does nothing — see What layering does not get you: inline layout below.

Three ways to override, in increasing power

1. Tokens — set any --pretable-* variable at :root or a scoped selector. This is the blessed path for recoloring and resizing. Override after importing the theme file. See Override tokens.

2. Deep CSS — write a selector targeting any grid part. Because the defaults are specificity (0,0,0), even a single class wins:

   cssCopy

   .my-grid [data-pretable-cell][data-pretable-selected="true"] {
     background: hotpink;
   }

3. Layer order — because all Pretable CSS is in @layer pretable, anything unlayered or in a later layer wins regardless of specificity.

Declare the layer order (Tailwind / reset users)

If you use cascade layers — including Tailwind v4, which layers Preflight in base — declare the order once so the cascade is predictable:

@layer theme, base, pretable, components, utilities;

• pretable is after base, so a reset (Tailwind Preflight, normalize.css in base) cannot clobber the grid's borders and padding.
• pretable is before utilities, so a utility class like class="bg-red-500" on a cell still wins.

If you don't use layers at all, you need none of this — plain unlayered CSS beats every layer automatically.

Put resets in @layer base. A normalize.css imported unlayered would beat the grid (unlayered beats all layers) and could strip its styling.

Worked examples

The three overrides in the demo above are the worked examples: recolor the selected cell, restyle the header, recolor the resize handle. All three are plain selectors with no !important — they win because the grid's defaults are layered and specificity-(0,0,0). deep-override.css in the demo's Code tab is exactly what you'd write; the only thing scoped for this page is the .cascade-demo prefix (see the file's own comment for why).

What layering does not get you: inline layout

Layering settles skin-versus-skin. It does not help against the grid's own inline styles, which beat every stylesheet regardless of layer.

The surface writes geometry inline — position, top, left, width, height, z-index — because those values are computed per render from the column plan and the scroll offset. A virtualized cell's left is not a design decision you can restyle; it is where that column currently is.

So width on the resize strip is not overridable. The demo above proves it rather than asserting it: deep-override.css also asks the resize handle for width: 8px, and the caption beneath the grid reads the handle's actual computed width straight out of the DOM — 4px, the value the surface wrote inline, not the 8px the stylesheet asked for.

!important does win, but the strip is anchored to its column's trailing edge and grows outward from it, so a thicker one overhangs the next column by the extra width. Prefer restyling what is not inline — background, cursor on hover, the --pretable-resize-handle* tokens.

The rule of thumb: anything that positions or sizes a box is inline and off-limits; type and color are yours. Fonts, background, padding, opacity and transition are all left to CSS.

Two things sit outside that rule and are inline today, so plan around them:

Header cells also carry inline text-align and gap, but those are the header's flex layout rather than skin. Their color and divider are not inline — both follow --pretable-text-header and --pretable-rule.

Targeting attributes

Pretable emits a stable set of data-pretable-* attributes you can target with CSS:

data-pretable-column-align is written only when a column resolves to something other than the default: "end" for type: "number" columns, or whatever the column sets on align explicitly. Start-aligned columns — the overwhelming majority — carry no attribute at all, so target the default by absence. A [data-pretable-column-align="start"] rule matches only the columns that opted into align: "start" by hand, and silently misses every column that is start-aligned because nothing said otherwise.

For example, style one column (header and body), the selected cells in another, and the start-aligned cells by absence:

[data-pretable-column-id="revenue"] {
  font-variant-numeric: tabular-nums;
}
[data-pretable-cell][data-pretable-selected="true"] {
  background: #1d4ed8;
  color: white;
}
/* Every start-aligned column — not [data-pretable-column-align="start"] */
[data-pretable-cell]:not([data-pretable-column-align]) {
  padding-inline-start: 12px;
}

These names are stable; aria-* and role are also targetable but follow ARIA semantics, not Pretable's namespace.