As part of the mass layoffs hitting Xbox, Doom developer id Software has laid off around 50 percent of its staff, according to Game Developer. One source claimed to the publication that the cuts equate to more than 90 redundancies. Another source said that id's QA department was significantly impacted. The report was published the same day that id is releasing a major expansion for its latest Doom game.
A former id employee affected by the cuts, Michael Maynard, corroborated the figure in a LinkedIn post, saying that the layoffs affected "roughly" 50 percent of the company. "We created arguably THE BEST first person engine technology in the …
Q1 2026 was a banner quarter for open source collaboration, as shown by the GitHub Innovation Graph’s economy collaborators metric, part of the latest data release. Outbound collaboration, defined as the sum of git pushes and pull requests sent from developers in one economy to public repositories in another economy, grew by 16% quarter-over-quarter from Q4 2025 to Q1 2026.
In third place was Q1 2023, with a 9% growth rate. This was the first quarter after a research lab blogged about a new website they made, and they enticed users to sign up and file bug reports by offering a chance to win up to $500 in API credits. Evidently, sweepstakes are unreasonably effective motivators.
Metrics by economy
While it’s clear that collaboration is growing globally, plotting these and other metrics separately by economy highlights the different trajectories of the world’s developer communities:
We’re grateful to the developers who advocated for these changes and the communities that continue to help spread the word, such as GitSyria. Thanks to their efforts, we’re happy to share that we’ve been able to provide the GitHub Student Developer Pack to over 8,000 verified Syrian students in just the last six months.
Helping maintainers manage collaboration
While greater collaboration leads to many benefits, we recognize that the rapid increase in contribution volume has strained several communities. Ashley Wolf, our Director of Open Source Programs, wrote about the Eternal September of Open Source in February 2026, describing how maintainers are managing new contribution dynamics and what we’re doing to try to help. Features we’ve shipped include:
Pull request limits: You can set a maximum number of open pull requests that users without write access may have open in your repository at one time, giving you a more proactive way to manage contribution volume.
Repo-levelpull requestandissuecontrols: Gives maintainers the option to limit pull request and issue creation to collaborators or disable pull requests and issues entirely.
Banners to reduce comment noise: Experience fewer unnecessary notifications with a banner that encourages people to react or subscribe instead of leaving noise like “+1” or “same here.”
Pull request performance improvements: Pull request diffs have been optimized for greater responsiveness and large pull requests in the new files changed experience respond up to 67% faster.
Faster issue navigation: Easier bug triage thanks to significantly improved speeds when browsing and navigating issues as a maintainer.
Temporary interaction limits: You can temporarily enforce a period of limited activity for certain users on a public repository.
Do you have feedback on the directions we’re exploring? Share it in the community discussion.
Share what is working for your projects, where the gaps are, and what would meaningfully improve your experience maintaining open source.
In the 1980s, Japan led the world in semiconductors, consumer electronics, and computer hardware, the industries everyone assumed would decide the next phase of economic power. Japan won them and still did not overtake the United States in the information revolution that followed. Jeff Ding, a political scientist at George Washington University, opens his book Technology and the Rise of Great Powers with the history of the first and second industrial revolutions and the third, the information revolution. The explanation he gives for who wins and who loses applies to companies as well as it does to nations, and very much to the current trajectory of AI.
Ding contrasts two theories of how technological revolutions reshape economic power. The conventional one he calls the leading sector model, or LS theory. It goes like this: New technologies create fast-growing new industries like steel and railroads and automobiles and semiconductors, and the country that dominates invention in those sectors captures the monopoly profits and the upstream and downstream economic linkages that come with them. As the story goes, if you win the leading sector, you win the era. Britain won in the first industrial revolution through its mastery of steam power, and then was surpassed by the US in the second through its leadership in electrification, the internal combustion engine, and mass manufacturing. The US kept its lead over Japan in the information systems revolution not by competing in the “leading sector” of electronic hardware but by diffusing “up the stack” via software that took the power of computing into every sector of the economy. (OK, that last bit is my explanation of what happened rather than Ding’s, but it’s consistent with his theory.)
Leading Sector theory is pretty clearly the working hypothesis of today’s AI industry and the national strategy that is forming around that industry. The company and the country with the biggest and best models wins. Everyone else is an also-ran.
Ding offers another explanation, which he calls diffusion theory. He points out that general-purpose technologies, foundational ones like the steam engine, electricity, and the computer, don’t just create massive profits and productivity gains in a single industry but instead spread across the whole economy. National economic leadership comes not from inventing the new sector but from diffusing the general-purpose technology more quickly and more broadly than your rivals. This happens over decades. The win goes to whoever most successfully embeds the technology into a wide range of ordinary productive work. This is how the US kept its lead over Japan rather than being surpassed by it.
This is obviously aligned with the thinking of Arvind Narayanan and Sayash Kapoor in “AI as Normal Technology,” which Ding cites in his book.
A big part of what enables diffusion is what Ding calls skill infrastructure, the education and training systems that widen the pool of people who can actually work with the technology. When the priority is widespread adoption rather than invention, he argues, the institutions that matter are the ones that build engineering skill at scale, standardize good practice, and tie research to industry. He writes:
GPT diffusion theory highlights the importance of GPT [General Purpose Technology] skill infrastructure. Education and training systems that widen the pool of engineering skills and knowledge linked to a GPT. When widespread adoption of GPTs is the priority, it is ordinary engineers, not heroic inventors, who matter.
Music to my ears, as it should be to yours: “It is ordinary engineers, not heroic inventors, who matter.”
That is not how the current AI narrative goes. Everyone is fixated on the labs, the frontier models, and the most famous researchers. And that fixation shapes enterprise strategy. Inside many companies AI strategy is a procurement decision: Which model and which vendor and which flagship tool should we choose? Or it’s a moonshot to stand up a lab and build an impressive demo and hire your own famous developer. Both approaches treat AI as a sector to be won. Ding’s argument is that the breakthrough sector itself is not where the long-term value for national power lives. And I believe that the same applies to corporate success. The value is in how widely and how well the technology gets embedded into the work of the people you already employ. The company that puts AI to work in finance and support and legal and sales and operations, across every unglamorous process, as well as in product and engineering, outperforms its competitors and drives its industry forward.
Diffusion is organizational, not technical
The reason diffusion takes a long time is that it is an organizational problem and not a technical one. In his oft-cited 1990 paper“The Dynamo and the Computer,” Paul David answered a quip from Robert Solow that you could “see computers everywhere except in the productivity statistics” by looking at the history of electrification, and more specifically, electric motors. When factories first electrified, they bolted a giant electric motor where the steam engine used to be and kept driving the same shafts and belts through the same Rube Goldberg system. Productivity barely moved.
MACHINE SHOP NORTH/NORTHEAST INCLUDING OVERHEAD LINE SHAFTING. MOSTLY BELT DRIVEN WITH ONE ROPE DRIVEN LATHE IN MIDDLE GROUND. POWER COMES FROM KNIGHT TURBINE ON FAR WALL. This image is available from the United States Library of Congress’s Prints and Photographs division under the digital ID hhh.ca2269. Public Domain.
The gains came decades later, when a new generation of entrepreneurs, factory architects, and electrical engineers redesigned the plant around what electricity actually made possible, with many small motors each driving its own machine and the factory floor laid out for the flow of work.
David’s account has since become a paradigmatic example of how technology transformation actually works. This historical analogy suggests that the future might not be ever bigger and smarter centralized AI models but a decentralized network of AI rightsized for thousands or millions of specialized tasks. Yes, there will still be big centralized AI dynamos somewhere, but most of the action will be with smaller (perhaps open source) models distributed throughout the economy.
But there’s more to the story than right-sizing the technology so that it can fit into specialized tasks. The know-how to reorganize work around it had to be built up one person and one plant at a time. This gradual, bottom-up growth of knowledge about how to apply a new technology is also the point of one of my favorite books about the first industrial revolution, James Bessen’s Learning by Doing. It’s also one of the key messages from Arthur Herman’s Freedom’s Forge, which tells the story of the rapid military industrialization of the US in response to the challenges of World War II. (This story may be newly relevant today as AI and drones transform modern warfare.) Herman called out Bill Knudsen’s bottom-up knowledge of the industry as a critical element in his success transforming the auto industry into a defense powerhouse. (Knudsen was the CEO of General Motors, but he had risen up the ranks from the shop floor.)
That is also the whole story of enterprise AI right now. The latest and greatest model is widely available. Frontier models are getting better so fast that diffusion of the latest and greatest model is not the point. That will happen naturally, much as the availability of the fastest PCs did 40 years ago when the diffusion frontier that provided actual competitive advantage moved to software.
What takes time to develop is the organizational know-how to redesign work around it. Most of that know-how does not live in the labs that trained the model. It lives in ordinary practitioners, and it accumulates the way David and Bessen and Ding have described, person by person and team by team, as people work out what the technology is good for in the specific context of their own industry and their own jobs. The speed of model turnover makes organizational skill infrastructure even more valuable, since it’s the only asset that survives each model generation.
What skill infrastructure looks like inside a company
Ding’s national version of GPT skill infrastructure is engineering education, standardized best practice, and strong links between universities and industry. My firm-level version of his vision is the internal apparatus for spreading skill and compounding what people learn. The problem with most enterprise AI transformation programs is that they treat AI as a subject to be taught rather than a capability to be built. Training is part of it, but only part. The harder part is the set of mechanisms that apply AI to the actual problems of the business, then capture each new discovery and turn it into something the whole organization can use, so that learning compounds instead of hiding away in a thousand private workflows.
In “The End of Programming as We Know It,” I made the case that AI expands who can build rather than replacing the people who build today. This means that a company’s best source of applied R&D is the everyday experimentation of the people it already has. The job is to make that experimentation visible, shareable, and rewarded. It is also the framework we are building into O’Reilly’s enterprise AI transformation programs.
We base our ideas about effective AI transformation in part on ideas we’ve taken from Wharton business school professor and author Ethan Mollick and from Dan Guido, the CEO of AI security firm Trail of Bits.
Join Dan Guido and Tim online at the Live with Tim O’Reilly event taking place on July 9. You can register here.
Mollick suggests solving the enterprise transformation problem takes three things: leadership that not only sets the conditions and incentives but gives a good example by getting their own hands dirty with AI; a lab that turns individual discoveries into tools everyone can use; and the crowd, meaning everyone else, whose daily work is where most applied discoveries actually happen. This is a great way to think about applied corporate AI adoption.
Guido adds a number of other elements to AI transformation strategy as we conceive it at O’Reilly. As he put it in his essay “How We Made Trail of Bits AI Native (So Far)”: “AI works. Most companies are using it wrong. They give people tools without changing the system. That’s the gap between AI-assisted and AI-native. One is a tool, the other is an operating system.” To build that “operating system,” he suggests that a company must:
Standardize its toolchain. This step seems boring and perhaps even unnecessarily restrictive but according to Guido, without a shared standard across an enterprise, you get zero organizational leverage. While experimentation is encouraged and different departments may have different tools, it’s important to constrain the possibilities so that you don’t get a sprawling set of incompatible workflows. That does not mean that the toolchain becomes fixed, just that organizational discipline is important. New capabilities and tools appear at a furious pace. A key corporate capability thus becomes how to evaluate and select tools at enterprise scale as well as how to govern the toolchain over time as the ecosystem evolves.
Write down the rules. When large language models were new, enterprise AI handbooks were full of warnings: Watch out for hallucinations. Watch out for putting in PII or proprietary company data. Beware of copyright infringement. Check and compensate for bias. And so on and on and on. As Mollick noted, such handbooks often discouraged adoption. Guido simply argues for clarity: what tools are approved, especially for sensitive data. For example, among their rules at Trail of Bits: “Cursor can’t be used on client code (except blockchain engagements; use Claude Code or Continue.dev instead). Meeting recorders are disallowed for client meetings conducted under legal privilege.” He notes, “The handbook doesn’t just list what’s approved. It explains the risk model behind each decision, so people understand why….Once you have policy, you can safely push harder on adoption.”
Build a capability ladder. Every company needs an “AI maturity matrix” to help employees understand where they are in their AI journey and measure their progress. This is not an exhaustive list of tools and techniques to master. The spine of the Trail of Bits maturity matrix is not specific technical skills but the pathway from resistance or lack of engagement (stage 0) to comfort with using a job-relevant set of AI tools (stage 1), to proactively seeking out and adopting new tools and techniques and sharing them with others (stage 2), to actually creating new tools and techniques that advance the AI capabilities of the firm (stage 3). As shown in the sample AI maturity matrix that Guido published in his blog post, you can see how the specific tasks and tools vary by department. His basic point, though, is that improvement across this matrix needs to be expected, measurable, and rewarded. At O’Reilly, as part of our AI transformation practice, we’ve built a similar capability matrix, integrated with our verifiable skills tooling and learning paths, which we plan to work with our customers to adapt to their unique situation.
Run adoption sprints so the org keeps pace with new tools and releases. Some of the best learning happens via organization-wide hackathons where people apply AI to their own problems rather than learning in the abstract. This is where Guido’s framework marries perfectly with Mollick’s: Management can use a regular hackathon to get “the crowd” engaged with the latest round of AI developments and apply it to their actual work. “The lab” then takes the best of that and explores how to productize it and make it reusable across the organization.
Package organizational learning into reusable artifacts (skills, repos, configs, sandboxes) so the system compounds. Compounding is absolutely critical to successful AI transformation, and I’m starting to understand what it means and how it works.
Make autonomy safe with sandboxing, guardrails, and hardened defaults. Give new employees one-click install of the AI environment they are expected to become proficient with.
Another thing that needs to be clarified is access to data. At O’Reilly, we’ve found that a major challenge in reuse of AI tools and skills created by our employees is fragmentation of data access. Workflows often cross departments, with users in one department having access to data and systems that are invisible or inaccessible to others. This needs to be fixed. Everyone doesn’t have to have access to the same data; there may be good reasons why they can’t. But every organization needs what DJ Patil, the first US Chief Data Scientist, calls “the tidy house.”
One of the biggest problems in enterprise AI, DJ notes, is the patchwork of systems of record without clear structure on who gets to access which data. As he put it to me, describing the data infrastructure he built that has enabled Devoted Health to move so quickly with AI, it is “fundamentally still data 101, unified data environments, data flows that are clean, that have a lot of organization. . . .Because we invested so heavily in that infrastructure, the dumb, boring, painful parts of making sure you’ve got a really great data warehouse, great data engineering pipes, all of the metadata that goes with it, when AI shows up, you get to use it right away.”
One constraint may be the incentives
Ding’s theory needs one adjustment when it moves from countries to companies. For a nation, skill infrastructure is close to a public good. Educate more engineers and the whole economy benefits, more or less independent of who captures the immediate return. Inside a firm, diffusion may collide with incentives. The value comes from ordinary practitioners sharing what they have learned, but the practitioner who shares a workflow that automates half of her own job, in an organization that rewards looking indispensable and is quick to notice who looks replaceable, is being asked to act against her own interest. Mollick has pointed out that people hide their AI use for exactly this reason. And that’s why Guido’s methodology is so dependent on rewarding people for learning and sharing what they learn.
This is where corporate AI transformation strategy intersects with my interest in mechanism design, an often underappreciated branch of economics. (See my previous essay, “The Missing Mechanisms of the Agentic Economy.”) Mechanism design has been described as “reverse game theory”: start with the outcome you want, and design the rules of the game to produce it.
The constraint on enterprise AI adoption is not just the raw skill of the people. It is whether the organization has built incentives under which sharing what you learn raises your status rather than lowering it. Get that right and diffusion follows on its own. Get it wrong and you can have a small kernel of great people leveraging every frontier model on the market while adoption stalls out at a small fraction of your workforce.
Ding’s claim is that these transitions are won by the patient and the adaptive rather than the first and the flashiest. This fits right in with the messaging of Mollick and Guido. The companies that pull ahead over the next decade will be the ones that turned their ordinary engineers and their ordinary analysts and marketers and support reps into people who put AI to work in their own jobs, and that built the incentives to make them want to share what they learned.
Sovereignty, open source, and common protocols
Ding’s framework also helps clarify the geopolitics of AI. A foundational general purpose technology cannot remain the exclusive instrument of a single company or a single nation for very long. If it is that important, everybody has to have it.
That has implications for how we think about sovereign AI. The phrase is often used to refer to national competition for frontier capability. But sovereign AI is not just a matter of national power. It is a predictable consequence of diffusion. A technology that diffuses widely will be adapted by different societies, firms, and institutions to suit their own needs, values, and constraints. Sovereign AI is AI designed for diffusion, not just raw increases in capability.
This is one reason the arms-race framing is unhelpful. It encourages us to treat AI as if it were a weapons system or a scarce strategic asset. But if AI is closer to electrification, computing, or the written word, the important thing is how the technology is embedded into the ordinary life of economies and institutions, and whether that embedding happens in ways that increase agency broadly rather than concentrating it in a few hyperpowerful companies.
There are a few additional lessons we can take from the history of electrification. While motors became decentralized, factories stopped generating their own power and bought it from a centralized grid. The unit-drive revolution decentralized application, not generation. This limitation, which we are now working to overcome to some extent with decentralized solar generation, is perhaps ironically showing up most strongly in the strain that AI data centers are placing on the grid. Let’s learn from that misstep. You can diffuse AI into every workflow via API calls to a big centralized model, or it can be diffused by a network of smaller models that turbocharge every part of the economy.
We should design for a future of multiple AIs, not a single universal system. Different countries will want systems shaped by different legal regimes, languages, histories, and cultural assumptions. So will companies. So will professions and communities of practice. The instinct of some frontier labs is to imagine that the right answer is to homogenize the technology, purge it of bias, and offer a single sanitized intelligence layer for the world. But AI is a social and cultural technology. The differences are not a defect to be smoothed away.
We do need to think about standards and interoperability. The historical analogy that comes to mind is railroad gauge. When real world systems are built to incompatible standards, the result is not healthy diversity but decades of friction, kludges, and retrofitting. The same may prove true for AI. If we force the future into a choice between one universal model and a patchwork of disconnected sovereign systems, we will get the worst of both worlds. We need a layer between uniformity and fragmentation, which can come from standardized protocols that allow different models, tools, and institutions to interoperate without requiring them to become identical.
This is also why open source matters, but only if it is properly understood. Open source is not just about licenses. My earliest introduction to the shared development of software that now goes by that name came from the research community that grew up around Bell Labs’ Unix operating system despite AT&T’s proprietary (albeit permissive) licensing. Because of that experience, I became convinced that it was the modular, protocol-centric architecture of Unix that was a key driver of collaborative, internet-enabled software development.
Open source AI depends on far more than open models. It depends on the architecture of participation built into the systems above and around them: the protocols, servers, interfaces, and shared technical conventions that let many different actors build on common foundations. The Open Source AI Gap Map shows just how rich that open source AI ecosystem is becoming. But open source can also coexist with proprietary, de facto standards like the OpenAI and Anthropic APIs. Like the electric grid we are now beginning to rebuild, the AI future will be a mix of centralized and decentralized systems. Cooperation and competition can coexist. Different actors can build different systems, for different purposes, under different forms of governance, while still participating in a shared technical and economic order.
This is how the future can belong not just to the inventors of AI but to the people who make it usable, adaptable, interoperable, and worth adopting.
What an incredible week for the ecosystem. We are diving deep into what it truly means to build a community-first framework, exploring how AI agents are changing how we write code, and looking at next-level browser testing.
Get inspired and upgrade your workflow with this week’s resources:
The Dev Life Podcast: Community-First Engineering with Magda Kustosz Brooke Avery @JediBravery and Matthew Christiansen sit down for a must-listen conversation with our very own Angular Community Manager, Magda Kustosz 🌟 Dive into the strategy, heart, and insights behind building a community-driven ecosystem. Plus, check out the full playlist intro to catch the rest of the season’s tech discussions.
Agentic Coding: AI Support for Angular Johannes Hoppe @JohannesHoppe and Ferdinand Malcher @fmalcher01 explore the frontier of Agentic Coding. Discover how advanced AI agents are moving past simple autocomplete to provide deep, context-aware architectural support tailored specifically for Angular workspaces.
Test Components Like a Real User with Vitest “Full” Browser Mode Younes Jaaidi @yjaaidi drops a game-changing tutorial on testing. Learn how to leverage Vitest’s Full Browser Mode to test your Angular components exactly how a real user interacts with them in an actual browser environment.
Signal Forms & Extended Compiler Diagnostics (Spanish with English Subtitles) Alejandro Cuba Ruiz @zorphdark brings us two fantastic videos with English subtitles. First, a comprehensive deep dive into the practical power of Signal Forms. Second, an essential look at how to leverage the Extended Diagnostics of the Angular Compiler to catch tricky bugs before they hit production.
AI Image Generation with Firebase Server Prompt Templates Connie Leung @connieleung404 shares an excellent code sample showing how to generate images using Angular and Firebase AI Logic, utilizing Server Prompt Templates for secure, scalable AI operations.
Restoring Status CSS Classes in Signal Forms (French) Modeste Assiongbon @rblmdst continues his expert French-language coverage of Angular v21, walking through how to seamlessly restore form status CSS classes when working with the new Signal Forms API.
What does “community-first engineering” mean to you? Whether you’re answering questions on forums, speaking at meetups, or writing open-source code, your voice builds this framework.
Let’s keep the knowledge moving. Use #AngularSparkles to share your favorite mid-year tutorials and insights 👇
So, we recently got the new shape() function (now Baseline!) as well as the corner-shape property. What else could we possibly need as far as making shapes in CSS? Let me tell you: the border-shape property!
shape()? corner-shape? border-shape?! Where did all these come from?
If you are not a CSS shape fanatic like me, you probably missed these features when they came out, so let’s give them brief, formal introductions, starting with…
Speaking about SVG, you can express any SVG shape using shape(). Said differently, you can convert any SVG shape into a CSS shape and, guess what, I made a converter that does exactly that!
As far as corner-shape goes, it’s a property that works in conjunction with border-radius. As its name suggests, it allows you to control the shape of an element’s corner using predefined keywords.
But is this the corner-shape property really useful or even needed? Except for the squircle value, most of the shapes can already be created using clip-path or mask. But what corner-shape does that these others can’t is easily add borders and other decorations to those shapes!
corner-shape will not only shape the corners, but it also supports other properties like border and box-shadow, allowing them to follow the shape rather than the element’s box. This is a game-changer because we all know that adding borders to shapes is a nightmare.
Support is still not great (Chromium-only as I’m writing this), but it’s a good time to explore it and get an overview of its potential.
Enter border-shape!
Shaping corners is good, but it’s still fairly limited as far as what we can do with it. Like, what about shaping the whole element instead? That’s what border-shape will do. It accepts the same values as clip-path, including the new shape() function.
So, it has the same job as clip-path? What’s new?
Like with corner-shape, most decorative properties such as border, box-shadow, and outline follow the shape.
clip-path (and mask) will clip/mask the whole element, including the decorations, so having borders is a big NO. That’s a major problem for creating CSS shapes.
The border-shape property is here to solve this issue. Instead of clipping the element, it “shapes” the element, allowing its decorations to follow that shape. In other words, putting borders on CSS shapes will become child’s play!
Not to mention that border-shape is also very easy to use. If you are familiar with clip-path, then you practically have nothing new to learn. Simply replace one property with another, and you are done.
I invite you again to learn more about the shape() function because it’s the value that makes border-shape really powerful. The two really go hand-in-hand.
Now that you know the basic use of the property, shall we start the fun stuff? I are here to push the limits and show you what is possible using border-shape.
Note: Support is limited to Chrome-only for now so check out the next demos using Chrome.
Border-Only Shapes
As I said, the first major advantage here is adding borders to shapes that follow the actual shape, which also means the ability to create border-only shapes. All you have to do is write the following code:
Most of the shapes are already available in my CSS Shapes collection, so really, making border-only shapes is something you can do with a simple copy/paste. Even some of my online generators are already configured to provide border-only versions of complex shapes, like blobs, wavy lines, and fancy frames, among many, many others.
Cutout Shapes
Let’s take the previous code and update it as follows:
You keep the shape code you had, and you add inset(0) at the beginning. Yes, you can have two shape values inside border-shape and the result will be as follows:
The border-shape property accepts either a single <basic-shape> or two <basic-shape>s:
Single <basic-shape> (Stroke mode): The border is rendered as a stroke along the shape’s path, with the stroke width determined by the relevant side’s computed border width. This mode is useful for creating outlined shapes.
Two <basic-shape>s (Fill mode) The border is rendered as the area between the two paths. The first shape defines the outer boundary, and the second shape defines the inner boundary. This mode provides precise control over the border region’s geometry.
Using a basic rectangle as the outer shape (inset(0)), I was able to easily transform the border-only version into a cutout version!
Do you want the shape inside a circle? Easy!
All I did is replace inset(0) (a rectangle) with circle() (a circle).
But we can do this with a simple border-radius: 50%, right?
No! When working with border-shape, the border-radius is ignored, which is kind of logical since we no longer have corners to round — the element is now shaped. This is not a big deal since we can literally create any kind of shape that replaces the use of border-radius, as shown in the previous example.
Perhaps this is nothing surprising considering what we have learned so far. We define two shapes and the border is drawn inside the area between them. What’s new here is that we are dealing with content and, as you can see, it overlaps the border.
border-shape shapes the whole element, including the element’s decoration, but any content inside remains unchanged and follows the initial rectangle shape. That’s not new behavior since the same happens even even with classic border-radius. And the content will overflow unless we decide to hide it using overflow hidden.
In this case, I won’t consider the overflow property as I want the content to overflow and be placed on top of the border decoration.
I made the circle smaller and the rectangle bigger. Do you see where I am going? By making the radius of the circle 0 and the rectangle bigger, I create a breakout background effect!
The element remains centered, but its background (that we are simulating using a border!) extends to the edge of the screen.
And this is not limited to using two shape values. Even with the one shape value, we can achieve a breakout decoration (which is typically difficult) if you consider any value that gets you out of the element’s boundary.
Here is a demo with many examples that I’ll let you explore:
Partial Decorations
Let’s piggy-back off that last demo to try different decorations.
This time, instead of extending outside the element boundary, I am staying within it to create partial decoration. In other words, we no longer have boundaries. border-shape has no limit. The only limit is your imagination!
I am mainly relying on the shape() function to create the decoration, so do yourself a favor and explore this feature by reading my four-article series! If you master shape(), you can easily produce complex decorations using border-shape.
Shape Animation
Yes, border-shape can be animated, and we can have different kinds of animations. With the two-value syntax, we can animate the border-width value to create a reveal effect:
Hover the below and see the result:
Cool, right? We can also apply this to image elements as well:
We can also animate the shape values to create more complex animations. Here is a demo of a bouncing hover effect applied to blob shapes (from my article “Making Complex CSS Shapes Using shape().”
I take the same code, replace clip-path with border-shape, and tada!
And why not add a subtle animation to those previous decorations? Hover the titles and the text to see what happens:
Want More? Let’s Go!
Here is a hand-drawn underline that slides between the menu items on hover. Straight lines are boring!
And why not an electric frame around your content? Don’t worry, it’s safe for touch screens.
Let’s connect circles with a straight line that bends when the circles get closer and stretches when they get farther. Drag the circles in the demo below and see the magic in play:
Conclusion
I think it’s clear now why I am calling this new property “powerful.” In addition to making it easy to create CSS shapes, it lets us add fancy decorations, cool animations, and more!
I didn’t go into fine detail with most of the demos as I wanted to keep this a light article showing the potential of border-shape. Now that you know we can create crazy stuff with it, stay tuned for more elaborate articles!
Don’t forget to bookmark my CSS Shapes collection and my online generators. I have already updated many of the shapes using shape(), and I am in the process of also including the border-shape version.
Log in
We’re announcing new capabilities in Managed Agents in Gemini API so developers can build reliable, production-ready agents.
