Styling drivers

Behavior and visual style are separate. The docs use their own CSS over the component parts; application styles can use the same data-part, data-state and native semantics.

Included drivers

import { setDriver, shadcnDriver } from "fuzor/ui/drivers";
setDriver(shadcnDriver);

The included drivers are unstyledDriver, shadcnDriver, bulmaDriver and daisyuiDriver. They supply classes and presentation attributes. You supply the matching framework CSS; a driver does not bundle Tailwind, Bulma or DaisyUI. Bootstrap is a possible custom driver, not an included one.

Popover and tooltip have driver parts for trigger, positioner, content, arrow and arrow tip. Popover also exposes title, description and close-trigger parts.

Scoped styles

import { setDriver, clearDriver, daisyuiDriver } from "fuzor/ui/drivers";
const preview = document.querySelector<HTMLElement>("#preview")!;
setDriver(daisyuiDriver, preview);
// Remove the scope so the preview inherits its ancestor's driver:
clearDriver(preview);

A subtree can use its own driver. Portals inherit from their logical owner. Changing a driver refreshes classes without replacing behavior or losing form state.

A custom driver

import { setDriver, type FuzorDriver } from "fuzor/ui/drivers";
const driver: FuzorDriver = {
  name: "docs",
  components: {
    popover: {
      parts: {
        trigger: { className: "docs-outline-trigger" },
        content: { className: "docs-outline-content" },
      },
    },
  },
};
setDriver(driver);

Keep ARIA semantics, event handling and focus management in the behavior engine. Use driver attributes for visual state, not to replace the engine's accessibility contract. Structural defaults have low CSS specificity and can be overridden by your own styles.