Modern CSS Radar: replace custom code with modern CSS

What your report looks like

The report turns the scan into an action plan: verified replacements with evidence, what to test, and a checklist you can use before shipping. You can also print or save the full report as a PDF.

Custom JavaScript modal overlays

Possible replacement: <dialog>

Why this was flagged: The page uses script-managed modal surfaces without native <dialog> behavior.

Why it may help

Deletes custom focus-trap logic and open-state tracking.
Lets the browser handle top-layer rendering and Escape key dismissal.
Provides modal semantics and focus management with less custom JavaScript.

Found in

Newsletter signup and mobile navigation overlays .newsletter-modal#mobile-menu

See the example on CodePen for native dialog (opens in a new tab)

Current HTML + JavaScript

<div class="modal" role="dialog"
  aria-modal="true" hidden>
  <button class="modal__close">Close</button>
  <!-- modal content -->
</div>


const modal = document.querySelector('.modal');
trigger.addEventListener('click', () => {
  modal.hidden = false;
  trapFocus(modal);
});

Modern alternative

<button type="button"
  commandfor="site-modal"
  command="show-modal">Open dialog</button>
<dialog id="site-modal" aria-label="Example dialog">
  <button type="button"
    commandfor="site-modal"
    command="close">Close</button>
  …
</dialog>

Everything the scanner checks

The scanner checks 20 code and behavior patterns plus 11 CSS quick wins, then reports only recommendations backed by captured evidence.

Custom code modern HTML and CSS can simplify

20 checks

These become findings only when the scanner captures matching implementation evidence.

Custom modals could become <dialog>
Custom popovers, tooltips, and dropdowns could become the Popover API
Scripted accordions and disclosure widgets could become <details> + <summary>
JavaScript-assisted entry transitions could become @starting-style
Parent state classes toggled by JavaScript could become :has()
Whole sections manually removed from the tab order could become the inert attribute
System theme detection scripts could become prefers-color-scheme + light-dark()
Smooth-scroll handlers and fixed-header offset math could become scroll-behavior + scroll-margin
Timer-driven logo and news tickers could become CSS keyframes with pause and reduced-motion states
Headings or steps numbered from JavaScript could become CSS counters
Decorative count-up libraries and timers could become @property + CSS counters
JavaScript-driven animated borders could become @property + conic-gradient()
Per-frame coordinates along a fixed path could become CSS Motion Path
Scripted before-and-after reveal geometry could become CSS masks driven by one custom property
Scroll-triggered reveal scripts could become animation-timeline: view()
Carousel and slider libraries could become CSS scroll snapping
Auto-growing textarea scripts could become field-sizing: content
JavaScript-positioned tooltips could become CSS anchor positioning
ResizeObserver classes used only for component layout could become CSS container queries
JavaScript scrollbar-width compensation could become scrollbar-gutter: stable

CSS quick wins

11 checks

These are matched directly in the collected stylesheets and shown separately in the report.

Percentage-padding aspect ratio boxes could become aspect-ratio
Transform-based centering could become place-items: center
100vh heights that break on mobile could become dvh and svh units
WebKit-only scrollbar styling could become scrollbar-color
Prefixed line-clamp workarounds could become line-clamp
Duplicated dark-mode color rules could become light-dark()
Resolution media queries for image density could become image-set()
Negative decorative layers that escape their component could become isolation: isolate
Paired physical spacing declarations could become logical properties
Clearfix pseudo-elements containing floats could become display: flow-root
Equal sibling margins in a non-wrapping flex layout could become gap

From rendered page to verified finding

Render the public page

Chrome captures rendered HTML, loaded stylesheets, and JavaScript, then explores desktop and mobile layouts.
Flag evidence, not conclusions

Deterministic checks surface candidate patterns across the supported categories.
Verify before reporting

Weak leads are rejected. Each finding includes evidence and tradeoffs to test.

The scanner only reports what a browser can verify on the public page. It does not inspect server-side code, authenticated states, or hidden business logic.

Every recommendation shows its work

What exists today

The page, interaction, and implementation evidence behind the finding.

What could replace it

The browser feature and the custom code it could simplify.

What to verify

Limitations and behavior to test before changing anything.

Built for public frontend work

A strong fit

Frontend teams maintaining older interaction code
Designers and developers preparing a redesign
Indie makers checking a public product or docs page

Outside this scan

Server-side code and authenticated product states
A full accessibility, performance, or security review
Changes that can only be judged with business context

Questions about the scan

Which pages can I scan?

CSS Radar can scan any public URL that Chrome can open without logging in. It cannot scan private network URLs. On pages with authentication or a paywall, it can only inspect the public state shown to a new visitor.

What can the audit not see?

CSS Radar cannot inspect server-side code or states that require an account. It explores safe interactions on the rendered page, but avoids forms and anything that could navigate away or change data. Very large HTML, CSS, or JavaScript sources may be shortened during analysis.

Why does it only check a fixed set of patterns?

CSS Radar currently checks 20 code and behavior patterns plus 11 mechanical CSS quick wins. Keeping a defined catalog lets the scanner require the right evidence for each recommendation. If a possible improvement falls outside that catalog, the audit does not report it.

Can I apply the findings directly?

Treat each finding as a recommendation to review, not an automatic patch. It includes the captured evidence, a possible replacement, browser support when available, and a To verify note. Read that note and test the current behavior before changing production code.

How long does a scan take?

Most scans finish within a few minutes. CSS Radar emails the report link as soon as it is ready, so you can close this page after the audit starts.

What happens to my email, URL, and report?

CSS Radar sends the submitted public URL and email address to its audit service. It uses the address to send the report or a notice if the audit cannot be completed, and adds it to Kit with the radar tag for occasional CSS Radar and modern CSS emails. You can unsubscribe from marketing emails at any time. Anyone with the report URL can open it. Reports are not listed on the site or included in its sitemap. The report file is scheduled for automatic deletion after 30 days, and the private audit record expires after 31 days. Kit keeps its subscriber record until you unsubscribe or ask for deletion. The free service allows each visitor to run up to 10 audits per day.

Keep going

Two ways to take this further.

Learn the patterns behind the scanner, or bring me in to audit and implement the rest.

The book

You Don't Need JavaScript

The modern HTML and CSS features this scanner looks for, explained through 27 practical examples you can use in real interfaces.

See what's in the book

Work with me

Need a full audit, or help implementing the changes?

I can audit the rest of your site and implement the changes that make sense for your codebase.

Email me at hey@theosoti.com

Prefer LinkedIn? Connect with me there.

Find what the platform can replace.

Paste one public URL to start an evidence-backed scan.

Audit my page

Replace custom code with modern CSS.