import type { TabsOrientation } from "./tabItems.ts";
/**
 * One tab's paint, shared by the `<button>` a panel tab renders and
 * the `<a href>` a routed tab renders.
 *
 * **This file is the reason the two cannot drift.** Docket's project
 * bar and Docket's Settings bar are the same shape doing the same
 * job, and before the routed mode existed the first was a `Nav`
 * wearing a filled pill while the second was a `Tabs` wearing this
 * underline — two answers to one question, in one app, on adjacent
 * screens
 * ([decision](../../../../docs/decisions/2026-08-31-a-routed-tab-is-a-tab-with-an-href.md)).
 *
 * The caller adds the one class that is genuinely its own: a button
 * needs `cursor-pointer`, an anchor needs `no-underline`.
 */
export declare const toTabTriggerClass: ({ isDisabled, isSelected, orientation, }: {
    isDisabled: boolean;
    isSelected: boolean;
    orientation: TabsOrientation;
}) => string;
/**
 * The list's own box — the border the selected marker sits on, and
 * the scroll rule.
 *
 * A tab bar **scrolls**; it does not wrap and it does not paint
 * outside its container. Without an `overflow`, a bar narrower than
 * its tabs simply spilled across whatever sat beside it — visible in
 * the `Responsive` board since M4, and invisible to a test asserting
 * only that `scrollWidth > clientWidth`, which is true of a
 * *spilling* bar too.
 *
 * The scrollbar is hidden rather than thin: a classic scrollbar takes
 * layout space inside the scroll container, so the narrow bar would
 * grow ~15px taller than the wide one and the underline would stop
 * lining up across a board. Keyboard users never need it — a panel
 * bar's `RovingFocus` calls `.focus()`, a routed bar's links are in
 * the tab order, and the browser scrolls a focused element into view.
 */
export declare const toTabListClass: (orientation: TabsOrientation) => string;
//# sourceMappingURL=tabStyles.d.ts.map