Popover
Floating overlay anchored to a trigger element, with controlled state, placement, and built-in scrolling.
API Reference
<Popover> <Popover.CloseTrigger> <Popover.Content> <Popover.Positioner> <Popover.Trigger> Floating overlay anchored to a trigger element, with controlled state, placement, and built-in scrolling.
<Popover> | Prop | Type | Default |
|---|---|---|
| open | — | $bindable() |
| portalled | — | true |
| modal | — | true |
| children | Snippet | required |
| positioning | — | required |
<Popover.CloseTrigger> | Prop | Type | Default |
|---|---|---|
| children | Snippet | required |
<Popover.Content> | Prop | Type | Default |
|---|---|---|
| class | — | required |
| shadow | OverlayShadow smalllarge | 'large' |
| children | Snippet | required |
| scrollAreaProps | Omit<ScrollAreaProps, 'children'> | undefined |
| scrollContentClass | string | undefined |
<Popover.Positioner> | Prop | Type | Default |
|---|---|---|
| class | — | required |
| children | Snippet | required |
<Popover.Trigger> | Prop | Type | Default |
|---|---|---|
| children | Snippet | required |
ploss is a Svelte UI component library built on Ark UI. The design philosophy is to get as close to a native app experience as possible — refined visuals, cohesive interactions, and attention to detail that give Svelte projects a polished foundation from day one.
This library is actively experimenting with new organizational patterns and internal architectures — as a result, the codebase is a bit chaotic under the hood right now. Things are being shuffled around, patterns are being tested, and not everything has settled into its final form. Expect some mess while the dust is still in the air.
All component styles are extracted into dedicated styles.ts modules using a streamlined variant-based API — dramatically reducing boilerplate and keeping maintenance cost
very low. You can override anything with className or swap entire style modules without touching
component internals. Redundant abstractions have been streamlined throughout.
On the platform side, touch interactions have been fixed across many components and Android back-button handling is built in. Upcoming releases will bring mobile-native experiences — haptic feedback, sound cues, and deeper platform integration. Accessibility is treated as a long-term commitment: keyboard navigation, screen reader support, and ARIA patterns are baked into every component from the start. There is still a long way to go, but each component that gets refined brings it one step closer.
ploss is also designed with computer use in mind — AI agents are becoming a new category of UI consumers, and components need to be machine-readable as much as they are human-usable. Clear semantics, predictable interaction patterns, and well-defined state surfaces make it possible for models to understand and operate the interface — whether that means recognizing a button's disabled state, navigating a dialog tree, or filling out a form. The same foundations that make the library accessible to humans also make it legible to machines.