Welcome back to New in Edge for developers, our recurring roundup of recent web platform updates in Microsoft Edge. In this edition, we'll look more closely at some of the newest additions to Microsoft Edge and the Chromium project, such as the OpaqueRange API, to highlight and interact with ranges of text in input fields, the referenceTarget property, to make your custom web components more accessible, and the aria-actions attribute, to expose your widgets' secondary actions to assistive technologies. We'll then round up other useful additions, including media-state pseudo-classes, relative alpha colors, and PWA drag regions, and go over early features that are ready for testing such as WebMCP, to unlock browsing agent scenarios.

OpaqueRange API: highlight and interact with text ranges in form inputs

The new OpaqueRange API provides live access to ranges of text within form inputs, such as <textarea> and <input> elements. You can use these ranges for operations like getBoundingClientRect() and getClientRects(), and therefore position UI at specific places within form inputs. The OpaqueRange API also works with the CSS Custom Highlight API, making it possible to create personalized highlights within editable text regions. To learn more about the OpaqueRange API, checkout our intro video, explainer, and live demos.

Reference Target: improve your web components' accessibility

A common pain point developers face when creating web components with Shadow DOM is making them accessible. A problem also known as cross-root ARIA. The referenceTarget property of a ShadowRoot object, which can also be set via the shadowrootreferencetarget HTML attribute on elements, solves this. It makes it possible to forward ID reference attributes, such as for or aria-labelledby, to elements that are inside the shadow DOM of a component. For example, you can use this to link a <label for> element to the right <input> element, even if that <input> is inside the shadow DOM of a web component.

<label for="custom-checkbox">Checkbox value</label>
<custom-checkbox id="custom-checkbox">
  <template shadowrootmode="open" shadowrootreferencetarget="real-checkbox">
    <input id="real-checkbox" type="checkbox">
  </template>
</custom-checkbox>

To learn more, read our explainer, and use our live demos.

aria-actions: make composite widgets accessible

Complex UIs often contain composite widgets with multiple actionable parts. For example, a tab widget may also include another button. These composite interactive widgets can be hard to make accessible to assistive technology users. The new HTML aria-actions attribute makes it possible to expose your widgets' secondary actions to screen readers. For example, you can expose the close button of a tab widget as follows:

<button class="tab" aria-actions="close-tab">
    <span class=”tab-title”>Tab 1</span>
    <span id="close-tab">Close</span>
</button>

To learn more, check out the tabs with action buttons example from the ARIA Authoring Practices Guide.

And many other features

The above features, which our team added to Microsoft Edge and contributed to Chromium, are only a part of what's been added over the past few releases. Below are other additions that might simplify your daily life as a web developer. For even more, check out the Edge web platform release notes.

• Media pseudo-classes allow you to style media elements, such as <video> and <audio>, based on their playback state, by using the new :playing, :paused, :buffering, :muted, and :stalled pseudo-classes.
• The window-drag CSS property is a new standardized way to make installed PWA windows draggable, which is helpful when using the Window Controls Overlay API. In addition, starting with Microsoft Edge 151 on Windows, when you use the Window Controls Overlay API, the PWA app title bar is now hidden by default, giving you more control over the look and feel of your app.
• New JavaScript Iterator methods make it easier to work with iterators:
  • Iterator.join() returns a string that's the concatenation of all elements that are produced by the iterator.
  • Iterator.zip(), and Iterator.zipKeyed() create new iterators that aggregate elements from multiple iterable objects. These methods zip the input iterables together, allowing simultaneous iteration over the input iterables.
• The soft-navigation and interaction-contentful-paint performance entries help you improve performance of modern single-page web apps by measuring soft navigations that update the page without triggering a traditional page browser history changes.
• The alpha() CSS function creates a new color by adjusting another color's transparency.
• textStream() is now available on Response, Request, and Body objects, making it more convenient to process text incrementally without manually decoding byte chunks.
• The <camera> and <microphone> HTML elements are browser-provided buttons that let users toggle camera or microphone streams and, when needed, connect the permission request directly to an explicit user action.

Ready for testing

We're already hard at work on what's coming next. Here are upcoming features that are available for your early testing and feedback. You can test these new features either by enabling them locally, or on your production website with your own users, by registering for an origin trial. Your feedback is crucial to help us shape these next features and ensure they meet your needs as developers, and the needs of your users.

WebMCP: unlock browsing agent scenarios on your site

We have been actively involved with the Web Machine Learning Community Group, specifying WebMCP: a web API that helps you create efficient, fast, and trusted human-agent collaboration workflows for your site. Using WebMCP, you can reuse your existing front-end code, and expose it as structured tools which a browsing agent can then use to help users accomplish tasks on your site. Our implementation of the WebMCP spec in Microsoft Edge is ready for testing. To get started, we created a few samples and a browser extension to run and debug your WebMCP tools. Find out more on the webmcp-labs repo.

JS Self-Profiling markers: see what the browser is doing during a trace

The JS Self-Profiling API is a great way to measure your app's performance in production, on real user devices. But it only samples your page's JavaScript, which often leaves unexplained gaps in a trace, moments where the browser was styling, laying out, painting, or running garbage collection. We're adding sample markers to fill those gaps. Each sample can now carry a marker that identifies what the browser was doing at capture time. Now, an unexplained gap shows up clearly as, for example, a run of layout markers, so you can pinpoint the real cause of a slow trace and optimize the right thing instead of guessing. To learn more, read the feature explainer, see the markers in action by running our live demo, and register for the origin trial to test it with your own users and share feedback.

New network debugging tools: edit and resend requests

Starting with Edge 153, the Network tool in DevTools now includes two new actions, available on each request via the contextual menu:

• Resend: this action resends a request such as XHR or Fetch.
• Edit and resend as fetch: this action creates a Fetch API call but doesn't send it right away. Instead, it writes it to the input of the Console tool. You can then modify the new request, such as by changing the request headers or parameters, and send it.

Learn more about these new features on our Network tool reference documentation at Resend a request and Edit and resend a request as a fetch call. These features are planned to replace the experimental Network Console tool. Try them out and share your feedback.

navigator.install() and <install>: install other web apps

Updated versions of the Web Install API and the <install> element are available for testing. Both navigator.install() and the <install> element now take a direct link to the target manifest file of the app you're installing. For example:

// Install the current app
navigator.install();

// Install a cross-origin web app
navigator.install( { manifest: https://example.com/manifest.json });

<!-- Install the current app -->
<install>

<!-- Install a cross-origin web app -->
<install manifest="https://example.com/app/manifest.webmanifest"></install>

To learn more about these web app installation features, check out the Web Install API and <install> element demos and resources. You can also start using the <install> element on your own site by registering to the origin trial.

News from across the web platform

Before closing, here are a couple of updates from the broader web ecosystem.

The Interop 2027 call for proposals closes soon

The Interop 2027 call for proposals is open, submit your ideas now! If there's a web feature you care about and would like to see more consistently supported across browsers, now is the time to make your case. Submit your idea and help shape the priorities for Interop 2027. Learn more by reading our blog post: Calling for Interop 2027 proposals.

Microsoft Edge sponsors Open Web Docs for the 7^th consecutive year

High-quality and up-to-date technical web platform documentation continues to play a key role in making the web the most universal application runtime in history. This is why, at Microsoft Edge, we have been sponsoring Open Web Docs. This year marks our 7^th consecutive year funding OWD, enabling the collective to continue creating and maintaining the documentation and data that all web developers need.

A native menu element is coming

Web developers have long needed a browser-provided way to build menus that don't require re-implementing accessibility, keyboard navigation, focus management, and positioning from scratch. The Open UI community is working on a new native menu element that aims to provide these capabilities out of the box, while remaining flexible enough to fit modern design systems. We're excited about this work because it reflects a broader trend toward more powerful, customizable built-in web platform components. Great work from the Google team for implementing the <menubar> element. To test the element, enable the "Experimental Web Platform features" flag on the about://flags page. We can't wait to see what you build.

Do you have feedback? We're listening

On the Microsoft Edge web platform team, we're always listening to what users and web developers need and work toward a better, more capable web. We hope these recent additions help you build experiences that are easier to use, easier to measure, and easier to maintain. Try the features that matter to your projects, tell us where the APIs fall short, and share the use cases the platform still doesn't solve. Your feedback helps us improve Edge, Chromium, and the web platform for everyone.

Prompt-to-app builders have changed how a lot of software gets started. You open a browser, describe what you want, and a few minutes later something is running. But most of these tools generate React and TypeScript. If your team’s skills, libraries, and existing applications are in .NET, you end up with a prototype in a stack you don’t maintain.

Today we’re releasing XAML.io v0.9, which brings that starting point to C# and XAML. You describe an application, and an AI agent writes it, compiles it, reads the compiler errors, and fixes them until it runs. You get a standard .NET solution. You can keep changing it with the agent, by editing the code, or in the visual designer. When it’s ready, publish it to the Web in one click or open it in Visual Studio.

The AI agent, the editable C#/XAML source, and the running application, side by side in XAML.io v0.9.

New to XAML.io? XAML.io is a free, browser-based IDE for building .NET apps with C# and XAML: a drag-and-drop designer with 100+ controls, a code editor, and in-browser .NET compilation via WebAssembly. No install, no signup. Built by Userware, powered by open-source OpenSilver. Try it →

---

What’s new in v0.9

• An AI coding agent that works across the whole C#/XAML solution. It creates and edits files, builds, reads diagnostics, and fixes errors.
• Diff review and Version History, so you can see exactly what changed and go back to any checkpoint.
• One-click Web publishing to a hosted xaml.cloud URL.
• Model choice and per-request cost, shown in dollars.
• AI-assisted WPF migration for the cases our deterministic tooling can’t handle alone.
• Free AI usage on every account (up to $5 a month), and XAML.io Pro at $20 per month with $20 of AI usage included.

---

One prompt: Paint, as it looked in Windows 98

A to-do list wouldn’t tell you much, so we picked something harder. We opened a blank project and typed one sentence:

Build a Paint clone as it appeared in Windows 98.

Then we left it alone. The agent created the C# and XAML files and implemented the UI and the drawing behavior. It compiled the project, hit errors, fixed them, and kept going. Nobody sent a follow-up prompt or touched the code during the run.

The agent worked for 42 minutes and produced about 3,500 lines of C# and XAML.

An edited overview of the run and the finished application.

Paint, recreated from a single prompt in XAML.io v0.9.

Paint is a harder test than it looks. Pointer input, drawing tools, selections, colors, menus, dialogs, and application state all have to work together. A bug in any of them is visible as soon as you pick up the pencil.

We used GPT-6 Astra at High reasoning effort, the most capable setting XAML.io offers today, because we wanted to see how far a single request could go. That makes it a stress test rather than a typical request, and we’ll come back to what it cost. Like any AI output, a second run of the same prompt would produce a different application.

You can check the result yourself. No account is needed:

Open the Paint project →

Click Run, draw something, try the tools and menus, then open the source the agent wrote.

---

Then change it

You can make any change to the application in three ways. You can describe it to the agent, edit the C# and XAML yourself, or adjust the UI in the visual designer. All three work on the same files, so nothing needs to be synced or exported between them, and you can switch whenever the task changes. The best choice depends on the change:

• Describe it when the change is an outcome that spans many files. “Add a gradient fill tool” means a new toolbox button, an icon, the drawing logic, and a way to pick the two colors. The agent can work through all of that and build the result.
• Edit the code when you know exactly what to change. To make the airbrush spray more densely, opening the C# and changing it yourself is often faster than explaining it.
• Use the designer for precise UI work. If the toolbox needs more spacing or the color palette should be larger, select it and adjust it directly.

One application, three ways to change it: AI, source code, or the visual XAML designer.

We don’t think every software change should become a conversation with an AI. The point is to use whichever tool fits the change in front of you.

---

See exactly what the agent changed

When the agent finishes, you can review a diff of every file it touched.

Reviewing the files changed by the agent.

Version History keeps checkpoints as the project evolves. You can compare versions, go back, or try a different approach without losing the one you like.

Reviewing an earlier project checkpoint in Version History.

This matters most for large changes. A successful build tells you the code compiles. It doesn’t tell you the application behaves correctly. Review the diff, run the app, and then decide.

---

Publish, and send someone a link

When the application is ready for someone else, click Publish. XAML.io builds it and hosts it at a xaml.cloud URL.

Publishing an application from XAML.io to the Web.

The person you send the link to gets the running application, not the IDE. Sharing a project is still there for when you want someone to read or fork the source. Publishing is for when you want them to use the app. That makes the loop short:

Build → run → publish → get feedback → change → publish again.

One-click hosting has been on our roadmap since v0.6, and it’s here now. If you’d rather host the app yourself, you can still download the static Web build and put it on any server.

The same Publish menu also produces desktop apps for Windows, macOS, and Linux, which we added in v0.7. Your C# runs as native .NET. The UI is rendered by a WebView, so the app looks consistent on all three platforms. (How it works →)

One C#/XAML project, published to the Web and to the desktop.

---

It’s still a .NET project

We want XAML.io to make the start easier without creating a separate world you’d have to leave later.

The agent writes C# and XAML. The XAML follows WPF syntax, so if you’ve built WPF applications, you can read and change what the agent writes. Projects can use compatible NuGet packages, and the visual designer edits the same XAML files. For everyday edit-build-run cycles, Roslyn compiles your C# inside the browser via WebAssembly, with no server involved.

When you want to continue elsewhere, download the project as a standard .NET 10 solution. You can open it in Visual Studio, VS Code, or Rider and use your usual source control, debugging, testing, and CI/CD. Or you can keep working in XAML.io.

The same project opened in Visual Studio.

All of this runs on OpenSilver, our MIT-licensed open-source C#/XAML framework. The runtime your application depends on isn’t locked inside our product.

---

What runs where

XAML.io has always kept compilation local, so it’s worth being precise about what changes with AI.

Editing, compiling, and running your project still happen in your browser. That includes the WPF compatibility analyzer and source import. Agent tasks are different: they can run for a long time and chain many edits, builds, and fixes. So they run in a temporary, isolated cloud environment. When you use the agent, the project files it needs are sent to that environment and to the AI model provider you selected.

AI is opt-in. If you don’t use it, your code stays where it was. Your code is never used to train any AI model.

---

What about the WPF applications you already have?

Starting a new application from a prompt is one side of the story. The other side is the large amount of .NET software that already exists in WPF.

XAML.io v0.8 introduced Migrate from WPF, which pairs a compatibility analyzer with deterministic transformations for migration patterns we know how to handle reliably. In that post we said the tooling doesn’t rewrite your code with AI. That principle hasn’t changed: we don’t regenerate working code. What v0.9 adds is help with the cases that need context rather than a rule.

Say an application uses a desktop functionality that has no browser equivalent. The agent can look at how the API is used and read the surrounding code. It can then make targeted changes across the affected files, rebuild, and keep working through the diagnostics. The deterministic fixes still run first, and the agent handles what’s left. Every edit it makes shows up in the same diff and Version History as any other change.

Family.Show shows the foundation underneath. It’s the WPF reference application Vertigo built for Microsoft, and our Web migration keeps 97% of the original C# and XAML unchanged.

Run Family.Show →

Inspect the migrated source →

We migrated Family.Show before the agent existed, so it isn’t an AI demo. It shows the migration layer the agent now builds on. That layer comes from our team’s more than 13 years of experience migrating customer applications, with over 10 million lines of production front-end C# and XAML migrated.

The approach is simple. Use deterministic transformations where a known migration works reliably, and use AI where the problem requires understanding the rest of the application.

---

Choose the model. See the cost.

A one-line fix and a 3,500-line application are very different AI workloads. XAML.io lets you choose among supported models and, where available, reasoning levels. Every request shows the model, the token usage, and its actual cost in dollars.

Request details: model, token usage, and dollar cost.

The Paint run sits at the far end of that range: our most capable model, at a high reasoning setting, working for 42 minutes. It cost about $57. Adding a significant new feature using the most capable model, such as adding the gradient fill tool in the Paint app, costs $1-$5, and a small edit can cost just a few cents.

We don’t convert AI usage into an internal currency. If one request costs a few cents and another costs several dollars, you see the difference directly, and you can pick a smaller model for smaller jobs.

Free accounts include up to $5 of AI usage per month, with at most $3 in a single day. XAML.io Pro costs $20 per month and includes $20 of AI usage every month, plus access to the frontier models. If your usage runs out partway through a task, the agent pauses and the code it has written so far is synced to your project, so nothing is lost. Once you top up, you can resume the task whenever you like.

---

Limitations

v0.9 is still part of our Preview series, and we want to be upfront about its limits:

• Review the agent’s work as you would a teammate’s pull request. The agent builds its own code and fixes what the compiler catches. But like any developer, it can make mistakes a compiler won’t flag. The diff view makes that review quick, and running and testing the app is still the final check before you ship.
• Results vary. The same prompt produces a different app on a different run. Large requests on top-tier models can cost tens of dollars.
• Front end only, for now. Applications can already call existing APIs and services. A built-in database with user authentication is coming soon (see below).
• Web apps run in the browser sandbox. Things a browser can’t do, such as Win32 calls, P/Invoke, or unrestricted file system access, need the desktop build or a different approach.

---

What’s next

The next step is data. In Q4 2026, we plan to add a built-in PostgreSQL database and user authentication. The agent will be able to create and update the database as it builds your app. That means you’ll be able to go from a prompt to a multi-user application that stores its data and knows who is signed in, then publish it the way you publish today.

You can already see the shape of the product in v0.9. You start with a prompt in the browser. You keep working with AI, visual design, or code. Then you publish to the Web, ship to the desktop, or move into Visual Studio and the rest of .NET.

---

Try XAML.io v0.9

XAML.io v0.9 is available today at xaml.io. The editor, visual designer, NuGet package manager, compiler, and runtime work without an account. A free account adds cloud saving, sharing, Web publishing, and AI.

If you want something concrete to start with, open Paint:

Open the Paint project →

Run it and read the C# and XAML. Then change something by hand, or save a copy and ask the agent to take it somewhere new. We’re looking forward to seeing what you build.

xaml.io | Free. No install. No signup required to start.

Paint and Windows are trademarks of Microsoft Corporation. This Paint recreation is an independent project, not affiliated with or endorsed by Microsoft.

Powered by OpenSilver. XAML.io is built on OpenSilver, the open-source framework that runs WPF-style C# and XAML in the browser via WebAssembly, and, through MAUI Hybrid and Photino, natively on mobile and desktop. Migrating a WPF, Silverlight, or LightSwitch application? Our team can help →

After I posted “Confessions of an Unrepentant Slop Snob” on LinkedIn last week, with links to the Honeycomb AI norms and values docs, I got this question from Niklas Lochschmidt:

I am curious if you could share more light on the process? Any guidance you would give people in companies that have the friction and internal debates, but maybe haven’t arrived at shared norms and values yet?

That’s a great question, and I will answer in just a minute.

I feel like this is a great way to kick off something I’ve been looking forward to all year — an old fashioned bloggy dialogue between myself and Dr Cat Hicks, research psychologist to the stars engineers, on the topic of norms, ethics, and learning in the era of AI.

In which Cat and I were both writing books at the same time

When Cat’s publisher reached out to me in November of 2025 about reviewing her book, “The Psychology of Software Teams”, I .. didn’t notice the email for a month, then put off reading it for another two months, because I was in the middle of my own private hell trying to get the second edition of Observability Engineering written, then rewritten, then written again.1 🫠

But once I did pick up her book, I downed it in a sitting. Then I wrote a long and gushing fan letter to Cat and her publisher, with bullet point lists (yes plural) of ideas for ways that we could collaborate or I could support her work.2 What struck me, reading her book, was how much overlap and resonance there was between what she was writing and what I was writing, despite being radically different books in almost every conceivable way.

Hers: a slim, disciplined 150 pages of text, plus another fifty pages of reference notes and citations, presenting common misconceptions about high-performing teams, what the research actually says, and how to integrate these learnings into practice, all neatly organized by theme.

Mine: a sprawling 600-page O’Reilly book on observability engineering, of which I was responsible for the first section, introducing the history and principles of observability, and the last, a guide to observability for technical decision-makers. It is…less disciplined, which is to say it is all over the fucking map. Instrumentation, evaluating costs and value of observability tools, making the case for investment, systems thinking, build vs buy, partnering with vendors, and more.

These books appear to have nothing in common besides the word “software”.

And yet.

The case I am making in the first and last sections of “Observability Engineering” (2nd ed) is the same case Cat is making in “Psychology of Software Teams”, from different angles.

What feeds greatness, in people and in teams? What are our responsibilities to each other? How do we engage with complex sociotechnical systems, as builders and caretakers, and leave them better off than we found them? How do we build systems of governance and accountability, a work environment that is supportive and pleasant, and a culture that equips us to successfully compete in the market? Are these things even compatible?

And now, of course, there’s AI in the mix. You might be delivering twice as much twice as fast, yet falling far short of expectations, if your managers, execs, or investors are expecting 10x, 100x or more. Are their expectations unreasonable, or has your output not sufficiently caught up or adjusted for what is now table stakes ? The only honest answer is that no one really knows yet.

How should we navigate this moment in our own workplaces?

So here we are. The stakes are high. There’s a vast sense of unsettledness and insecurity in our industry, with ecstatic possibilities coexisting alongside existential dread, and we’re all along for the ride with our meat sacks and Paleolithic psychologies. Surely there has never been a less boring time to be a psychologist who studies software engineers. I’m really looking forward to chatting about this with you, Cat, and grappling with some of these practical and/or existential questions together.

Let’s start off by circling back to the question we started off with. If other companies are interested in writing down some of their norms and values around AI usage, where should they start?

My response:

Start by listening. I put a few discussion hours on my calendar, opt-in, open door, each one capped at 10 people, and asked wide-open questions like “What AI-related thing has annoyed you lately?”

Themes began to emerge early on, and I followed those threads in later sessions to get a fuller picture of what was happening around the org. It was really helpful. It also felt like an excellent steam valve to release some of the pent-up anger and frustration people were feeling, to the point that when we did eventually release the AI norms and values documents internally, it felt like the heat had simmered down quite a bit.

Cat, where would you advise people to start?

(Watch for her response at her newsletter site, fightforthehuman!)

When you need to extract values from complex JSON payloads, manual navigation quickly becomes hard to read and maintain. Meziantou.Framework.JsonPath provides a JSONPath implementation for System.Text.Json based on RFC 9535, so you can query JSON documents using concise, standard expressions. Installation Install the package from NuGet: dotnet add package Meziantou.Framework.JsonPath Parse and evaluate a…