Adding Baseline Status to My Eleventy Site

As I've recently started writing about relatively new CSS and web platform features again, I wanted to show 'at a glance' browser support that's available and/or whether something is "safe" to use or not. A browser support table copied from somewhere else can go very stale very quickly. A screenshot would be even worse.

What I wanted was a 'living' component. Something that does what I needed and can easily update itself.

That's exactly what the <baseline-status> web component can do. It fetches current support data from the Web Features API and renders a small, self-contained component on the page.

Here's how it's integrated into this Eleventy (Build Awesome) website.

Why Baseline over CanIUse?

I've been a big fan of Can I Use since forever. It's brilliant for deeper investigation. Checking specific browser versions, finding out if something needs a flag or prefix, any know bugs or existing resrouces, or getting a wider overview of a feature.

But it still leaves the decision on using a new CSS feature entirely with you.

Baseline is opinionated by design.

• Limited Availability - when a feature isn't yet known to be supported across all core browsers
• Newly Available - once all core browsers have shipped support
• Widely Available - once that support has been stable for 30 months

With these three states, you can make an informed decision instantly. If your teams CSS authroing guidelines stipulate only using Widely Available features, you know immediately whether you're good to go.

The component fetches live data from the Web Features API, so the status will update as browsers move features through these states. Folks get a clear 'on the day' answer, not a point-in-time screenshot.

The integration

Installing the package

npm install baseline-status

The package ships a minified, self-contained ES module (baseline-status.min.js) that includes everything it needs, including Lit. It's around 50KB minified (including the Lit framework). That's not ridiculously huge, but it's not something I want loading on every page either.

Copying the script at build time

Rather than loading the component from a CDN, I copy it from node_modules into the build output during the Eleventy build. In .eleventy.js:

config.addPassthroughCopy({
  'node_modules/baseline-status/baseline-status.min.js':
    'scripts/baseline-status.min.js',
});

The script ends up at /scripts/baseline-status.min.js in the site output. No CDN dependency, no runtime fetch to jsDelivr or unpkg, it's served straight from my own servers. The version is also pinned in package.json, so the component won't quietly change underneath me between builds.

Updating is as simple as:

npm update baseline-status

The passthrough copy should pick up the new file on the next build automatically.

Easily "turn on and off-able"

I could have just dropped the script into the bottom of my page template and called it done. But then every page would carry that extra weight, even articles that never mention browser support. Instead, I made it opt-in at the article level using Nunjucks conditionals and a frontmatter flag.

The shortcode checks for the frontmatter flag before rendering anything. When writing an article, I add baselineStatus: true to the frontmatter, then type {% baselineStatus 'feature-id' %} wherever I want the widget to appear.

If I forget to set the flag, nothing renders, which I'll spot when reviewing the article.

The frontmatter flag

Any article that wants to use <baseline-status> sets a flag in its front matter:

---
title: 'My Article About a CSS Feature'
date: 2026-03-09
baselineStatus: true
---

No flag, no script. It's off by default for the rest of the site.

The conditional load in the base layout

In _includes/layouts/base.njk, just before </body>, the script tag is only rendered when that flag is present:

{% if baselineStatus %}
<script type="module" src="/scripts/baseline-status.min.js"></script>
{% endif %}

As the script is loaded as type="module", it defers automatically and shouldn't block rendering. Browsers that don't support ES modules don't load it at all which is fine, because in practice those are browsers that wouldn't render the component (or probably the web platform feature) either.

The shortcode

Writing raw HTML in a Markdown article is fine, but using a shortcode can keep things a little cleaner and consistent.

In .eleventy.js:

config.addShortcode('baselineStatus', function (featureId) {
  // Only render if the page has baselineStatus flag set
  if (this.ctx && this.ctx.baselineStatus) {
    return `<baseline-status featureId="${featureId}"></baseline-status>`;
  }
  return '';
});

Using it in an article

Finding a feature ID

Feature IDs come from the web-platform-dx/web-features repository. The quickest way to find one is to visit webstatus.dev, search for the feature you're interested in, and read the ID from the URL.

Feature IDs don't always match what you'd expect. For example, CSS Nesting is just called nesting in the data, and Anchor Positioning is anchor-positioning. The safest approach is to search webstatus.dev for what you want - you'll find the correct ID right there in the URL.

Here are some common examples:

Step-by-step

1. Add baselineStatus: true to the article's front matter. This loads the script on that page and only that page.

---
title: My Brilliant Article about Container Queries
baselineStatus: true
---

2. Drop the shortcode wherever you want the widget to appear:

{% baselineStatus 'container-queries' %}

3. That's it. Here's what that actually renders on this page:

The component fetches live data from the Web Features API, so the status reflects the current state of the feature not whatever was true when I wrote the article.

Worth it tho?

Since I have been regularly writing about brand new or relatively new CSS and web platform features. Yes, absolutely.

I like that the opt-in approach keeps the script off pages that don't need it, the shortcode keeps the authoring tidy, and serving the file myself means I'm not dependent on a third-party CDN staying online.

It's a small thing, but I think it can make the articles feel a little more alive, more informative.

Browser support data that updates itself beats a screenshot from 2024 every time.

• Eleventy
• Build Awesome
• Web Components
• Baseline
• Web Standards
• Progressive Enhancement