Replace custom code with modern CSS.

For frontend teams

Replace custom code with modern CSS.

Scan a public page to see where modern HTML and CSS can replace custom code. Each finding includes the evidence and what to test before making the change.

Public page URL No login needed

Audit my page

What a finding looks like

Each finding connects the current pattern to a possible platform replacement, then shows the evidence and tradeoffs behind it.

#### 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 on this page `.newsletter-modal` `#mobile-menu` Newsletter signup and mobile navigation overlays (2 instances)

See the native dialog working on CodePen ↗

#### Current HTML + JavaScript

<div class="modal" role="dialog"
  aria-modal="true" hidden>
  <button class="modal__close">Close</button>
  <!-- modal content -->
</div>
/ Original JavaScript excerpt /
const modal = document.querySelector('.modal');
trigger.addEventListener('click', () => {
  modal.hidden = false;
  trapFocus(modal);
});

#### Modern alternative

<dialog id="site-modal">
  <form method="dialog">
    <button>Close</button>
  </form>
  <!-- modal content -->
</dialog>
const modal = document.querySelector('#site-modal');
trigger.addEventListener('click', () => modal.showModal());

Everything the scanner checks

The audit reports only the checks below: 18 code and behavior patterns, plus 9 mechanical CSS quick wins. Every recommendation must be supported by evidence captured from the public page.

27 reportable checks

18 code and behavior patterns

9 mechanical CSS quick wins

Custom code modern HTML and CSS can simplify

18 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

CSS quick wins

9 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

From rendered page to verified finding

1. ### Render the public page Chrome captures rendered HTML, interaction signals, same-origin CSS, and JavaScript. 2. ### Flag evidence, not conclusions Deterministic checks surface candidate patterns across the supported categories. 3. ### 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 18 code and behavior patterns plus 9 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 take about 2 minutes. CSS Radar renders the page, explores safe interactions, checks the captured code, and validates the evidence before building the report. You can cancel while it is running.

What happens to my URL and the report?

Anyone with the report URL can open it. Reports are not listed on the site or included in its sitemap. They are automatically deleted after 30 days. 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