fuz

Fuz is a Svelte UI library that builds on my CSS framework Moss. It's in early alpha and there will be many breaking changes. I'm making it to support Zzz and my other projects that focus on end-users, so it'll continue to grow slowly as I find the time and usecases.

The goal is to make a fully-featured Svelte UI library, but it'll take extra time to get there. That lets us prioritize design above features, making it an interesting project for learning and experimentation. For more see the readme, and to get involved see contributing.md.

Fuz bases its theme support on my CSS framework Moss, which is based on CSS custom properties. For usage docs see Themed.

Browse the full api docs.

Fuz supports SvelteKit's config for Content Security Policies with the create_csp_directives helper. Fuz also provides related helpers, types, and CSP data.

The goal is to provide a simple trust modeling system that balances safety+security+privacy with ergonomics, helping users maintain secure policies without unhelpful burden or restriction. It's restrictive by default and easy to set granular overrides, and there's tiered grants for convenience.

Example usage:

Auditability and transparency are key concerns for the API, but some features are designed to help you to trade away some directness for ergonomics, with the idea that we make it easy for nonexpert users to safely configure basic scenarios, and advanced users can opt into using the API with full declarative transparency (and more verbosity and information load).

Fuz defines an optional system with three levels of trust/risk/sensitivity (low/medium/high, CspTrustLevel) that can be configured for each trusted source to give blanket permissions at a specified tier. Granular overrides are straightforward and declarative.

I'm trying to design for full customizability with clear, intuitive boundaries with escalating security and privacy implications. Fuz includes a debatable set of defaults, and input is appreciated to help tune the tradeoffs.

Fuz provides an optional CSP abstraction with three trust levels (of type CspTrustLevel) with tiers of escalating risk and implied permission. Sources can opt-in to blanket permissions at a specific level:

The trust system introduces opt-in abstraction and indirection, and a downside of the design is that it encourages over-permissioning at each individual tier. The maintainers currently feel that this granularity with 3 tiers offers an intuitive base that gets most of the important questions right most of the time for most users, and additional safeguards are available for those that want tighter control or less chance of error.

The CSP helpers have a convenient, declarative API for defining directives per source. These override any defaults, and unlike trust, the directives do not depend on an abstraction layer, so WYSIWYG.

Explicit directives are additive with the trust system. For example, a source with trust: 'low' would normally not be allowed for connect-src, but you can explicitly permit this by including connect-src in the directives array.

The options value_defaults_base (defaults to csp_directive_value_defaults) and required_trust_defaults_base (defaults to csp_directive_required_trust_defaults) afford full control over defaults:

The exported csp_directive_specs has JSON data about the CSP directives. Fuz omits deprecated directives.

The intersect helper in intersect.svelte.ts creates an attachment that observes when an element enters or leaves the viewport using the Intersection Observer API.

Uses the lazy function pattern to optimize reactivity: callbacks can update without recreating the observer, preserving state.

The callback receives intersecting (boolean), intersections (number count), el, observer, and disconnect.

Triggers when the element enters the viewport by at least a pixel. Scroll to see items change state.

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Triggers when 50% of the element is visible.

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Triggers only when the element is fully visible.

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Disconnects after the first intersection cycle (enter and leave). A count of 0 disables observation. Negative or undefined never disconnects. (the default)

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Disconnects after two intersection cycles.

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Try different parameter combinations. Positive count values disconnect after N cycles. 0 disables observation. Negative or undefined never disconnects. (the default)

• item 0
• item 1
• item 2
• item 3
• item 4
• item 5
• item 6
• item 7
• item 8
• item 9
• item 10
• item 11
• item 12
• item 13
• item 14

Fuz includes a number of logos available as data that can be mounted with the Svg component. Only the ones you use are included in your bundle.

• <Svg data={zzz_logo} />
• <Svg data={moss_logo} />
• <Svg data={belt_logo} />
• <Svg data={gro_logo} />
• <Svg data={fuz_logo} />
• <Svg data={webdevladder_logo} />
• <Svg data={fuz_blog_logo} />
• <Svg data={fuz_mastodon_logo} />
• <Svg data={fuz_code_logo} />
• <Svg data={fuz_gitops_logo} />
• <Svg data={fuz_template_logo} />
• <Svg data={earbetter_logo} />
• <Svg data={spiderspace_logo} />
• <Svg data={github_logo} />
• <Svg data={mdn_logo} />
• <Svg data={chatgpt_logo} />
• <Svg data={claude_logo} />
• <Svg data={gemini_logo} />

mdz is a small markdown dialect that supports Svelte components, auto-detected URLs prefixed with https:// and /, and Fuz integration like linkified identifiers and modules in `backticks`. The goal is to securely integrate markdown with the environment's capabilities, while being simple and friendly to nontechnical users.

mdz prioritizes predictability: strict syntax with one canonical pattern per feature, preferring false negatives over false positives to minimize surprise.

Supports bold, italic, and strikethrough:

All inline formatting can nest:

mdz preserves and renders all whitespace exactly as written, minimizing surprise for nontechnical users:

Single newlines create line breaks:

Double newlines create paragraph breaks:

Triple newlines create paragraphs with a blank line between:

Use exactly three hyphens (---) at the start of a line to create a horizontal rule. Must be separated from other content by blank lines (paragraph breaks), except at document start/end:

Backtick code automatically links to identifiers and modules:

Non-identifiers become plain code elements:

mdz supports three kinds of links:

• standard markdown link syntax
• external URLs starting with https:// or http://
• internal paths starting with /

Note: Relative paths (./, ../) are not supported (currently, I think this will be changed). mdz content may be rendered at different URLs than where source files live (e.g., TSDoc comments from src/lib/foo.ts render at /docs/api/foo.ts). Root-relative paths (/docs/...) have unambiguous meaning regardless of render location, making them more portable. However it seems very useful to make ../ and ./ links work, maybe we can support it and make the renderer accept a custom base path?

mdz supports an opt-in set of HTML elements for semantic markup and styling.

Elements must be registered:

Unregistered elements render as <tag-name /> placeholders for security.

mdz supports Svelte components to a minimal (and possibly expanding) degree. Components are distinguished from HTML elements by their uppercase first letter:

Components must be registered:

Unregistered components render as <ComponentName /> placeholders.

For more control, use mdz_parse directly with MdzNodeView:

For example you may want white_space_pre to avoid wrapping in some circumstances.

Use 1-6 hashes followed by a space:

Must start at column 0, have a space after hashes, and be followed by a blank line or EOF. Headings can include inline formatting.

Use three or more backticks with optional language hint:

Must start at column 0, closing fence must match opening length, and be followed by a blank line or EOF.

mdz supports fewer syntax variants than CommonMark/GFM:

• bold: **text** only
• italic: _text_ only

In CommonMark, *text* is italic. In mdz, single * has no special meaning and renders as literal text. This choice creates a clear visual distinction between bold and italics.

In general, mdz wants to minimize surprise to nontechnical users, so it's strict in what it accepts and prefers false negatives over false positives. For example, it requires a separating blank line and ``` with no preceding spaces or characters to start a code block.

For more see the generated mdz docs:

• mdz specification
• mdz grammar
• fixtures debug page

icon can be a string prop or snippet:

Alerts can be buttons by including an onclick prop. This API may change because it's a bit of a mess - a separate AlertButton may be better.

clicks: 0

The status prop, which defaults to 'inform', changes the default icon and color.

Fuz provides a customizable contextmenu that overrides the system contextmenu to provide helpful capabilities to users. Popular websites with similar features include Google Docs and Discord. Below are caveats about this breaking some user expectations, and a workaround for iOS Safari support. See also the contextmenu_event docs and w3 spec.

When you rightclick inside a ContextmenuRoot, or longpress on touch devices, it searches the DOM tree for behaviors defined with Contextmenu starting from the target element up to the root. If any behaviors are found, the Fuz contextmenu opens, showing all contextually available actions. If no behaviors are found, the default system contextmenu opens.

Here's a ContextmenuRoot with a Contextmenu inside another Contextmenu:

This simple hierarchical pattern gives users the full contextual actions by default -- not just the actions for the target being clicked, but all ancestor actions too. This means users don't need to hunt for specific parent elements to find the desired action, unlike many systems -- instead, all actions in the tree are available, improving UX convenience and predictability at the cost of more noisy menus. Developers can opt out of this inheritance behavior by simply not nesting Contextmenu declarations, and submenus are useful for managing complexity.

Mouse and keyboard:

• rightclick opens the Fuz contextmenu and not the system contextmenu (minus current exceptions for input/textarea/contenteditable)
• holding Shift opens the system contextmenu, bypassing the Fuz contextmenu
• keyboard navigation and activation should work similarly to the W3C APG menubar pattern

Touch devices:

• longpress opens the Fuz contextmenu and not the system contextmenu (minus current exceptions for input/textarea/contenteditable)
• tap-then-longpress opens the system contextmenu or performs other default behavior like selecting text, bypassing the Fuz contextmenu
• tap-then-longpress can't work for clickable elements like links; longpress on the first contextmenu entry for those cases (double-longpress)

All devices:

• opening the contextmenu on the contextmenu itself shows the system contextmenu, bypassing the Fuz contextmenu
• opening the contextmenu attempts haptic feedback with navigator.vibrate

Check the boxes below to disable automatic a link detection and copy text detection, and see how the contextmenu behaves.

When no behaviors are defined, the system contextmenu is shown instead.

Expected: the Fuz contextmenu will open and show:

• custom "some custom entry" entry
• "copy text" entry when text is selected
• link entry when clicking on a link

Fuz provides two versions of the contextmenu root component with different tradeoffs due to iOS Safari not supporting the contextmenu event as of October 2025, see WebKit bug #213953.

Use ContextmenuRoot by default for better performance and haptic feedback. Use ContextmenuRootForSafariCompatibility only if you need iOS Safari support.

ContextmenuRoot

• standard, default implementation
• relies on the browser's contextmenu event
• much simpler, better performance with fewer and less intrusive event handlers, fewer edge cases that can go wrong
• does not work on iOS Safari until WebKit bug #213953 is fixed

ContextmenuRootForSafariCompatibility

• opt-in for iOS
• some browsers (including mobile Chrome) block navigator.vibrate haptic feedback due to the timeout-based gesture detection (because it's not a direct user action)
• implements custom longpress detection to work around iOS Safari's lack of contextmenu event support
• works on all devices including iOS Safari
• more complex implementation with custom touch event handling and gesture detection
• a longpress is cancelled if you move the touch past a threshold before it triggers
• opt into this version only if you need iOS Safari support

The Fuz contextmenu provides powerful app-specific UX, but it breaks from normal browser behavior by replacing the system contextmenu.

To mitigate the downsides:

• The Fuz contextmenu only replaces the system contextmenu when the DOM tree has defined behaviors. Note that a links have default contextmenu behaviors unless disabled. Other interactive elements may have default behaviors added in the future.
• The Fuz contextmenu does not open on elements that allow clipboard pasting like inputs, textareas, and contenteditables -- however this may change for better app integration, or be configurable.
• To bypass on devices with a keyboard, hold Shift while rightclicking.
• To bypass on touch devices (e.g. to select text), use tap-then-longpress instead of longpress.
• Triggering the contextmenu inside the Fuz contextmenu shows the system contextmenu.

See also the contextmenu_event docs and the w3 spec.

The Details component is an alternative to the details element. By default it's lazy, and you can pass eager to render the children immediately like the base element.

Benefits of lazy children:

• children are transitioned in/out with an animation (TODO this may be doable with eager children, if so it would probably be the better default, and then the prop should be swapped to lazy)
• improved performance, can significantly improve UX in some cases

Tradeoffs:

• ctrl+f does not work to find text and auto-open the details
• you may desire some behavior caused by mounting the children

A modal that overlays the entire page. Uses Teleport to allow usage from any component without inheriting styles.

This is a component related to Gro's public packages features.

This is a component related to Gro's public packages features.

The default animation has text children, so they scale with font-size.

Set size with custom properties:

Set size with classes:

Size is inherited by default:

with inline={true} •••

with children 🐢🐢🐢 * 2

with running={true}

and children

Preserves a button's normal width while animating.

toggle the pending status of the buttons below

do something async

Adds a redirect for a page using a meta tag with the refresh header. Includes a rendered link and JS navigation fallback.

redirect to /docs

Fills available space by default:

Set size: (see the Moss typography docs)

Set --font_size on the component or a parent:

Set fill: (see the Moss colors docs)

Set --text_color on the component or a parent, for svgs that have no default fill:

Relocates elements in the DOM, in the rare cases that's useful and the best solution. The Dialog uses this to mount dialogs from any component without inheriting styles.

Themed defaults to automatic color-scheme detection with prefers-color-scheme, and users can also set it directly:

Pass props to override the default:

The builtin themes support both dark and light color schemes. Custom themes may support one or both color schemes.

A theme is a simple JSON collection of Moss style variables that can be transformed into CSS that set custom properties. Each variable can have values for light and/or dark color schemes. In other words, "dark" isn't a theme, it's a mode that any theme can implement.

Themes are plain CSS that can be sourced in a variety of ways.

To use Fuz's base theme:

Themed can be customized with the the nonreactive prop themer:

Themed sets the themer in the Svelte context:

For a more complete example, see fuz_template.

Themed initializes the system's theme support. Without it, the page will not reflect the user's system color-scheme. By default, Themed applies the base theme to the root of the page via create_theme_setup_script. It uses JS to add the .dark CSS class to the :root element.

This strategy enables color scheme and theme support with minimal CSS and optimal performance for most use cases. The system supports plain CSS usage that can be static or dynamic, or imported at buildtime or runtime. It also allows runtime access to the underlying data like the style variables if you want to pay the performance costs. Scoped theming to one part of the page is planned.

The theme setup script interacts with sync_color_scheme to save the user's preference to localStorage. See also ColorSchemeInput.

The setup script avoids flash-on-load due to color scheme, but currently themes flash in after loading. We'll try to fix this when the system stabilizes.