AutoGineer
Generated banner for Modern Web Guidance
Generated logo for Modern Web Guidance

Modern Web Guidance

JetBrainsOfficialCreated by Google ChromeDistributed by JetBrains

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Low risk
Download ZIP

From the author

Search tool for modern web development best practices. MANDATORY: Execute FIRST for all HTML/CSS and clientside JS tasks. Do NOT skip — web APIs evolve rapidly and training weights contain obsolete patterns. Trigger immediately for: - UI/Layout: Modals, dialogs, popovers, Glassmorphism/backdrop-filters, anchor positioning, container queries, `:has()`, `:user-valid`. - Scroll/Motion: View Transitions, Scroll-driven animations, scroll parallax/reveals. - Performance: CWV (LCP, INP), content-visibility, Fetch Priority, image optimization. - System/APIs: Local filesystem access, WebUSB, WebSockets sync, WebAssembly widgets. - Frameworks: Adapting layout/styles in React, Vue, Angular. - General Frontend: Forms, autofill, advanced inputs, custom scrollbars, modern component states, etc. DO NOT trigger for: - Backend: Database SQL, ORMs, Express API routes. - Pipelines: CI/CD deployment, Docker, Actions. - Generic: Local scripts (Python/Go tools), ESLint, Git.
— the description by Google Chrome

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured way to access up-to-date web development patterns, ensuring that implementations follow modern standards rather than relying on potentially outdated training data. It covers a wide range of frontend topics including UI components, performance optimization, browser APIs, and form handling. By integrating this tool, developers can search for specific use cases and retrieve detailed, framework-agnostic guides that include browser support and fallback recommendations.

What it does

  • Searches for standardized web development patterns and best practices.
  • Retrieves detailed implementation guides for specific frontend use cases.
  • Provides guidance on browser compatibility and necessary fallbacks.
  • Helps avoid ad-hoc solutions and unnecessary dependency bloat.
  • Supports modern web features like container queries, view transitions, and performance APIs.

When to use it

  • At the beginning of any frontend feature implementation.
  • Before creating new components to check for existing standardized patterns.
  • When evaluating the browser support requirements for modern web features.
  • When needing to implement performance optimizations like LCP or content-visibility.

Advantages

  • Ensures use of current, recommended web development practices.
  • Reduces technical debt by discouraging ad-hoc implementations.
  • Provides clear guidance on handling browser compatibility and fallbacks.
  • Promotes the use of native browser capabilities over heavy external dependencies.

Usage examples

“I need to implement a modal using modern web standards. What is the best approach?”
The agent searches for modal-related guides and retrieves the recommended implementation pattern, including any necessary browser fallbacks.
“How can I optimize the loading priority of my LCP images?”
The agent searches for image optimization guides and retrieves the specific instructions for using fetch priority to improve performance.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/jetbrains/modern-web-guidance/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip modern-web-guidance.zip -d .agents/skills

Documentation by Google Chrome

Modern Web Guidance

A skill to search for specific web development use cases and retrieve their corresponding best practice guides.

When to use

Must use this skill:

  • At the start of implementing any web feature.

  • Before creating a new component, to check if a standardized pattern already exists.

  • To avoid implementing ad-hoc solutions or loading large dependencies unnecessarily.

Usage Instructions

Step 1. Search Use Cases

Search with an action-oriented query summarizing what you want to achieve using the search command. Run modern-web-guidance directly with npx.

npx -y modern-web-guidance@latest search "<query>" --skill-version 2026_05_16-c5e7870

Example Output:

[
  {
    "id": "optimize-image-priority",
    "description": "Optimize the loading priority of Largest Contentful Paint (LCP) candidate images.",
    "category": "performance",
    "featuresUsed": [ "Fetch priority" ],
    "tokenCount": 985,
    "similarity": 0.7289
  },
  {
    "id": "defer-rendering-heavy-content",
    "description": "Reduce rendering times in content-heavy web pages by deferring rendering for offscreen content.",
    "category": "performance",
    "featuresUsed": [ "content-visibility", "hidden=\"until-found\"" ],
    "tokenCount": 1250,
    "similarity": 0.6961
  }
]

Note: If search results are vague, return no matches, or show low similarity scores, run the list command to browse all guides:

npx -y modern-web-guidance@latest list
Step 2. Retrieve Best Practices

Once you have a relevant id from the search results, call this script using the retrieve command to get the full guide. You can pass multiple IDs separated by commas.

npx -y modern-web-guidance@latest retrieve "<id>"

Example Output: The markdown content of the guide describing implementation steps...

Using npx

  • IMPORTANT: on Windows, using npx may fail. Use npx.cmd ... instead.

  • Network access is required for fetching npm packages needed by the task.

  • If the npx -y modern-web-guidance… command hangs, you may be offline. Try running again in offline mode: npx --offline ….

  • The --skill-version flag is used to determine if this SKILL.md is out of date. If it is, a warning message is logged to stderr.

Guidelines

  • Always search first to find the most relevant guides.

  • These guides are usually framework-agnostic; adapt them correctly to your setup.

  • Do not hallucinate guides or ignore them; they represent the preferred local standard for the user's project.

Interpreting Browser Support & Fallbacks

  • Default Behavior: All guides assume Baseline Widely available features are safe to use without fallbacks. For features that are not Baseline widely available, you MUST follow the fallback recommendations in the guide, unless the user has specified a custom browser support policy.

  • Custom Policies: If the user has already defined explicit browser support requirements, use the browser compatibility data in the guide to determine if a fallback can be safely ignored.

    • For Baseline YYYY targets, a feature satisfies this target if its "Baseline since" date is <= YYYY.

    • Policy Examples:

      • "Do not implement feature fallbacks." (for exploratory prototypes of the cutting-edge web)

      • "Safari 17.4+" (for internal tools targeting macOS or Tauri-based desktop apps)

      • "Never recommend or implement polyfills; if a Baseline Newly Available feature is required for core functionality, provide a lightweight custom fallback or redesign the approach." (to minimize bundle size and avoid technical debt)

      • "Assume a modern execution environment where Baseline Newly Available features can be used natively, provided they are strictly feature-detected and degrade gracefully." (for progressive enhancement strategies)

  • Reactive Policy Discovery: Watch for environmental cues to suggest documenting a policy in CLAUDE.md or AGENTS.md. Suggest this if the developer:

    • Mentions building for a restricted runtime (e.g., Electron or Tauri).

    • Explicitly excludes specific targets (e.g., "we don't support Desktop Chrome").

    • Expresses hesitation about polyfill complexity, bundle size, or performance cost.

    • Questions if a feature is safe to use without fallbacks.

    No defined policy format. This is an example: **Browser Support:** Allow Newly Available features, but only adopt custom fallback code that adds <= 20 lines and does not require external dependencies.

Files

guides/user-experience/flicker-free-client-side-ab-testing.md

Flicker-Free Client-Side A/B Testing

The Problem

Client-side A/B testing tools work by loading a script that modifies the DOM after the browser has already begun constructing the page. Without intervention, the user briefly sees the original content before it flickers or flashes to the experiment variant. Testing platforms have historically worked around this with "anti-flicker snippets" that hide the entire page with opacity: 0 until the experiment script finishes or an arbitrary timeout (typically 4 seconds) elapses. This approach sacrifices progressive rendering, allows accidental clicks on invisible content, and introduces unnecessary paint cycles.

The Solution

The blocking=render attribute allows a <script> or <link> element placed in the <head> to block rendering—but not parsing—until the resource has been fetched and executed. This gives experimentation scripts the same render-blocking behavior that stylesheets have by default, ensuring the browser never paints the page until the experiment variant has been applied. No opacity hacks, no arbitrary timeouts, and no flicker.

Implementation Strategy

  1. MANDATORY: Place the experimentation script in the document <head> and add blocking="render".

  2. MANDATORY: Ensure the script either has type="module" (preferred for inline scripts) or async (preferred for external scripts with a src value).

  3. DO keep the experimentation script small and fast. Because rendering is blocked until the script executes, a large or slow script directly delays first paint.

  4. DO NOT use blocking="render" on scripts that do not need to run before first paint. It is intended only for scripts whose output must be visible in the initial render.

  5. DO NOT apply blocking="render" to scripts outside the <head>. Only scripts in the <head> can block rendering.

Implementation Guide

Basic Setup

MANDATORY: Load the experimentation script with both async and blocking="render". The async attribute ensures the script does not block HTML parsing (the browser continues building the DOM while fetching the script). The blocking="render" attribute ensures the browser does not paint anything until the script has executed.

<head>
  <!--
    MANDATORY: Both `async` and `blocking="render"` are required.
    - `async`: Prevents parser-blocking, so the DOM is built in parallel.
    - `blocking="render"`: Holds rendering until the script executes,
      ensuring experiment changes are applied before the user sees anything.
  -->
  <script
    src="https://cdn.example.com/experiment-sdk.js"
    async
    blocking="render"
  ></script>
</head>
Loading Experiment-Specific Styles

If the experiment requires a variant stylesheet, use blocking="render" on the <link> element. Stylesheets in the <head> already block rendering by default, but dynamically injected stylesheets or those added via script do not. Use blocking="render" explicitly when the stylesheet is added dynamically or when you want to be explicit about the intent.

<head>
  <!--
    DO: Use blocking="render" on experiment stylesheets that are
    dynamically inserted or conditionally loaded by the experiment SDK.
    This ensures variant styles are applied before first paint.
  -->
  <link
    rel="stylesheet"
    href="https://cdn.example.com/experiment-variant-b.css"
    blocking="render"
  >
</head>
Inline Experiment Script

If the experiment logic is lightweight enough to inline, use an inline module script with blocking="render". This is useful when the experiment logic fetches a configuration and applies DOM changes directly.

<head>
  <!--
    DO: Use an inline module script when the experiment logic is small.
    Module scripts are deferred by default (non-parser-blocking),
    and blocking="render" ensures rendering waits for execution.
  -->
  <script type="module" blocking="render">
    // Fetch the experiment configuration from your testing platform.
    const config = await fetch('/api/experiment?id=homepage-cta')
      .then(res => res.json());

    // Apply the variant by setting a data attribute on <html>.
    // CSS rules keyed to this attribute will style the variant.
    document.documentElement.dataset.variant = config.variant;
  </script>

  <style>
    /* Default styles (control group) */
    .cta-button {
      background-color: blue;
    }

    /* Variant B styles, activated by the data attribute */
    [data-variant="b"] .cta-button {
      background-color: green;
    }
  </style>
</head>

Best Practices

  • MANDATORY: The experimentation script MUST execute quickly. A slow script delays all rendering. Set a performance budget (e.g., under 100ms execution time) for the render-blocking script.

  • DO split heavy experiment logic from the render-blocking script. Load a small, render-blocking stub that applies the variant, then load heavier tracking or analytics scripts separately with async or defer (without blocking="render").

  • DO use a data attribute on <html> or <body> to signal the active variant, and use CSS selectors keyed to that attribute for variant styling. This avoids direct DOM manipulation in the render-blocking script.

  • DO NOT use blocking="render" on analytics, tracking, or other non-visual scripts. Only scripts that must change what the user sees on first paint should block rendering.

  • DO NOT combine blocking="render" with legacy anti-flicker snippets. They solve the same problem; using both creates unnecessary delays.

Fallback Strategies

blocking="render" has limited availability. Supported by: Chrome 105 (Sep 2022), Edge 105 (Sep 2022), and Safari 18.2 (Dec 2024). Unsupported in: Firefox.

The blocking attribute is not supported in all browsers. In browsers that do not support it, the attribute is ignored and the script loads with its default behavior (async in the examples above), which may result in flicker. A fallback is required to prevent flicker in unsupported browsers.

Fallback: Anti-Flicker Snippet

DO: Use a lightweight anti-flicker snippet as a fallback only when blocking="render" is not supported. Feature-detect support and skip the fallback in browsers that handle it natively.

<head>
  <!--
    DO: Load the experiment script with blocking="render" for
    browsers that support it. This is the preferred approach.
  -->
  <script
    src="https://cdn.example.com/experiment-sdk.js"
    async
    blocking="render"
  ></script>

  <script>
    // DO: Only apply the anti-flicker fallback in browsers
    // that do not support blocking="render".
    if (!Object.hasOwn(HTMLScriptElement.prototype, 'blocking')) {
      // Hide the page until the experiment script runs.
      document.documentElement.classList.add('ab-loading');

      // DO: Set a timeout to reveal the page if the experiment
      // script takes too long. This prevents an indefinitely
      // blank page on slow connections. Adjust the timeout
      // to match your experiment SDK's expected load time.
      setTimeout(() => {
        document.documentElement.classList.remove('ab-loading');
      }, 4000);
    }
  </script>

  <style>
    /*
      DO: Use opacity to hide content during experiment loading.
      This is only applied when blocking="render" is unsupported.
    */
    .ab-loading {
      opacity: 0 !important;
    }
  </style>
</head>
// DO: In your experiment SDK's initialization callback,
// remove the fallback class to reveal the page.
function onExperimentReady() {
  document.documentElement.classList.remove('ab-loading');
}

Other Considerations

  1. Performance Impact: blocking="render" trades first-paint speed for visual correctness. Monitor Largest Contentful Paint (LCP) and First Contentful Paint (FCP) to ensure the experimentation script is not adding excessive delay.

  2. Third-Party Script Reliability: If the experiment SDK is hosted on a third-party CDN, a CDN outage could block rendering entirely. The browser applies its own timeout heuristics (which may be longer than 4 seconds), but there is no developer-controlled timeout for blocking="render". Ensure the third-party provider has strong uptime guarantees.

  3. Server-Side Alternatives: For performance-critical pages, consider server-side A/B testing (where the server renders the correct variant directly) instead of client-side testing. Server-side approaches eliminate flicker entirely without any render-blocking cost. Use client-side blocking="render" only when server-side testing is not feasible.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Google Chrome
Publisher
JetBrains (Official)
Distributed by
JetBrains
Source
JetBrains/skills · modern-web-guidance · commit 3f53782
Licence
Apache License 2.0 (redistribution allowed)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google Chrome or JetBrains.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download modern-web-guidance.zip