ESLint CSS rule gets a clearer name

The @eslint/css package reached version 0.6.0, bringing with it a rename of the require-baseline rule to use-baseline. While the change is cosmetic in terms of functionality, it improves how the rule reads in configuration files and lint output. The release also adds support for linting nested CSS blocks and includes several bug fixes. Developers using earlier versions of @eslint/css should review the updated package.

Querying the Web Platform Dashboard

A recently published article walks through querying the Web Platform Dashboard, both through its frontend and its HTTP API. For teams building Baseline-related tooling, the API provides a way to fetch feature data and identify which features have crossed a given Baseline threshold. The approach could power a script that periodically checks for features that have become Newly or Widely available. The guide covers the details needed to get started.

Baseline and polyfills

A new article offers a framework for thinking about polyfills alongside Baseline. Baseline itself does not factor polyfills into its Newly or Widely available classifications, nor does it dictate whether you should use them. That decision remains application-specific. The article walks through the trade-offs: polyfills are valuable tools, but they can carry performance costs and, in some cases, accessibility concerns. The goal is that as more features reach Baseline availability, the need for polyfills diminishes.

contenteditable="plaintext-only" reaches Baseline

The contenteditable attribute lets users edit an element's contents as if it were a text field—for example, placing it on a <p> element allows interaction similar to a <textarea>. A common frustration arises when users paste rich text with formatting they didn't intend. The value contenteditable="plaintext-only" prevents that, stripping pasted content of formatting. This attribute/value combination has now become Baseline Newly available, and the announcement post explains how it can improve editing experiences.

Intl.DurationFormat goes Newly available

Formatting durations as human-readable strings like "2 days, 6 hours, 3 minutes" typically requires a library, especially when supporting multiple languages. The Intl.DurationFormat class aims to change that. You pass an object with the time units you want formatted to its constructor, and it returns the string in the desired locale:

const duration = {
  years: 1,
  hours: 20,
  minutes: 15,
  seconds: 35
};

// English output: '1 year, 20 hours, 15 minutes, 35 seconds'
new Intl.DurationFormat('en', { style: 'long' }).format(duration);

// German output: '1 Jahr, 20 Stunden, 15 Minuten und 35 Sekunden'
new Intl.DurationFormat('de', { style: 'long' }).format(duration);

// Spanish output: '1 año, 20 horas, 15 minutos y 35 segundos'
new Intl.DurationFormat('es', { style: 'long' }).format(duration);

The result is that applications relying on third-party libraries for this kind of formatting can potentially drop that dependency, saving bandwidth for users. The announcement post provides further details on usage.

Baseline session at W3C Breakouts Day 2025

The W3C's 2025 Breakouts Day included a session on Baseline. For those unfamiliar with the project, it covered the core concepts of Newly and Widely available, as well as how those definitions are derived from data—moving from browser-compat-data up through the web-features data that determines a feature's Baseline threshold. The session linked in the digest covered the material concisely, and the slides from it are already published for those who missed it.