The modern web is becoming increasingly heavy. Sites load massive files. Yet, a large part of this code is never used. Developers often use complete libraries. They only use a small fraction of the functions. This surplus of data slows down navigation. It consumes battery on mobile. It wastes bandwidth.

Google Chrome offers a very powerful integrated tool. It is called the Coverage tab. This tool analyzes your code as you browse. It shows what is executed. Most importantly, it shows what remains inactive. Removing this dead code is a priority for performance. It is essential for improving your Core Web Vitals.

Why is dead code dangerous?

Every byte sent has a technical cost. The browser follows a strict process to display a page.

The impact on CSS rendering

CSS blocks the page display. The browser must read the entire file before drawing. If your file is 200 KB but only 10 KB are useful, you are wasting time. The user sees a white screen. This increases the LCP (Largest Contentful Paint) score. A fast site retains its visitors better.

The cost of JavaScript

JavaScript is very expensive for the processor. The browser must download the file. Then, it must decompress it. Then, it must parse and compile it. This work uses a lot of resources. On an old smartphone, this creates stutters. The Coverage tool helps you reduce the TBT (Total Blocking Time).

How to open the Coverage tab?

The tool is hidden in Chrome’s advanced options. Here are the steps to access it:

1. Open your website in Chrome.
2. Open the developer tools with the F12 key.
3. Press Ctrl + Shift + P (or Cmd + Shift + P on Mac).
4. A search bar appears.
5. Type the word “Coverage”.
6. Select the “Show Coverage” option.

A new panel opens at the bottom of your window. To start the analysis, click the reload button. It is the icon with a circular arrow. The page will refresh. The tool will then record every line of code used.

Understanding data visualization

The Coverage tab presents a complete table. Each row corresponds to a loaded file.

• URL: The name and address of the file. This includes your scripts and styles.
• Type: Indicates whether it is JS or CSS.
• Total Bytes: The total weight of the file.
• Unused Bytes: The amount of code that was not used.
• Usage Visualization: A very useful horizontal bar.

Analyzing colors

In this tool, the colors are simple to understand. The red bar represents code that has never been executed. The grey bar represents useful code.

If you see a bar that is almost entirely red, the file is a problem. In the image above, some files show 100% unused code. This is a total loss of efficiency. This often happens with icon fonts or old tracking scripts.

Detailed analysis in sources

Click on a row in the table. The file opens in the Sources tab. Look to the left of the line numbers. Color strips appear.

• A grey strip means the line was read by the browser.
• A red strip means the line is ignored.

The human factor: interaction

The Coverage tool is a live recorder. It cannot guess the future. When the page loads, everything related to dropdown menus or pop-ups will be red. This is normal. The code has not been used yet.

To obtain a reliable report:

1. Start the recording.
2. Browse your entire page.
3. Click on all the buttons.
4. Open the menus.
5. Scroll to the footer.

You will see the red bars turn grey in real time. The code you really need reveals itself little by little.

How to eliminate unnecessary code?

Once the diagnosis is complete, you must act. Here are three methods to clean your project.

1. Manual removal

This is the simplest method for CSS. If the tool shows that entire styles are red across the whole site, delete them. It is often old, forgotten code.

2. Code splitting

Do not load the code for your “Contact” page on your “Home” page. Split your scripts into small pieces. Only load them when necessary. This is very easy to do with modern frameworks.

Here is an example of conditional loading in JavaScript:

const feedbackBtn = document.querySelector('.js-feedback');

if (feedbackBtn)
{
  import('./modules/feedback.js').then(module =>
  {
    module.init();
  });
}

3. Tree Shaking

This is an automatic technique. It removes dead code during the site’s creation. For this, use tools like Vite or Webpack. They analyze your code and remove what is not called.

// We only import what is useful
import {computeTotal} from './math-library.js';

const result = computeTotal(10, 20);
console.log(result);

// The multiply() function in math-library.js will remain unused
// It will not be included in the final file

Browser extensions and the Coverage tab

The image of the Coverage tab often shows lines starting with chrome-extension://. This is not your site’s code. These are the scripts from your own extensions (like uBlock or LastPass).

Warning: Do not confuse these files with your own assets. Focus only on files that start with http:// or https:// with your domain name. Extensions consume a lot of resources. They can distort your performance tests. Always test your site in Incognito mode to avoid this.

Benefits for SEO and indexing

A light site ranks better on Google. The search engine analyzes speed. If your JS files are too heavy, the Google bot will spend less time indexing your pages. This is called the crawl budget.

By reducing dead code:

• The site loads faster.
• User experience improves.
• Bounce rate decreases.
• Your Lighthouse score increases.

Conclusion

The Coverage tab is a vital diagnostic tool. It allows you to see the invisible. In a few clicks, you identify the culprits of slowness. Cleaning your code is a mark of respect for the user.

Start today. Open your tools. Launch an analysis. Every red line removed makes the web faster and greener.

Frequently Asked Questions

For a long time, the Web used only one shape for corners: the circular arc. While the border-radius property is extremely useful, it is limited. It cannot create clipped right angles (bevels) or more complex shapes without external help.

The corner-shape property changes this. It allows you to choose the shape of the corner without changing its * size*. This is a performance revolution because everything is handled natively by the browser.

Why use corner-shape?

Previously, to create a beveled corner, we used images or complex masks. These methods slow down the site. corner-shape offers three advantages:

1. Speed: The browser draws the shape directly.
2. Lightweight: Less code and no images to load.
3. Flexibility: The shape automatically adapts to the block size.

Here is an example of fluid and high-performance code:

.card {
  background-color : #1a1a1a;
  border-radius    : clamp(1rem * $font-size, 5vi, 3rem * $font-size);
  corner-shape     : bevel;
  inline-size      : 100%;
  padding          : 2rem * $font-size;
}

The Four Basic Shapes

The corner-shape property offers four simple keywords. Each keyword changes how the corner is traced.

1. Round Mode

This is the default value. The browser draws a quarter circle. This is exactly what border-radius does on its own.

2. Bevel Mode

The bevel cuts the corner with a straight line. It’s ideal for modern or industrial designs. The calculation is very simple for the Graphics Processing Unit (GPU), making the rendering instantaneous.

3. Scoop Mode

Scoop mode creates an inward curve. Imagine removing a circular piece from the corner of the block. This is very difficult to achieve without this property.

4. Notch Mode

The notch creates a stair-shaped cutout. The corner consists of two straight lines meeting inside the block.

The Superellipse: The Secret of High-End Design

The superellipse() function is the most technical part of corner-shape. It allows for very smooth curves, often called “squircles.”

What is a Superellipse?

It is a mathematical shape between a square and a circle. Unlike a circle, the curve starts very gently. There is no visible break between the straight line and the start of the corner. Apple uses this shape extensively for its icons and products.

.premium-box {
  aspect-ratio  : 1 / 1;
  border-radius : 20%;
  corner-shape  : superellipse(2.5);
  inline-size   : min(20rem * $font-size, 80vi);
}

In this code, the number 2.5 is the mathematical exponent.

• If the number is 2, it’s a perfect circle.
• As the number increases, the corner becomes “fuller” and approaches a square.

How the Browser Renders These Shapes

To ensure maximum performance, it is important to understand what happens inside the browser.

The Rendering Pipeline

When you use corner-shape, the browser follows these steps:

1. Layout Calculation: It defines the block size (the rectangle).
2. Painting Phase: It draws the border with the chosen shape.

The advantage of corner-shape is that it does not affect the layout stage. The block remains the same size regardless of the corner shape. This prevents the browser from recalculating positions if the shape changes, for example, during a hover effect.

Hardware Acceleration

Tracing shapes like bevels or superellipses is sent directly to the GPU. The GPU is designed to draw vectors very quickly. This is much more efficient than using JavaScript filters or masks.

Accessibility and Visual Comfort

Good code must be readable by everyone, including assistive tools.

Focus Indicators

A major problem with old techniques was that the selection ring (when using the Tab key) remained rectangular. With corner-shape, the browser adapts the focus ring to the shape of the corner.

.interactive-element:focus-visible {
  outline        : .2rem * $font-size solid #4a90e2;
  outline-offset : .4rem * $font-size;
}

Fluid Units

We use rem and the $font-size variable so that the corners adapt to the user’s text size. If a person increases the font size in their browser to read better, the corners will remain proportional, and the interface will stay clean.

Summary for Developers

To optimize your interface with corner-shape, remember these points:

• Use bevel for a technical look and maximum performance.
• Use superellipse for a soft, luxury look.
• Use relative units (rem) to ensure the design is accessible.
• Avoid corner images to save precious milliseconds during loading.

corner-shape is the perfect tool for combining complex design with incredible loading speeds. It is the future of high-performance web design.

The following demo is by Amit Sheen.

Frequently Asked Questions (FAQ)

In modern interface development, managing user input is a constant challenge. You have likely encountered this problem: a user copies and pastes rich text from a web page or a Word document into your comment area, and suddenly your layout explodes, polluted by useless <span> tags, inline styles, or even malicious scripts.

For a long time, we used textarea for its simplicity, at the cost of complex auto-expansion management. Or, we forced contenteditable by developing complex JavaScript “gas factories” to clean data on the fly.

There is now a native, robust, and extremely high-performance solution: the contenteditable="plaintext-only" attribute.

What is contenteditable=“plaintext-only”?

It is a specific value for the HTML contenteditable attribute. When applied to an element (usually a div or a span), the browser strictly restricts input and pasting behavior.

Unlike the classic contenteditable="true" mode which allows the creation of complex DOM structures (text nodes, formatting tags, images), the plaintext-only mode imposes a strong constraint: only text characters and line breaks are accepted.

Any pasted rich content is immediately converted to raw text by the browser’s rendering engine before it even reaches your event handler.

Why is it a strategic lever?

1. Security by design

The first argument is security. By allowing rich text via contenteditable="true", you potentially expose yourself to XSS (Cross-Site Scripting) vulnerabilities if your sanitization process is incomplete or bypassed.

With plaintext-only, the attack surface is drastically reduced. The browser does not interpret inserted HTML tags. An attacker trying to inject <script>alert(1)</script> will see these characters displayed as literal text, without any execution. This is the principle of defense in depth through technological choice.

2. Performance and User Experience (UX)

In a context where every millisecond counts, avoiding heavy JavaScript processing is crucial.

• DOM Reduction: No more need to parse complex DOM trees generated by malicious copy-pastes.
• Native Auto-expansion: By using a div with contenteditable="plaintext-only", you natively benefit from an area that adapts to the content height, without complex JavaScript input event listeners to recalculate height (as was the case for auto-adjusting textarea).

3. Content Consistency

Your databases will receive uniform data. No more mixed fonts, disparate colors, and unexpected DOM structures that make display or backend processing (like PDF generation or exporting) unpredictable.

Technical Implementation

Implementation is trivial but requires careful attention to CSS styling to maintain the appearance of an input area.

.input-field {
  /* Using clamp for fluid and reactive width */
  inline-size    : clamp(18.75rem, 50%, 50rem);
  min-block-size : 1.5em;
  padding        : .625rem;
  border         : .0625rem solid #ccc;
  /* Ensure readable typography */
  font-family    : sans-serif;

  /* Avoiding useless overrides with :not */

  &:not([contenteditable='plaintext-only']) {
    border-color : red;
  }
}

Here is how to structure your HTML component:

<div
  class="input-field"
  contenteditable="plaintext-only"
  role="textbox"
  aria-multiline="true"
  placeholder="Enter your text here...">
</div>

The role of accessibility

It is essential to add role=textbox and aria-multiline=true so that assistive technologies understand that this is a textual input field. Without this, the element is not correctly interpreted as a form control.

Comparison with alternatives

Limitations and Best Practices

While powerful, this mode has its limits:

1. Browser Support: It is widely supported in modern browsers (Chromium, WebKit). Always check compatibility if you target very specific environments.
2. Event Management: Even if the text is “clean,” you still need to handle input or blur events to capture the data and send it to your backend.
3. Placeholder: contenteditable does not support the placeholder attribute natively. You will need to use a CSS trick with the :empty pseudo-class to display help text when the field is empty.

[contenteditable='plaintext-only']:empty::before {
  content : attr(data-placeholder);
  color   : #888;
}

Conclusion

Switching to contenteditable="plaintext-only" is not just a syntactic improvement. It is a paradigm shift that places security and performance at the heart of your interface design. By delegating the formatting constraint to the browser, you free up development time for higher value-added features while ensuring a consistent and fast user experience.

Do not wait to audit your current input fields and migrate to this native approach.

FAQ

In the frantic race for web performance, every millisecond saved on the Main Thread is a victory. While we have long relied on complex JavaScript libraries to manage lazy rendering, modern CSS brings a native solution of formidable efficiency: content-visibility.

The problem is simple: the heavier a DOM page is, the more time the browser spends calculating the layout and painting elements, even those located 5000 pixels below the fold. By using content-visibility, you instruct the browser to skip the rendering work for off-screen elements.

The hidden cost of invisible rendering

When a browser loads a page, it performs a series of critical steps: building the DOM, the CSSOM, then calculating style, layout (geometry), and finally the “paint” (drawing pixels). On a page containing thousands of nodes, this stage can paralyze the processor for several hundred milliseconds.

This is where the concept of containment comes in. Historically, the contain property allowed isolating parts of the DOM to prevent the recalculation of a small component from triggering a recalculation of the entire page. content-visibility is the logical and automated evolution of this concept.

1. content-visibility: auto, the smart rendering engine

The auto value is the most powerful. It allows the browser to determine whether an element is in the viewport (the visible area) or not. If the element is far from the user’s view, the browser:

• Does not calculate the layout of its children.
• Does not paint its content.
• Treats it as if it had strict “containment”.

As soon as the user scrolls and approaches the element, the browser triggers rendering just in time.

Technical implementation

Here is how to apply this optimization to page sections smoothly, using clamp() to adapt dynamically to screen size without media queries.

.optimized-section {
  content-visibility     : auto;
  /* Using clamp for fluid management of reserved space */
  contain-intrinsic-size : auto clamp(25rem, 60vh, 75rem);
}

/* Avoiding unnecessary overrides on already visible sections */
.optimized-section:not([data-priority='high']) {
  margin-block : clamp(1rem, 5%, 3rem);
}

2. The scroll jump problem: contain-intrinsic-size

Using content-visibility: auto alone has one major flaw: the browser assumes the unrendered element has a height of 0px. As the user scrolls, the element is rendered, its actual height is calculated, and all content below it “jumps” abruptly.

This is a disaster for CLS (Cumulative Layout Shift), a key Google indicator for SEO.

To fix this, we use contain-intrinsic-size. This property acts as a placeholder or fallback size. It tells the browser: “Even if you don’t render this element, reserve this space”.

Modern and precise syntax

It is now possible to use auto combined with a size value. If the browser has already rendered the element once, it will remember its actual size instead of using the estimated value, making the scroll perfectly fluid.

.dynamic-card-container {
  content-visibility     : auto;
  /* Defining intrinsic width and height */
  contain-intrinsic-size : auto 100% auto clamp(15.625rem, 30vh, 31.25rem);
}

3. SEO and Accessibility: What impact?

This is the question all SEO experts ask: if the content is not rendered, can Google see it?

The answer is yes. content-visibility: auto does not hide DOM content the same way display: none does. The content remains accessible in the render tree for search engines and screen readers. However, since the content is not “ painted”, it is recommended not to use it on critical text elements for immediate accessibility (like the main navigation menu).

Why it is good for your SEO

1. LCP (Largest Contentful Paint): By freeing the processor from useless rendering tasks, the browser can focus on the main element of the page.
2. INP (Interaction to Next Paint): Less rendering work means a main thread that is more responsive to user clicks and interactions.

4. Advanced optimization strategies

To maximize performance, you should not apply these properties to every small element. The trick is to target “chunks” or logical sections of your page.

main > section:not(:first-child) {
  content-visibility     : auto;
  contain-intrinsic-size : auto 50rem;
}

In this example, we leave the first section (often above the fold) alone for immediate rendering, while optimizing all subsequent sections.

5. Comparison: CSS vs JavaScript (Intersection Observer)

Before this property, we used the IntersectionObserver API to add or remove CSS classes. Here is why the native method is superior:

• Raw performance: CSS runs at the rendering engine level, not in the JavaScript virtual machine.
• Zero delay: The browser knows exactly when to start rendering to avoid white flashes, which is very difficult to synchronize perfectly in JS.
• Lightness: Less JS means less code to download, parse, and execute.

Conclusion: A giant leap for web performance

Implementing content-visibility and contain-intrinsic-size represents one of the most cost-effective optimizations in terms of “effort / gain” ratio. With just a few lines of code, you can transform a heavy, stuttering page into a fluid, app-grade experience.

This is the essence of modern engineering: delegating intelligence to the browser to focus on the added value of your interface.

FAQ

On the modern web, speed is a priority. Every byte sent between a server and a user impacts loading time. Heavier data makes applications feel slow, especially on mobile devices or poor connections.

Until recently, client-side data compression required importing massive third-party libraries like pako or zlib.js. These tools add weight to your application before it even starts working. Today, a built-in solution exists: the CompressionStream API.

Why compress data on the client side?

Most developers think compression is a task reserved for the server. This is often true for downloading pages. However, in data-rich applications, the client (the browser) often needs to send large amounts of information to the server.

Here are some situations where native compression is useful:

1. Sending logs: If your application sends detailed error reports.
2. Saving documents: For online text or drawing editors.
3. Local storage: To save more information in the browser database (IndexedDB) without saturating the user’s disk space.

What is the CompressionStream API?

This programming interface (API) allows you to compress and decompress data streams natively. “Native” means the code is already present in the browser. You do not need to download anything extra.

It uses streams. A stream is a way to process data bit by bit, like water flowing through a pipe, rather than waiting for the entire bucket to be full. This prevents using too much memory (RAM) on the user’s device.

Available algorithms

The API offers three main formats to transform your data:

• GZIP: The most common format on the Internet. It offers an excellent balance between final file size and calculation speed.
• DEFLATE: A very fast basic algorithm.
• DEFLATE-RAW: A version of Deflate without header information, used for specific technical needs.

Practical application: compressing data

To use this API, we create a compression stream. Here is how to transform simple text into compressed data.

/**
 * Compresses a string into GZIP
 * @param {string} inputData
 * @returns {Promise<Uint8Array>}
 */
async function compressData(inputData)
{
  const
    encoder = new TextEncoder(),
    rawData = encoder.encode(inputData),

    // Create a stream from raw data
    stream = new Blob([rawData]).stream(),
    compressionStream = new CompressionStream('gzip'),

    // Pass data through the compressor
    compressedStream = stream.pipeThrough(compressionStream),

    response = new Response(compressedStream),
    buffer = await response.arrayBuffer();

  return new Uint8Array(buffer);
}

Doing the opposite: decompression

If you receive compressed data from the server or your local database, you must make it readable again.

/**
 * Decompresses GZIP data to get text
 * @param {Uint8Array} compressedData
 * @returns {Promise<string>}
 */
async function decompressData(compressedData)
{
  const
    decompressionStream = new DecompressionStream('gzip'),

    // Create a readable stream for the decompressor
    stream = new ReadableStream(
      {
        start(controller)
        {
          controller.enqueue(compressedData);
          controller.close();
        }
      }),

    decompressedStream = stream.pipeThrough(decompressionStream),
    response = new Response(decompressedStream);

  return await response.text();
}

The importance of streaming

The strength of this API lies in its ability to process huge files without freezing the computer. If you try to compress a 1 GB file all at once, the browser might close the tab due to lack of memory.

With the pipeThrough system, data flows in small segments. This is called backpressure management. The system automatically adapts to the processing speed of the device.

Design optimization and accessibility

Technical performance is not enough. The user must understand what is happening. If compression takes time, a fluid progress bar should be displayed.

Let’s use modern CSS to create an indicator that adapts to all screen sizes using fluid properties.

.progress-container {
  /* Use clamp for fluid and responsive width without media queries */
  inline-size      : clamp(15rem, 50vw + 2rem, 100%);
  background-color : #f0f0f0;
  border-radius    : .5rem;
  padding          : .25rem;
}

.progress-bar {
  block-size       : 1rem;
  background-color : #007bff;
  border-radius    : .25rem;
  /* Optimization: Only apply transition if the user doesn't prefer reduced motion */
  transition       : width .2s ease-in-out;
}

/* Use :not to avoid CSS overrides and keep the code clean */
@media (prefers-reduced-motion : reduce) {
  .progress-bar:not(.static) {
    transition : none;
  }
}

Impact on SEO

Google and other search engines use robots to analyze your site. These robots reward sites that are lightweight and resource-efficient.

1. Reduction in total weight: Less JavaScript code to download means a better “Core Web Vitals” score.
2. Interaction speed: By compressing outgoing data, you free up the user’s bandwidth faster, making the application more responsive.
3. Mobile experience: A site that saves its users’ mobile data is better ranked and more appreciated.

When to avoid using this API?

There are cases where compression is useless or even counterproductive:

• Already compressed files: Images (JPG, PNG), videos (MP4), and PDF files are already compressed. Trying to compress them again with GZIP can sometimes make the file larger.
• Small data: If your text is less than 100 bytes, compression will add structure information that will make the final result larger than the original.

Browser compatibility

The CompressionStream API is available on almost all recent browsers (Chrome, Firefox, Safari, Edge). However, for older systems, it is important to check if the tool exists before using it.

console.log(
  ('CompressionStream' in window)
    ? 'Native compression is available!'
    : 'Using a slower alternative method.'
);

Conclusion: a step towards a cleaner web

Using the CompressionStream API is a smart decision for any performance-conscious developer. It allows for removing unnecessary dependencies, reducing memory consumption, and improving the overall user experience.

In 2026, the quality of an application is not only measured by its features, but by its ability to be lightweight and respectful of the user’s resources. Native compression is one of the best tools to achieve this goal.

Frequently Asked Questions (FAQ)

Web development is a quest for precision. We optimize our scripts. We reduce image weight. Yet, we often use obsolete color tools. The RGB format dates back to the first tube monitors. The HSL format was created to simplify mathematical calculations. None of these formats understand how your eyes work.

OKLCH changes everything. It is not just a new syntax. It is a new way to calculate light in the browser. In this guide, we will explore in depth why you must adopt it today.

Why HSL Has Always Fooled Us

You might think that changing lightness in HSL is enough. This is a common mistake. In HSL, the ‘Lightness’ (L) value is relative to the mix of primary colors. It does not account for the sensitivity of the human retina.

The Yellow and Blue Experiment

Let us perform a simple test. Take a pure yellow (hsl(60, 100%, 50%)). Take a pure blue (hsl(240, 100%, 50%)). Both have a lightness of 50%. However, if you turn this image into black and white, the yellow will look almost white. The blue will look almost black.

Why? Because the human eye perceives yellow as naturally brighter than blue. If you create an interface with these two colors in HSL, your contrasts will be wrong. You will have to correct each color by hand. This is a huge waste of time for a developer.

The Solution: OKLCH and Human Perception

The OKLCH color space is ‘perceptually uniform’. This means the numbers match what you see. If two colors have an ‘L’ (Lightness) of ‘0.7’, they will have exactly the same clarity to a human.

Understanding the Three Components

1. L (Lightness): The clarity. It goes from ‘0’ (total black) to ‘1’ (pure white). Unlike HSL, ‘0.5’ in OKLCH is always perceived as a perfect medium gray.
2. C (Chroma): The strength of the color. It starts at ‘0’. The higher the number, the more vivid the color. It is more precise than saturation because it does not depend on lightness.
3. H (Hue): The tint. It is the angle on the color wheel from ‘0’ to ‘360’.

/* Using variables for optimal performance */
:root {
  --hue-brand   : 260;
  --chroma-main : .12;

  /* We define lightness fluidly based on screen size */
  --light-fluid : clamp(.4, 2vw + .1, .8);
}

.main-container *:not(footer) {
  background-color : oklch(var(--light-fluid) var(--chroma-main) var(--hue-brand));
}

Performance and Code Optimization

In a high-performance context, CSS structure is vital. OKLCH allows writing less code to achieve more results.

Automatic and Predictable Dark Mode

In HSL, switching to dark mode is a headache. You change the ‘L’, but the color often becomes too saturated or shifts hue visually. In OKLCH, you simply lower the ‘L’. The hue and purity remain strictly identical.

[data-theme='dark'] {
  /* We halve the lightness without altering the color */
  --light-fluid : .2;
}

.article-content {
  color : oklch(var(--light-fluid) var(--chroma-main) var(--hue-brand));
}

Optimizing Color Animation Fluidity

The browser calculates OKLCH colors natively. By using CSS Variables with OKLCH, you avoid heavy recalculations. The GPU can interpolate these values very quickly during transitions. This ensures a 60 frames per second (FPS) rendering.

Impact on SEO and Accessibility

Google uses algorithms to check if your text is readable. If your contrasts are poor, your SEO score drops.

Towards the WCAG 3 Standard (APCA)

Future accessibility standards (APCA) will favor models like OKLCH. Why? Because they are closer to physical reality. By using OKLCH today, you prepare your site for tomorrow’s standards.

Simplified Contrast Algorithm

With OKLCH, you no longer need complex tools to check your colors. You can define a simple rule for your team: ‘The text must always have an L that differs by 0.5 from the background’. This rule will work for ALL colors in the spectrum. This is a major productivity gain.

.badge {
  /* Light background */
  background-color : oklch(.9 .05 var(--hue-brand));

  /* Dark text guaranteed readable on 0.9 background */
  color            : oklch(.2 .05 var(--hue-brand));
}

The P3 Gamut: Pushing Screen Limits

Most developers remain stuck in ‘sRGB’. It is an old, limited color space. Recent screens (OLED, Retina) support * Display P3*.

OKLCH is the bridge to this universe. It allows you to declare colors that do not exist in RGB or HSL. These colors are more vibrant and deeper. They draw the eye to your Call to Action (CTA) buttons.

A Risk-Free Transition

If the user has an old screen, the browser performs the calculation. It finds the closest possible color. This is called progressive enhancement. You offer the best to modern users without breaking the experience for others.

Methodology: How to Migrate an Existing Project?

Switching to OKLCH requires a rigorous method to maintain performance.

1. Identify Hues: List your current colors (Hex or HSL).
2. Convert: Use converters to find the OKLCH equivalent.
3. Parameterize: Create variables for Hue (H) and Chroma (C).
4. Adjust: Use Lightness (L) to create your shades (hover, active, focus).

.button-action {
  /* Avoid media queries with clamp */
  --btn-width      : clamp(6.25rem, 15vw, 16.25rem);

  width            : var(--btn-width);
  background-color : oklch(.6 .2 150);
}

.button-action:hover {
  /* Simple and clean clarity increase */
  background-color : oklch(.7 .2 150);
}

Conclusion: Modern Code Craftsmanship

OKLCH is not an option. It is a necessity for any developer who cares about software quality. It provides:

• Mathematical and reliable accessibility.
• Optimal rendering performance.
• Increased maintainability through logical variables.
• Strengthened SEO via perfect contrasts.

In 2026, the web must be inclusive and fast. By mastering OKLCH, you regain total control over the light in your interfaces. Your sites will not just be more beautiful. They will be more accurate.

Frequently Asked Questions (FAQ)

Web development is a complex job. Creating a site is not enough. Your code must work everywhere. It must work on all screens. It must work for all users.

There are many different browsers. There are many email applications. Some servers use old technologies. These differences create errors. We call these compatibility problems.

A technical error drives your customers away. It also blocks people with disabilities. It prevents search engines from reading your site.

To succeed, you must check your code. Here are 5 tools to code with precision.

1. CanIUse: Checking Web Browsers

Link: https://caniuse.com/

CanIUse is a huge database. It lists web features. It shows which browsers accept your code. It covers Chrome, Firefox, Safari, and Edge.

Why Use This Tool?

Browsers do not evolve at the same speed. A feature might work on Chrome but not on Safari. CanIUse displays color tables.

• Green: The code works well.
• Red: The code does not work.
• Yellow: The code works sometimes.

Technical CSS Code Example

Modern CSS allows you to write fewer lines. We use mathematical functions for element sizes. We also use selectors to exclude objects.

Here is a very high-performance code example:

/* Container with fluid width */
.main-wrapper {
  width         : min(100% - 2rem, 75rem);
  margin-inline : auto;
}

/* Text size adapts to the screen */
.main-title {
  font-size : clamp(1.25rem, 4vw + 1rem, 2.5rem);
}

/* Style only elements that are not disabled */
.action-link:not(.is-disabled) {
  color           : '#05f';
  text-decoration : underline;
}

Before copying this code, go to CanIUse. Type min, clamp, or :not. The tool gives you the percentage of compatible users. If the score is high, you can code. If the score is low, you must change your method. This avoids breaking the display for your customers.

2. CanIEmail: Email Compatibility

Link: https://www.caniemail.com/

Sending an HTML email is very difficult. Email applications are old. They do not read code like a browser. Outlook is the most difficult application. It uses the Microsoft Word engine to display emails.

The Dangers of Code in Emails

Many CSS properties are forbidden in emails. CanIEmail tests over 50 applications. It also tests over 170 features.

If you use bad code, the email will be unreadable. The user will delete your message. CanIEmail saves you time. It shows you what is safe. Often, you must use HTML tables for the structure. It is an old but very solid technique. The tool helps you choose between design and compatibility.

3. A11y Support: The Accessibility Tool

Link: https://a11ysupport.io/

Web accessibility allows disabled people to use the internet. Blind people use screen readers. This software reads the code aloud. But not all screen readers read the same thing.

Why Check A11y Support?

A code can be correct for the W3C. Yet, software might not understand it. A11y Support lists these problems. It compares browsers and screen readers.

The tool tests ARIA attributes. It also tests HTML roles.

• It prevents making a site invisible to a blind person.
• It ensures your buttons are usable with a keyboard.
• It makes your site truly inclusive.

Always check your interactive components on this tool. It is a mandatory step for quality.

4. CanInclude: Validating HTML Structure

Link: https://caninclude.glitch.me/

The HTML language has precise rules. We call this semantics. Some tags cannot go inside other tags. CanInclude checks these rules for you.

The Risks of a Bad Structure

Nesting your tags incorrectly creates bugs. The browser must make efforts to fix your errors. This slows down the page display.

A bad structure also loses Google robots. Google uses HTML to understand your topic. If the HTML is wrong, your SEO drops. CanInclude is very simple. You provide the parent tag. You provide the child tag. The tool answers ‘Yes’ or ‘No’. It is fast and efficient.

5. Can I PHP: Server Compatibility

Link: https://caniphp.com/

PHP code runs on the server. PHP changes versions often. Each version brings new functions. If your server is old, your recent code will crash.

Securing Your Backend

A PHP error stops the entire site. The user sees a white page. We call this a fatal error. This is very bad for your business.

Can I PHP gives you the minimum version for each function. Here is an example of modern PHP code:

<?php

/* Check a string with a modern function in PHP
 * This requires PHP 8.0 or higher */
function check_user_access(string $role)
{
  if (str_contains($role, 'admin'))
    return 'Access granted';

  return 'Access denied';
}

Go to Can I PHP. Type str_contains. The tool will tell you: ‘PHP 8.0’. If your server uses PHP 7.4, the code will break. You will have to use an old function like strpos. This tool protects your server against crashes.

Conclusion

Performance depends on compatibility. A good developer always checks their tools.

• CanIUse secures your styles and scripts.
• CanIEmail makes your emails readable everywhere.
• A11y Support opens your site to everyone.
• CanInclude validates your HTML structure.
• Can I PHP protects your server from errors.

Use these tools every day. Your code will be stronger. Your users will be happier. Your site will be faster.

Frequently Asked Questions (FAQ)

For over twenty years, PHP has reigned supreme over the web backend. Its execution model was immutable: an HTTP request comes in, a process is born, generates a response, and then dies. But those days are over. The introduction and maturation of the FFI (Foreign Function Interface) extension have opened a breach into which new architectures are flooding.

Today, the BosonPHP project stands as the new frontier of the ecosystem. It is not just a localized web server, but a true open-source runtime (MIT licensed) designed to run PHP code as a native desktop application. Gone is the excessive weight of Chromium and Node.js inherent to the Electron ecosystem. Welcome to direct, ultra-lightweight, and lightning-fast execution.

BosonPHP 0.19.5: Anatomy of a Desktop Kernel

The project’s official slogan on GitHub perfectly summarizes its philosophy: “Because it’s not an Electron!”.

The traditional approach to building desktop apps with web technologies involves embedding a full browser within each application. The result? A basic app often consumes over 200 MB of RAM at rest and carries significant weight on the disk.

BosonPHP takes the opposite path. In its current version 0.19.5, the system relies on high-level bindings to Saucer v6.0, an ultra-lightweight C++ library dedicated to creating smart WebView windows. BosonPHP wraps your code in the native WebView engine provided by the operating system (Edge WebView2 on Windows, WebKit on macOS and Linux). The final compiled application weighs only a few dozen megabytes.

The Strategic Choice of PHP 8.4

You might wonder if BosonPHP already uses PHP 8.5, which is starting to be discussed. The answer is no. Currently, the reactor’s core remains firmly anchored on PHP 8.4 (as confirmed by the php84 technical tag in their official repository).

Why stick to version 8.4? Because creating native interfaces via FFI requires complex manipulation of memory pointers in C. PHP 8.4 offers extremely well-documented stability regarding the asynchronous Garbage Collector and typed structures—vital elements to avoid memory leaks in a long-running process. Moving to a higher minor version would require revalidating the reliability of all underlying memory bridges.

The ‘Zero HTTP Overhead’ Architecture and Framework Bridges

The real revolution of BosonPHP lies in the absence of a network. In previous attempts to port PHP to the desktop, a micro-web server was launched in the background, and the interface communicated with it via TCP requests on localhost.

With BosonPHP, the GUI communicates directly with the PHP process in memory. Events trigger PHP methods directly. But how can we use our favorite frameworks if the whole concept of an HTTP request has disappeared?

The Bridge System

This is where BosonPHP demonstrates its engineering prowess. The team has developed an ecosystem of Bridges that emulate HTTP behavior directly in RAM, without ever opening a network port.

The project offers official components to integrate your frameworks without modification:

• boson-php/laravel-provider and boson-php/laravel-http-bridge
• boson-php/symfony-bundle and boson-php/symfony-http-bridge
• boson-php/spiral-bridge
• boson-php/psr-http-bridge (for any PSR-7 compatible router)

When your application’s WebView attempts to load an internal URL or submit a form, the Boson Bridge intercepts the call, builds a native request object (e.g., an Illuminate\Http\Request for Laravel), and injects it into the framework in memory. The response is generated and returned to the WebView instantly.

Developing with BosonPHP: A Practical Case

BosonPHP’s software structure is highly modular. To add native features, you install specific extensions via Composer.

Let’s take an example of an application that monitors network and battery status. We will use the boson-php/webview-ext-battery and boson-php/app-ext-alert components.

<?php

use Boson\App;
use Boson\Window;
use Boson\Extensions\Alert\AlertExtension;
use Boson\Extensions\Battery\BatteryExtension;

class SystemMonitor
{
  private App $app;
  private Window $window;

  public function __construct()
  {
    $this->app = new App();
    
    // We register native extensions into the Kernel
    $this->app->register(new AlertExtension());
    $this->app->register(new BatteryExtension());
  }

  public function boot(): void
  {
    $this->window = new Window(
      title: 'Boson System Monitor',
      width: 800,
      height: 600
    );

    $this->window->on('ready', function (Window $win)
    {
      $this->checkBatteryStatus($win);
    });

    $this->app->run();
  }

  private function checkBatteryStatus(Window $win): void
  {
    // Calling the native Battery API via FFI bindings
    $battery = $win->native->getBatteryInfo();
    
    if ($battery->percent < 20 && !$battery->isCharging)
    {
      // Calling native OS message box without HTML/JS
      $win->native->alert(
        title: 'Warning',
        message: 'Battery level is critically low.'
      );
    }

    // Pushing data to the WebView DOM
    $win->executeJS('updateBatteryUI(' . $battery->percent . ');');
  }
}

$monitor = new SystemMonitor();
$monitor->boot();

In this code, we see the power of the API. The app-ext-alert extension does not create a fake HTML dialog box. It calls the actual MessageBox API of the OS on Windows or the NSAlert API on macOS via FFI bindings.

Critical Memory Management in a Desktop Context

This is the major friction point for a backend developer transitioning to BosonPHP. In classic PHP (PHP-FPM), memory cleanup is not your primary concern because the process dies at the end of the request.

In BosonPHP, your application can stay open in the background for weeks. The development rules change:

1. Ban Infinite Global State: Arrays stored in $GLOBALS or static class properties that accumulate over time will cause a fatal memory leak.
2. Master Weak References: Boson provides the boson-php/weak-types component to manage data. A weak reference allows you to associate metadata with an object without preventing the Garbage Collector from destroying it when it is no longer used elsewhere.
3. Force Cyclic Cleanup: In complex applications, it is often wise to bind the gc_collect_cycles() function to an internal timer or a change in application state (such as minimizing the window to the taskbar).

The Workflow: From Writing to Compilation

The project excels in its fluid deployment process. The Developer Experience (DX) is designed to be as simple as possible.

You initialize your project with:

composer create-project boson-php/app my-app

During development, you test the application by simply running:

php index.php

Once development is complete, the boson-php/compiler component comes into play. It consolidates your source code, front-end assets, and the internal PHP engine into a single, standalone executable.

php vendor/bin/boson compile

The generated executable contains everything needed. The end user absolutely does not need to have PHP installed on their machine. It is total plug-and-play.

Conclusion

BosonPHP is no longer just an experiment. With a stable architecture based on PHP 8.4, the integration of Saucer v6.0, and robust framework support via native asynchronous bridges, version 0.19.5 offers high-level industrial tooling.

Capitalizing on BosonPHP means using your current technical knowledge to deploy ultra-lightweight and high-performance software on any desktop operating system. The elephant language is no longer just the king of the server; it now has a place on your desktops.

Frequently Asked Questions

Browser rendering engines have historically treated CSS gradients as generated images. Since an image is a complex value rather than a simple numerical unit, the browser cannot calculate a smooth transition between two background-image states. Without intervention, switching from one color configuration to another is binary and instantaneous, lacking any fluid interpolation.

The CSS Houdini API, specifically through the @property rule, transforms this constraint. It allows developers to declare typed variables that the CSS engine can interpolate mathematically. This document details how to leverage this technology to fluidize interfaces while optimizing the rendering pipeline.

The Architecture of Typed Variables

A standard CSS variable (Custom Property) is a string of characters with no semantic meaning for the browser. To enable animation, the nature of the data must be explicitly defined. @property associates a type (syntax) with a variable, such as an angle or a color.

Declaration and Registration of Properties

Property registration must be precise. The inherits: false parameter is critical for performance. It prevents the variable from unnecessarily propagating down the DOM tree, thereby limiting the scope of style calculations during transition phases.

/* Registration of the animation tokens */
@property --gradient-angle {
  syntax        : '<angle>';
  inherits      : false;
  initial-value : 45deg;
}

@property --gradient-start {
  syntax        : '<color>';
  inherits      : false;
  initial-value : #00f;
}

@property --gradient-end {
  syntax        : '<color>';
  inherits      : false;
  initial-value : #09f;
}

.surface {
  /* Fluid sizing via arithmetic functions, eliminating media queries */
  height             : clamp(15rem, 30vh + 5rem, 40rem);
  width              : 100%;
  margin-block-start : clamp(1rem, 5vw, 3rem);
  position           : relative;
  cursor             : pointer;

  background         : linear-gradient(var(--gradient-angle), var(--gradient-start), var(--gradient-end));
  transition         : --gradient-angle .7s cubic-bezier(.4, 0, .2, 1),
                       --grad-start .7s cubic-bezier(.4, 0, .2, 1),
                       --grad-end .7s cubic-bezier(.4, 0, .2, 1);

  /* Layer isolation for painting optimization */
  contain     : layout paint style;
  will-change : transform;
}

.surface:hover {
  --gradient-angle : 225deg;
  --gradient-start : #f00;
  --gradient-end   : #f70;
}

Rendering Pipeline Optimization

Choosing this technique directly impacts the Critical Rendering Path. Unlike opacity animation, which runs on the Compositor (GPU), animating gradient properties triggers a repaint.

Managing the Repaint Cycle

At each frame of the animation, the browser recalculates the pixels of the background image. Although more costly than a simple layer merge, this process is optimized by two factors:

1. Semantic Isolation: By declaring inherits: false, you reduce the cost of style recalculation. The browser knows that modifying the variable does not affect child nodes.
2. DOM Tree Reduction: This method eliminates the need for pseudo-elements (::after) or extra tags. A lighter DOM accelerates all phases of rendering, from parsing to layout.

Responsive Arithmetic and Fluidity

The use of clamp() allows for the removal of traditional Media Queries. Every @media rule forces the browser to re-evaluate the CSS cascade during window resizing. By using mathematical functions, size calculation becomes a dynamic operation performed during the Layout phase.

This approach ensures constant visual stability. It also reduces the total size of the CSS file, speeding up download and analysis time by the main thread.

Accessibility and Motion Compliance

Animating colors and angles can impact users suffering from vestibular disorders or motion sensitivity. Respecting system preferences is both a technical and ethical necessity.

@media (prefers-reduced-motion : reduce) {
  .surface {
    transition : none;
  }
}

Integrating this media query ensures compliance with international accessibility standards (EAA 2025 / WCAG). It ensures that the aesthetic of the interface does not become a barrier to navigation.

SEO Impact and Core Web Vitals

Perceived and real performance is a major ranking criterion. The use of @property optimizes several key metrics:

• Largest Contentful Paint (LCP): Rendering is immediate because it does not depend on loading an external resource (image). The gradient is generated natively by the graphics engine.
• Cumulative Layout Shift (CLS): Fluid dimension definition via clamp prevents abrupt layout shifts during style loading.
• Total Blocking Time (TBT): Since the CSS code is more concise and lacks JavaScript logic for animation, the main thread remains available for user interactions.

Deployment Strategy and Support

As of 2025, support for @property is widespread across Blink (Chrome, Edge), WebKit (Safari), and Gecko (Firefox) engines. For environments that do not support Houdini, the browser simply ignores the transition. The user benefits from a static gradient that changes instantly on hover. This principle of progressive enhancement ensures that the interface remains functional everywhere while providing a superior experience on modern browsers.

Conclusion

The CSS Houdini API redefines how we design graphic transitions. By moving from a hack based on overlapping elements to a native interpolation of typed variables, we clean up the source code and optimize system resource usage. Mastering @property allows for the marriage of surgical CSS engineering precision with a fluid and high-performance user experience.

Technical FAQ

Website design should never slow down the user. A button is the most critical element for conversion. If it looks good, users want to click. If it is fast, users feel confident.

Often, light effects (Glow) require many computer resources. If the code is poorly written, the animation stutters. We will see how to create a rotating luminous border. This code uses only CSS to remain ultra-performant.

The Problem with Poorly Designed Buttons

Many developers make the mistake of using images or JavaScript to make a button shine. This causes three problems:

1. Weight: An animated image is heavy to download.
2. Readability: If the effect passes in front of the text, it becomes unreadable.
3. Slowness: JavaScript uses the browser’s main processor.

Our solution uses hardware rendering. This means the work is done by the graphics card (GPU). The main processor (CPU) remains free for other site tasks.

HTML Structure: Simplicity and Efficiency

For the browser to work fast, it needs simple code. We use a box (div or button) and a container for the text. This allows the visual effect to be separated from the actual content.

<div class=box>
  <div class=content>
    <h1>Glowing border</h1>
    <p>Hover your mouse to animate the border</p>
  </div>
</div>

Here, we do not use quotes for simple classes like class=box. This is an optimization that slightly reduces the HTML file size. Modern browsers understand this code perfectly.

Step 1: Declaring an Intelligent Variable

In CSS, we often use variables. But here, we use a “typed” variable. We tell the browser that --angle is a unit of rotation measurement.

@property --angle {
  syntax        : "<angle>";
  initial-value : 76deg;
  inherits      : false;
}

Why is this important? Without this, the browser does not know how to smoothly transition from 0 to 360 degrees. Thanks to @property, the animation is handled mathematically. This allows for 120 frames per second without any effort.

Step 2: Fluid Design with clamp and min

We want our box to look good everywhere. We do not use fixed sizes in pixels. Instead, we use min() and clamp() functions.

.box {
  position    : relative;
  display     : grid;
  place-items : center;
  /* Width adapts between 90% on mobile and 25rem on desktop */
  width       : min(90vw, 25rem);
  height      : auto;
  background  : #012;
  /* Fluid spacing */
  padding     : clamp(.625rem, calc(1.136vw + .3978rem), 1.25rem);
  margin      : 1.25rem;
}

clamp() automatically calculates the best size. There is no need for complex rules for mobile phones. This is a win for performance and code maintenance.

Step 3: Creating Light Layers

We use two invisible layers behind the box: ::before and ::after. The secret is to use a conic gradient.

1. The ::before layer: This is the sharp border. It is placed right behind the background.
2. The ::after layer: This is the glowing halo. It is placed even further back (z-index: -2) and is blurred.

.box::before, .box::after {
  content    : "";
  position   : absolute;
  inset      : -3px; /* Border thickness */
  z-index    : -1;
  background : conic-gradient(from var(--angle), #56e0a6, #060c21, #11b9d1, #060c21, #56e0a6);
}

.box::after {
  z-index : -2;
  filter  : blur(20px);
}

By using inset: -3px, we ask the gradient to slightly overlap the box. This creates the colored border.

Step 4: Interaction and Animation

The effect only activates when the user hovers over the box. This saves energy. We use two animations at the same time. The first rotates the angle. The second adds a sepia filter to make the light more intense.

&:hover::before, &:hover::after {
  animation : glowing-border 3.5s linear infinite;
}

&:hover::after {
  animation-name : glowing-border, blur-effect;
}

@keyframes glowing-border {
  to { --angle : 436deg }
  /* 76deg + 360deg for a full rotation */
}

@keyframes blur-effect {
  to { filter : blur(15px) sepia(.3) }
}

The sepia filter is very clever. It slightly changes the hue of the colors. This gives a more “vivid” and warm look to the button during clicks or hovers.

Why is this Technique the Fastest?

There are several ways to draw a border. But most of them force the browser to recalculate the page’s shape. This is called Layout Shift.

Our method uses only the final Rendering Process (Composite). Since we only modify one variable (--angle) and one filter (blur), the browser does not redo position calculations. This is the least tiring method for the computer.

SEO Impact and Core Web Vitals

SEO is not just text. It is also the technical quality of your components. Here is how this button helps your ranking:

1. LCP (Largest Contentful Paint): The button is lightweight. It does not block the display of the rest of the page.
2. INP (Interaction to Next Paint): The hover response is instantaneous because it is handled by the GPU. Google loves fast interactions.
3. CLS (Cumulative Layout Shift) : By using aspect-ratio or calculated sizes (height: auto), content does not jump during loading.

Accessibility: Readability and Movement

A button must be readable for everyone. In our example, the text is in a separate layer (.content). It always remains white on a dark background. The contrast is excellent, which is vital for visually impaired users.

We must also think of people sensitive to movement. Some people may feel dizzy with rotating lights. CSS allows us to automatically disable the animation for them.

@media (prefers-reduced-motion : reduce) {
  .box::before, .box::after {
    animation  : none;
    background : #11b9d1; /* A fixed and calm border */
  }
}

Performance Optimization: Avoiding Overrides

In our code, we do not use complicated selectors. We use CSS nesting (&::before). This allows the browser to read the code faster. If you need multiple variants, use :not(). For example: .box:not(.no-animation). This avoids forcing the browser to cancel styles that have already been calculated.

Conclusion: The Power of Modern CSS

Creating “Premium” interfaces does not require heavy libraries. With a few well-thought-out lines of CSS, you get:

• Fluid animation at 120 FPS.
• A perfect performance score on Lighthouse.
• A pleasant and interactive user experience.

Performance is not the enemy of design. It is the engine that allows design to be appreciated by everyone. Every millisecond of calculation saved is a victory for your SEO and the planet.

Frequently Asked Questions (FAQ)

On the internet, friction is the number one enemy. Every field a user must fill manually is an opportunity for them to leave your site. This is called form abandonment. For an e-commerce site or an online service, this represents a direct loss of money.

However, there is a free, native, and extremely high-performance technical solution: the autocomplete attribute. According to figures from Zuko, correctly using auto-completion increases form success rates from 59% to 71%.

This guide explains how to transform your forms using only HTML.

Why autocomplete changes everything?

Filling out a form requires significant effort, especially on a mobile phone. The user must click the field, wait for the keyboard to appear, type their information without mistakes, and then move to the next field.

The autocomplete attribute allows the browser to do all this work for the user. In a fraction of a second, the browser identifies the data stored in its system and offers to fill the entire form at once.

The difference between “heuristic” and “semantic”

If you don’t use the autocomplete attribute, the browser tries to guess what it should fill. This is called heuristics. It looks at the field name (name=prenom) or the surrounding text. But browsers often make mistakes, especially if your site is translated into several languages.

By adding autocomplete, you provide a semantic instruction. You tell the browser: “This field is exactly for the first name.” There is no more room for error. The performance gain is immediate because the browser no longer needs to analyze your code to guess your intentions.

1. User Identity

This is the basis of every form. For the browser to suggest the correct information, you must use standard tokens.

Here is a code example optimized for identity:

<div class=form-group>
  <label for=first-name>First Name</label>
  <input id=first-name name=fname type=text autocomplete=given-name required>
</div>

<div class=form-group>
  <label for=last-name>Last Name</label>
  <input id=last-name name=lname type=text autocomplete=family-name required>
</div>

<div class=form-group>
  <label for=nickname>Username</label>
  <input id=nickname name=user type=text autocomplete=nickname>
</div>

<div class=form-group>
  <label for=job-title>Job Position</label>
  <input id=job-title name=position type=text autocomplete=organization-title>
</div>

Why separate first and last names?

Some forms use a single “Full Name” field. This is an error for auto-completion performance. Browsers often store first and last names separately. By using given-name and family-name, you guarantee perfect filling.

2. Contact details

Typing errors in email addresses or phone numbers are the leading causes of account creation failure. Auto-completion eliminates this risk.

<!-- Contact details optimized for mobile interaction -->
<div class=form-group>
  <label for=user-email>Email Address</label>
  <input id=user-email name=email type=email autocomplete=email required>
</div>

<div class=form-group>
  <label for=user-phone>Phone Number</label>
  <input id=user-phone name=phone type=tel autocomplete=tel>
</div>

Technical note: Always use type=email and type=tel in addition to autocomplete. This allows smartphones to display the correct keyboard (numeric keypad for phone), which further increases input speed.

3. Shipping Address: The e-commerce challenge

The address is the longest part to fill. It often contains five or six different fields. This is where the impact on conversion is strongest.

<!-- Shipping address tokens for e-commerce performance -->
<div class=form-group>
  <label for=street>Street Address</label>
  <input id=street name=addr1 type=text autocomplete="shipping street-address">
</div>

<div class=form-group>
  <label for=city>City</label>
  <input id=city name=city type=text autocomplete="shipping address-level2">
</div>

<div class=form-group>
  <label for=zip>Zip Code</label>
  <input id=zip name=zip type=text autocomplete="shipping postal-code">
</div>

<div class=form-group>
  <label for=country>Country</label>
  <input id=country name=country type=text autocomplete="shipping country">
</div>

By adding the word shipping before the token (e.g., shipping postal-code), you indicate to the browser that this is the delivery address. If it is the billing address, use billing. This allows the browser to offer two different addresses if the user has saved them.

4. Payments and Security

Filling in credit card numbers is stressful for the user. By automating this step, you reduce anxiety and speed up the payment.

<!-- Payment fields with secure native autocomplete -->
<div class=form-group>
  <label for=card-num>Card Number</label>
  <input id=card-num name=cnum type=text autocomplete=cc-number>
</div>

<div class=form-group>
  <label for=card-name>Name on Card</label>
  <input id=card-name name=cname type=text autocomplete=cc-name>
</div>

<div class=form-group>
  <label for=card-exp>Expiry Date</label>
  <input id=card-exp name=cexp type=text autocomplete=cc-exp>
</div>

Contrary to popular belief, this is more secure. The user does not need to take out their card in a public place. The browser protects this data with a password or fingerprint (TouchID/FaceID).

5. Password Management

This is one of the most critical points. Poor autocomplete configuration can block a user trying to log in.

• For Login: Use autocomplete=current-password.
• For Registration: Use autocomplete=new-password.

This tells the password manager whether to suggest an old code or generate a new one securely.

6. Accessibility (WCAG): A right for everyone

Web accessibility is not just for the blind. It also concerns people with motor impairments (difficulty typing) or cognitive impairments (difficulty remembering their own information).

The WCAG 2.1 standard requires identifying the purpose of the input (criterion 1.3.5). The autocomplete attribute is the official solution to comply with this rule. Without it, your site may be considered non-compliant with accessibility laws.

7. Performance: Why native always wins?

Many sites use heavy JavaScript scripts to help with input (address search via API). While these tools are useful, they slow down the page. They require time to load the script and execute the code.

The HTML autocomplete attribute has a performance cost of zero.

1. No additional network request.
2. No CPU calculation time.
3. Works even if the network is slow or if JavaScript is blocked.

Absolute mistakes to avoid

• Abuse of autocomplete=off: Some developers think they increase security by forbidding auto-completion. It’s the opposite. You force the user to use simple passwords to remember them.
• Fancy field names: If you use name=field_1, the browser will struggle to understand without the autocomplete attribute. Always be explicit.

Conclusion

Form optimization is not about adding complex features, but about the intelligent use of web standards. The autocomplete attribute is the most powerful tool to improve user experience without any compromise on performance.

As a developer or site manager, your mission is to reduce your visitors’ effort. A form that fills itself is a form that converts.

FAQ

Modern web development relies almost exclusively on asynchrony. Whether fetching data via an API, loading modules on the fly, or managing streaming flows, the fetch() function has become the universal tool. However, a crucial question is often ignored: what happens when the user leaves a page before the loading finishes?

Without control, you create “zombie requests.” These processes continue to consume bandwidth and processor resources ( CPU) in the background, even if the result is no longer needed. This is where AbortController comes in.

In this expert guide, we will break down how this API transforms the management of your requests to achieve an optimal level of performance and digital sobriety.

The Problem of Orphaned Requests

Imagine a “search-as-you-type” interface. For every character typed, a fetch() request is launched. If the user types “JavaScript” quickly, seven or eight requests can be sent to the server. If the early requests arrive after the last one, they might overwrite the most recent data in your interface (a race condition problem).

Previously, canceling a promise was complex, if not impossible to do cleanly. The introduction of AbortController in 2018 radically changed the game by providing a standardized way to interrupt any asynchronous process.

Anatomy of AbortController

The object consists of two distinct but linked parts:

1. The Controller: The object that holds the power to cancel.
2. The Signal: The token passed to asynchronous functions so they know when to stop.

Here is the simplest implementation:

const
  controller = new AbortController(),
  signal = controller.signal;

// Triggers cancellation
controller.abort();

Canceling a fetch Request: A Practical Case

To cancel a fetch(), simply pass the signal in the request’s options object.

async function fetchData(url)
{
  const controller = new AbortController();

  try
  {
    const response = await fetch(url, {signal: controller.signal});
    return await response.json();
  } catch (error)
  {
    if (error.name === 'AbortError')
      console.warn('Fetch request was cancelled by the user.');
    else
      console.error('A network error occurred:', error);
  }
}

Why Is It Vital for Performance?

By calling abort(), the browser immediately cuts the TCP connection. You instantly save battery on mobile devices and free up RAM that won’t be used to process a useless response.

Native Timeout Management: Goodbye Manual setTimeout

One of the greatest recent advancements (Baseline 2023) is the static AbortSignal.timeout() method. It allows you to set a time limit for an operation without having to manage complex counters yourself.

async function fetchWithTimeout(url, ms)
{
  try
  {
    // Automatically aborts after 'ms' milliseconds
    const response = await fetch(url, {signal: AbortSignal.timeout(ms)});
    return await response.json();
  } catch (error)
  {
    if (error.name === 'TimeoutError')
      console.error('The request took too long and timed out.');
  }
}

This approach is much more robust than old “hacks” using Promise.race(), because it actually cancels the network request instead of simply ignoring its result.

Advanced Usage: AbortSignal.any()

In 2026, we often have to handle cancellations from multiple sources (a “Cancel” button AND an automatic timeout). The AbortSignal.any() method allows combining several signals. The first signal to activate triggers the global cancellation.

async function robustFetch(url)
{
  const
    userController = new AbortController(),
    timeoutSignal = AbortSignal.timeout(5000),
    // Combine signals: aborts if user clicks OR if 5s elapse
    combinedSignal = AbortSignal.any([
      userController.signal,
      timeoutSignal
    ]);

  return fetch(url, {signal: combinedSignal});
}

State Management and User Feedback

Canceling an asynchronous task should not come at the expense of clarity. An interface that remains frozen after clicking “Cancel” is a UX error. The logic resides in state transitions driven by JavaScript and reflected by robust * CSS*.

async function handleActionWithFeedback(controller)
{
  const btn = document.getElementById('action-btn');
  btn.classList.add('is-loading');

  try
  {
    await performHeavyTask(controller.signal);
  } catch (err)
  {
    if (err.name === 'AbortError')
      btn.classList.replace('is-loading', 'is-cancelled');
  }
}

To accompany this logic, I use a fluid design that ensures my status indicators remain readable on any screen, without multiplying media queries:

.status-indicator {
  /* Fluid typography: min 14px, max 20px based on viewport width */
  font-size : clamp(0.875rem, 1.2vw + 0.5rem, 1.25rem);
  padding   : clamp(0.5rem, 2vh, 1.5rem);

  /* Target only end states without overriding the base */
  &:not(.is-loading, .is-success) {
    background-color : var(--background-soft);
    filter           : grayscale(1);
    opacity          : 0.7;
  }
}

AbortController Beyond the Network: Event Listeners

AbortController is not reserved for network requests. You can use it to clean up your Event Listeners all at once. This is a major technique for avoiding memory leaks in Single Page Applications (SPA).

const menuController = new AbortController();

window.addEventListener('resize', handleResize, {signal: menuController.signal});
window.addEventListener('scroll', handleScroll, {signal: menuController.signal});

// Clean up everything at once
function destroyComponent()
{
  menuController.abort();
}

Performance and Eco-design: The Virtuous Circle

On this blog, I often advocate for digital sobriety. AbortController is one of its best technical ambassadors:

• Server Traffic Reduction: Fewer useless requests processed by your PHP or Node.js backend.
• Data Economy: Crucial for users with limited plans or in low network coverage areas (3G/Edge).
• Display Fluidity: By cutting useless processing (JSON parsing, DOM manipulations), you avoid jank and allow the browser to maintain a smooth 60 FPS rendering.

SEO Strategy and Accessibility

While request cancellation is a background task, it indirectly impacts your SEO. Google analyzes the visual stability and response speed of your pages (Core Web Vitals). A site that doesn’t manage its zombie requests ends up lagging, degrading the LCP (Largest Contentful Paint) score.

On the accessibility side, ensure that when an operation is canceled by a timeout, the user is informed via an aria-live region.

const statusEl = document.getElementById('status-message');

if (error.name === 'AbortError')
{
  statusEl.textContent = 'Loading interrupted.';
  statusEl.setAttribute('aria-live', 'polite');
}

Conclusion: Toward Responsible Code

AbortController is not an option; it is a necessity for any developer aiming for technical excellence. It allows you to move from code that suffers from asynchrony to code that directs it. In 2026, the quality of an application is judged not only by what it displays but by the cleanliness with which it handles what it no longer displays.

Take back control, cancel the superfluous, and build a faster, more human web.

Frequently Asked Questions

Accessibility is not just a checkbox; it is a software quality assurance process. Even the best intentions can fail if they are not backed by rigorous tools and a clear audit methodology.

An audit tool does only one thing: it helps you validate the technical application of WCAG rules. It will never replace your developer judgment. For this reason, it is essential to know the strengths and limits of each instrument.

This guide is a critical examination of the 11 essential tools to ensure the compliance of your projects, especially in view of the European Accessibility Act (EAA 2025).

1. Automated Analysis Tools (CI/CD Integration)

A. Axe Accessibility (Deque Systems) — The Industrial Standard

B. WAVE (WebAIM) — The Educational Evaluation Tool

C. Lighthouse (Chrome DevTools) — The Global Score Audit

2. Manual Testing Tools

A. Screen Readers (NVDA and VoiceOver)

B. Keyboard Navigation (The Tab Key)

3. Design and Contrast Validation Tools

A. Color Contrast Analyzer (TPGi)

C. Stark (Figma/Sketch Plugin) — Design Integration

4. Journey Audit Tools

A. Tanaguru — User Journey Audit

Conclusion: Accessibility is a Quality Metric

Mastering these tools allows you to offload low-level validation from development to focus on complex semantics and UX. By combining automation (Axe) with manual testing (NVDA), you guarantee not only WCAG compliance but also a truly superior experience for every user.

In 2026, accessibility is the new indicator of performance and technical rigor.

Frequently Asked Questions

Web accessibility is often seen as a technical chore. We tend to think it is only about complying with laws like the EAA 2025. In reality, accessibility is a mark of quality. An accessible site is better built and faster for everyone.

In 2026, we have precision tools to help users: Preference Media Queries. These lines of code detect settings chosen by users on their phones or computers. The site can then change its look automatically.

In this guide, we will explore 7 essential media queries. We will learn how to code for maximum performance while remaining compatible with all browsers.

A Golden Rule: Progressive Enhancement

Before coding, you must understand an important rule. Do not build a heavy site and then try to “fix” it for people with disabilities. Do the opposite.

Use the Progressive Enhancement logic:

1. First, create a simple, static, and easy-to-read base. This is the version for everyone.
2. Add animations or visual effects only if the user has not requested restrictions.

To achieve this, we often use the no-preference value.

1. prefers-reduced-motion: mastering movement

Some people experience dizziness or nausea when there is too much movement on the screen. These are called vestibular disorders. About 35% of adults over 40 are affected by these disorders, according to a study published by the National Institutes of Health.

Unfortunately, since support is currently limited on some browsers, we cannot condition everything via this media query. If a browser does not support it, no style will be applied. To avoid this, we define a static base and then add the animation inside the media query block. We will therefore have two contradictory orders when the value is “no-preference,” but that is the price of compatibility.

The high-performance method:

/* Static and lightweight base for everyone */
.my-title {
  transform: none;
}

/* Animation is only enabled if the user accepts movement */
@media (prefers-reduced-motion: no-preference) {
  .my-title {
    animation: 1s slide-in forwards;
  }
  
  :root {
    scroll-behavior: smooth;
  }
}

2. prefers-color-scheme: native dark mode

This is likely the most well-known media query. It detects whether the user has chosen a light or dark theme in their device settings.

Using prefers-color-scheme is essential for visual comfort. It is also a gesture for the planet: on modern (OLED) screens, displaying black consumes less energy.

Optimize with light-dark()

To go further and simplify your code, you can combine this query with the new light-dark() function. It allows you to manage two colors in a single line of code.

To understand how to use it and boost your rendering performance, read my complete guide on the light-dark() function and eco-design.

3. prefers-contrast: visual clarity

Not everyone perceives contrasts the same way. With age or certain vision conditions (like cataracts), light gray text on a white background becomes unreadable.

Implementation:

.my-card {
  border: 1px solid #ccc;
}

@media (prefers-contrast: more) {
  .my-card {
    border: 2px solid #000; /* Thicker, black border */
    box-shadow: none;       /* Remove shadows that blur vision */
  }
}

4. forced-colors: visual survival mode

On Windows, “High Contrast” mode replaces your colors with a palette chosen by the system. In this case, your background colors disappear. You must ensure that your elements remain visible through their borders.

It is useless to fight against this mode. You must embrace it by using system color keywords.

@media (forced-colors: active) {
  .action-button {
    /* Force a border that adapts to system colors */
    outline: 2px solid ButtonText;
    border: 1px solid ButtonText;
  }
}

To see all available codes, check the system colors list on MDN. This guarantees that your buttons will never be invisible.

5. inverted-colors: respecting system inversion

Some visually impaired users invert all their screen colors to read better (white becomes black, blue becomes orange). The problem is that your photos also become unreadable “negatives.” The inverted-colors query allows you to fix this.

@media (inverted-colors: inverted) {
  img, video {
    /* Re-invert images to make them look natural again */
    filter: invert(100%);
  }
}

6. prefers-reduced-transparency: avoiding visual fatigue

Blur effects (Glassmorphism) are pretty but tire the brains of people with attention disorders or reading difficulties. Text becomes blurry on a transparent background.

Since Firefox does not yet handle this option, we use the same logic as for movement: a solid base style, and the visual effect added only for those without restrictions.

/* Base: solid, opaque background for easy reading */
.nav-menu {
  background: #ffffff;
}

/* Visual effect added only if the user has no restriction */
@media (prefers-reduced-transparency: no-preference) {
  .nav-menu {
    background: rgba(255, 255, 255, 0.7);
    backdrop-filter: blur(5px);
  }
}

7. The speech media query: the web for ears

Accessibility is also for those who listen to the web. Blind users use software that reads the site aloud. The speech query allows you to adapt the text specifically for these tools.

@media speech {
  .decorative-spacer, .ads-banner {
    display: none;
  }
}

Performance and SEO: why code this way?

Using these techniques is not just an ethical act. It is a software quality strategy:

1. Zero JavaScript: CSS is handled natively by the browser, which is much faster than detection scripts.
2. LCP Score: Rendering is more stable because media queries are resolved instantly during CSS parsing.
3. Technical SEO: Google favors sites that respect web standards and provide a smooth experience for all user profiles.

Conclusion: a more human web

Learning accessibility media queries is the mark of an expert developer in 2026. It’s not just extra code; it’s better-thought-out code. An accessible site is a universal site, performant and ready for the future.

Inclusion is the ultimate form of optimization.

Frequently Asked Questions

Dark mode is no longer just a trend. It is a mandatory ergonomic standard. According to a study on Dark Mode usage by 82% of users, this setting has become the norm. It now dictates how I design my interfaces.

However, many websites still use outdated methods. These methods slow down the browser. They create unpleasant flashes of light during page load. In 2026, I must use native CSS tools. This guide explains how to combine technical performance with visual comfort.

Why dark mode is a strategic priority

A dark theme is not just “pretty.” It is a powerful lever for three pillars: health, energy, and performance.

1. Accessibility and eye health

Dark mode reduces eye strain. This is especially true in dark environments. It also helps people sensitive to bright light (photophobia).

However, I must be careful with contrasts. Dark gray on a black background is unreadable. I follow WCAG 2.1 standards. This ensures my content remains accessible to everyone.

2. Eco-design and battery life

This is where technology meets ecology. On OLED screens, a black pixel is a pixel turned off. A turned-off pixel consumes no energy.

According to a study published by the ACM, dark mode can save up to 47% of battery. This gain is highest when screen brightness is high. At 50% brightness, the saving drops to around 9%. Dark mode is a concrete digital sobriety tool for mobile users.

3. Rendering performance

Old methods used a lot of JavaScript. JavaScript must be loaded and executed. This increases Total Blocking Time (TBT).

Native CSS is handled directly by the browser’s rendering engine. It is faster. It uses less processor (CPU) power. It is the best choice for web performance.

The color-scheme: light dark revolution

For a long time, developers used classes like .dark-mode on the <body> tag. It was heavy. It required syncing JavaScript and CSS.

The first modern step is to declare theme support to the browser:

:root {
  /* Tell the browser that I support both themes */
  color-scheme: light dark;
}

This line is magic. It automatically changes native elements of the page:

• Scrollbars.
• Buttons and form fields.
• Default system background colors.

The elegance of the CSS light-dark() function

The light-dark() function is a major new feature. It allows defining two values in a single property. It is much cleaner than repeating media queries everywhere.

Syntax and implementation

Here is how I centralize my colors:

:root {
  color-scheme: light dark;

  /* light-dark(light-value, dark-value) */
  --bg-primary: light-dark(#f4f4fa, #16191a);
  --text-main: light-dark(#333333, #eeeeee);
  --accent: light-dark(#005398, #4dabf7);
}

body {
  background-color: var(--bg-primary);
  color: var(--text-main);
}

The major benefit: The code is shorter. The CSS tree is simplified. The browser decides which value to use instantly.

Managing images in dark mode

A very bright image can blind a user in dark mode. This breaks the user experience. There are two technical solutions.

1. Darken via CSS filters

I can apply a global filter. It is fast and effective for photos:

@media (prefers-color-scheme: dark) {
  img:not([src$=".svg"]) {
    /* Lower brightness and boost contrast for better visibility */
    filter: brightness(.85) contrast(1.1);
  }
}

2. Use the element for diagrams

Sometimes, a simple brightness drop is not enough. This applies to charts or logos. In that case, I use two versions of the image:

<picture>
  <source srcset="chart-dark.avif" media="(prefers-color-scheme: dark)">
  <img src="chart-light.avif" alt="Technical architecture diagram" width="800" height="400">
</picture>

Avoiding Flash of Unstyled Content (FOUC)

The light “flash” (FOUC) happens when JavaScript takes too long to execute. The user sees the light mode for a fraction of a second before the dark mode activates. This is a serious UX error.

The high-performance solution: By using prefers-color-scheme and light-dark(), the browser knows the theme before displaying the first pixel.

1. No JavaScript to load.
2. No preference to read from a database.
3. No visual flash.

This is the approach I use in EcoComposer. The library detects user preferences declaratively. This ensures a smooth experience, even on slow connections.

Dark design pitfalls

A successful dark mode requires subtlety. Here are three common mistakes I avoid.

1. Pure black (#000)

I never put pure white text on a pure black background. High contrast tires the eyes. It creates a “halation” effect. I prefer very dark grays like #121212.

2. Color saturation

A bright color is perfect on a white background. On a dark background, it can become “electric” and aggressive. I desaturate my accent colors for dark mode. Users will appreciate it.

3. Depth and elevation

In light mode, I use drop shadows to create depth. In dark mode, shadows are invisible. To show that an element is in the foreground (like a modal), I use a slightly lighter background color.

• Page background: #121212.
• Elevated element: #1e1e1e.

Impact on SEO and Core Web Vitals

Google loves fast sites. Native dark mode directly helps your scores:

• LCP (Largest Contentful Paint): Less JavaScript means faster display.
• CLS (Cumulative Layout Shift): Avoiding late CSS classes prevents layout shifts.

A comfortable site keeps users longer. This improves your bounce rate. It is a positive signal for your SEO.

Conclusion: responsible code craftsmanship

Mastering dark mode is proof of professionalism. By using light-dark() and color-scheme, I show that I master modern tools. I build a lighter, more accessible, and more sustainable web.

I don’t let technical constraints dictate my work. I use them to offer the best possible experience.

FAQ

Creating a modern website often requires displaying overlapping elements, such as pop-up windows (modals) or slide-out menus. But one question remains: how can you be sure that the user won’t click on a button left “behind” or navigate with their keyboard in an area they can no longer see?

For a long time, this simple task was a nightmare for developers. It required writing very long and complicated JavaScript scripts to prevent the cursor from moving anywhere. Today, there is a much simpler solution built directly into the HTML language: the inert attribute.

In this guide, we will see how this tiny tool makes your sites faster, lighter, and above all, much simpler to use for people with disabilities.

What exactly is the inert attribute?

The word “inert” means something that does not move or act. In web programming, when you add the inert attribute to a part of your page (a div, a section, or a main), you tell the browser to consider that this area no longer exists for the user.

It is not just a visual change. It is a deep “sleep mode” for the element. Here are the three main effects it produces immediately:

1. No more clicking: Any links, buttons, or forms in the area become impossible to click with a mouse or touch on a
2. touchscreen.
3. The keyboard ignores it: If a user uses the “Tab” key to move from one link to another, the browser will
4. directly skip the entire part marked as inert. This is a huge help for people with motor difficulties.
5. Screen readers stay silent: Software used by blind people completely ignores the content of the area. This
6. prevents reading information that is not relevant at that moment.

A radically simple approach

Unlike old methods that required modifying every button one by one, inert applies to a parent. If you set a box to “inert,” everything inside it automatically becomes inert as well. This is called “shorthand” or “cascade” propagation.

Why is it a revolution for accessibility?

For a user who sees well and uses a mouse, it is easy to understand not to click on what is behind an open window. But for a person with a disability, the situation is different.

Protecting the user from “navigation errors”

Imagine a blind person opening a navigation menu on their smartphone. If the developer hasn’t made the rest of the page inactive, the screen reader will continue to suggest links from the footer or articles in the background, even though the menu is still open. The user feels lost and no longer knows where they are on the site.

By using inert, you create a kind of “safety barrier.” You guide the user so they stay focused on the important action of the moment (filling out a form, choosing an option in a menu) without risking leaving that area by mistake.

Simplifying keyboard usage

Many people use the keyboard instead of the mouse, either by habit or necessity (motor disability). Without the inert attribute, these users sometimes have to press the “Tab” key 50 times to cross an entire page before reaching the “Close” button of a window. With inert, you remove all unnecessary obstacles. Navigation becomes fluid and natural.

How to use ‘inert’ in your code?

One of the greatest advantages of this solution is its technical simplicity. You don’t need to be a programming expert to use it.

Practical example: the modal window

This is the most common case. Here is how to structure your page so it works perfectly:

<body>
  <!-- Wrap all main content in a div -->
  <div id=main-content>
    <header>...</header>
    <main>...</main>
    <footer>...</footer>
  </div>

  <!-- The window that pops up on top -->
  <div id=my-modal-window role=dialog aria-modal=true>
    <button onclick="close()">Close</button>
    <p>This is important information.</p>
  </div>
</body>

When you display the window, you simply add the attribute to the area you want to make inactive: document.getElementById('main-content').setAttribute('inert', '');

And when you close the window, you remove the attribute: document.getElementById('main-content').removeAttribute('inert');

In a single line of code, you have solved all the interactivity problems on your page.

Inert vs aria-hidden: don’t get them confused anymore

This is a very common confusion during development. Many sites use aria-hidden="true". It is a good intention, but it is incomplete.

• aria-hidden="true": Tells the screen reader not to read the area. But the user can still click on it or access
• it with the Tab key on their keyboard. This is very confusing because you can interact with something that isn’t being
• announced.
• inert: Blocks everything at the same time. Mouse, keyboard, and voice. It is the complete solution.

Performance and eco-design: code less to do more

On this blog, I often talk about performance and respect for the digital environment (eco-design). The inert attribute is an excellent example of this philosophy.

Reducing page weight

Previously, to manage navigation blocking, we downloaded JavaScript libraries (like focus-trap) that weighed several dozen kilobytes. Multiplied by millions of visitors, this represents significant energy consumption for servers and networks.

By using a native browser function, you remove these useless files. Your site loads faster, which improves your LCP (Largest Contentful Paint) score. For Google, this is a positive signal that can help your SEO.

Less work for the user’s computer

Every script running in a browser consumes battery on a smartphone. inert is handled directly by the browser engine (in very fast C++ language). It is much more energy-efficient than a JavaScript script that monitors every mouse movement or every key press.

A word on compatibility (Baseline 2024)

For a few years, inert was an experimental novelty. That is no longer the case. Since 2024, it has been part of what is called the “Baseline.” This means all modern browsers (Chrome, Firefox, Safari, Edge) support it perfectly.

If you still need to support very old browsers (which is increasingly rare), light “polyfills” (backup scripts) exist, but for 96% of internet users, this will work natively without any extra effort on your part.

Design tip: stylizing inactive zones

To improve the user experience (UX), it is recommended to visually show that the background content is no longer available. You can use the inert attribute as a selector in your CSS file:

/* Reduce visibility of everything that is inert */
[inert] {
  opacity        : .4;
  filter         : blur(2px);
  user-select    : none;
  pointer-events : none;
}

This way, the user immediately understands, at a glance, that they must focus on the active window. It’s an elegant way to marry design and technology.

Conclusion: Toward responsible code craftsmanship

Adopting the inert attribute is not just about saving the developer time. It is a sign of respect toward users. By choosing native and lightweight solutions, we build a web that leaves no one behind, whether they are people with disabilities or users with slow internet connections.

In 2026, the quality of a site is no longer measured by the complexity of its scripts, but by the relevance of its technical choices. Use inert, simplify your code, and make accessibility a strength for your project.

Frequently Asked Questions

Web accessibility is often perceived as a purely technical constraint—a simple checkbox to comply with legal standards like the EAA 2025. However, behind the algorithms and tags lies a massive human reality: according to the World Health Organization, at least 2.2 billion people suffer from near or far vision impairment.

For a developer or designer, ignoring this audience is not just an ethical lapse; it’s a major strategic mistake. An unreadable site is a site that doesn’t convert. In this article, we will explore how to turn this “constraint” into a lever for software quality by learning how to simulate these impairments and code robust CSS solutions.

Understanding the Spectrum of Visual Impairments

A common mistake is reducing vision impairment to total blindness. In reality, the spectrum is vast and impacts web navigation in diverse ways:

1. Color Blindness (Dyschromatopsia): According to the Colour Blind Awareness organization, it affects approximately 8% of men and 0.5% of women. Whether it’s protanopia (red), deuteranopia (green), or tritanopia (blue), the problem remains the same: information transmitted solely through color is lost.
2. Low Vision: This includes reduced visual acuity, blurred vision, or extreme sensitivity to light. These users often rely on intensive zooming (up to 400%), an adaptation requirement now mandated by W3C WCAG standards.
3. Central or Peripheral Vision Loss: Conditions like macular degeneration (AMD) or glaucoma create “dead zones” in the field of vision.
4. Cataracts: This produces clouded vision and a drastic loss of contrast, making thin or light gray fonts completely invisible.

Simulating to Better Understand: Browser Tools

Before fixing, you must feel. Did you know that your Chrome DevTools (and Firefox) include real-time vision simulators?

How to Enable the Simulation?

1. Open the Inspector (F12).
2. Use the shortcut Ctrl+Shift+P (or Cmd+Shift+P on Mac) to open the command palette.
3. Type “Rendering” and select the tab.
4. Scroll down to the “Emulate vision deficiencies” section.

Here, you can test your site through the eyes of someone with protanopia or blurred vision. It’s often a brutal experience for a designer: you instantly realize that your “critical” red buttons on a dark background are invisible to part of your users.

CSS Strategies for an Inclusive Interface

Once the observation is made, how do you act at the code level? Accessibility doesn’t mean making “ugly” or black-and-white sites. It’s about resilient design.

1. Contrast: The Golden Rule

The WCAG 2.1 standard requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

• Technical Tip: Use tools like color.review to find combinations that work.
• Beyond Black and White: Avoid pure contrast (black #000 on white #FFF), which can cause eye strain (halation) in people with dyslexia or photophobia. Prefer very dark grays on off-whites.

2. Typography: Abandon Pixels

This is the most common frontend error. Using px for font sizes blocks the user’s ability to resize text via their browser settings.

• The Solution: Use the rem unit. It is based on the root size defined by the user.
• Line Height and Spacing: A line-height of at least 1.5 and generous paragraph spacing radically improve reading for people with blurred vision.

3. Layout Robustness (The Zoom Test)

A visually impaired user will zoom your page to 200% or even 400%. If your menu overlaps the content or columns clash, the site is unusable.

• Fluid Design: Use Flexbox and CSS Grid to allow content to reorganize naturally.
• Container Queries: This is the future. They allow a component to adapt to the space allocated to it, rather than the total screen width, which is crucial during intensive zooming.

Media Queries: Give Control Back to the User

Modern CSS offers tools to detect user preferences at the operating system level.

/* Detect "High Contrast" modes forced by the OS */
@media (forced-colors: active) {
  .button {
    /* We force a border because the background might disappear */
    border: 2px solid ButtonText;
    outline: 1px solid transparent;
  }
}

/* For light-sensitive users */
@media (prefers-color-scheme: dark) {
  body { background-color: #121212; color: #e0e0e0; }
}

/* For those who enabled "High Contrast" on Windows/macOS */
@media (prefers-contrast: more) {
  .button { border: 2px solid currentColor; }
}

/* Activate animations only if no reduction is requested */
@media (prefers-reduced-motion: no-preference) {
    .modal {
      animation: fadeIn 0.3s ease-in-out;
    }
    .link {
      transition: color 0.2s ease;
    }
}

These media queries allow you to offer a personalized experience without the user having to configure anything on your site. This is the principle of Universal Design.

SEO and Performance Impact: The Virtuous Circle

Many don’t know it, but visual accessibility is a direct booster for your Organic Search (SEO). Google behaves like the most powerful “visually impaired” user in the world: it analyzes code to understand meaning, not pixels.

Alt Attributes: Signal vs. Noise

It’s often said that everything must be described. This is false.

1. Informative Image: (e.g., a technical diagram) Use a descriptive alt. It’s vital for the user and excellent
2. for Google Images.
3. Decorative Image: (e.g., an abstract shape, a repetitive icon) **The alt attribute must be present but empty
4. (alt="")**. Why? Because an empty alt tells the screen reader to ignore the image. If it’s missing, the reader
5. will often read the file name (e.g., “bg-pattern-01.jpg”), which is useless noise.

LCP and Core Web Vitals

An accessible page often avoids heavy JavaScript layout manipulations. By using native and robust CSS, you improve your LCP (Largest Contentful Paint) and visual stability, two key factors for ranking in 2026.

Conclusion: Toward Responsible Code Craftsmanship

Accessibility is not a destination; it’s a continuous practice. By integrating visual impairment simulation from the development phase, you create more robust, faster, and more human interfaces.

In 2026, the web can no longer afford to be exclusive. Take control of your contrasts, free your typography, and remember that every millisecond of clarity gained is a victory for all your users.

Frequently Asked Questions

In the all-digital era, the idea of printing a web page might seem outdated. Yet, it is an essential feature that is far from dead. From cooking recipes to consult with your hands full, to assembly guides to follow away from the screen, or plane tickets to keep safe, users still have many reasons to move from pixels to paper.

What if I told you that your CSS can not only make this experience pleasant but also save trees and strengthen your brand image?

This comprehensive guide will show you how to master print styles to transform a chaotic web page into a clear, professional, and environmentally friendly document.

The Strategic Impact of a Print Stylesheet

Many developers ignore the print stylesheet, considering it a minor detail. This is a strategic mistake. Proper print management has direct impacts on user experience, accessibility, and even your brand image.

1. User Experience (UX) and Professionalism

When a user clicks “Print,” they expect a readable document. If the result is a page filled with navigation elements, advertisements, and cut-off columns, the experience is frustrating. A site that offers a clean, well-formatted print version shows attention to detail and high professionalism.

2. Accessibility (a11y)

Accessibility isn’t limited to screen readers. For many people, especially seniors or those suffering from eye strain, reading a long document is more comfortable on paper. Providing a printable and readable version is an important facet of inclusion.

3. Eco-design and Savings

A well-designed print stylesheet is a simple but powerful eco-design gesture. By hiding unnecessary images and forcing a white background, you significantly reduce your users’ ink and paper consumption. It’s good for their wallets and for the planet.

The Basics: @media print

The heart of the magic lies in a simple CSS media query. Everything inside this block will only apply when the page is printed.

@media print {
  /* Your print styles go here... */
}

This approach keeps your print styles completely separate from your screen styles, with no impact on site performance during normal browsing.

6 Steps to a Perfect Print Layout

Optimizing for print isn’t complicated. Follow these steps to cover 99% of needs.

Step 1: Clean Up the Unnecessary

The first rule is to hide everything that doesn’t belong on a sheet of paper. This includes navigation, footers, sidebars, ads, comment forms, and interactive buttons.

@media print {
  header,
  nav,
  footer,
  aside,
  form,
  .comments,
  .ads,
  .no-print {
    display: none;
  }
}

How to ensure these rules apply without conflict?

You might think of specificity wars or using !important. However, the cleanest and most robust solution is architectural: isolating screen-specific styles.

The best practice is to wrap all your complex layout rules or styles that only concern the screen display in a @media screen media query.

Concrete Example:

Instead of having a global style for your header:

/* Bad practice: global style that may conflict */
.main-header {
  display: flex;
  justify-content: space-between;
  background-color: #333;
}

Structure your CSS to clearly separate contexts:

/* Base styles, shared by screen and print */
.main-header {
  /* Ex: padding, etc. */
}

/* Styles ONLY for the screen */
@media screen {
  .main-header {
    display: flex;
    justify-content: space-between;
    background-color: #333;
  }
}

/* Styles ONLY for print */
@media print {
  .main-header {
    display: none;
  }
}

With this architecture, the rules for @media screen and @media print are mutually exclusive. The browser will never apply screen styles during printing, thus eliminating any risk of specificity conflict. Your display: none; will work every time without needing to override selectors or use !important.

This approach ensures cleaner, more predictable, and easier-to-maintain code in the long run.

Step 2: Adapt Typography for Reading

What is readable on a screen isn’t necessarily so on paper.

• Font Family: Serif fonts, such as Georgia or Times New Roman, are often considered more readable for long texts on paper.
• Font Size: Use points (pt) rather than pixels (px) or rem. A size of 12pt is a comfortable standard.
• Color: To save ink and maximize contrast, force the text to pure black and the background to white.

@media print {
  body {
    font-family: Georgia, 'Times New Roman', Times, serif;
    font-size: 12pt;
    color: #000;
    background: #fff;
  }
}

Step 3: Guarantee a Linear Layout

Unlike a screen, a sheet of paper is a fixed-width linear medium. The goal is therefore to ensure that your content flows in a single column, from top to bottom, for maximum readability.

Modern layouts using display: flex or display: grid are powerful assets here. If your site is already responsive and displays in a single column on mobile screens, you’ve already done most of the work.

However, to guarantee this behavior during printing, regardless of the screen size from which the user starts the print, it is recommended to explicitly reset the layout. This also ensures that screen-specific properties, like position: sticky, are neutralized.

@media print {
  /* Basic reset for main containers */
  main, .container, article {
    width: 100%;
    min-width: 0;
    margin: 0;
    padding: 0;
    box-shadow: none;
    border: none;
  }

  /* Force flexbox containers into a single vertical column */
  .flex-container {
    flex-direction: column;
  }

  /* Transform CSS grids into a simple, single-column flow */
  .grid-container {
    display: block; /* The simplest and most robust solution */
  }
}

By forcing a vertical direction for your main containers and resetting their dimensions, you ensure that the content will flow naturally, providing an optimal reading experience on paper.

Step 4: Handle Links

Hyperlinks are useless on paper. To keep them helpful, it is good practice to display the full URL next to the link text. This can be done very simply with a CSS pseudo-element.

@media print {
  a::after {
    content: ' (' attr(href) ')';
    font-size: 9pt;
    color: #333;
  }

  /* Avoid displaying internal links or anchors */
  a[href^="#"]::after,
  a[href^="javascript:"]::after {
    content: '';
  }
}

Step 5: Control Page Breaks

This is where the magic really happens. CSS gives you control over where page breaks should (or should not) occur.

• break-inside: avoid;: Prevents an element (like an image or a code block) from being split in two by a page break.
• break-before: page;: Forces a page break before an element. Very useful for starting a new section on a new page.
• break-after: page;: Forces a page break after an element.

@media print {
  h2, h3 {
    break-after: avoid; /* Prevents a page break right after a heading */
  }

  figure, pre, table {
    break-inside: avoid; /* Protects figures and tables from being cut */
  }
}

Step 6: Manage Page Margins with @page

The @page rule is specific to printing and allows you to define the margins of the printed document, much like in a word processor.

@media print {
  @page {
    margin : 2cm;
  }

  /* You can even target the first page differently */
  @page :first {
    margin-block-start : 3cm;
  }
}

Testing Your Print Styles

No need to waste paper! All modern browsers include a print preview mode in their developer tools.

1. Open developer tools (F12 or Ctrl+Shift+I).
2. Go to the “More tools” menu > “Rendering”.
3. Look for the “Emulate CSS media type” option and select “print”.

Your page will instantly display as if it were being printed, allowing you to adjust your styles in real time.

Conclusion: Small Effort, Big Impact

Optimizing print styles is an often-neglected task, but it demonstrates a high level of polish and respect for the user. With just a few lines of CSS, you not only improve the user experience and accessibility, but you also make a concrete gesture for digital eco-design.

It is proof that well-thought-out code can have benefits far beyond the screen.

Frequently Asked Questions

Web accessibility is often perceived as a compliance constraint—a checklist to avoid legal penalties. This is a narrow view. In reality, it is a pillar of software quality and code robustness.

In this article, we will dive deep into the world of WAI-ARIA. We won’t just talk about “doing the right thing,” but rather about data structures, rendering performance, and how the browser translates your tags for assistive technologies.

The Birth of an Invisible Semantic Layer

In the early days of the web, pages were simple static documents. A link was a link, a heading was a heading. But with the explosion of JavaScript and frameworks like React, Vue, or OTRA, we began simulating complex behaviors. A simple <div> can now become a dropdown menu, a modal window, or a price slider.

The problem? For a screen reader, a <div> remains a meaningless box. To bridge this gap, the WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) specification was created. It acts as an extension of HTML—a system of meta-information that changes nothing visually but redefines the object within the Accessibility Tree.

The Concept of the Accessibility Tree

Few developers realize that the browser does more than just build the DOM (Document Object Model) and the CSSOM (CSS Object Model). It also generates a third tree: the Accessibility Tree.

This tree filters DOM information to keep only what is useful for voice or braille navigation. When you use ARIA attributes, you directly modify the nodes of this tree. If you overload it with useless information, you create “semantic noise” that slows down the user. Performance, in this context, is measured by the speed at which the user understands the interface.

The Three Pillars of the ARIA Specification

To manipulate ARIA with surgical precision, you must understand its three components: roles, properties, and states.

1. Roles (role)

The role defines the element’s contract. Is it a button? A tab? A search area?

• Structural Roles: main, navigation, banner, contentinfo. They help map out the page.
• Widget Roles: dialog, tablist, tooltip. They announce interactive behavior.
• Landmark Roles: They allow users to “jump” directly to a specific section.

2. Properties

These describe characteristics that are generally stable. For example, aria-labelledby allows linking an element to its title via an ID. This is far more powerful than a simple title attribute because it allows for building a complex semantic hierarchy without duplicating text in the code.

3. States (states)

This is the most dynamic part of your development. States change based on user interaction:

• aria-expanded="true/false": Indicates if a menu is open.
• aria-busy="true": Signals to the screen reader that a section is being updated (e.g., an AJAX load).
• aria-invalid="true": Indicates a real-time input error in a form.

The W3C Golden Rule: The Paradoxical “No ARIA”

The number one rule in the official documentation is blunt: “If you can use a native HTML element that already has the semantics and behavior you need, then do not use ARIA.”

The Hidden Cost of “Custom CSS/JS”

Take a checkbox for example.

1. Native Approach: <input type="checkbox">. Pros: Focus management, native keyboard support (Space), automatic “checked” state, maximum performance.
2. ARIA Approach: <div role="checkbox" aria-checked="false" tabindex="0">. Cons: You must write JS to handle the click, JS to handle the Space key, and JS to toggle the state.

Every line of JS added to compensate for a lack of native semantics is technical debt and an extra CPU load for the user’s device. By prioritizing native HTML, you practice eco-design: saving server resources (less code to send) and client resources (fewer scripts to run).

Focus Management: The Heart of Interaction

Accessibility isn’t just about text labels; it’s about movement. For a user navigating solely by keyboard, “focus” is their only means of action.

ARIA does not manage focus on its own. This is a common mistake. If you open a modal window with role="dialog", it is up to you as a developer to move the focus inside the window and implement a “Keyboard Trap” so it doesn’t escape into the background.

The tabindex attribute is your best ally here. tabindex="0" inserts an element into the natural flow, while tabindex="-1" allows an element to be focusable only via JavaScript. Mastering this mechanic is what differentiates an interface that is “accessible on paper” from one that is truly usable.

Handling Dynamic Content with aria-live

In modern web applications, content changes constantly without a page refresh. How does a blind person know that an error message just appeared at the top of the screen while they are filling out a field at the bottom?

The answer is: Live Regions. By using aria-live, you create a monitoring zone for the browser.

• aria-live="polite": The announcement is made as soon as the user stops typing or navigating. This is the most UX-friendly approach.
• aria-live="assertive": The announcement interrupts the screen reader immediately. Use this with extreme caution for critical alerts only.

ARIA and Technical SEO: An Underestimated Alliance

ARIA is often restricted to the realm of screen readers. People forget that search engine crawlers are also “non-visual users.” Google increasingly uses semantic signals to understand the structure of an application.

A site that correctly uses main, search, and navigation roles offers superior “semantic density.” By helping machines understand which button closes a window or which section is complementary (role="complementary"), you indirectly assist Natural Language Processing (NLP) algorithms. High-performance SEO in 2026 is no longer just about keywords; it extends to the structural understanding of the code.

Testing and Validation Strategies

To guarantee the quality of your production version, automation is necessary but not sufficient.

1. Automated Tests: Use libraries like axe-core in your CI/CD pipelines. This catches about 40% of the most common errors (misspelled ARIA attributes, missing IDs).
2. Manual Audit: Nothing replaces a walkthrough with a screen reader (NVDA or VoiceOver). Navigate with your eyes closed. If you feel lost, your ARIA architecture is failing.
3. Browser Inspection: Chrome and Firefox dev tools now have an “Accessibility” tab. Use it to inspect the accessibility tree and verify that your attributes are correctly calculated.

Frequently Asked Questions

Conclusion: Toward Responsible Code Craftsmanship

Mastering WAI-ARIA is not about slapping labels everywhere. It is about understanding how information flows between your source code and the end user. It is an exercise in precision that requires rigor but transforms an ordinary website into a universal platform.

As developers, we have a responsibility to build a web that leaves no one behind. Take back control of your semantics, simplify your components, and make accessibility a driver of your performance.

Forgejo is a complete solution for hosting your source code. It is a free tool that belongs to its developer community. It allows managing IT projects in an ethical and sovereign way.

You too can set up your own instance on your server in a few minutes. Discover why Forgejo has become essential for web professionals seeking independence.

The history of software forges and the emergence of Forgejo

To understand the importance of this tool, one must look at the history of collaborative development. For a long time, developers used centralized tools like SourceForge. Then, GitHub became the global standard for storing code.

However, GitHub is owned by a very large private corporation. This raises questions about data ownership and freedom of choice technological. It is in this context of needing sovereignty that tools like Gitea appeared.

Project origins and the conflict with Gitea Ltd

Forgejo was born from a specific event in the free software ecosystem. Originally, the tool was named Gitea and was managed by passionate volunteers. But in 2022, a company called Gitea Ltd was created to monetize the tool without everyone’s consent.

The community feared losing its technical independence to financial interests. They decided to create a “fork”: a free and community-led copy of the project. This is how Forgejo was born to protect the actual interests of users.

Codeberg and digital sovereignty in Europe

Today, the Codeberg e.V. association oversees the development of the project. It is a non-profit organization based in Germany, subject to European laws. It guarantees that the software will always remain free, open, and ad-free for everyone.

Forgejo’s source code is fully public and can be audited by anyone. Every developer can suggest a bug fix or a new improvement. To do this, you just need to fill out a contribution form on their official platform.

A Git forge managed as a common good

Unlike private platforms, Forgejo has no shareholders to satisfy. Priority remains on software stability and contributor satisfaction. This democratic structure prevents any takeover by a single entity.

The project uses its resources to improve essential developer functions. This avoids adding useless features that often bloat modern tools. It is this philosophy of “chosen sobriety” that makes Forgejo strong.

Technical performance adapted to eco-design

Forgejo’s strength is undoubtedly its lightness and digital sobriety. Unlike GitLab, which requires a lot of RAM, Forgejo is optimized for efficiency.

A lightweight infrastructure for every project version

The software is written in the Go (Golang) language, known for its high performance. This language allows compilation into a single binary, very easy to deploy. You can track every version of your project without slowing down your server, even under heavy load.

Forgejo can run on very modest hardware without losing responsiveness. It is capable of running on a Raspberry Pi with only 100 MB of available RAM. This is a major advantage for reducing the electricity consumption of data centers.

Advanced functions for daily collaborative work

Forgejo is not just a passive storage space for your code. It includes all the modern tools to organize a technical team’s work:

• Integrated Kanban boards to track task progress in real time.
• A powerful ticketing system (Issues) to manage bugs and suggestions.
• A complete Wiki to document every feature of your software.

Each tool is designed to be fast and accessible, even with a slow connection. The interface is minimalist to avoid distracting the user from their main task. This also reduces page weight and speeds up overall display on the web.

Modern automation with Forgejo Actions

Modern development requires testing code with every modification. Forgejo now integrates its own CI/CD system called Forgejo Actions. This allows running automatic tests to ensure everything works as expected.

The system is compatible with GitHub Actions configuration files. You can migrate your current automations to Forgejo without rewriting everything. This greatly facilitates the switch to a more respectful and private infrastructure.

Technical choice: Go language vs Ruby

Why is Forgejo so fast compared to its competitors? The answer lies in the choice of the Go language used for its development. Go consumes far fewer resources than Ruby or Java.

This allows managing thousands of repositories on a standard server. This raw efficiency reduces hosting costs for companies. It also helps extend the life of old hardware.

Constant evolution towards version 10.0 and beyond

The project progresses very fast thanks to a global community of contributors. The recent version 10.0 brought major visual and technical improvements. The user interface is smoother, and permission management is more precise.

The software also integrates the latest security standards on the market. It natively supports two-factor authentication and physical security keys. This is a crucial point for protecting your work against unauthorized access.

Why choose Forgejo for your projects in 2026?

Choosing a Git forge is a strategic decision that impacts the longevity of a project. Forgejo offers the best balance today between freedom, security, and power.

An ethical alternative to web giants

By using Forgejo, you take back total control over your digital assets. Your files are no longer stored with a web giant with opaque terms of service. It is a strong commitment toward a more decentralized and respectful IT world.

This autonomy protects you against sudden price changes in cloud services. It also allows you to comply with data protection regulations (GDPR). Your code stays on an infrastructure that you control from end to end.

Performance gain for your development workflow

A lightweight server is a server that responds faster to your requests. By using sober tools like Forgejo, you optimize your entire production chain. This is exactly the performance philosophy I share on this technical blog.

Every millisecond saved on your tools increases your productivity. It also reduces the frustration related to heavy and slow interfaces. The tool fades away to make room for creativity and pure logic.

Impact on SEO and brand image

My goal is to prove that good SEO starts with a quality infrastructure. Choosing Forgejo is part of this quest for global and sustainable quality. It shows your partners that you take care of your technical environment.

By using Forgejo, you join an ecosystem that values code craftsmanship. You invest in a tool that respects the user as much as the machine. It is the way to build a healthier and faster digital future.

Frequently Asked Questions