DEV Community: Anja Beisel

The Hybrid Analytics Architecture

Anja Beisel — Mon, 23 Mar 2026 12:26:02 +0000

Privacy-First Analytics for Modern Web Apps (Part 4)

A modern and practical solution is to combine two analytics systems:

Layer 1: privacy-first analytics for all visitors
Layer 2: Google Analytics only for users who explicitly accept cookies

This architecture separates two different goals:

understanding product usage
running detailed analytics and marketing analysis

By splitting these responsibilities, you get useful insights without relying entirely on cookie-based tracking.

Why a hybrid analytics setup helps

When using Basic Consent Mode, users who decline analytics cookies are completely invisible in Google Analytics. Your analytics becomes incomplete.

A hybrid architecture solves this by using a privacy-first analytics platform for baseline reporting while keeping Google Analytics behind explicit consent.

In practice this means:

everyone contributes to anonymous product analytics
only consenting users are tracked in Google Analytics

The result is a better balance between:

privacy
product insight
legal safety

Layer 1 — Privacy-first analytics

For the first layer, you use a tool designed to work without cookies and without persistent identifiers.

Popular options include:

Umami
Plausible

These tools typically provide:

pageviews
referrers
country / region statistics
device types
simple product-usage events

They intentionally avoid:

cross-site tracking
persistent user identifiers
advertising profiles

This makes them easier to justify from a privacy perspective.

Example: Event tracking with Unami

Setting up Umami

Umami offers both cloud hosting and self-hosting.

Typical onboarding steps are:

Create an account at Umami Cloud.
Add your website domain.
Copy the tracking script from the dashboard.
Insert it into your app’s HTML template.
Verify pageviews appear in the analytics dashboard.

At the time of writing, Umami Cloud offers a Hobby tier with around 100k events/month for free, though pricing can change.

The dashboard typically shows:

top pages
traffic sources
device types
countries
custom events

This is already enough to answer many product questions.

Event tracking with Umami in React + TypeScript

Add the Umami tracker script to your main HTML template.

<script defer src="https://cloud.umami.is/script.js" data-website-id="YOUR_UMAMI_WEBSITE_ID"></script>

This automatically tracks pageviews.

Create a helper wrapper in your React project.

// src/lib/analytics/umami.ts

declare global {
  interface Window {
    umami?: {
      track: (event: string, data?: Record<string, unknown>) => void
    }
  }
}

export function trackEvent(
   name: string,
   data?: Record<string, unknown>
) {
   window.umami?.track(name, data)
}

Add the event tracking helper in a component

import { trackEvent } from "../lib/analytics/umami"

export function OpenEditorButton() {
   return (
      <button
         onClick={() => {
             trackEvent("open_editor")
         }}>
      Open editor
      </button>
   )
}

This event will appear in the Umami dashboard. Typical product-analytics events might include:

open_editor
view_gallery_item
view_pricing_page
start_publish
publish_complete

Layer 2 — Google Analytics (opt-in only)

For users who explicitly accept analytics cookies, you can enable Google Analytics. Google Analytics provides deeper analysis including:

user journeys
funnels
campaign attribution
conversion analysis
returning sessions

Because GA uses cookies and identifiers, it should only be initialized after consent.

Example: Remember consent and track GA events only with given content

Add a remember consent helper

// src/lib/analytics/consent.ts

export function getConsent(): boolean | null {
   const value = localStorage.getItem("cookie_consent")

   if (value === "true") return true
   if (value === "false") return false

   return null
}

export function setConsent(value: boolean) {
   localStorage.setItem("cookie_consent", value ? "true" : "false")
}

Add google analytics helper

// src/lib/analytics/googleAnalytics.ts

import ReactGA from "react-ga4"

const GA_ID = process.env.REACT_APP_GA_ID

let initialized = false

export function initGA() {
  if (!GA_ID || initialized) return

  ReactGA.initialize(GA_ID)
  initialized = true
}

export function trackPageView(path: string) {
  if (!initialized) return

  ReactGA.send({
    hitType: "pageview",
    page: path
  })
}

Enable GA only after consent

Example cookie consent handler:

import { setConsent } from "../analytics/consent"
import { initGA } from "../analytics/googleAnalytics"

export function acceptAnalytics() {
  setConsent(true)
  initGA()
}

export function declineAnalytics() {
  setConsent(false)
}

Initialize GA on page load if previously accepted

import { useEffect } from "react"
import { getConsent } from "./analytics/consent"
import { initGA } from "./analytics/googleAnalytics"

export function App() {
  useEffect(() => {
    if (getConsent()) {
      initGA()
    }
  }, [])

  return <Routes />
}

How the two layers work together

With the hybrid setup, the user journey looks like this:

Visitor arrives
  ↓
Umami analytics runs for everyone
  ↓
Cookie banner appears
  ↓
Accept → Google Analytics is initialized
Decline → Google Analytics stays disabled

This provides:

baseline product analytics for all visitors
deeper insights for consenting users
a clearer privacy model

What each layer is best at

Privacy-first analytics (Umami / Plausible)

Best for:

product decisions
feature usage
top pages
referrers
general traffic insight

Google Analytics

Best for:

funnels
marketing analysis
campaign attribution
deeper engagement analysis

Separating these roles is exactly why the hybrid architecture works well.

Practical recommendation

For most modern web apps — especially developer tools — a good starting setup is:

Umami for all visitors
Google Analytics only after consent
no Advanced Consent Mode initially

This gives you:

useful analytics from day one
less legal ambiguity
a clean foundation if you later introduce advertising or subscriptions

One final note on privacy

Privacy-first analytics tools often market themselves as cookie-free and simpler from a compliance perspective. That can reduce complexity, but it does not remove your responsibility to review your own legal obligations.

A good rule of thumb is simple transparency:

anonymous product analytics help improve the product
optional analytics cookies enable deeper reporting

Users usually respond well to that level of honesty.

Series: Privacy-First Analytics for Modern Web Apps

Why Cookie Consent Breaks Your Analytics
Google Consent Mode Explained (React + TypeScript)
Ads, Tracking, and the Legal Reality in the EU and UK
The Hybrid Analytics Architecture

About this series

This series is based on real-world work building CSSEXY, a visual UI platform where understanding user behaviour is essential for improving the product.

All articles are also available on CSSEXY and there in the Gallery.

Ads, Tracking, and the Legal Reality in the EU and UK

Anja Beisel — Sun, 22 Mar 2026 19:17:39 +0000

Privacy-First Analytics for Modern Web Apps (Part 3)

Why analytics, advertising, and consent are tightly connected — and where the risks actually are

Analytics and advertising are often discussed separately.

In reality, they are deeply connected.

The moment you introduce ads — or even just conversion tracking — your analytics setup becomes part of a much larger system involving:

user tracking
profiling
legal compliance

To understand the trade-offs, it helps to break things down.

The three types of advertising

Not all ads are the same. From a privacy and legal perspective, there are three fundamentally different models.

1. Contextual advertising (privacy-first)

Contextual ads are selected based on what the user is currently viewing, not who they are.

Example:

Page about CSS tools
  ↓
Ad for web hosting

Advantages

no user tracking
no personal profiles
simple compliance
works without consent banners in many cases

Typical networks

Carbon Ads
EthicalAds

This is the most privacy-friendly model and aligns well with developer-focused platforms.

2. Personalized advertising (tracking-heavy)

Personalized ads rely on tracking users across multiple websites.

Example:

User visits hosting websites
  ↓
Ad network builds profile
  ↓
Hosting ads shown elsewhere

Advantages

higher ad revenue
better targeting

Disadvantages

requires extensive tracking
strict consent requirements
legally more complex

Typical platform

Google AdSense

This is where most privacy concerns — and regulations — apply.

3. Conversion tracking (the hidden layer)

Even if you are not running ads, you may still care about:

Which action led to a signup?

This is called conversion tracking.

It is often used for:

marketing campaigns
onboarding optimisation
product growth

This is also where Google Consent Mode becomes relevant.

Where Advanced Consent Mode fits in

Advanced Consent Mode tries to solve a key problem:

How can you measure behaviour if users decline cookies?

It does this by sending cookieless signals such as:

page views
timestamps
device/browser info
approximate location

Google then uses modelling to estimate user behaviour.

The legal reality in the EU and UK

Privacy regulation in Europe mainly comes from:

GDPR
ePrivacy / PECR

The core rule is simple:

Users must give consent before non-essential technologies access or store information on their device.

Traditional analytics cookies clearly require consent.

Why Advanced Consent Mode is debated

Even without cookies, Advanced Consent Mode still sends:

device information
page URLs
IP-based location

Some privacy experts argue that this still counts as:

👉 accessing information from a user’s device

Because of this, Advanced Consent Mode sits in a legal grey area.

What can actually happen in practice

In reality, enforcement tends to focus on:

large platforms
large-scale tracking
clear violations

Examples of companies involved in major enforcement actions include:

Meta
Google
TikTok

For smaller websites, the most likely scenario is much simpler:

Regulator review
  ↓
Request to disable tracking before consent

In most cases:

no fines
no legal escalation
just a requirement to adjust implementation

What this means for developers

When choosing an analytics and advertising setup, you are balancing:

data quality
legal clarity
implementation complexity

A simple way to think about it:

Contextual ads → lowest risk
Hybrid analytics → balanced
Advanced consent mode → more data, more uncertainty
Personalized ads → highest risk

Key takeaway

The moment you introduce:

ads
tracking
or conversion measurement

you are no longer just dealing with analytics.

You are designing a data collection system under legal constraints.

Understanding the differences between advertising models and consent strategies is essential to making the right trade-offs.

Series: Privacy-First Analytics for Modern Web Apps

Why Cookie Consent Breaks Your Analytics
Google Consent Mode Explained (React + TypeScript)
Ads, Tracking, and the Legal Reality in the EU and UK
The Hybrid Analytics Architecture

About this series

This series is based on real-world work building CSSEXY, a visual UI platform where understanding user behaviour is essential for improving the product.

All articles are also available on CSSEXY and there in the Gallery.

Google Consent Mode Explained (React + TypeScript)

Anja Beisel — Fri, 20 Mar 2026 09:10:01 +0000

Privacy-First Analytics for Modern Web Apps (Part 2)

To address the data-loss problem (see Part 1), Google introduced Consent Mode.

The goal is to allow analytics tags to load before consent, but with restricted behaviour.

What Advanced Consent Mode does

With Advanced Consent Mode:

User visits site
  ↓
Google tag loads
  ↓
Consent state = denied
  ↓
Cookieless pings sent

These pings may contain:

page URL
timestamp
browser / device type
approximate region

But they do not set cookies.

Google uses these signals to estimate user behaviour.

Basic vs Advanced Consent Mode

Basic consent mode: Google Analytics loads only after consent

Advanced consent mode: Google tag loads immediately with restricted tracking

Implementing Basic Consent Mode (React + TypeScript)

Example cookie consent logic:

import ReactGA from "react-ga4"

export function enableAnalytics() {
  const GA_ID = process.env.REACT_APP_GA_ID

  if (GA_ID) {
    ReactGA.initialize(GA_ID)
  }
}

Called when the user clicks Accept.

Implementing Advanced Consent Mode

Advanced Consent Mode uses the gtag consent API.

Default state:

window.gtag("consent", "default", {
  analytics_storage: "denied",
  ad_storage: "denied"
})

When the user accepts:

window.gtag("consent", "update", {
  analytics_storage: "granted",
  ad_storage: "granted"
})

When the user declines:

window.gtag("consent", "update", {
  analytics_storage: "denied"
})

This allows the Google tag to operate in restricted cookieless mode.

Series: Privacy-First Analytics for Modern Web Apps

Why Cookie Consent Breaks Your Analytics
Google Consent Mode Explained (React + TypeScript)
Ads, Tracking, and the Legal Reality in the EU and UK
The Hybrid Analytics Architecture

About this series

This series is based on real-world work building CSSEXY, a visual UI platform where understanding user behaviour is essential for improving the product.

All articles are also available on CSSEXY and there in the Gallery.

The HTML popover Attribute — Complete Deep Dive

Anja Beisel — Wed, 18 Mar 2026 18:32:53 +0000

The popover attribute is a modern, built-in way to create lightweight overlays like:

dropdowns
menus
tooltips
context panels
mini-dialogs

It is native HTML, meaning:

no JavaScript library required
no ARIA hacks required
no portal logic
minimal focus management (mostly handled for you)

It was added as part of the Open UI / HTML Living Standard and is now supported in modern Chromium, Safari, and Firefox versions.

Why this matters

For years, building dropdowns, menus, and overlays meant:

custom JS state management
focus traps
event listeners everywhere
z-index bugs
accessibility edge cases

The Popover API replaces most of that with native browser behavior.

This is one of the biggest shifts in UI development since <dialog>.

Popover vs Dialog vs Div

Feature	Popover	Dialog	Div + JS
Built-in open/close	✅	✅	❌
Light dismiss	✅	❌ (modal only)	❌
Top layer	✅	✅	❌
Focus management	Partial	Strong	Manual
Positioning	Needs anchor	Centered	Flexible
Best for	Menus, dropdowns	Modals	Custom layouts

Basic Concept

A popover is a hidden element that can be shown/hidden declaratively via attributes. You declare

<div popover id="menu">
  Hello Popover
</div>

The element is hidden by default. To show it, connect it to a button:

<button popovertarget="menu">Open</button>

That’s it. No JS required.

How it works internally

When a popover is opened, it is removed from display: none, enters the top layer (like <dialog>) and so renders above all stacking contexts and behaves independently of z-index, and is not clipped by overflow: hidden.

popover Attribute Values

`<div popover="auto">` or `<div popover>` (default)

Behavior

clicking outside closes it
pressing ESC closes it
only one auto popover open at a time

This is ideal for menus, dropdowns, tooltips, context panels

`<div popover="manual">`

Behavior

does NOT close automatically
you must close it manually via JS
multiple can be open simultaneously

Use this when you need custom open/close logic, you're building complex UI.

How To Trigger a Popover

Declarative Trigger

<button popovertarget="myPopover">
  Open
</button>

<div popover id="myPopover">
  Content
</div>

You can control the toggle behavior with popovertargetaction with possible values toggle (default), show or hide.

<button
   popovertarget="myPopover"
   popovertargetaction="show">

JavaScript API

You can control popovers manually

const pop = document.getElementById("myPopover");

pop.showPopover();
pop.hidePopover();
pop.togglePopover();

// check popover state
pop.matches(":popover-open");

Styling Popovers

The default styling depends on the browser. For example in Chrome you see

[popover]:where(:not(:popover-open)) {
   display: none;
}

[popover]:popover-open {
   display: block;
   overlay: auto !important;
}

[popover] {
   position: fixed;
   position-anchor: auto;
   width: fit-content;
   height: fit-content;
   color: canvastext;
   background-color: canvas;
   inset: 0px;
   margin: auto;
   border-width: initial;
   border-style: solid;
   border-color: initial;
   border-image: initial;
   padding: 0.25em;
   overflow: auto;
}

The Popover is in the top layer, with fixed position, and centered on the visible screen. A simple way to style it is to leave its positioning, inset, and margin alone.

[popover] {
   border: none;
   border-radius: var(--radius-xl);
   box-shadow: var(--shadow-lg);
   padding-block: calc(var(--spacing) * 3);
   padding-inline: calc(var(--spacing) * 3);
   width: max-content;
   max-width: 40rem;
}

To add an effect when the Popover opens, use the pseudo class :popover-open like in

[popover].popIn:popover-open {
   animation: menuPopIn 0.2s;
}

@keyframes menuPopIn {
   0% {
      opacity: 0;
      transform: scale(0.9, 0.9);
   }
   60% {
      opacity: 1;
      transform: scale(1.03, 1.03);
   }
   100% {
      transform: scale(1, 1);
   }
}

The open Popover has a ::backdrop pseudo-element which you can style

[popover].showBackdrop::backdrop
{
   background-color: var(--blue-500-10);
   backdrop-filter: blur(8px);
}

Popover positioning

As mentioned before, a popover is opened on the top layer, position fixed and centered.

But what if I want a popover for example positioned relative to the button which opens it?

.popover-wrapper {
   position: absolute;
   top: 0;
   left: 0;
}

<div class="relative">
   <button type="button" popovertarget="popover3">Open popover</button>
   <div id="popover3" popover="auto" class="popover-wrapper">
      ...
   </div>
</div>

As you've probably guessed, the popover will not behave like a normal absolutely positioned element inside a relative parent. Popover elements are rendered in the top layer. They are removed from normal DOM stacking. They are not positioned relative to their DOM parent. It will appear at Top-Left of the viewport.

If you want to position a popover relative to another element, you have three real options

anchor Positioning (Best modern solution)
JS positioning

const rect = button.getBoundingClientRect();

popover.style.top = rect.bottom + "px";

popover.style.left = rect.left + "px";

don’t use popover

Use a normal <div>. Toggle visibility manually. Then position: absolute works normally.

Anchored Positioning

Modern browser support anchor positioning

button {
  anchor-name: --tabs;
}

[popover] {
  position-anchor: --tabs;
}

This allows true dynamic anchoring without JS.

By assigning an anchor name and then the anchor to the popover with position-anchor, the distance between the anchor and the viewport top and left is available in the styles of the popover.

.anchor {
    anchor-name: --tabs;
}

.anchored-popover {
    position-anchor: --tabs;
    top: anchor(bottom);
    left: anchor(right);
    transform: translateX(-100%);
    margin: 0;
}

<div>
   <button type="button" popovertarget="popover3" class="anchor">Anchor positioned popover</button>
   <div id="popover3" popover="auto" class="anchored-popover">
      <ul>
         <li>Tree</li>
         <li>Add</li>
         <li>Edit</li>
         <li>Assign CSS</li>
      </ul>
   </div>
</div>

No anchor positioning in older browsers: CSS supports check + JS fallback

Popover API and CSS Anchor Positioning are both young, with Popover API being realistically supported by all modern engines since April 2024. CSS Anchor Positioning only recently landed in Firefox (late 2025).

Though you could demand that your users work with modern browser only, there is a safer way and it is not hard to set up.

Use CSS @supports to check if your browser supports CSS anchoring

@supports (anchor-name: --a) {
   .anchor { 
      anchor-name: --tabs; 
   }

   .anchored-popover {
      position-anchor: --tabs;
      top: anchor(bottom);
      left: anchor(right);
      transform: translateX(-100%);
   }
}

If CSS anchoring is not supported, add a JS fallback, here one way to do it with a React Custom Hook

const supportsAnchors = (): boolean => {
   return !!CSS?.supports?.("anchor-name: --a");
};

export const useGetAnchorStyles = ({
   anchorName,
   pos,
   offSetH,
   offSetV,
   popoverRef,
   anchorRef,
}: {
   anchorName: string;
   pos: TPos;
   offSetH?: string;
   offSetV?: string;
   popoverRef: RefObject<HTMLElement | null>;
   anchorRef: RefObject<HTMLElement | null>;
}) => {
   const [styles, setStyles] = useState<CSSProperties>({});

   useEffect(() => {
      const pop = popoverRef.current;
      const anchor = anchorRef.current;
      if (!pop || !anchor) return;

      const handleToggle = (e: Event) => {
         const toggleEvent = e as ToggleEvent;
         const isOpen = toggleEvent.newState === "open";

         if (isOpen && !supportsAnchors()) {
            const nextStyles = getPopUpPositionRelativeToAnchor({
               pos,
               offSetH,
               offSetV,
               popoverRef,
               anchorRef,
            });
            setStyles(nextStyles);
         }
      };
      pop.addEventListener("toggle", handleToggle);

      return () => {
         pop.removeEventListener("toggle", handleToggle);
      };
   }, [popoverRef, anchorRef, pos, offSetH, offSetV]);

   useEffect(() => {
      if (supportsAnchors()) {
         const nextStyles = getAnchorStyles({
            anchorName,
            pos,
            offSetH,
            offSetV,
         });
         setStyles(nextStyles);
      }
   }, [anchorName, pos, offSetH, offSetV]);

   return styles;
};

And then in your component you set the styles generated by useGetAnchorStyles on the popover which results, depending on the make and age of the browser of the user, in a relative position of the top left corner of the popover as achor() or in pixel.

React style example

// browser does support anchor positioning
{
   "positionAnchor": "--html-tree-anchor",
   "top": "anchor(bottom)",
   "left": "anchor(left)"
}
// browser does not support anchor positioning
{
   "left": "73.5px",
   "top": "321.25px"
}

While you are here: Fix Popovers Above `<iframe>` with pure CSS

When using the Popover API, the browser normally closes a popover automatically when the user clicks outside it. This is called light dismiss and works out of the box with:

<div popover="auto">...</div>

However, there is one common case where this breaks. If a popover sits above an <iframe>, clicking on the iframe does not close the popover. Why? Because an iframe is a separate browsing context. Pointer events inside it do not reach the parent document. So when the popover is open, user clicks iframe, event handled inside iframe document, parent page never receives the outside click and popover stays open.

The modern CSS solution

You can disable pointer interaction with the iframe whenever a popover is open:

body:has(:popover-open) iframe {
  pointer-events: none;
}

How it works

This uses three modern CSS features :has(), :popover-open and pointer-events: none. :has() allows a parent element to react to the state of its descendants. body:has(:popover-open) means "if any element in the document currently has an open popover". pointer-events: none removes the element from pointer hit-testing. Now when a popover is open CSS disables pointer events on iframe. When the user clicks outside the popover in the iframe area, the click goes to the parent page and the browser performs automatic popover light-dismiss, means the popover closes.

This technique is useful when you have UI elements above an iframe, such as preview panels, embedded demos, code playgrounds, editors with a rendered output, and dashboards with embedded content.

This tiny CSS snippet is super clever. I did discuss my initial problem, can't close popovers with click over iframe, with ChatGPT. There were some long and complex suggestions where and how to attach event listeners, or add manual overlays, checking the internet, and answering patiently my requests for a simple solution. CSS and HTML become really clever, but we are not used to it. I keep the one above as my little spell, which shall guide me to think straight about a modern HTML and CSS solutation first, and plan the JS fallback really just if I must.

Common gotchas

Popovers ignore parent positioning (top layer)
margin: auto centers them by default
Clicks inside iframes don’t close them
Anchor positioning is not fully supported everywhere yet

Final thought

The Popover API is not just a new feature — it’s a shift.

It moves UI patterns from JavaScript into the browser itself.

Fewer bugs. Less code. Better accessibility.

If you want to explore more modern HTML, CSS, and SVG patterns,

you can find interactive examples on CSSEXY.com.

Your Cookie Consent Banner Is Probably Breaking Your Analytics

Anja Beisel — Wed, 18 Mar 2026 18:16:34 +0000

Privacy-First Analytics for Modern Web Apps (Part 1)

How GDPR compliance causes data loss — and what modern web apps do instead

Most cookie consent banners quietly destroy your analytics.

If users decline cookies, tools like Google Analytics stop tracking completely.
For many websites, that means losing 30–50% of user behaviour data.

That creates a real problem for developers:

How do you respect GDPR and ePrivacy rules while still understanding how users use your product?

The real problem

Modern web applications depend on analytics to answer simple but critical questions:

Which pages do users visit?
Which features are actually used?
Where do users drop off?

But in the UK and EU, analytics intersects with:

GDPR
ePrivacy / PECR

These regulations require user consent before setting non-essential cookies.

And that’s where things break.

What actually happens with basic cookie consent

The typical implementation looks like this:

User visits site
  ↓
Cookie banner appears
  ↓
Accept → Google Analytics loads
Decline → Google Analytics never loads

In many React applications, the logic looks roughly like this:

if (userAcceptedAnalytics) {
  ReactGA.initialize(GA_ID)
}

If the user declines, Google Analytics never runs.

That means for a significant portion of your users:

no pageviews are recorded
no navigation behaviour is tracked
no product usage data is captured
From an analytics perspective, those users effectively do not exist.

Why this breaks your analytics

Let’s say your site gets 1000 visitors:

1000 visitors
  ↓
40% decline cookies
  ↓
Google Analytics sees only 600 users

That means:

you miss real user journeys
feature usage becomes unclear
conversion funnels are incomplete

Your data becomes:

❌ incomplete
❌ biased
❌ misleading

This is especially painful when building:

SaaS products
developer tools
interactive apps

Why this is still the “safe” approach

Despite the drawbacks, this model is widely used because it is:

✔ legally conservative
✔ easy to implement
✔ easy to explain

No cookies before consent → no legal ambiguity.

Important: this is a Google Analytics problem

This issue exists because of how Google Analytics works:

relies on cookies (_ga, _gid)
uses persistent identifiers
tracks users across sessions

That design conflicts directly with modern privacy requirements.

What modern apps do instead

Instead of relying on a single tool, many teams now use a hybrid analytics architecture:

Visitor arrives
  ↓
Anonymous analytics runs for everyone
  ↓
Cookie banner appears

Accept → Google Analytics enabled
Decline → Google Analytics disabled

This setup combines:

1. Privacy-first analytics (for all users)

Tools like:

Umami
Plausible

These provide:

pageviews
referrers
device types
product usage events

Without:

cookies
persistent identifiers

2. Google Analytics (opt-in only)

Only enabled after user consent.

Provides:

funnels
campaign tracking
deeper engagement insights

Why this approach works

This architecture gives you:

✔ visibility into real product usage
✔ compliance with privacy regulations
✔ a cleaner mental model

Instead of choosing between:

privacy OR analytics

you get:

privacy AND useful analytics

This is becoming standard practice

This hybrid approach is increasingly used in:

SaaS products
developer tools
modern web platforms

Where understanding product behaviour is essential.

Key takeaway

If you rely only on Google Analytics with cookie consent:

you are likely missing a large portion of user behaviour

Modern web apps solve this by combining:

privacy-first analytics for all users
Google Analytics only after consent

What’s next

In the next article, we’ll go deeper into:

👉 Google Consent Mode

what it actually does
Basic vs Advanced Consent Mode
how to implement it in React + TypeScript

Final thought

Analytics is no longer just a marketing tool.

For modern web applications, it’s a product development tool.

Understanding how users move through your app helps you:

improve onboarding
identify friction
build better features

The challenge is doing that without violating user trust.

That’s exactly what this series is about.

Series: Privacy-First Analytics for Modern Web Apps

Why Cookie Consent Breaks Your Analytics (this article)
Google Consent Mode Explained (React + TypeScript)
Ads, Tracking, and the Legal Reality in the EU and UK
The Hybrid Analytics Architecture

About this series

This series is based on real-world work building CSSEXY, a visual UI platform where understanding user behaviour is essential for improving the product.

All articles are also available on CSSEXY and there in the Gallery.

Stop Rebuilding Modals: A Deep Dive into the Element

Anja Beisel — Sun, 22 Feb 2026 15:16:30 +0000

Introduction

For more than a decade, building modals on the web meant re-implementing infrastructure:

focus traps
scroll locking
ARIA wiring
z-index battles
accessibility edge cases

Frameworks solved it with layers of abstraction, but the browser had no native solution.

That changed.

The <dialog> element is no longer an experimental curiosity. Since 2022–2023, it has become a fully viable, cross-browser modal primitive — complete with focus management, top-layer rendering, backdrop handling, and built-in accessibility.

This article explains what <dialog> really does, how it differs from show() and showModal(), how it compares to <details> and the Popover API, and when you should (and shouldn’t) replace your custom modals with it.

How to implement

<dialog id="myDialog">
   <p>Hello world</p>
   <button onclick="myDialog.close()">Close</button>
</dialog>

<button onclick="myDialog.showModal()">Open</button>

JavaScript API

The real power of <dialog> is in its methods:

.showModal()

sets open attribute
promotes dialog into “top layer”
creates ::backdrop
applies inert to rest of document
exposes the dialog as aria-modal="true" to assistive technology
moves focus
registers ESC listener

The “top layer” is not just used by dialog, but also by Fullscreen API, Popovers, and Context menus. It sits above normal stacking context. That’s why z-index does not affect modal dialogs at all: they are rendered in a separate top layer above the normal stacking context.

.show()

sets open attribute
keeps the dialog in normal layout and stacking context

When you open the dialog with show() there is no inert, backdrop, focus trap, aria-modal, just the visible dialog.

.close()

Closes dialog.

Backdrop Styling

When opened with .showModal(), the browser creates a backdrop as a special pseudo-element. You style it like this:

dialog::backdrop {
  background: rgba(0, 0, 0, 0.5);
}

Common Mistakes When Using `<dialog>`

Even though <dialog> simplifies modal behavior, there are a few pitfalls that developers frequently run into.

Using `open` Instead of `showModal()`

Setting <dialog open> or dialog.open = true does not make the dialog modal. It only makes it visible.

There is no focus trap, no backdrop, no inert background, no top-layer behavior.

If you need modal behavior, always use dialog.showModal().

Forgetting to Label the Dialog

A dialog without an accessible name is confusing for screen reader users.

Always provide one of <dialog aria-labelledby="titleId"> or <dialog aria-label="Delete item">.

If the dialog has no heading and no label, it will simply be announced as “dialog”, which provides no context.

Animating the open Attribute Incorrectly

A closed dialog is effectively display: none. That means transitions often don’t run when the dialog first opens.

To animate correctly, you either use @starting-style (modern CSS), or apply a class in the next animation frame after calling showModal().

Expecting `show()` to behave like `showModal()`

show() only makes the dialog visible. It does not move it to the top layer, trap focus, create a backdrop, make the background inert.

If you need blocking interaction, use showModal().

Opening Multiple Modal Dialogs

Only one modal dialog can be open at a time. Calling showModal() on a second dialog while one is already open will throw an error. If you need stacked interactions, close the current dialog before opening another.

Re-Implementing What the Browser Already Does

Some developers still add their own focus trap, add role="dialog" manually, add aria-modal="true" manually, lock body scroll manually.

When using showModal(), this is unnecessary and can even conflict with native behavior. Let the platform handle it.

Accessibility Notes

By default a showModal() dialog

behaves like role="dialog"
has aria-modal="true" set

You still need accessible labeling. Screen readers need to know what the dialog is about. So this is good

<dialog aria-labelledby="dialogTitle">
  <h2 id="dialogTitle">Delete item</h2>
  ...
</dialog>

<dialog aria-labelledby="confirm-title" aria-describedby="confirm-desc">
  <h2 id="confirm-title">Delete file?</h2>
  <p id="confirm-desc">This cannot be undone.</p>
  ...
</dialog>

<dialog aria-label="Delete item">

Note: If your dialog contains no heading at all, you MUST provide a label via aria-label. Because a dialog without a name is bad for screen readers.

What `inert` actually does

When you call dialog.showModal() the browser internally makes everything outside the dialog inert. inert is an HTML attribute that means this subtree is not interactive and not focusable. It does three things

removes elements from the tab order
blocks pointer events
removes the subtree from the accessibility tree and prevents user interaction

What's the difference to

display: none: removes from layout and accessibility tree
visibility: hidden: hides visually but still affects layout
inert: keeps layout visible but disables interaction + accessibility

That’s why background content is still visible but inaccessible.

How Focus Trapping Works Without JS

With <dialog> when opened then

the browser moves focus inside the dialog
Tab cycles only inside dialog
Shift+Tab also cycles inside
ESC triggers cancel

On close the previous focus is restored. No JS required.

Tip: Initial focus

Browser will focus on the first focusable element inside dialog. If none exist, it may focus the dialog itself. Best practice is to set the focus on an element in the dialog, e.g. <button autofocus>Cancel</button>.

All the work you do not need to do

Before <dialog>, modals required:

focus trap logic
scroll locking
ARIA wiring
z-index management
ESC handling
backdrop click logic

Now: dialog.showModal().

Should you replace all my modals with `<dialog>`?

Not automatically. But the new modals <dialog> is often the cleanest option if it fits your UX.

How new really is the `<dialog>` HTML element?

Although was introduced around 2012 and implemented in Chrome in 2014, it wasn’t fully viable cross-browser until 2022–2023 when Safari and Firefox shipped consistent modal behavior, ::backdrop, and inert. That alignment marked its real turning point.

But it still feels new now, because around 2022–2024 Popover API shipped, Inert shipped, Anchor positioning started appearing, Container queries became stable. So the platform shifted toward native UI primitives. <dialog> suddenly made sense again.

Before <dialog>, modals were accessibility nightmares, focus-trap hacks, scroll-lock hacks, z-index wars, screen-reader inconsistencies. The spec authors wanted a built-in, accessibility-safe modal primitive. It just took years to reach consistent implementation.

So which of my custom modals should I replace straight away?

When <dialog> is a great replacement

You want a standard centered modal
You want correct focus trap + restore with minimal code
You don’t need fancy portal stacking logic
You’re happy with “platform behavior” (ESC, backdrop, top layer)

When you might not want <dialog> everywhere

Your modal is actually a drawer / side panel (sometimes better as a “region” or popover, depending)
You rely on a UI library modal that already handles everything well (e.g. AntD Modal)
You need very custom stacking / nested modals / toasts interacting with modals
You need full control over close timing/animations (still possible, but a bit more work)

A pragmatic recommendation

Migrate gradually. Replace simple confirm/alert/small-form modals first. Keep complex stacked/drawer-style modals where a framework abstraction makes more sense.

Last not least, what's the alternative? A comparison of `<dialog>` vs `<details>` vs `popover`

`<details>` (2010s)

Purpose: simple disclosure / expand-collapse.

Behavior: built-in toggle, open attribute, keyboard support

Adoption story: adoption was slow, but it was eventually widely accepted and is now commonly used

Pattern: declarative + small built-in state machine.

`<dialog>` (viable 2022)

Purpose: modal / interaction interruption

Behavior: modal state machine, focus trap, inert background, backdrop, top layer

Adoption story: long stagnation, suddenly viable once Safari + Firefox implemented fully, but still catching up in ecosystem mindset

Pattern: semantic + heavy interaction behavior.

`popover` (2023+)

Purpose: lightweight floating UI

Behavior: top layer, light dismiss, ESC handling, no focus trap

Adoption: very new, likely to replace many custom dropdown libraries

Pattern: attribute-based primitive, not a new HTML element.

When should you use dialog and when is it a popup?

Use a modal <dialog> (showModal()) when you need to stop the user from continuing until they respond. Typical signals:

Decision required: confirm / cancel (“Delete snippet?”, “Discard changes?”)
Blocking error: “Session expired — sign in again”
Wizard / required form: must finish or explicitly dismiss
Critical info where continuing without acknowledging is risky
You need focus trap + inert background (keyboard can’t escape to the page)

Examples: confirm delete, unsaved changes prompt, payment / security step, required “choose one option to continue”.

Use a non-modal dialog / popup when it’s supplementary, doesn’t require a decision, and the user should be able to keep working. This includes:

Tooltips (“This field must be unique”)
Info popovers (“What’s this?” help bubble)
Context menus (right-click style menu)
Inline pickers (color picker, date picker, emoji picker)
Autocomplete dropdowns
Toast notifications (not a dialog at all)

Conclusion

<dialog> is not just another HTML element. It represents a shift in the web platform: moving interaction infrastructure from JavaScript frameworks into the browser itself.

For years, modal behavior required custom state machines. Today, a single call to dialog.showModal() gives you:

Focus trapping
Background inerting
Backdrop rendering
Escape handling
Top-layer stacking
Accessible semantics

That doesn’t mean you should rewrite every modal overnight. But it does mean that for simple, blocking interactions, the platform now provides a robust, accessible default.

Just as <details> simplified disclosure widgets, and popover is simplifying floating UI, <dialog> simplifies modal interaction.

The web platform is catching up with the patterns we’ve been re-implementing for years.

And this time, it’s doing it right.

Also available on CSSEXY

This article is based on real-world work building CSSEXY, a visual UI platform helping you using the most up to date HTML, CSS and SVG in the typical CSSEXY way, what is extreme and easy.

The articles is also available in the CSSEXY Gallery with examples. From there you can download it and use it as template to build your own dialogs.

DEV Community: Anja Beisel

The Hybrid Analytics Architecture

Privacy-First Analytics for Modern Web Apps (Part 4)

Why a hybrid analytics setup helps

Layer 1 — Privacy-first analytics

Example: Event tracking with Unami

Layer 2 — Google Analytics (opt-in only)

Example: Remember consent and track GA events only with given content

How the two layers work together

What each layer is best at

Practical recommendation

One final note on privacy

Series: Privacy-First Analytics for Modern Web Apps

About this series

Ads, Tracking, and the Legal Reality in the EU and UK

Privacy-First Analytics for Modern Web Apps (Part 3)

Why analytics, advertising, and consent are tightly connected — and where the risks actually are

The three types of advertising

1. Contextual advertising (privacy-first)

2. Personalized advertising (tracking-heavy)

3. Conversion tracking (the hidden layer)

Where Advanced Consent Mode fits in

The legal reality in the EU and UK

Why Advanced Consent Mode is debated

What can actually happen in practice

What this means for developers

Key takeaway

Series: Privacy-First Analytics for Modern Web Apps

About this series

Google Consent Mode Explained (React + TypeScript)

Privacy-First Analytics for Modern Web Apps (Part 2)

What Advanced Consent Mode does

Basic vs Advanced Consent Mode

Implementing Basic Consent Mode (React + TypeScript)

Implementing Advanced Consent Mode

Series: Privacy-First Analytics for Modern Web Apps

About this series

The HTML popover Attribute — Complete Deep Dive

Why this matters

Popover vs Dialog vs Div

Basic Concept

How it works internally

popover Attribute Values

<div popover="auto"> or <div popover> (default)

<div popover="manual">

How To Trigger a Popover

JavaScript API

Styling Popovers

Popover positioning

Anchored Positioning

No anchor positioning in older browsers: CSS supports check + JS fallback

While you are here: Fix Popovers Above <iframe> with pure CSS

The modern CSS solution

How it works

Common gotchas

Final thought

Your Cookie Consent Banner Is Probably Breaking Your Analytics

Privacy-First Analytics for Modern Web Apps (Part 1)

The real problem

What actually happens with basic cookie consent

Why this breaks your analytics

Why this is still the “safe” approach

Important: this is a Google Analytics problem

What modern apps do instead

1. Privacy-first analytics (for all users)

2. Google Analytics (opt-in only)

Why this approach works

This is becoming standard practice

Key takeaway

What’s next

Final thought

Series: Privacy-First Analytics for Modern Web Apps

About this series

Stop Rebuilding Modals: A Deep Dive into the Element

Introduction

How to implement

JavaScript API

Backdrop Styling

Common Mistakes When Using <dialog>

Using open Instead of showModal()

`<div popover="auto">` or `<div popover>` (default)

`<div popover="manual">`

While you are here: Fix Popovers Above `<iframe>` with pure CSS

Common Mistakes When Using `<dialog>`

Using `open` Instead of `showModal()`

Expecting `show()` to behave like `showModal()`

What `inert` actually does

Should you replace all my modals with `<dialog>`?

How new really is the `<dialog>` HTML element?

Last not least, what's the alternative? A comparison of `<dialog>` vs `<details>` vs `popover`

`<details>` (2010s)

`<dialog>` (viable 2022)

`popover` (2023+)