Shipping a widget that never touches your CSS
Shadow DOM, scoped styles and the small tricks that keep our launcher invisible until it is needed.
A third-party widget has one cardinal sin: leaking. The moment a button picks up your global reset, or your design system bleeds into our overlay, both sides break in ways that are miserable to debug. So the very first decision we made was to render the entire widget inside a Shadow DOM.
A wall between two worlds
The shadow boundary means our styles cannot escape and yours cannot enter. We mount a single host element, attach a shadow root, and render everything — launcher, overlay, form — inside it. Your CSS resets, your Tailwind layers, your specificity wars: none of them reach across.
If a customer can tell we are even on the page before they click, we have already failed.
That isolation is what lets us promise a calm launcher. It sits quietly in the corner, picks up no stray hover states, and never shifts your layout.
The small tricks
Isolation is the headline, but the details are what keep it invisible in practice:
- System font stack — the widget always renders in system-ui, never a webfont, so there is nothing to download and nothing to flash.
- No layout impact — the host is fixed-positioned and the overlay is portalled, so we never reflow your content.
- One global, namespaced — a single entry point on `window`, scoped so it cannot collide with yours.
The result is a widget you forget is there until the moment a customer needs it — which is exactly the point.
- #widget
- #shadow-dom
- #engineering
Building NOCK NOCK — the feedback widget for web products.