CtrlK
BlogDocsLog inGet started
Tessl Logo

vannifr/cross-browser-render-check

Use when you need to check browser-specific CSS/layout/JS rendering differences (Chromium/Firefox/WebKit) before shipping a CSS/JS change or investigating compatibility issues across engines. NOT for viewport/breakpoint layout review (use responsive-visual-review), NOT for functional/interaction E2E testing across browsers (use playwright-testing), NOT for designing a polyfill/feature-detection fix.

66

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files
name:
cross-browser-render-check
description:
Use when you need to check browser-specific CSS/layout/JS rendering differences (Chromium/Firefox/WebKit) before shipping a CSS/JS change or investigating compatibility issues across engines. NOT for viewport/breakpoint layout review (use responsive-visual-review), NOT for functional/interaction E2E testing across browsers (use playwright-testing), NOT for designing a polyfill/feature-detection fix.

Cross-Browser Render Check

Renders the same pages in Chromium, Firefox, and WebKit at one fixed viewport and diffs what a human would notice — font fallbacks, layout quirks, unsupported CSS features, console errors unique to one engine. Works on any website; no existing multi-browser test setup required, though it will reuse one if the project already has Playwright projects configured per engine.

When not to use this

  • Different screen widths, same engine → responsive-visual-review. This skill holds the viewport fixed and varies the engine instead.
  • Functional testing across browsers (does the checkout flow work in Safari) → playwright-testing / the project's own E2E suite. This skill never clicks anything — it only compares what renders.
  • A single already-reported browser bug → just fix it; this skill is for systematic sweeps, not one-off triage.
  • Deciding how to fix a found incompatibility (polyfill, @supports fallback, drop the feature) — that's a design decision for the person fixing it, not something to prescribe from a rendering diff alone.

Phase 0 — Scope

  1. Reuse the same page set as responsive-visual-review if a recent run exists (homepage, one content/detail page, one form page, one long-form/typography-heavy page — 3-5 pages total).
  2. Pick one fixed, non-mobile viewport (992×900 is a reasonable default — distinct from responsive-visual-review's breakpoint sweep so the two skills don't overlap). Add a mobile-width pass only if the site's mobile experience diverges meaningfully between engines (rare, but WebKit's mobile emulation quirks are a known exception).

Phase 1 — Capture

For each page, capture a full-page screenshot in each of the three engines at the same viewport:

  • Playwright MCP tools, switching browser_type per engine, or
  • npx playwright test --project=chromium --project=firefox --project=webkit if the project already has a multi-browser Playwright config (check playwright.config.ts first — most projects only run Chromium by default; don't assume multi-engine config exists).
  • Capture browser console output per engine alongside the screenshot — engine-specific JS errors are a common, easy-to-miss finding.

Name captures <page-slug>-<engine>.png, saved to the scratchpad directory (throwaway review artifact, not for commit).

Phase 2 — Checklist

Compare the three screenshots per page side by side.

Rendering

  • Font fallback/rendering consistent (no missing-glyph boxes, no wildly different line-height causing reflow)
  • Flexbox/Grid layout identical across engines (Safari's older Grid gaps and Firefox's flexbox min-content defaults are classic divergence points)
  • CSS features used actually supported in all three engines — check caniuse.com for any feature the site uses that isn't universally safe (:has(), container queries, backdrop-filter, text-wrap: balance, subgrid, :focus-visible quirks)
  • Form control default styling (checkboxes, radios, <select>, date/time inputs) — Safari and Firefox diverge most here
  • Scrollbar/overlay behavior (Firefox's overlay scrollbar vs WebKit/Chromium's reserved gutter can shift layout width)
  • Video/audio codec or format actually plays in all engines if the page embeds media

Console

  • No JS errors present in one engine but not the others (a common sign of a missing polyfill or an engine-specific API assumption)

Phase 3 — Findings

Severity-ranked, each with: page, engine(s) affected, screenshot pair (reference engine vs divergent engine), and a suspected CSS/JS cause where identifiable — "Safari renders the pricing grid columns unequal width, likely grid-template-columns: auto interacting with old Safari Grid auto sizing" is actionable; "looks different in Safari" is not.

SeverityExamples
CriticalPage unusable or content inaccessible in one engine
HighVisible layout break, broken form control, engine-unique JS error breaking a feature
MediumNoticeable but non-blocking visual divergence (font rendering, spacing)
LowCosmetic-only, sub-pixel differences a user wouldn't consciously notice

Report findings for triage — this skill does not fix the underlying CSS/JS.

Workspace
vannifr
Visibility
Public
Created
Last updated
Publish Source
CLI
Badge
vannifr/cross-browser-render-check badge