DEV Community: Beto Muniz

Who Owns the Surface?

Beto Muniz — Mon, 15 Jun 2026 22:15:29 +0000

Most people I've talked to think generative UI means letting a model render React components on the fly. That's the worst possible version of the idea, and if that's what you're shipping, you've already lost.

The actual story is a taxonomy. Three patterns of how an agent and a UI fit together, distributed across a power law, each suited to a different kind of surface. And underneath the taxonomy, a quieter fight worth caring about: who controls the layer between the model and the pixels.

Let me walk through it.

The Inversion

There's a real difference between "we shipped an AI assistant" and "we built a fullstack agentic application," and it has nothing to do with marketing.

In the assistant-on-the-side version, the agent doesn't know what's on screen, doesn't know what the user just clicked, and can't do anything except return text into a sidebar. The application underneath couldn't care less. The agent is a sticker.

In the fullstack version, the agent shares state with the app, drives the UI, and moves next to the user. You can't draw a clean line between where the app ends and the agent begins. The agent isn't a feature parked next to the product; it's part of how the product runs.

That's the inversion. The agent stops being a feature in the product. The product starts bending around the agent. The UI exists to give the agent surfaces to operate on.

That flips the design question entirely. It's no longer "how do users prompt for components" It's: how does the agent know what UI to put in front of the user, when to put it there, and how to do it without breaking trust?

That question splits into three answers, depending on how predictable the surface is.

Three Patterns, One Power Law

The cleanest way I've seen this framed is as a frequency distribution. Most of the surfaces in any real product are predictable. You know what they need to look like and you've already designed them. Some surfaces are shape-roughly-known but variable. A few are genuinely open-ended.

I'll call them the Catalog, the Vocabulary, and the Sandbox, each named after what you actually hand the agent. A catalog of pre-built components. A vocabulary of primitives the agent composes with. A sandbox where third-party surfaces run.

The choice between them isn't aesthetic. It's a decision about predictability, trust, and how much control you hand to the model versus how much you keep.

Let me unpack each.

Pattern 1: The Catalog

This is where most teams should start, and where most agentic apps in production actually live today.

The shape of it: you declare a fixed catalog of components (bar chart, pie chart, contextual card, button, whatever your design system already contains), each one annotated with what it's called, what it does, and what arguments it needs. A middleware layer translates that catalog into tool definitions the agent can see. The agent runs, decides one of the registered components is the right answer, and calls the corresponding tool. The frontend tool call pauses backend execution, hands control to the client, and the SDK maps the call to the component, fills the props, and mounts it.

The open protocol forming around this pattern is AG-UI, an MIT-licensed event protocol that originated inside CopilotKit with LangGraph and CrewAI, and now has implementations across Mastra, Microsoft's Agent Framework, AG2, Agno, and LlamaIndex. Framework-agnostic by design.

The thing to notice here: the model never generates UI code. It picks from a menu you've already designed, tested, and signed off on. The "generative" part is the choice and the data binding. Not the markup, not the layout, not the styling.

This is what you want for surfaces that are predictable, which is most of your product. The dashboards, the cards, the inline answers, the action buttons. The bar chart isn't going to surprise you with a 3D rotating waveform that mangles your design system. It's your bar chart. The agent just decided to use it. Grafana Assistant is a clean production example of this: a sidebar chat that responds using Grafana's existing component vocabulary (panels, plots, queries, tables) instead of only free-form text or markup. The components are predefined. The agent's job is to pick the right one for the conversation and wire it to the right data.

If you build one of these patterns, build this one. It covers the majority of the surface area of any real product, and it's the only one where the runtime risk is genuinely bounded.

Pattern 2: The Vocabulary

Sometimes you can't pre-register every possible component. The agent needs to compose a layout you didn't anticipate. The data shape is different every time. The surface answers a request that doesn't fit your catalog.

That's where the declarative approach earns its keep. The open spec here is A2UI (Agent-to-UI), at a2ui.org, open-sourced by Google in collaboration with CopilotKit. The core idea is simple.

The agent doesn't send code. It doesn't pick from a fixed menu either. It emits a declarative description of intent (structured operations), and a renderer on the client materializes those operations into native UI components from your design system.

If you've worked with React internally, this should feel familiar. It's reconciler-shaped, but with the agent as the source of truth instead of your component tree. The agent says "show a card with this title, this body, these three actions". The renderer maps that to your design system. The model never touches a <div>, never writes a Tailwind class, never decides spacing.

Notion AI is a clean in-the-wild example of this: when you ask it to draft a structured page, it composes from Notion's existing block vocabulary (headings, tables, callouts, toggles, databases) rather than generating markup. Notion's renderer handles the actual UI.

There are two flavors of A2UI that matter more than they look at first:

Fixed schema: you build the layout in advance. The agent populates it with data at runtime. Predictable structure, dynamic content.
Dynamic schema: a second model pass produces the layout itself, adapted to whatever the conversation is actually about. The same spec-level constraints still hold, but the structure is decided in-flight.

Fixed schema is the safer default and probably what you want most of the time you reach for this pattern. Dynamic schema is what you reach for when the shape genuinely can't be enumerated in advance. Even then, the spec keeps the model inside a sandbox you defined.

Either way, the layer between the model and the pixels is yours. That's the part that matters.

Pattern 3: The Sandbox

The far end of the curve. The thing you reach for when the answer isn't "render a component" or "compose a layout". It's "open this entire other app inside my app".

The open standard here is MCP Apps, part of the broader Model Context Protocol, consolidating earlier work from MCP-UI and OpenAI into a single specification. Three components, with the boundaries between them doing the heavy lifting.

Worth flagging the spec status: MCP Apps already exists and is in production use, but the upcoming MCP 2026-07-28 spec revision (currently a release candidate, locked May 21, ships final July 28) formalizes it as a first-class extension with a dedicated lifecycle. The pattern is stable; the surrounding surface is consolidating.

The Server publishes both the tools and the UI surfaces themselves. Each tool carries a URI pointing at the embeddable app. The Host is your front-end app. It mounts the embedded surface inside a sandboxed iframe and brokers messages between the agent and the embedded app. The View is the surface itself, running in the sandboxed iframe. It can't touch your DOM. It can't read your cookies. It can't do anything except talk back through postMessage.

Tool calls between Server and Host. postMessage and JSON-RPC between Host and View. Three boundaries, three trust zones, no shared state across them.

This is the right pattern when you're building something platform-shaped: a host-of-hosts that orchestrates third-party experiences. The agent picks which embedded surface to open. The developer pre-wired the integration. The user sees a third-party app running right inside the agent's surface, with the agent able to drive it.

Claude and ChatGPT both ship variations of this pattern in production today: both can host third-party UI surfaces (connected tools, MCP server apps) embedded inside the agent's product, with sandboxed iframes brokering between host and View.

It's the most powerful pattern and the most dangerous one. You're embedding code you don't own. The iframe sandbox isn't decoration. It's load-bearing. The whole point of the architecture is that the View can't reach in, can't read out, can't do anything except talk through the channel you opened. Take that boundary seriously or don't ship this pattern at all.

So Where Does Each Pattern Belong?

Pulling the implicit strategy out into the open:

Catalog for ~80% of your surface area. The components you'd build anyway. The agent just picks intelligently from your registered set.
Vocabulary (A2UI) for the tail. Surfaces where you know roughly what shape you'll need but can't enumerate every variation in advance.
Sandbox (MCP Apps) for the platform edge. When you're building a host for other people's products, not a product itself.

Most teams will live entirely in Catalog and never need the other two. That's correct, actually. The mistake is jumping straight to "let the model render anything it wants" because it looks more impressive in a demo. That's the path to UI that looks great in screenshots and falls apart in production within a quarter.

The further right you move on the curve, the more flexibility you get, and the more trust you outsource to the spec, the iframe, the third-party app. Move only as far right as the surface actually demands.

Same Shape, New Decision-Maker

This three-tier arc isn't unique to generative UI. The same pattern played out in browser plugins, in embeds and iframes, in browser extensions, across thirty years of platform evolution: a curated middle, a declarative layer, and an open sandbox. The architectural shape isn't novel.

What is novel: the decision-maker choosing between those tiers is now a language model instead of a user with a mouse. The topology stayed the same. The thing in front of the topology, picking which tier to use and when, became something with its own opinions.

That's the shift worth paying attention to. Not the patterns themselves, but who's choosing between them.

The Real Concern Nobody Is Saying Out Loud

The interesting tension here isn't technical. It's about who owns the line.

When the agent decides what UI to show, even within constraints, the agent is doing product work that used to belong to designers and PMs. The constraints (your registered catalog, the A2UI primitives, the MCP sandbox) are the only thing standing between your product's design integrity and a runtime that picks whatever feels right to a language model on a given Tuesday.

Whoever ships the spec, the renderer, and the constraint layer ends up controlling a meaningful slice of what every agentic product is allowed to look like. That's what's actually being decided at ag-ui.com, at a2ui.org, inside the MCP Apps spec, inside every framework racing to ship a generative UI primitive. It's not really a UI standards conversation. It's a control-plane conversation, wearing a UI library's clothes.

(My guess: the spec layer consolidates around two or three contenders in the next eighteen months, the same way the JS framework wars did. A2UI has the head start, with Google's backing and the open-source ecosystem already shipping around it. AG-UI is locking in the transport layer underneath. MCP Apps is becoming the standard at the platform edge. But the surface is wide open, and whoever wins the constraint layer ends up with the kind of leverage Stripe has over payments. That's the actual prize.)

Where to Start

There's a temptation, when a stack like this lands, to split the takeaway across roles. Engineers get one paragraph, PMs another, designers a third. I'm skipping that. The roles are converging anyway: the person making the surface decision, writing the code, and owning the product spec is increasingly one person, or a small group wearing all three hats. (More on that in a future post ☺️)

One synthesis instead:

Start with the Catalog. Most surfaces don't need anything else. Build the registered set, expose it as tools, let the agent pick from a menu you designed. The "let the model render anything" demo looks great in screenshots and falls apart in production within a quarter.

When you genuinely need flexibility, reach for the Vocabulary before open-ended rendering. The constraint layer is what keeps the model from picking what feels right on a given Tuesday.

Keep the Sandbox for the moment your product becomes a host for other people's products. When you ship that, take the iframe seriously. It isn't decoration.

And every time you move further right on the gradient, the question is the same: what are you outsourcing trust to, and do you actually trust it?

The component-library era of "AI features" is ending. The agent-runtime era is starting. Build accordingly.

The three-tier framing borrows its shape from the Controlled/Declarative/Open spectrum laid out in Build Interactive Agents with Generative UI; the Catalog/Vocabulary/Sandbox labels are my simplified own restatement.

The Quiet AI War Inside Your Browser

Beto Muniz — Mon, 25 May 2026 22:09:47 +0000

Google shipped the Prompt API in Chrome 148 on May 5, 2026. Mozilla objected. Apple's WebKit team objected. The W3C TAG objected. Microsoft Edge disabled the feature entirely despite running on the same Chromium engine. It was, by any measure, one of the most contested browser feature launches in recent memory.

And it doesn't matter. Google has already won this one.

What Actually Happened

Chrome 148 quietly gave every website on earth the ability to run AI inference locally (text generation, summarization, classification, image captioning) by talking to Gemini Nano, a 4GB model that Chrome now ships to users' devices without asking. The API is dead simple:

const session = await LanguageModel.create({
  initialPrompts: [{ role: "system", content }],
});
const result = await session.prompt("Your prompt here");

That's it. No API key. No latency. No server cost. No data leaving the device.

The opposition's core argument is a legitimate one: unlike fetch() or addEventListener(), an AI model isn't a deterministic spec. Two browsers implementing the "same API" with different underlying models could produce wildly different outputs, breaking the foundational promise of web standards: write once, run identically everywhere.

It's a real concern. It's also, in practice, irrelevant.

The Web Has Never Guaranteed Identical Outputs

Font rendering differs across browsers. Canvas pixels vary by GPU driver. Audio processing behaves differently on macOS versus Windows. Math.random() is, by definition, non-deterministic. None of these killed the web. Developers adapted, and they'll adapt here too.

The "we can't standardize non-deterministic output" argument proves too much. If it were applied consistently, half the modern web platform wouldn't exist.

Cloud Is the Real Baseline: Not Firefox's Future Model

Here's the thing critics seem to be missing: developers building serious AI features today aren't choosing between Chrome's Prompt API and Firefox's theoretical equivalent. They're calling cloud APIs: OpenAI, Anthropic, Gemini Cloud. Those are where the quality is, where the context windows are, where the capable models live.

Gemini Nano is a small model. It's good at lightweight, well-scoped tasks: summarizing a paragraph, classifying sentiment, extracting a date from a string. It's not replacing GPT-4o or Claude Sonnet for anything that actually matters.

So the Prompt API isn't competing with cloud AI. It's filling a specific niche:

Zero latency tasks that need to feel instant
Offline-capable features in PWAs
Privacy-sensitive processing where data must stay on device
Cost-sensitive at-scale operations (spell check, auto-tagging, content filtering)

Developers will reach for it as a progressive enhancement layer: use the Prompt API when available, fall back to a cloud call when not. The non-determinism objection collapses entirely in this framing: nobody is relying on Chrome and Firefox producing the same tokens. They're relying on "good enough local inference" vs "cloud inference." That gap is fine.

We Have Seen This Movie Before

PWAs. Web Components. Service Workers. WebRTC. Each time, the pattern is the same:

Google ships something useful but contested
Mozilla and Apple raise principled standards objections (sometimes valid, sometimes a proxy for business interests)
Developers adopt it anyway, because Chrome is 65% of global browser traffic
The holdouts implement their own version 2–5 years later
It retroactively becomes a "web standard"

PWAs are the sharpest example. Apple resisted for years: not primarily because of standards purity, but because native apps and the App Store are a multi-billion dollar business. They eventually shipped, incompletely at first, then more fully as the pressure became undeniable. Web Components took a similarly winding road: Google and Mozilla aligned early, Apple dragged its feet, and today Custom Elements and Shadow DOM are universally supported.

The Prompt API will follow the same arc. The only open question is how long the lag is and what compromises get made along the way. (My guess: Firefox and Safari eventually ship something with a compatible API surface but their own models underneath. Mozilla with something open-source, Apple with something Core ML-optimized. The outputs will differ. Nobody will care.)

The Real Concern Nobody Is Saying Out Loud

Apple's strategic worry isn't about spec compliance. It's about this: Google just normalized the browser as an AI delivery vehicle and installed its model on over 4 billion devices. That's not a web standards problem. That's an ecosystem control problem.

Whoever controls the model layer of the browser controls a significant surface area of how users interact with the web: what gets summarized, how content gets classified, what gets surfaced and what doesn't. Apple understands this better than anyone; it's exactly the kind of leverage they've built with the App Store for 15 years.

That's a legitimate concern worth having a serious conversation about. But dressing it up as a standards integrity argument dilutes it and, frankly, makes the objectors look like they're arguing in bad faith. That weakens their position when the real fight (model governance, content policies, on-device data access) eventually arrives.

What This Means for You

If you're building web products today:

Developers: Start experimenting with the Prompt API now for lightweight, latency-sensitive tasks. Design with graceful degradation: the API isn't available in Firefox or Safari yet, so treat it as enhancement, not baseline. WebGPU-based bring-your-own-model approaches (via transformers.js, ONNX Runtime Web) remain the cross-browser story for anything more demanding. If you want a unified abstraction over both, check out web-ai-sdk.dev.

Product and business: The interesting unlock here isn't replacing your cloud AI pipeline. It's enabling AI features that previously couldn't exist on the web: instant, offline, private, zero marginal cost. Think client-side content moderation, on-device personalization, local draft assistance. The economics and privacy story are genuinely new.

The browser is becoming an AI runtime. Google didn't ask for permission. That ship has sailed.

The Prompt API is available in Chrome 148+. WebGPU-based inference works cross-browser today via libraries like Transformers.js. WebNN remains experimental across all browsers.

How to improve the Critical Path CSS on web using the “Above-The-Fold" strategy?

Beto Muniz — Mon, 31 May 2021 15:28:04 +0000

In this brief content, I am sharing about the Above-The-Fold strategy to load CSS and why it matters to improve the page loading of our web pages.

📁 Above-The-Fold strategy on the web is a practice that extracts critical CSS declaration to render the layout displayed during the initial page load.

⏬ Non-critical CSS is added to another context (usually a dedicated .css file) to use async loading.

⌛️ Above-The-Fold enhances the loading experience while browsing since the browser will have the necessary CSS to scaffold the layout.

⏱ Also, this technique is an essential strategy to improve First Content Paint metrics in our web pages.

👉 Have you already heard about this web optimization opportunity strategy?

How to avoid Meltdown, Spectre and CSRF Attacks on Web with CORP, CORB, and CORS?

Beto Muniz — Mon, 24 May 2021 21:33:26 +0000

A brief and useful content about the mechanics on Cross-Origin Read Blocking, Cross-Origin Resource Policy and Cross-Origin Resource Sharing against Meltdown, Spectre and CSRF Attacks.

CORB

By design, Cross-Origin Read Blocking validates browser requests before they even reach the server using their MIME type as a validation rule.

To enable it, send the HTTP header X-Content-Type-Options: nosniff from the server.

CORP

Cross-Origin Resource Policy is a complementary CORB mechanism for validation applied to requests flagged with no-cors to invalidate them if they came from different domains or origin.

Send the header Cross-Origin-Resource-Policy from the server with values same-origin or same-site to invalidate no-cors requests from different domains or origin.

CORS

Cross-Origin Resource Sharing is a logical context mechanism that ensures minimal security in the way that users consume web content using browsers instructing how the browser will validate the origin of the requests.

To define rules about how the origin of the request will be identified, send the HTTP header Access-Control-Allow-Origin using values like <exact_request_origin> and even a more generic approaches using *.

Conclusion

Hope that now you understand a bit better why to use these Cross-Origin Resource features

Try don't disable or ignore them in your web applications. Spectre, CSRF, and Meltdown attacks are really dangerous.

How to Protect Cookies Against Common XSS Attacks on the Web?

Beto Muniz — Mon, 17 May 2021 21:58:30 +0000

We can ignore Cookies danger by just not recommending its usage, but the fact is that at least 55% of all the websites use Cookies RIGHT NOW even with lots of existing cookieless strategies.

So how to protect Cookies against Common XSS Attacks?

Well, if your app really needs to use Cookies, configure each one through Set-Cookie HTTP Header with at least the following flags:

🍪 Secure: To allow the Cookie only through HTTPS

🍪 HttpOnly: To remove the Cookie from the document.cookie

🍪 SameSite: To limit the Cookie context usage

Set-Cookie: Secure;HttpOnly;SameSite=Strict;...

Hope that with these tips, your app now has a few more chances against XSS Attackers that use Cookies breaches. Anyway, keep in mind that complex attacks can easily bypass these tips. So try to migrate ASAP to cookieless strategies.

XSS Attacks Types on Web

Beto Muniz — Mon, 10 May 2021 21:03:19 +0000

Know how each Cross-Site Scripting Attack behaves is crucial to start to think about how vulnerabilities in our web apps allow malicious codes to be executed using the browser to take sensible data from users.

That's what this article is about.

🔓 Reflected XSS

📌 This attack XSS use URL parameters or data submitted via POST in forms to inject malicious code on that server request that persists some data for later execution in the browser. Third-party Browser extensions could even be an access point to inject such a malicious code.

🔓 Stored XSS

📌 This attack XSS happens when malicious code is persisted by the attacker directly in the server-side of the web app and is executed by the user (victim) when she accesses the infected application.

🔓 DOM XSS

📌 This attack XSS happens when the application manipulates the DOM incorrectly, opening breaches to malicious scripts sent by URL parameters to inject malicious code.

🔓 The question is... How to defend against attacks XSS?

📌 There's no formula - A system security is always dependent on that system context, keep this in mind, but there are practices against well-known XSS attacks to stay updated about XSS attacks.

👉 Start reading about Content Security Policy, Mozilla Observatory, OWASP recommendations, and signing up my newsletter. As a web security lover, I always talk about it.

Proxy Pattern in JavaScript

Beto Muniz — Mon, 03 May 2021 21:03:24 +0000

Just a catch up about how the Proxy object works on JavaScript to allow us to implement Proxy patterns.

📌 JavaScript's Proxy object allows us to intercept and modifies any JavaScript object.

📌 JavaScript's Proxy object is an elegant and safe way for creating or extending libraries, caching, error handling, and complex data manipulation on JavaScript.

const obj = {a: 1, b: 2};

const arrProxy = new Proxy(obj, {
  get: function (item, property) {
    if (item.hasOwnProperty(property)) return item[property];

    return "default value";
  },
});

arrProxy.z; // "default value"
arrProxy.a; // 1

💡 What are the use cases that you most liked to use such a JavaScript feature?

📚 Still, for a detailed API spec of Proxy's object in JavaScript, take a look in the MDN docs.

Earn money using the Web Monetization API

Beto Muniz — Mon, 26 Apr 2021 16:03:05 +0000

Content inspired after I receive my first payment using Web Monetization API

🧑‍🔬 The How

Sign up to wallet.uphold.com/signup and verify yourself
Find the Interledger Payment Pointer in the Transact panel

And pick a currency target. It could be USD, BTC, etc

The Web Monetization API needs a Payment Pointer to address micropayments for you.

🏗 The Where

You could now use your already created Uphold's Payment Pointer on your website using this declaration:

<meta name="monetization" content="$ilp.your.payment/pointer" />

Also, dozens of services offer support:

Even YouTube, when connected in a creator account on Coil.

💰 The Web Monetization API

The Web Monetization API is a W3C Standard that uses a neutral payment protocol called Interledger (ILP) for transferring money for anyone by anyone.

The proposal help web creators avoid systems that slow down the web and creates annoying UX

📚 More about Web Monetization Standards

Map and Set in JavaScript for Humans

Beto Muniz — Mon, 19 Apr 2021 21:37:35 +0000

Would you like to hear more about Set and Map objects in JavaScript?

Let's catch up with them on this thread 🧵

Set in JavaScript 👇

📌 It's not key/value like the Object type. Keys are just values exposed

📌 Don't accept duplicated values

📌 It's iterable with forEarch method and for...of

📌 Conceptually is similar to []

💡 Set is useful to remove duplicates on [].

Map in JavaScript 👇

📌 Allow/preserve any key type. Even objects

📌 Don't expose insecure data properties

📌 Iterate with forEarch method and for...of

📌 Stay the insertion order doesn't matter the type

💡 Prefer Map instead of {} for client-side data manipulation.

Thoughts on Map, Set, {}, and [] in JavaScript 👇

📌 Each has a specific usage in JS

📌 Use {} for data traffic from the server.

📌 Set helps apply omit, diff, etc. on []

📌 Map return size. {} don't return size

🗣 There's not a silver bullet. Use them carefully.

😉 Hope that you now understand better such useful objects on JavaScript, they are highly valuable, and master them will make you a better JavaScript Developer.

Using "noopener" and ”noreferrer” against Phishing Attacks

Beto Muniz — Mon, 12 Apr 2021 19:24:45 +0000

Want to help users to avoid some Phishing Attacks with HTML?

👉 Use rel="noopener noreferrer" while adding external links to your website to improve user navigation security.

<a rel="noopener noreferrer" href="https://...">
 External Link
</a>

🐿 noopener: tells the browser to remove sensitive data from window.opener object when the user arrives at the destination website.

🤓 noreferrer: protect sensitive data of the origin website removing it from the Referrer header while the user navigates between origin website and destination website.

😋 Super easy security strategy to implement. Adopt this recommendation without moderation.

CSS Custom Properties with @property

Beto Muniz — Mon, 05 Apr 2021 14:19:38 +0000

Have you heard about the CSS @property statement?

📣 @property is a CSS Houdini at-rule that allows us to configure CSS custom properties by data type using the syntax field, default values using the initial-value field, and set if it allows inheritance.

@property --colorPrimary {
  syntax: "<color>";
  initial-value: magenta;
  inherits: false;
}

body {
  /* Fallback for browsers without @property support. */
  --colorPrimary: magenta;
}

.text {
  color: var(--colorPrimary);
}

🪄 The nicest aspect about @property is the capability to enhance CSS dynamics through high-level declarations with simplicity and certain performance enhancements.

🔬 Some use cases for @property statement are data type validation on CSS and animations.

@property --status {
  inherits: false;
  initial-value: 0%;
  syntax: '<percentage>';
}

.progress-bar {
  width: var(--status);

  height: 5px;
  background: gold;
  animation: progress 2s forwards;
}

@keyframes progress {
  to {
    --status: 100%;
  }
}

😋 Really cool, right?

CSS Property: content-visibility

Beto Muniz — Mon, 29 Mar 2021 19:19:01 +0000

👉 The CSS property content-visibility allows the web developer inform to the browser rendering engine which parts of the page are out of the user view.

😍 With this info, the browser can optimize the render flow time to focus on where really matters for the user.

content-visibility: visible;
content-visibility: hidden;
content-visibility: auto;

🪔 content-visibility using visible or hidden values show or hide respectively the content on a rendering engine level.

⚡️ content-visibility with value auto tells the browser rendering engine to render the elements based on user needs.