As I’ve had more opportunities to work with cookie consent managers, I’ve come to the surprising realization that most of them (all of them?) fail to track if websites are in compliance with various privacy laws.

One client we’ve been working with pays a lot of money for an enterprise-level cookie consent solution. Their cookie process is similar to what I’ve seen for other consent managers:

• The consent manager runs a scan across the client’s website to identify any cookies or other trackers.
• The consent manager may provide a suggested category for any trackers that it recognizes.
• The client has to verify that the suggested categorization is correct and categorize any cookies that the consent manager didn’t recognize.
• There may be some additional work to make sure these categorizations are replicated in tag managers.
• Once the categorization is complete, then the cookies should only be set when users provide the appropriate consent.
• Periodically, the consent manager will scan the site to look for any new cookies or trackers. If any are found, this process is repeated.

The realization I’ve had is that the subsequent scans aren’t checking to verify that the cookies are being set correctly or not. Their primary purpose is to look for new cookies. That’s valuable, but it doesn’t ensure compliance.

Our client needed to be certain that non-required cookies weren’t getting set before consent was granted. I created a script that checks what trackers are set before and after consent. But in order to get this information from their enterprise solution, they had to request a special scan.

Even after requesting the special scan, our client only knew what had been set before consent. Not whether cookies were getting set correctly based on the categories users have consented to.

I wonder how many organizations think they’re in clear when it comes to CCPA or GPDR because they’ve implemented a cookie consent solution, but don’t realize that their solutions are never checking to make sure they are truly in compliance.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Of all the talks I’ve given, none scared me more than my presentation at the 2024 performance.now() conference. The talk was ostensibly about third-party scripts and web performance, but it also touched on a topic embarrassing to me—my weight—and equated it to what I was observing on the web.

Two recent events reminded me of this talk, how much has changed for me since then because of GLP-1, and how the same can’t be said for the web.

Struggling to get healthier

I was in a strange place in Fall of 2024. We had spent three and a half years taking care of my father before he passed in October 2023. He had suffered a stroke right before COVID that left him bedridden with a tracheostomy. A respiratory pandemic is difficult enough to survive without a direct path to your lungs.

To keep him safe, we took him into our home and became his nurses, respiratory therapists, PTs—anything necessary to keep him alive. 

Taking care of him was all-consuming. As a result, our own health suffered. I gained a lot of weight and had a couple of health scares that sent me to the ER. I was pre-diabetic and while my bloodwork wasn’t dangerous yet, it was heading the wrong direction.

After my father passed, I was determined to lose weight and get into shape. I didn’t want to put the same burden on our kids that my father had on us.

So I set up a home gym in the space that had previously been his hospital room. I started rowing and lifting weights daily for the first time in my life. I purchased an underdesk treadmill so I could exercise while working.

I saw some improvements. I was stronger than I had ever been and had lost some weight, but I had plateaued. I wasn’t losing weight any more. I felt stuck.

Our clients were stuck too

Around this same time, I was conducting performance audits for some of our clients. I love helping organizations make their websites run faster so working on performance audits is usually one of my favorite tasks. But in these cases, the audits were frustrating.

Like the vast majority of websites we see in the wild, the biggest performance problems for our clients were due to third-party scripts. The good news was that I could identify which scripts caused the most issues. I could even show how much faster their site would be if they removed the scripts.

The bad news was that even if they wanted to, our clients couldn’t remove the scripts. In one case, the client was using Bolt for their cart and checkout. Bolt was a massive React app that weighed in at nearly 1MB. It slowed down the most critical parts of an ecommerce funnel. But they couldn’t remove it without breaking core functionality.

Ozempic and other GLP-1s

It didn’t seem to matter how much I worked out. I wasn’t losing weight. So I started researching Ozempic and other GLP-1s.

I was intrigued by the way Chris Coyier and Paul Ford described their own experiences. Paul Ford wrote:

Where before my brain had been screaming, screaming, at air-raid volume—there was sudden silence. It was confusing. Would it last?

I went alone that night to a Chinese restaurant, the old-school kind with tables, and ordered General Tso’s. I ate the broccoli, a few pieces of chicken, and thought: too gloopy. I left it unfinished, went home in confusion, a different kind of sleepwalker. I passed bodegas and shrugged. At an office I observed the stack of candies and treats with no particular interest.

Decades of struggle—poof. 

Before I started using GLP-1, it had already changed me. The success of these drugs made me reassess my relationship to weight loss. If the food noise in my head could be tamed with medication, then perhaps my weight wasn’t a personal failing. 

I wasn’t weak. I was just wired in a way that caused my brain to think I was hungry when I wasn’t. And I could be rewired.

What about a GLP-1 for the web?

As preparation for my talk heated up, I found myself researching third-party scripts during the day and GLP-1s at night. It’s no surprise I started to see parallels between them.

Most website owners know how important performance is for user experience and how it impacts conversions and revenue. They want a fast site. 

And yet websites continue to grow in size. Even ecommerce sites which have a strong financial motivation to fix performance issues get larger every year on average.

I knew I needed help to get unstuck. Maybe my clients did too?

I started looking for something akin to a GLP-1 for the web. I knew it wouldn’t solve every problem, but maybe a little boost would help. Was there some way we could rewire the web like I hoped GLP-1 would rewire my brain?

This became a focal point of my research. I looked into Partytown which tries to move third-party scripts off the main thread and onto a web worker where they will have less impact on the user. I explored Cloudflare’s Zaraz product which attempts something similar using Edge Workers. I revisited server-side Google Tag Manager for the umpteenth time hoping that this time it seemed more likely to work for our clients.

But every one of these solutions had significant drawbacks. They are all difficult to implement. I wasn’t certain how I could tell if third-party scripts were still working, especially when we don’t usually have access to the dashboards for these services.

That’s not to say that some people aren’t having success with them. Julian Jandl shared how they’ve been using Partytown successfully at performance.sync() 2025. I think it is easier for internal teams to experiment with solutions like this than it is for our clients to sign up for something unproven.

If I was working on the talk today, I’m sure someone in the audience would ask if AI could help. If AI will cure cancer, surely it can solve web site bloat.

Unfortunately, most AI-generated websites seem to have performance problems. Tim Kadlec points out that JavaScript bytes on the web have exploded since May 2025—the month when Claude Code, Github Copilot Coding Agent, and Cursor AI agents launched.

I suppose it doesn’t have to be that way. In theory, you can add enough context or constraints to get a performant experience out of AI, but that would require people to prioritize it. It doesn’t happen by default. So I don’t see AI solving the web’s performance problems (or cancer) any time soon.

Video of my presentation

While I didn’t find a GLP-1 for the web, I’m still proud of the talk. There are many practical suggestions on how to analyze and manage third-party scripts. 

I recommend watching the talk, but I’ll admit I have a hard time doing so. I was going to send it to a client last week and was shocked at how big I look in the video.

My Tirzepatide journey

I nearly started GLP-1 before the performance.now() conference, but I was worried about potential side effects before the trip. I didn’t want indigestion during the conference or after it when my family was meeting me for a vacation.

After we returned home, the holidays took precedence. In early 2025, I read about the FDA removing some GLP-1s from the shortage list which meant compounding pharmacies could no longer make it. Compounding pharmacies were providing affordable alternatives. I knew I couldn’t afford the full price, and my insurance wasn’t going to cover it.

So I gave up for a bit until a friend who I hadn’t seen in a few months visited. I was stunned by his transformation. He was on Tirzepatide (a different GLP-1) and looked like an entirely different person.

His experience inspired me to give it another try. I took my first shot of Tirzepatide on June 27, 2025. I still have more to go, but I’ve lost 50 pounds so far. I’m at the lowest weight since college. I can now see the evidence of my daily workouts. And most importantly, my blood work is trending in the right direction.

The 49MB Web Page

Unfortunately, the story for the web over the same period hasn’t been great. One of the triggers for revisiting my presentation was this excellent article by Shubham Bose examining a 49MB New York Times article.

Bose points out all of the privacy and user hostile code being used on the web these days. Most of this code comes from third-party scripts.

And maybe it’s a bit of silly numerology, but I couldn’t help but feel some kinship to this random NYT article. The page weighs 49MB. I’ve lost 50 pounds.

I wish I could share some of my Tirzepatide with these pages.

Open for discussion

I like helping people build faster websites, but I can only help so many clients at a time. It’s a drop in the bucket compared to the direction the web is headed. It feels as futile as dieting.

The main purpose for my talk was to spur discussion in the web performance community because I believe only collective action on third-party scripts can make a difference. I don’t know if we will be able to find some miracle GLP-1-like solution for third-parties. But maybe we can make it easier for people to learn which third-party scripts are better from a performance standpoint. That would be a good start.

In a similar vein, I’d like this article to be the starting point for discussion. If you want to brainstorm ways to handle third-parties and make the web faster, I’d love to hear about it—particularly if you’ve successfully used PartyTown, Zaraz, or server-side GTM. 

I’m also open to talking about weight loss and my experience with Tirzepatide. I’m keenly aware of how difficult it can be to talk about these things. I’ve been too embarrassed to do so for years. But Tirzepatide has made a huge difference for me so I’m happy to share what I’ve learned.

So I’m open for discussion. You can ask me anything. You can reach out publicly or privately. I’m happy to talk about either topic or anything else that may be on your mind. We’re all in this together.

P.S. We’re looking for projects. Please spread the word.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I’ll cut to the chase: Our calendar is light, and we need more projects. Especially projects with a UX design, UI design or hybrid creative/development focus.

Small projects? No prob, we’ve got individual high-velocity contributors to spare, ready to slot in at any project stage.

Large projects? Bring it on: Our unique approach scales well to big problems, like modernizing legacy applications or building up multi-brand design systems. (Once you’ve made Walmart’s cart and checkout responsive, you can do anything!)

(Already know us? Skip to ways you can help)

Why Cloud Four?

• Your audience deserves better than just another sluggish, inaccessible, generic web experience.
• Our fast-paced, collaborative process keeps your team engaged and your goals in focus.
• Interactive, browser-based deliverables remove guesswork from the review process while streamlining implementation.
• You’ll support a small, independent company that’s served customers for almost 20 years while sharing more than 25 talks, 80 code repositories and 500 (!!) articles for free with their community.

What clients say

Cloud Four really dug in to understand what our customers needed and how our business worked. We chose Cloud Four for their web expertise, but what they delivered would be world-class on any platform. I’m so proud of what we accomplished together.

Cloud Four’s process stands out for being so transparent, iterative and collaborative. They listened carefully to our goals, asked tough but important questions, and encouraged contributions from everyone. I’m amazed by how much our web experiences transformed with their guidance.

Cloud Four not only massively simplified our purchasing flow but also prototyped a foundation for our future plans. On top of that, they were also an absolute pleasure to work with. Professional, thoughtful, and most importantly fun.

The API Explorer demo has been a big help in explaining our APIs to developers. It increased engagement over 400% and improved the quality of our conversions.

How to help

If you have (or may have) a project, get in touch via our contact form, email or phone.

If you have a boss or hiring manager in charge of contracting design resources, recommend us to them, share this post, or reach out to make that connection directly.

Share this post (or any article you find more relevant) with friends, family, forums, work chats, or social connections who might benefit from (or amplify) our services.

It’s thanks to our amazing clients we’ve been able to ship so many exceptional experiences over the past 19 years, continually sharing what we learn along the way. I hope you’ll be part of that journey soon!

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Starting on January 1, the California Consumer Privacy Act (CCPA) requires that websites provide confirmation that they have honored a user’s Global Privacy Control (GPC) opt out. Unfortunately, many cookie consent banners are doing this in the most confusing way possible and making me wonder if they are doing it intentionally or not.

What is Global Privacy Control?

Global Privacy Control is a web standard that allows users to tell websites that they wish to opt out of having their information tracked or sold. In theory, if you have set Global Privacy Control, you shouldn’t see any cookie consent banners.

Global Privacy Control works behind the scenes by setting two values. One is an HTTP Header, Sec-GPC: 1, that is sent by the browser with every request to a server. The second value makes sure GPC is available to JavaScript by setting navigator.globalPrivacyControl property to true.

Some browsers—Firefox, DuckDuckGo, and Brave among them—implement GPC support by default. For other browsers, you can install extensions like the Electronic Freedom Foundation’s Privacy Badger. If you want to test to see if your browser is sending GPC correctly, you can test it on the Global Privacy Control informational site.

What happened to Do Not Track?

Some of you may be wondering how Global Privacy Controls differ from an earlier solution called Do Not Track. While Do Not Track also used HTTP Headers to opt out of tracking, it wasn’t an official standard, and never gained traction with website owners. In 2019, the working group behind Do Not Track disbanded, and browsers started removing support for it.

The biggest difference between Do Not Track and GPC is that GPC has been codified in law. Eleven states require businesses to honor GPC opt outs. The EU’s General Data Protection Regulation (GDPR) was written before GPC was created, but it likely that GPC still applies under GDPR. According to CookieScript, “While not explicitly mentioned in the GDPR regulation, the principles of ‘Privacy by Design’ and ‘Ease of Withdrawal’ make GPC signal a requirement to honor user opt-out choices.”

UX fails or malicious compliance?

All of this brings me back to California’s new GPC confirmation rule and the odd way that cookie consent solutions have implemented it. Digital compliance vendor Clym describes the new rule thusly:

Starting in 2026, it is no longer sufficient to simply process an opt-out silently. If you receive an opt-out signal (like the Global Privacy Control), you must explicitly display a confirmation to the user.

• Requirement: You may need to display a message like “Opt-Out Request Honored” or show a toggle in the user’s privacy settings indicating they have opted out.
• This allows consumers to know that their automated browser signals are working.

Because I have GPC turned on in my browser, I began to see these confirmations. Unfortunately, it is often not clear what I should do with the information. For example, this is what I saw on a recent website using OneTrust for cookie management:

It’s nice to see confirmation that my opt out preference has been honored, but what am I supposed to do now?

There is a big button that says, “Accept All Cookies” that appears to be my main option. If I click on it, will the site still honor my opt out? Or will clicking on the button override GPC?

I decided to give it try, and as expected, clicking the only button available to me overrode my opt out.

I find this preferences panel hilarious. It says it has honored my opt out, but every bit of tracking has been turned on. I tested a few other cookie consent options and found similar interfaces where you’re informed that your opt-out has been honored, but you’re still forced to make a choice about what cookies you will allow.

I know that for any of these banners, I can click on the cookies settings link to adjust my preferences, but isn’t the whole point of the GPC opt out to streamline the process so users don’t have to manually opt out?

By contrast, the best implementation I’ve seen was a small notification that my opt-out had been honored. That’s it. No further action required. I believe this is what California was hoping for when it added this new requirement.

It seems the new rule has surprised cookie consent managers. In my testing, many of them do not yet honor the notification requirement even if they honor GPC behind the scenes. So perhaps these broken and confusing user experiences are because notifications are being quickly grafted onto existing applications.

However, when I see that the service is aware that I’ve opted out, and the only button it provides is one to accept all cookies, I find myself wondering if it is intentional. I know Hanlon’s Razor says we shouldn’t immediately ascribe situations like this to malice so I’m hopeful that over time cookie consent banners will do a better job of honoring GPC opt outs.

If you’re interested in learning more about privacy and cookies, check out my recent two-part series on cookie consent management in 2026.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

In part one of this series, I shared some high-level thoughts on why organizations are increasingly focused on cookie consent and some things I’ve learned about how to pick a good solution and roll it out in your organization.

In this article, I want to focus on the more technical aspects of identifying what source is setting a cookie so that you can ensure that your cookie consent solution is handling it properly.

Turn off content blockers

In order to test what cookies could be set, you have to turn off any features that may block cookies. For me, that meant turning down browser privacy setting and turning off extensions like Privacy Badger and uBlock Origin. My home network runs on Eero Plus which also features ad blocking. Everything had to be turned off.

Don’t use default Incognito mode

Chrome in Incognito mode is my default testing environment. Incognito mode provides a clean slate when I’m troubleshooting performance issues.

However, I wasn’t seeing some of the cookies I expected in my tests. Turns out that when Chrome is in Incognito mode, it blocks third-party cookies by default. You can bypass this behavior by clicking on the eye icon in the toolbar.

I used Incognito almost exclusively for my testing which means I’ve have been doing this wrong for years.

Lazy-loading and dynamic cookies

As I ran my tests, I started to see cookies that only showed up occasionally. I finally figured out that these cookies were set by scripts that were lower on the page and were only loaded when someone scrolled down.

In addition, ad networks can include different scripts which in turn set different cookies based on a user’s geography, etc. These dynamic insertions are hard to predict. Thankfully, these changing cookies seem primarily limited to ad networks so if you categorize the parent script correctly, then any additional cookies added later will also be categorized correctly.

Finding the cookie culprit

Figuring out what asset set a cookie can be challenging. When you look at the list of cookies in Dev Tools, you can get some hints about what might be setting the cookie from the cookie’s name and domain. If you’re lucky, there is only one asset coming from the domain, and you’ve found your culprit. Most of the time, you won’t be that lucky.

Unfortunately, the cookie panel doesn’t contain the equivalent of the initiator column in Chrome’s network panel. When I’m conducting performance audits, I rely on the initiator section to help me track down the chain of requests that led to an asset getting downloaded. I’d love to have something similar for cookies.

Instead, you either need to make some intelligent guesses or create some tooling. Absent tooling, my investigation steps look something like this.

First, I look at the domain name and tracker name to try to determine what service I think might be setting a cookie. For example, a cookie with the domain set to .linkedin.com with the name __cf_bm likely was set by a LinkedIn script and the cf name suggests that the cookie is related to Cloudflare.

I’ll then look up the cookie using a service like Cookiesearch.org. In this example, the search will tell me that __cf_bm is set by Cloudflare and “is used to support Cloudflare Bot Management.”

Once I have a domain for the cookie, I turn to the network panel to see if I can find the culprit. I’ll filter the network panel to only show assets coming from suspect domain.

Cookies can be set by HTTP Headers or JavaScript. HTTP Headers are easier to look for, so I always start there. In the network panel, I look at the response headers for each asset that comes from the suspect domain. The response headers are the headers sent by back the server when the browser requested the asset. The server can ask the browser to create cookies using Set-Cookie headers. There can be more than one Set-Cookie header for a given asset.

If the cookie isn’t set using HTTP Headers, it can be more difficult to isolate which bit of JavaScript is setting the cookie. I often use request blocking in the network panel as a blunt tool to isolate which script sets the cookies.

First, I’ll block the entire request domain, clear all cookies, and then check to see if the cookie is still getting set. If it is, I’m looking at the wrong source. If the cookie is no longer being set, I now know that one of the assets I blocked is responsible.

Often I’m able to make an educated guess about which asset is likely to set the cookie based on the description of the cookie and the asset names. If I have a hunch, I’ll try blocking that asset alone and see if the cookie is still set.

If I don’t have a guess or I guessed wrong, I’ll narrow it down by blocking half the requests from the suspect domain to see if that blocks the cookie. If it does, I know where to continue looking. If not, the cookie must be set in the other half. Repeat this a few more times and you can quickly winnow down even a long list of assets.

Cookies blocked by the browser

Cookies that were blocked by the browser may still show up in cookie list to help with troubleshooting. Their row will be distinguished in a different color and if you hover over the associated request, you will see information about why the cookie was rejected.

Testing using a headless browser

Manual testing can only get you so far. I had to audit hundreds of cookies for a client, so I looked for ways to automate the process. I couldn’t find anything that did exactly what I needed so with Claude Code’s help, I wrote a command line tool that used Puppeteer to see which cookies were set before and after consent was granted.

Puppeteer helped me find cookies that my manual testing had missed. Every time Puppeteer launches, it has a clean slate. Therefore, any cookies that my script finds must have been set by the test page. This helped capture third-party cookies that were only showing up on the first page load.

I also added logic to intercept cookies being set to create my own version of the the initiator chain. Eventually, I expanded the tests to look for local storage, session storage, and IndexDB. Puppeteer also scrolls the page to make sure it captures any lazy loading cookies.

If you need to do any significant amount of testing, I recommend using Puppeteer, or its alternative Playwright, so you have a clean testing environment and can automate the process.

Cookie consent can be fun?

When our clients first asked for help with their cookie consent management, I wasn’t looking forward to it. I like designing and building solutions for users not dealing with legal requirements. Plus, cookie consent banners are annoying.

But by the end of these projects, I found myself enjoying the work. The cookie consent tools do a good job of recognizing most cookies, but there are always a few mysteries in the box. I love a good mystery. And sometimes you find truly surprising things like a site manifest file setting multiple cookies.

Plus, there is satisfaction in knowing that people will have their privacy preferences honored. Not to mention the fact that we’re able to significantly reduce the legal risk for our customers.

Cookie consent management can seem daunting at first, but it is important for your organization and its users. And maybe I’m just a sicko, but I found it to be a lot of fun.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I’ve noticed a trend. Over the last few months, multiple customers have asked us to help with cookie consent compliance. Either it is a mighty coincidence or something has caused companies to start taking privacy compliance more seriously.

I think the renewed interest is because ambitious lawyers have started sending threatening letters to companies that aren’t in compliance with the California Consumer Privacy Act (CCPA) and the EU’s General Data Protection Regulation (GDPR) provisions. I know of at least one company with over $100k in related legal fees.

Last month, California won a $2.75M settlement with Disney over CCPA violations. CCPA fines can add up quickly. They start at $2,663 per incident. The fines increases to $7,988 per incident for willful violations or violations involving people under 16.

It’s not limited to CCPA and GPDR. Enterprising lawyers have dusted off the 1967 California Invasion of Privacy Act (CIPA) and applied it to web technology. The law firm Varnum explains:

Plaintiffs’ attorneys are using CIPA to challenge common website technologies, including cookies, analytics tools, session replay software, and chat features. Many companies are caught off guard when they receive a demand letter alleging unlawful website tracking, followed by the threat of litigation.

Thousands of CIPA website tracking claims have been asserted, and filings continue to rise.

So it’s not surprising that companies are trying to get their cookie house in order. I may be a glutton for punishment, but I’ve enjoyed working on these cookie consent projects, and thought I’d share some of the things I’ve learned. In part one, I’ll share some high-level thoughts. In part 2, I’ll dig into some technical details.

Organizational resistance

When an organization implements cookie consent management for the first time, the impact on their analytics and marketing initiatives can be dramatic. If people can opt out of being tracked, a significant percentage will choose to do so. If your marketing relies on tracking, it will suffer.

I know of an organization that backtracked on cookie compliance because of the impact on marketing. Doing so creates legal exposure, but it’s understandable how a company that sees their sales drop might panic.

So my first piece of advice is to talk to marketing ahead of time to understand what tools are being used. Determine which are most likely to be impacted by cookie banners, and see what you can do to mitigate them. Sign up now for a GPDR-compliant, cookie-less analytics service like Plausible or Umami so you have a baseline of analytics information. You can use these services track trends before and after you implement a consent banner.

Unfortunately, in a lot situations, there isn’t much you can do to alleviate the data loss. If someone doesn’t want to be tracked and your marketing tools depend on tracking data, then the tools are going to be less effective. But helping your marketing colleagues anticipate where cookie consent will impact them will not only help mitigate data loss, but it will also prepare the team for their new reality.

Hire a good lawyer

I’m not a lawyer. If you’re reading this, you’re probably not either. You need knowledgable legal counsel to help you decide how cookies should be categorized. Only a lawyer can help an organization make sure they are in compliance and understand the risks of various choices.

Plus, if you’re the person leading the privacy charge, then the people are going to resist you. Instead, if a lawyer tells your organization what they need to do, then you don’t have to argue with co-workers about whether their favorite service’s cookies should be defined as essential or not. You get to be the hero helping the organization while the lawyer plays the bad cop.

Find a good cookie consent solution

I find cookie consent banners annoying. As a user, I didn’t care what solution a website used so long as I could dismiss it quickly.

But after working with a few different cookie consent solutions for our clients, I now have a list of features I consider critical:

• GPDR compliant: You may only care about CCPA right now, but CCPA is evolving towards GPDR. In fact, even though one of our clients is based in California and doesn’t sell in Europe, their lawyers advised them to use a GPDR-style cookie consent banner where you can select specific categories of cookies instead of a CCPA-compliant one where you either accept or reject cookies.
• Regular scanning of your site: What cookies are being used on your site may change over time without you knowing about it either because a new third-party service is added to the site or an existing one adds a new cookie. You need regular scans to tell you if a cookie has been discovered so you can categorize it.
• Identifies local storage, session storage, and IndexDB in addition to cookies: Even though everyone talks about cookies, the privacy laws don’t care what technical mechanism is used to track people. You need a tool that looks at all of the ways people can be tracked.
• Intuitive web-based reports: We’ve worked with one cookie consent manager where account managers send periodic spreadsheets that appear to be manually generated. By contrast, my favorite provider has an easy-to-use web report that shows what cookies their scans have discovered and how to take action on them.
• A solution that is lightweight and fast: Cookie consent banners have to load early on the page and block other scripts. Therefore, any performance issues they have are magnified.

On that last point, I asked the web performance Slack community if anyone had recommendations for a performant cookie solution. The kind folks at RUMVision shared data from across their customer base:

Because I have a performance hammer and everything is a nail, I started my explorations with CookieYes (That’s an affiliate link. If you sign up, we get a tiny kickback.) It is almost twice as fast as the nearest competitor in the RumVision data.

I’ve been quite happy with CookieYes. It is reasonably priced. The administrative dashboard is easy to work with. The scans surface cookies we need to address. Most importantly, their support has been fast and knowledgeable.

Monitor your compliance

Complying with privacy laws requires some form of ongoing vigilance. Unless you are not using any third-party services, the cookies being used on your site may change without your knowledge. Therefore, you need regular scans and people who are responsible for addressing any new issues that arise.

In larger organizations, you have to keep an eye out for other teams creating new websites. These websites need to be integrated with your main cookie consent solution. If someone opts out on one of your websites, their decision should carry over to others. This may require all company websites to use subdomains so cookie consent decisions can be more easily shared between them.

The privacy laws themselves change. As of January this year, CCPA not only requires websites to honor a user’s Global Privacy Control (GPC) setting, but also explicitly notify them that it has been honored.

The good news is that while you do need to monitor cookies and privacy laws to make sure you remain in compliance, the ongoing work is minimal once you tackle the initial audit, categorization, and implementation of a cookie consent banner.

In part 2 of this series, I’ll share some technical tips and tricks I learned for identifying the source of cookies.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Eleventy Build Awesome is great for rapid prototyping! Tyler shows off a few of his favorite shortcodes, filters and other techniques to quickly populate interactive mockups and wireframes with “dummy” or FPO (for placement only) content.

You can watch the presentation here:

Example Helpers

These are the main code samples from my slides, consolidated below for easy reference.

Each helper is written in ESM syntax (but should work in CommonJS with a few small changes), and each assumes it lives in its own file (imported by the config).

Text, Numbers, etc.

With the Chance dependency:

import Chance from "chance";
let chance;

export default function (method, ...args) {
  // Support JSON string for first argument
  if (typeof args[0] === "string") {
    args[0] = JSON.parse(args[0]);
  }

  // Instantiate Chance the first time
  if (!chance) {
    chance = new Chance();
  }

  // If the method exists, return its output
  if (typeof chance[method] === "function") {
    return chance[method](...args);
  }

  // Otherwise, log an error but proceed
  console.error(`[chance] No method named ${methodName}`);
  return "";
}

import chanceHelper from "./helpers/chance.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("chance", chanceHelper);
  eleventyConfig.addFilter("chance", chanceHelper);
}

Images

With our Simple SVG Placeholder dependency:

import simpleSvgPlaceholder from "@cloudfour/simple-svg-placeholder";

/**
 * Modify these to suit the project!
 * @see https://github.com/cloudfour/simple-svg-placeholder#option-reference
 */
const defaults = {
  bgColor: "rgb(0 0 0 / 0.8)",
  textColor: "white",
};

export default function (width, height, options = {}) {
  // Support JSON string for argument
  if (typeof options === "string") {
    options = JSON.parse(options);
  }

  return simpleSvgPlaceholder({...defaults, width, height, ...options});
}

import fpoImageHelper from "./helpers/fpo-image.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("fpoImage", fpoImageHelper);
}

Icons

This example uses the Iconify API via Eleventy Fetch.

I’ve made a small enhancement since the presentation, adding the entities package to escape attribute values on the inline SVG based on a recommendation from Zach Leatherman:

import EleventyFetch from "@11ty/eleventy-fetch";
import { escapeAttribute } from "entities/escape";

const apiUrl = "https://api.iconify.design";

const fetchOptions = {
  duration: "1y",
  type: "json",
};

const defaultAttr = {
  xmlns: "http://www.w3.org/2000/svg",
  class: "icon",
};

// Get a specific set:name icon string
async function getSpecificIcon(icon) {
  // If already specific, do nothing
  if (icon.includes(":")) {
    return icon;
  }

  const searchUrl = `${apiUrl}/search?query=${icon}&limit=1`;
  const searchData = await EleventyFetch(searchUrl, fetchOptions);
  const results = searchData.icons || [];

  if (results.length === 0) {
    throw new Error(`No icon found for ${icon}`);
  }

  return results[0];
}

// { class: "icon", width: 120 }
// => 'class="icon" width="120"'
function objectToAttributeString(obj) {
  return Object.entries(obj)
    .map(([key, value]) => {
      value = escapeAttribute(`${value}`);
      return `${key}="${value}"`;
    })
    .join(" ");
}

export default async function (icon, attr = {}) {
  // Support JSON strings for attributes
  if (typeof attr === "string") {
    attr = JSON.parse(attr);
  }

  try {
    icon = await getSpecificIcon(icon);
    const [setName, iconName] = icon.split(":");
    const iconDataUrl = `${apiUrl}/${setName}.json?icons=${iconName}`;
    const iconData = await EleventyFetch(iconDataUrl, fetchOptions);

    if (typeof iconData !== "object") {
      throw new Error(`Request for ${icon} returned ${iconData}`);
    }

    const { width, height } = iconData;
    const { body } = iconData.icons[iconName];
    const attrString = objectToAttributeString({
      ...defaultAttr,
      "data-icon": icon,
      viewBox: `0 0 ${width} ${height}`,
      width,
      height,
      ...attr
    });

    return `<svg ${attrString}>${body}</svg>`;
  } catch(err) {
    console.error(`[iconify] ${err.message}`);
    return "";
  }
}

import iconifyHelper from "./helpers/iconify.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("iconify", iconifyHelper);
}

Resources

More references from the talk (other than dependencies in the previous section):

• For more about Cloud Four’s process, check out Responsive Design Process That Works and one of our case studies
• Why I Like Designing in the Browser and five tips for beginners
• Build Awesome provides helpful docs for Shortcodes and Filters
• If you already have an icon library, check out uncenter’s awesome plugin
• Flow and Redacted are fonts intended for stubbing out text sections in wireframes
• Performance chart from the Page Weight section of the 2025 Web Almanac
• Accessibility chart from The WebAIM Million’s WCAG Conformance section
• XKCD’s Website Task Flowchart cartoon

Some Questions Answered

Two questions stood out to me during a live Q&A following my presentation:

Acknowledgements

Big thanks to Sia Karamalegos for having me, Zach Leatherman for creating Build Awesome (new Kickstarter launching soon) and encouraging my unique possum interpretations, and especially everyone who attended the meetup!

If you want to see Cloud Four’s process in action, get in touch! We’re always looking for our next web app design challenge.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Does this sound familiar to you?

Chat, is it good when your AI-obsessed colleague drops a +16,105 -193 pull request with 102 commits all titled “wip: implement next task” and asks that it be immediately approved for next release?
— eva

The issue isn’t AI specifically, but the speed with which contributors can generate massive amount of code, exposing weaknesses in a team’s workflow.

Cloud Four is currently a small agency, with only a handful of devs. We often work together with our client’s internal developers, or with contractors. Because of this, we’ve developed a set of best practices that I’m quite proud of. If your team members dread the notification that they’ve been added as a reviewer on a pull request, I think the following guidelines can help.

All Code Gets Reviewed

Our first rule is a strict one. If a code change is going to production, it gets reviewed. We work for clients, so “move fast and break things” isn’t a realistic way to do business. If I get sloppy and push unreviewed code that causes an incident, I’ve put the client in a bad spot, triggered an urgent crisis for my team to deal with, and perhaps jeopardized our client relationship.

In every code repository we work in, we recommend enabling protection rules for the production branch. GitHub makes it easy to require a pull request before merging, and to require pull requests be approved by someone other than the author. The only exception we make is to grant certain senior developers permission to bypass these rules for safe changes like minor dependency updates.

I know teams that require two developers to review every pull request. Normally, one dev can be the person who submitted the PR, but in the case of AI-authored pull requests, two human devs still need to review it. That’s a clever way to ensure automated code gets a bit more attention than normal.

The natural consequence of requiring a review for all code is the dev team has to actually review all that code. This can be time-consuming, and if you don’t already have a team culture that values code review, this may be a tough pill to swallow. The rest of our guidelines are aimed at reducing the burden placed on code reviewers.

Prefer Many Small PRs Over One Giant PR

Firstly, we absolutely reserve the right to reject massive pull requests like the one described in the introduction. A common problem we run into is pull requests that make multiple unrelated changes, such as including a refactoring pass alongside new features or bug fixes. When I see this happen, I’ll reach out to the dev in a non-confrontational way and explain that by combining all their changes like this, it makes the reviewer’s task much more difficult.

Here are some things we’ll commonly ask a dev to pull out into a separate pull request:

• Lint rule changes that result in many files being changed at once. This happens, but there’s no reason to combine it with anything else. It’s easier to review dozens of similar file changes when there’s no unrelated changes lurking in the code. Plus, it simplifies the acceptance criteria for the lint changes if you don’t expect any impact on functionality.
• Moving code from one location to another. If there’s a huge block of red in one file, and a huge block of green in another file, and a comment saying “no changes, just relocated this code for [reasons],” that’s trivial to review. On the other hand, if the code moved and there are also unrelated changes, the code diff doesn’t show those changes. It’s far easier to review if you break it up into one PR to move the code, and another to modify it.
• Unrelated bug fixes or features. I know it’s tempting to fix a bug you noticed while you were in that file, or to update some code to modern standards, but that just adds noise for the reviewer. It’s totally fine to file a second pull request at the same time, making that bug fix.

Once your team gets the hang of it, you’ll see fewer monster pull requests, and your team will become more comfortable pushing back on unnecessarily large pull requests in general.

Explain Why This Change is Needed

A pull request should not just explain what changes are being made, it should explain why they’re being made. That context is incredibly valuable to anyone who isn’t intimately familiar with the code you’re changing. Whether that’s your fellow dev who is taking time away from their tasks in a different part of the code base, someone who works on another team entirely, or yourself in the future.

I want to emphasize that last one. I can’t tell you how many times I’ve been trying to figure out why some feature works the way it does, and when I dive into git blame I see my name staring back at me. When I track the change back to a commit I authored with a well-written description, I’m relieved. Conversely, when I find a simple “change the client wanted” comment, I want to pull my hair out.

The same is true of any developer who ends up reviewing your code. Give them the context for why you’re making this change. What problem were you solving? Why was this the best solution? Armed with this information, your reviewer will have an easier time.

Provide Thorough Testing Instructions

The phrase “acceptance criteria” isn’t just for project managers! After a good description of why the change is being made, we like to provide detailed testing instructions. We started this when we were working with some new contractors, who didn’t necessarily have a full picture of how to test the application. It’s also proven valuable when non-developers step in to help out while we’re facing an impending deadline.

Don’t assume the person who is testing your pull request knows how to work with your app. We often literally provide step-by-step checklists like this:

• Check out this branch in your local environment
• Set new_feature_flag in config.js to true
• Start the app and navigate to /new-feature
• Apply a filter using the hamburger menu in the top-right
• You should see the list of cards has been filtered
• Remove the filter
• Now you should see all the cards again
• Etc…

This might feel like overkill, especially if another dev on your team will review it. But remember that other dev may be working on another part of your application, and hasn’t been paying careful attention to the part you’re working on. A checklist like this, that doesn’t assume the reviewer already knows how to test your feature, reduces the burden on any reviewer, and even opens the door to less-technically minded team members helping with testing.

Another benefit of this approach is that writing out testing instructions gives you an opportunity to follow those instructions. I can’t tell you how often, in the course of writing a step-by-step checklist for a pull request, I’ve uncovered an issue. If I can address that before the reviewer starts, I’m saving everyone time.

Bonus: writing testing instructions for a human tends to give you a clear idea for automated tests. After all, if you know how it should work, why not let your CI workflow check it for you?

Code Review is a Culture Issue

What all these suggestions have in common is being aware of the cognitive burden on another developer who may be stepping away from their assigned tasks to think about yours. Context switching is a productivity killer, and anything you can do to make it easier for someone else to review your code helps avoid code review becoming something your team members dread.

Requiring all code be reviewed before going to production shows you value the quality of what you ship. Asking your team to prefer small pull requests over large ones helps reduce the scope of review. Providing context for why a change was made helps the reviewer understand those decisions. And providing clear testing instructions means reviewers don’t get derailed figuring out how to test the changes.

All of this adds up to a culture that expects quality code, values the time it takes to review it, and respects the team’s efforts to do so.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

For over ten years now, I’ve been sharing front-end links with the community via a newsletter and social media account called Friday Front-End. Every week, I bookmark 20–30 articles, and pick the best ones to include. In that time, I’ve learned some things I want to pass along to you: Recommendations to make your article more likely to be shared in newsletters and social media accounts like the one I run.

There’s loads of great content out there, and it’s funny how often someone puts the work into crafting an excellent post, but misses out on all the things that make it easy to widely share.

To understand what people like me are looking for, consider the format of a typical Friday Front-End post:

Your Exciting Post About #CSS: “Here’s a short quote from your article to interest people to read it.” https://example.com/

Pretty simple, right? A featured image, then the title, followed by a short quote, the URL, and a hashtag for the primary focus of the article (for Friday Front-End, this will almost always be #CSS, #JavaScript, or #a11y).

Now, here are the things you can do to make your post easier to share:

Add Open Graph tags

If you take just one thing from this post, make it this. Adding OG (Open Graph) tags to your post gets you the most bang for your buck. Here’s what OG tags look like:

<meta property="og:url" content="https://example.com/" />
<meta property="og:title" content="An exciting post about CSS" />
<meta property="og:description" content="Here's a short description of this exciting post about CSS" />
<meta property="og:image" content="https://example.com/thumbnail.jpg" />

There are more tags you could use, but you get the idea. In a nutshell, a long time ago, Facebook came up with a standard for describing your web page so their crawlers could understand it. They used that information to make little preview cards of a link when someone shared your page. The concept spread quickly, and now pretty much every social network out there will use your OG tags to make a preview card.

Even better, tools that people like me use to manage their social media accounts and newsletters, like Buffer or Curated, also understand them. That means I can simply pass them your post’s URL, and they automatically extract useful information like the title and thumbnail, which makes my job much easier.

Note: add Open Graph tags about your post, not your site

A surprisingly common problem I run into is a great post that does have OG tags, but they describe the person’s site as a whole, rather than the individual post I’m trying to share. This might feel better than nothing, but it actually backfires because when I share the link to your post, the preview card might show information about your site, rather than the actual post. (e.g., “Sandra’s Awesome CSS Blog” vs “An Exciting Post About CSS.”). If the goal of the preview card is to convince readers to click through, then you definitely want the card to show information about your post, not your site as a whole.

Learn more about Open Graph tags:

• Open Graph specification
• IndieWeb Open Graph documentation
• Yoast SEO Open Graph documentation
• How We Added Open Graph Tags to CloudFour.com

Add a sharing image

A well-chosen sharing image can be the perfect teaser for your post, something that catches the audience’s attention and makes them want to click through to learn more. If you have a great sharing image, it absolutely increases the likelihood that I will share your post, and that readers will click through.

However, I understand not everyone is lucky enough to work with a talented cartoonist like my coworker Tyler, who has created some of the best sharing images here on Cloud Four. If that’s the case for you, I recommend a visit to Unsplash, which has an excellent collection of free images that you can use for your sharing image, often just for the cost of giving the creator an image credit at the bottom of your post.

Another increasingly common approach is to automatically generate sharing images for your posts by creating an image of the post’s title. This is better than no sharing image, but unless they’ve got a bit of design flair, it can feel bland or even repetitive, since the post title will usually be displayed near the post thumbnail in the preview card.

One thing I see people do that is actually worse than providing no sharing image is to use a single sharing image for every page on your site, typically the site logo or a big photo of yourself. When readers see these seemingly random images in the preview card for your post, it can feel unintentional.

And to be clear, I’m not saying that a hand-crafted illustration is always better than a stock photo or a generated title card. For example, A stock photo of a footpath worn in the grass of a public space for a post about “paving the cowpaths” for user accessibility is great. A stock photo of a boat anchor on a post about CSS anchor positioning is less interesting.

Here’s some excellent advice on choosing stock photos for your post.

Use a descriptive title

It’s always frustrating to share a well-written post with a title that communicates nothing about the topic of the post. Let me give you an example with two titles for a hypothetical post about the flexibility of CSS custom properties to allow users to override your theme’s default colors:

• You Can Go Your Own Way
• How to Empower Developers with Custom Properties

I understand if you feel the second title is bland or even boring. But you know what it does well? It tells me what the post is about. The first example might be clever in context, but if I can’t understand it until after I’ve read the post, then it’s failing to convince me to read in the first place.

Add a blurb

Something I love, and will often copy directly into Friday Front-End posts, is when the author provides a TL;DR (Too Long; Didn’t Read) summary at the top of the post. Call it whatever you want: a blurb, a description, an excerpt, or a summary. The point is that it’s a short, punchy description that summarizes your post and convinces me to read.

There’s a sweet spot for length. Too short, and you won’t communicate enough. Too long, and I’ll just have to trim it to make it fit in a social media post. Here are two extreme examples:

• How to override theme colors with custom properties.
• CSS custom properties are a powerful tool that can empower developers and users alike. In this article, I’m going to show you how to make your theme fully customizable through the use of custom properties, discuss their limitations, explore browser support, and encourage you to adopt this fantastic tool into your arsenal.

The first is certainly an efficient description of the post topic. But it’s actually too short. There’s nothing there to convince me to read it. The second, on the other hand, is too verbose. I get distracted before I even finish reading it.

As a rule of thumb, I like to aim for 140 characters — a completely arbitrary length that happens to be half the length of a post on a certain social media site I don’t use anymore. That’s short enough to be easy to share in a social media post (along with the title and URL), but long enough to be able to tease the contents of the post.

Use canonical URLs properly

Okay, this one’s getting into the weeds a bit, but it’s something to check on your site. Some CMS tools will automatically add a canonical URL tag. This is really useful if you have a post with multiple valid URLs, or if you’re syndicating content from one site to another, and want to make sure all the SEO traffic goes to the original site.

<link rel="canonical" href="https://example.com">

However, a surprisingly common problem I see is that a post will have a canonical URL tag that points to the homepage of the site rather than the post itself. This is an insidious issue because you can still go to the URL directly, but tools that understand the canonical URL will link to the wrong place.

I’m particularly aware of this because some of the tools I use to save links, like Instapaper, will save the canonical URL if one is available. Which means when I go to review my links later, what’s actually been saved is a seemingly random link to someone’s homepage. If I’m lucky, I can skim their recent posts and remember the title of the post I tried to save, but sometimes I can’t figure it out, and their post doesn’t get shared.

So, please take a moment to view the source on one of your posts and, if you see a canonical URL tag, make sure it’s pointing to the correct URL.

Add a date

This last tip is perhaps more specific to the front-end industry, but since web technologies change so quickly, it’s important to know that you’re not unintentionally sharing some out-of-date information. If you show the date your post was published somewhere, it’s easy for me to check that I’m not accidentally linking to something written a long time ago, which may no longer be valid.

Conclusion

Putting out a weekly newsletter means I’m in the unusual position of getting a high-level overview of the most popular web development content being shared every week. It means I can spot some trends, see what people are interested in (or struggling with). It also means I see a wide variety of sites and how well they interact with common social media sharing tools. I hope this list of tips helps you avoid putting a lot of work into writing a post, only to see it struggle for views because it’s not easy to share.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Chris posed this challenge on Mastodon, where I suggested a solution he ended up building upon for his 2025 Yearnotes.

Here’s a refined version of the demo I shared:

A few details I’m proud of:

• It’s actually transparent (backgrounds show through)
• The border remains middle-aligned with the “legend,” even when it breaks to multiple lines
• You can easily tweak its appearance via CSS custom properties

So, how’s it work?

HTML

Our markup consists of three elements:

• An outer container (our fake <fieldset>)
• A heading (our fake <legend>)
• A wrapper for the inner content

<div class="legendary">
  <h3>This is not a fieldset</h3>
  <div>
    <!-- content -->
  </div>
</div>

A few quick notes:

• This pattern won’t rely on specific elements. You should use whatever containers, heading levels, etc. make the most semantic sense for your use case.
• The inner content wrapper may not be necessary if you’re willing to accept some compromises. (More on this later.)
• I stole the excellent class name from Mr. Kirk-Nielsen’s implementation. Thanks, Chris!

CSS

Instead of struggling to overlay the “legend” while clipping the border beneath, we’re going to slice the containing shape into three chunks: One for either side of our legend, and one for everything below.

We already have elements for our legend and lower content section. To avoid cluttering the markup, we’ll use pseudo elements to represent the “northwest” and “northeast” slices.

First, let’s translate our sketch to a CSS Grid. I like to use grid-template-areas to make a little text-based representation of the layout:

.legendary {
  display: grid;
  grid-template-areas:
    "nw      legend  ne"
    "content content content";
}

To keep our legend middle-aligned to the top of the adjacent borders, we’ll have it span an additional row (one earlier than the corner areas):

.legendary {
  display: grid;
  grid-template-areas:
    ".       legend  ."
    "nw      legend  ne"
    "content content content";
}

We should also add some column and row definitions so the browser knows to divide the legend space evenly, and to stretch the northeast corner (right of the legend):

.legendary {
  display: grid;
  grid-template-areas:
    ".       legend  ."
    "nw      legend  ne"
    "content content content";
  grid-template-columns:
    1em
    auto
    minmax(1em, 1fr);
  grid-template-rows: 1fr 1fr auto;
}

Now we can use a content view to render the aforementioned pseudo elements:

.legendary {
  /* ...  */

  &::before,
  &::after {
    content: "";
  }
}

And assign the grid areas we’ve defined:

.legendary {
  /* ...  */

  &::before {
    grid-area: nw;
  }

  &::after {
    grid-area: ne;
  }
  
  > :first-child {
    grid-area: legend;
  }

  > :last-child {
    grid-area: content;
  }
}

Now for the visual appearance!

Since this technique hinges on coordinating the same styles across separate elements, we’ll define a few custom properties up top:

.legendary {
  --border-color: currentColor;
  --border-radius: 0.25em;
  --border-style: solid;
  --border-width: 1px;
  --legend-gap: 0.375em;
  --padding: 1em;

  /* ... */
}

Which we’ll pepper throughout our final styles to draw borders and manage spacing:

.legendary {
  --border-color: currentColor;
  --border-radius: 0.25em;
  --border-style: solid;
  --border-width: 1px;
  --legend-gap: 0.375em;
  --padding: 1em;

  column-gap: var(--legend-gap);
  display: grid;
  grid-template-areas:
    ".       legend  ."
    "nw      legend  ne"
    "content content content";
  grid-template-columns:
    calc(var(--border-width) + var(--padding) - var(--legend-gap))
    auto
    minmax(calc(var(--border-width) + var(--padding) - var(--legend-gap)), 1fr);
  grid-template-rows: 1fr 1fr auto;

  &::before,
  &::after,
  > :last-child {
    border: var(--border-width) var(--border-style) var(--border-color);
  }

  &::before,
  &::after {
    border-bottom-width: 0;
    content: "";
  }

  &::before {
    border-right-width: 0;
    border-top-left-radius: var(--border-radius);
    grid-area: nw;
  }

  &::after {
    border-left-width: 0;
    border-top-right-radius: var(--border-radius);
    grid-area: ne;
  }
	
  > :first-child {
    font: inherit;
    grid-area: legend;
    margin: 0;
  }
	
  > :last-child {
    border-bottom-left-radius: var(--border-radius);
    border-bottom-right-radius: var(--border-radius);
    border-top-width: 0;
    grid-area: content;
    padding-top: var(--padding);
  }
}

(Note the use of calc in the first and last columns. This keeps the main content aligned with that of the heading while taking into account gaps between the legend and border.)

Variations

Depending on the needs of your project, there may be ways to adjust or simplify this technique.

If your background is a flat color and known ahead of time, you can give the legend the same background and use a faux container instead of separate corners:

A similar trick could work for varied backgrounds if you’re willing to set a blend mode (and accept any resulting color shifts):

And if minimal markup is the goal, you can pull this off without the inner <div> element, it’ll just impose a few more constraints:

We may one day get a CSS feature for mimicking <legend>’s display (as pointed out by Amelia Bellamy-Royds in the original thread). For now, it’s another fun excuse to solve an interesting (if eerily familiar) challenge with the niceties of modern CSS!

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work