WebBlocks UI - JavaScript

Correct responsibility split Layout is CSS-driven through layout and pattern classes. Overlays, tooltips, tabs, drawers, theme controls, password visibility, command palette, and dismiss flows are JavaScript-driven through shipped hooks and public APIs.

Behavior conventions

Small modules

The bundle stays readable because behavior is split into named modules instead of one large anonymous runtime.

Named APIs on window

WBTheme, WBModal, WBGallery, WBDrawer, WBToast, and related modules remain inspectable from the console.

Data hooks in markup

Most interactions start from data-wb-* attributes so the HTML still tells you what can open, close, or change.

Common modules

Module	Trigger pattern	Purpose
`WBTheme`	`data-wb-mode-set`, `data-wb-accent-set`, `data-wb-preset-set`	Theme and axis control
`WBModal`	`data-wb-toggle="modal"`	Canonical top-layer pattern for confirms, forms, and content-first viewer or gallery-viewer usage
`WBGallery`	`data-wb-gallery-target`	Inline gallery pattern runtime that populates a shared `wb-modal` viewer
`WBCookieConsent`	`data-wb-cookie-consent-*`	Reusable consent storage, reopen, and preference-center behavior for public sites
`WBDrawer`	`data-wb-toggle="drawer"`	Off-canvas panels
`WBDropdown`	`data-wb-toggle="dropdown"`	Dropdown menus
`WBCommandPalette`	`data-wb-toggle="cmd"` or `Cmd/Ctrl + K`	Search and command surface
`WBTabs`	`data-wb-tab`	Panel switching
`WBPasswordToggle`	`data-wb-password-toggle`	Password visibility toggle for input groups
`WBAccordion`	`.wb-accordion-trigger`	Disclosure blocks

Trigger model

<button data-wb-toggle="modal" data-wb-target="#confirm-dialog">
  Delete
</button>

<button class="wb-gallery-trigger"
        data-wb-gallery-target="#media-viewer"
        data-wb-gallery-full="/images/demo-full.jpg">
  Open gallery item
</button>

<button data-wb-cookie-consent-open data-wb-target="#siteCookiePreferences">
  Cookie settings
</button>

<button data-wb-mode-set="dark">Dark</button>
<button data-wb-dismiss="modal">Close</button>

Most behavior starts from a small attribute contract. Use data-wb-toggle="modal" for direct modal triggers, let data-wb-gallery-target upgrade inline gallery items into a shared content-first modal viewer, and use the cookie-consent hooks when a project needs one reusable consent and reopen flow.

Live package-only demos

Theme and dropdown

wb-overlay-root is shared top-layer infrastructure. Anchored overlays render there in JS mode to avoid clipping, and gallery viewers still route through the same shared wb-modal foundation instead of a second overlay system.

Tabs and accordion

Prefer data attributes when the shipped markup contract already exists.

Use public APIs when behavior must be triggered programmatically.

Because the package already exposes clear data hooks and window.WB* entry points for the shipped interactions.

API shape

WBTheme.setMode('dark')
WBTheme.setAccent('forest')
WBTheme.setRadius('soft')
WBTheme.setDensity('compact')
WBModal.open(document.getElementById('my-modal'))
WBGallery.open(document.querySelector('.wb-gallery-trigger'))
WBDrawer.open(document.getElementById('my-drawer'))
WBPasswordToggle.toggle(document.querySelector('[data-wb-password-toggle]'))
WBToast.show('Saved', { type: 'success' })
WBCookieConsent.open()
WBCookieConsent.clear()

Use the public API when you really need imperative control. If a declarative data-wb-* trigger already exists, prefer that markup path first.