Make components more reliant on HTML instead of Javascript/Portals

[HugoVG]

I'm currently working with Blazor Server, while everything works pretty good, there are some components, namely all the popover/portals/modals that always are pretty hit or miss whenever someone uses them with a latency.
My current approach has been to not use them but, to just use to base form inside a div-popover, a html5 dialog or an css anchor
Since I kept writing these myself, I was wondering if this is something you want in the main project, it lessens the amount of the javascript interaction and makes it more accessible since it's browser default

[mathewtaylor]

Thanks for raising this @HugoVG — and for framing it around Server latency specifically, because that's exactly where the current design shows its seams.

Why it's "hit or miss" today

A quick tour of how overlays actually work right now, since it explains the latency:

• Portaling is Blazor RenderFragment relocation, not a JS DOM move — content renders wherever you place <BbPortalHost /> and escapes parent stacking contexts via position: fixed + z-index, not the top layer.
• Positioning is Floating UI (vendored, ~19 KB) driven over JS interop: open → register portal (C#) → host re-renders → a render handshake → computePosition in JS → JS writes the inline left/top.

On a fast circuit that's invisible. On a laggy Server circuit, several of those steps are round-trips over the wire and the element is positioned after a round-trip — which is precisely the flash/misplacement you're describing. So it's not you holding it wrong; the position-via-round-trip model is the root cause, and native primitives attack it at the source: <dialog>/popover render in the top layer (no portal handshake) and CSS anchor positioning places the element in the browser with zero JS round-trip. For Server, that's the real win.

Where each piece stands (mid-2026 baselines) and how it fits

I'd phase this by browser maturity and how contained the change is:

1. <dialog> for Dialog / AlertDialog / Sheet — strongest candidate, do first. Baseline since 2022. showModal() gives the top layer, a built-in focus trap, Escape handling, and ::backdrop for free — letting us delete the JS focus-trap, the ref-counted scroll-lock, and the escape-key stack for modals (all <div role="dialog"> today). Contained to BbDialogContent/BbDialogOverlay/BbDialogPortal and the AlertDialog/Sheet analogues. Highest confidence, biggest JS reduction per unit of effort.

2. popover attribute for Popover / Dropdown / Tooltip / Select / HoverCard — next. Baseline since April 2025 (Firefox 125+, Safari 17+). Top layer + native light-dismiss removes the portal handshake. The catch: our light-dismiss isn't naïve — the Bug: BbDatePicker / BbDateRangePicker popover opens and immediately closes on click (Blazor Server) #371 fix pairs pointerdown/pointerup to survive Blazor Server re-renders and distinguishes parent vs. child portals for nested overlays. Native light-dismiss doesn't replicate the nested case, so we'd layer that behavior back on. Doable, but it's the subtle part.

3. CSS anchor positioning to replace Floating UI — biggest payoff, progressive-enhancement only for now. This is the one that actually kills the positioning round-trip (and drops the 19 KB bundle + the scroll/resize autoUpdate listeners). But it's the least mature: Baseline 2026 — Firefox only enabled it by default in 147 (Jan 2026), and the @position-try flip/collision behavior (what Floating UI's flip/shift do for us) needs Safari 18.4+. So I'd gate it behind a capability check with Floating UI as the fallback, not a hard swap.

Proposed shape

Make it opt-in and additive — no breaking change: a rendering-strategy switch (per-component parameter + a global default in AddBlazorBlueprintComponents) choosing native vs. the current JS path, native where supported and the current path as fallback. That lets us ship <dialog> first, then popover, and treat anchor positioning as progressive enhancement — no big-bang migration, nobody loses support. Nicely, the platform is already moving your way: the Invoker Commands API you reached for in #380 hit baseline in Jan 2026 too.

Risks I'd want to design around

• Focus-trap / scroll-lock semantics differ subtly between our JS and native behavior (nested modals, iframe/Teams embeds, scrollbar-gutter compensation).
• Preserving the Bug: BbDatePicker / BbDateRangePicker popover opens and immediately closes on click (Blazor Server) #371 dismiss behavior on top of native light-dismiss.
• Top-layer + ::backdrop vs. our current enter/exit animations and theming.
• Prerender/SSR interplay, and Blazor's diffing over an element the browser has promoted to the top layer — needs real testing on a throttled Server circuit (your original scenario).

Want to take a swing at it? You're already a contributor and this is a great fit. The highest-confidence, most self-contained start is Dialog → <dialog> behind a strategy flag — open a spike PR there and I'll review closely; we can nail the pattern (parameter naming, capability detection, fallback) on the smallest surface before rolling it to the positioned overlays. If you'd rather I scaffold the strategy switch first, say the word.

[manuel-rw]

I am also encountering this problem with InteractiveWebAssembly. I run into the timeout and no dialogs or popups are working