Web platform Archives - Microsoft Edge Blog https://blogs.windows.com/msedgedev/tag/web-platform/ Official blog of the Microsoft Edge Web Platform Team Tue, 09 Dec 2025 16:57:51 +0000 en-US hourly 1 https://wordpress.org/?v=6.6.4 https://winblogs.thesourcemediaassets.com/sites/33/2021/06/cropped-browser-icon-logo-32x32.jpg Web platform Archives - Microsoft Edge Blog https://blogs.windows.com/msedgedev/tag/web-platform/ 32 32 Making complex web apps faster https://blogs.windows.com/msedgedev/2025/12/09/making-complex-web-apps-faster/ https://blogs.windows.com/msedgedev/2025/12/09/making-complex-web-apps-faster/#respond Tue, 09 Dec 2025 16:57:51 +0000 https://blogs.windows.com/msedgedev/?p=26139 On the web, speed is everything. The responsiveness of your browser, the time it takes for a web app to appear, and how quickly that app handles user interactions all directly impact your experience as a web user.

At Microsoft, we care deeply about

The post Making complex web apps faster appeared first on Microsoft Edge Blog.

]]>
  • Within the browser itself, by making Edge faster and more responsive.
  • Under the hood, by making the browser engine run complex web apps faster.
  • And finally, by helping web developers build faster web apps.
  • Based on our own experience, we know that complex applications require complex architectures that sometimes rely on multiple windows, iframes, or worker threads. To deal with the slowdowns that these multiple parallel contexts can introduce, we're proposing a new feature for web developers: the Delayed Message Timing API. If you're a web developer, continue reading to learn more about the Delayed Message Timing API proposal, and let us know if it might help you make your own web app faster, or share ways in which the API could be better.

    What causes delays in cross-context messaging?

    Delays can occur when an app exchanges a lot of messages between its various contexts, such as the app's main window, worker threads, or iframes. If those messages get queued and are not processed promptly, delays occur. These delays can degrade the user experience by making the application feel unresponsive. While it's easy to witness the delay, identifying its root cause is challenging with current development tools. Let's review the three types of delays which can occur when exchanging messages between contexts with the postMessage() API, and how the Delayed Message Timing API can help diagnose their root cause.

    Slowdown 1 – The receiving context is busy

    As the following diagram illustrates, the context to which you're sending a message might be processing a long synchronous task, effectively blocking its thread, causing your message to be queued up before it can be processed: Diagram showing two web app contexts (a main document and worker thread). The main document sends a message to the worker thread, but that thread is blocked on a long task and the message gets delayed. To understand if the receiver of the message is busy with other tasks, you need to know how long the message was blocked. To do this, the Delayed Message Timing API introduces the blockedDuration property, which represents the amount of time a message had to wait in the queue before being processed.

    Slowdown 2 – The task queue is congested

    Another possible reason for cross-document messaging slowdowns is when the task queue of a context is overloaded with many short tasks. In a webpage's main thread, this can often happen when the queue is saturated with high-priority tasks such as user interactions, network handling, and other internal system overhead tasks like navigation, loading, and rendering. In a worker, congestion can occur when many messages are posted in a short period of time. In both cases, tasks or messages arrive faster than they can be processed, creating a backlog that delays subsequent messages, including those that might be time sensitive. Although each individual task isn't long, together, they accumulate and cause congestion, which effectively acts like a single long task. Diagram showing two web app contexts (a main document and worker thread). The main document sends many messages to the worker thread, and each takes a little bit of time to process in that thread, leading, over time, to a longer and longer message blocked duration on the worker thread. To help diagnose this situation, the Delayed Message Timing API introduces the taskCount and scriptTaskCount properties, to show how many tasks were blocking the message.

    Slowdown 3 – Serialization and deserialization overhead

    Before crossing the boundaries between contexts, messages must be serialized and then deserialized again when received. These operations occur synchronously on the same threads where the messages are sent and received. Serializing and deserializing messages can therefore introduce noticeable overhead, particularly when sending a lot of data over postMessage(). Diagram showing two web app contexts (a main document and worker thread). The main document sends a message to the worker thread, but because the message contains a lot of data it takes time to serialize and then deserialize, leading to a long blocked duration. While the serialization and deserialization operations are internal to the browser and you can't change them, the Delayed Message Timing API provides the serialization and deserialization properties to accurately measure their duration.

    Using the Delayed Message Timing API

    The API will work with windows, tabs, iframes, or workers, and will cover cross-document messaging, cross-worker/document messaging, channel messaging, and broadcast channels. For a complete round-trip timing analysis, you'll need to correlate the Performance entries that you collect from both the sender and receiver contexts. To learn more, check out the explainer. The following code snippet shows how to use the proposed API:
    // Create a PerformanceObserver instance.
    const observer = new PerformanceObserver((list) => {
      console.log(list.getEntries());
    });
    
    // Start observing "delayed-message" Performance entries.
    observer.observe({type: 'delayed-message', buffered: true});
    And here is an example of the properties available on the corresponding "delayed-message" Performance entry:
    {
        "name": "delayed-message",
        "entryType": "delayed-message",
        "startTime": 154.90000009536743,
        "duration": 169,
        "traceId": 4,
        // The type of message-passing event.
        "messageType": "cross-worker-document",
        // The timestamp for when the message was added to the task queue.
        "sentTime": 155,
        // The timestamps for when the receiving context started and stopped
        // processing the message.
        "processingStart": 274.90000009536743,
        "processingEnd": 324.7000000476837,
        // The time the message spent waiting in the receiver's task queue.
        "blockedDuration": 119.90000009536743,
        // The time needed to serialize and deserialize the message.
        "serialization": 0,
        "deserialization": 0,
        // The number of queued tasks blocking the postMessage event.
        "taskCount": 38,
        // The number of entry-point JavaScript tasks, including those with
        // a duration lower than 5ms.
        "scriptTaskCount": 2,
        // The time needed to run all script.
        "totalScriptDuration": 119,
         // The list of PerformanceScriptTiming instances that contribute to the
         // delay.
        "scripts": [
            {
                "name": "script",
                "entryType": "script",
                "startTime": 154.90000009536743,
                "duration": 119,
                "invoker": "DedicatedWorkerGlobalScope.onmessage",
                "invokerType": "event-listener",
                "windowAttribution": "other",
                "executionStart": 154.90000009536743,
                "forcedStyleAndLayoutDuration": 0,
                "pauseDuration": 0,
                "sourceURL": "...",
                "sourceFunctionName": "runLongTaskOnWorker",
                "sourceCharPosition": 267
            }
        ],
        // The PerformanceMessageScriptInfo instance which provides details
        // about the script that sent the message.
        "invoker": {
            "name": "invoker",
            "sourceURL": "...",
            "sourceFunctionName": "sendMessage",
            "sourceCharPosition": 531,
            "sourceColumnNumber": 14,
            "sourceLineNumber": 13,
            "executionContext": {
                "name": "",
                "type": "window",
                "id": 0
            }
        },
        // The PerformanceMessageScriptInfo instance which provides details 
        // about the script that handled (or is handling) the message.
        "receiver": {
            "name": "receiver",
            "sourceURL": "...",
            "sourceFunctionName": "runLongTaskOnWorker",
            "sourceCharPosition": 267,
            "sourceColumnNumber": 41,
            "sourceLineNumber": 9,
            "executionContext": {
                "name": "",
                "type": "dedicated-worker",
                "id": 1
            }
        }
    }

    Let us know what you think

    The Delayed Message Timing API is in its early stages, and we'd love to hear your feedback about this proposal. There may be additional scenarios where cross-context slowdowns occur in your apps today and sharing your experiences with us will help us design the right API for you. Take a look at our proposal and let us know your feedback by opening a new issue on the MSEdgeExplainers repo.]]>
    https://blogs.windows.com/msedgedev/2025/12/09/making-complex-web-apps-faster/feed/ 0
    The Web Install API is ready for testing https://blogs.windows.com/msedgedev/2025/11/24/the-web-install-api-is-ready-for-testing/ https://blogs.windows.com/msedgedev/2025/11/24/the-web-install-api-is-ready-for-testing/#respond Mon, 24 Nov 2025 16:55:46 +0000 https://blogs.windows.com/msedgedev/?p=26122 We're happy to announce that the Web Install API is now ready for testing on your own site, as an origin trial in Microsoft E

    The post The Web Install API is ready for testing appeared first on Microsoft Edge Blog.

    ]]>
    origin trial in Microsoft Edge. With the Web Install API, your website can request the browser to install other web applications on the user's device, by calling the asynchronous navigator.install() function. This allows you to invoke the browser's built-in web app installation experience from your own user interface and exactly when you need it. This can help you improve the installation experience of your own app or suite of apps but can also be used for app store-like experiences. The Web Install API origin trial is available on Windows, macOS, and Linux. You can learn more about the API by reading our explainer document, checking out demos, or watching the following video: https://www.youtube.com/watch?v=WmFYlO4qln8

    Test the API today by registering to the origin trial

    The Web Install API origin trial is available now in Microsoft Edge starting with version 143 and running until version 148. To participate in the origin trial, and test the API on your live website, register to the origin trial. Here's how:
    1. Go to the WebAppInstallation origin trial page, sign-in with your GitHub account and accept the terms of use. The Web Install origin trial page on the Microsoft Edge origin trial site.
    2. Add your website's domain name to enable the Web Install API origin trial for that domain. The page to enter a domain name to register for the Web Install origin trial, on Microsoft Edge's origin trial site.
    3. Copy the token string: The page showing the token to use for the Web Install origin trial, for the registered domain name.
    4. Add the following meta tag to your website's HTML code:
      <meta http-equiv="origin-trial" content="[paste the token here]">
      You can also send the origin trial token as an HTTP server response instead:
      Origin-Trial: [paste the token here]
    By registering to the origin trial, the users of your site will not need to enable the Web Install API locally. It will be enabled for them by Microsoft Edge automatically. Note that the earliest version of Edge where the origin trial is available is 143, which is, at the time of writing, available as Microsoft Edge Beta. Version 143 will become the next Edge stable release in early December, and the origin trial will continue running until Edge 148.

    Or test the API locally only

    You can also enable the Web Install API on your development device only, for local testing. To do this:
    1. Open a new tab in Microsoft Edge and go to the edge://flags page.
    2. Search for "Web App Installation API".
    3. Change the flag's default value to Enabled and then restart the browser.
    The internal flags page in Microsoft Edge, showing the Web Install flag entry.

    Let us know what you think

    This is a very exciting milestone for the Web Install API. With this origin trial, we're hoping to gather early interest and feedback from the community on the API. The feedback you share with us will allow us to continue evolving the feature to better match your needs and use cases. To provide feedback, please open a new issue on our explainers GitHub repository. We welcome any comment, suggestion, and bug report you encounter while using the API, and we look forward to making web app installation much easier by building the functionality right into the web platform, thanks to your help!]]>
    https://blogs.windows.com/msedgedev/2025/11/24/the-web-install-api-is-ready-for-testing/feed/ 0
    Unlock text editing use cases with highlightsFromPoint and other FromPoint APIs https://blogs.windows.com/msedgedev/2025/09/25/unlock-text-editing-use-cases-with-highlightsfrompoint/ https://blogs.windows.com/msedgedev/2025/09/25/unlock-text-editing-use-cases-with-highlightsfrompoint/#respond Thu, 25 Sep 2025 16:01:19 +0000 https://blogs.windows.com/msedgedev/?p=26050 We're excited to announce the availability of the highlightsFromPoint() method in Microsoft Edge 140, and other Chromium-based browsers, a useful addition to the CSS Custom Highlight API, which makes it possible to f

    The post Unlock text editing use cases with highlightsFromPoint and other FromPoint APIs appeared first on Microsoft Edge Blog.

    ]]>
    highlightsFromPoint() method in Microsoft Edge 140, and other Chromium-based browsers, a useful addition to the CSS Custom Highlight API, which makes it possible to find existing highlights at a given x, y coordinate.

    Drawing highlights in CSS

    The CSS Custom Highlight API allows you to highlight arbitrary ranges of text, without having to add new elements to the DOM. This API works by creating Range objects in JavaScript, registering these ranges using the CSS.highlights registry, and then highlighting the ranges in CSS, by using the ::highlight() pseudo-element: A high-level diagram of the CSS Custom Highlight API, showing two custom highlight objects, each with their own ranges. The highlight objects are registered in the CSS highlights registry, under custom names. And CSS code can then style the ranges by using the ::highlight pseudo-classes corresponding to the custom names. This API is great for dynamic styling of text ranges that don't need to, or can't, exist in the DOM, which is often the case for client-side text editors. The following screenshot shows different types of highlights that were created by using the CSS Custom Highlight API (see the live demo): A paragraph of text with five different types of highlights. Some parts are highlighted in yellow, others have a wavy red underline, others a double blue underline, etc. Some highlights overlap.

    Introducing highlightsFromPoint()

    And today, starting with Edge 140, we're adding one more piece to the puzzle: the CSS.highlights.highlightsFromPoint() method. This new method lets you detect the custom highlights that exist at a given x, y coordinate location on the screen, so that you can alter the appearance of the highlight or display additional UI elements around it. This makes it a lot simpler to implement features like spellcheck, collaborative editing, tooltips, contextual menus, or search. CSS.highlights.highlightsFromPoint() can detect highlights and their corresponding text ranges in the DOM and Shadow DOM without having to write complicated hit-testing code. Now, adding interactive features, with high performance, particularly when dealing with overlapping highlights or shadow DOMs, is much easier. The following screenshot shows a popup which lists three overlapping highlights applied to a text range which the user clicked: A paragraph of text with multiple different highlights, including some which overlap. The user has clicked on an area of the text where highlights exist. A popup is displayed where the user clicked, listing the highlights that were found at this point. To learn more, see HighlightRegistry: highlightsFromPoint() method, at MDN, and see the API in action by using our API demo (source code).

    Other *FromPoint APIs

    The highlightsFromPoint() method might remind you of other similarly named methods: Just like highlightsFromPoint(), these methods also provide DOM information based on x, y coordinates on the screen, and they can be very useful for cases where users interact with the UI by clicking or hovering, and where location-based detection is needed instead of using pre-set event listeners or explicit element references. The *FromPoint APIs are especially useful for text editing scenarios but can also be used to implement drag and drop, simulate actions at specific coordinates (such as in automated testing or games), and enable tools or extensions to identify page elements without prior knowledge of their IDs or selectors. Check out our highlighter demo (and source code) to see how you can use the caretPositionFromPoint and highlightsFromPoint together to let users create and delete different highlights in text, without needing to create extra DOM elements. Screenshot of the highlighter demo. It shows a toolbar on the side, with different types of highlights to choose from. It also shows a text area with multiple paragraphs. Various ranges of the text in the text area have been highlighted in different styles.

    Let us know what you think

    We'd love to hear your feedback about the new CSS.highlights.highlightsFromPoint() API, such as the use cases it allows you to implement, the ideas you have for future improvements, or the problems you might be running into. For feedback about the API, please file an issue in the CSS Working Group repository. If your feedback is about a bug in Microsoft Edge instead, please send feedback to our team from the browser directly: go to Settings and more (...) > Help and feedback > Send feedback.]]>
    https://blogs.windows.com/msedgedev/2025/09/25/unlock-text-editing-use-cases-with-highlightsfrompoint/feed/ 0
    Calling for Interop 2026 proposals https://blogs.windows.com/msedgedev/2025/09/04/calling-for-interop-2026-proposals/ https://blogs.windows.com/msedgedev/2025/09/04/calling-for-interop-2026-proposals/#respond Thu, 04 Sep 2025 16:26:26 +0000 https://blogs.windows.com/msedgedev/?p=26048 The Interop 2026 call for proposals is now open, submit your ideas now!

    We're very proud to have been part of Calling for Interop 2026 proposals appeared first on Microsoft Edge Blog.

    ]]>
    The Interop 2026 call for proposals is now open, submit your ideas now! We're very proud to have been part of the Interop project for the past 5 years, and it's amazing to see the collective enthusiasm of our industry for pushing the limits of what's possible for developers to do on the web. Critical building blocks like grid, subgrid, flexbox, container queries, popover, the :has() selector, and declarative shadow DOM would just not be in their current state today if it wasn't for the Interop project. In fact, just this year, View Transitions, URLPattern, and the @scope rule are on track to becoming interoperable across the web, making it possible for web developers to truly rely on these features in a simple and performant way. Interoperability is essential for ensuring the web remains a unified platform where developers can build great products and users have the freedom to achieve their goals using the browser of their choice. But interoperability is never done. The web needs to constantly evolve to meet the needs of its users and the devices they use. We need to continue adding new standards-based capabilities to the web all the time, and ensure they're interoperable quickly, down to the tiniest details. That's why the Interop project has been running for the past 5 years, and that's why we're already planning for the next iteration of the project. Starting today, you can now send your ideas for Interop 2026! Help us choose which web platform features to improve next year by sharing what matters most to you. Review the submission guidelines and submit your proposal now. The submission period will remain open through September 24, 2025. You can also take a look at the selection process to understand how and when we'll review the proposals, and what the next steps are.]]> https://blogs.windows.com/msedgedev/2025/09/04/calling-for-interop-2026-proposals/feed/ 0
    Removing -ms-high-contrast and embracing standards-based forced colors in Microsoft Edge https://blogs.windows.com/msedgedev/2025/06/30/removing-ms-high-contrast-and-embracing-standards-based-forced-colors-in-microsoft-edge/ https://blogs.windows.com/msedgedev/2025/06/30/removing-ms-high-contrast-and-embracing-standards-based-forced-colors-in-microsoft-edge/#respond Mon, 30 Jun 2025 16:00:24 +0000 https://blogs.windows.com/msedgedev/?p=25955 The Edge team is excited to announce that the non-standard -ms-high-contrast media feature and -ms-high-contrast-adjust property are now completely removed from Edge, starting with version 138.

    The road to removing these CS

    The post Removing -ms-high-contrast and embracing standards-based forced colors in Microsoft Edge appeared first on Microsoft Edge Blog.

    ]]>
    -ms-high-contrast media feature and -ms-high-contrast-adjust property are now completely removed from Edge, starting with version 138. The road to removing these CSS features began just over a year ago with the introduction of the standards-based forced colors feature. When we shipped this new standard in Chromium-based Edge for the first time, we also wanted websites that still used the -ms-high-contrast media query and the -ms-high-contrast-adjust property from Internet Explorer and EdgeHTML to have time to migrate. With the deprecation period now complete, we are looking forward to seeing more web developers move to the new forced colors feature, which is currently supported in Chromium-based browsers and Firefox. With this change, the browsing experience of people using Windows contrast theme will be consistent between Edge, other Chromium-based browsers, and Firefox, creating a more interoperable experience between browsers that support forced colors mode. If you believe your site could be impacted by the removal of the non-standard -ms-high-contrast properties, check out our initial deprecation announcement to learn more about testing your site with contrast themes enabled, and using the new standard forced colors mode properties.

    Let us know how things go

    If you encounter any issues as a result of the deprecation, please send us feedback in either of these two ways:
    • To send us feedback directly from Microsoft Edge: go to Settings and more (...) > Help and feedback > Send feedback.
    • Or, to report a problem directly with the Chromium implementation of the new forced colors mode standard, create a new issue using Chromium's bug tracker.
    ]]>
    https://blogs.windows.com/msedgedev/2025/06/30/removing-ms-high-contrast-and-embracing-standards-based-forced-colors-in-microsoft-edge/feed/ 0
    The Edge 2025 web platform top developer needs dashboard https://blogs.windows.com/msedgedev/2025/06/26/the-edge-2025-web-platform-top-developer-needs-dashboard/ https://blogs.windows.com/msedgedev/2025/06/26/the-edge-2025-web-platform-top-developer-needs-dashboard/#respond Thu, 26 Jun 2025 15:58:08 +0000 https://blogs.windows.com/msedgedev/?p=25950 For the fifth year in a row, together with our partners at Igalia, Google, Mozilla, and Apple, we're working hard on improving the consistency of some of the major features which web developers need the most. Indeed, the The Edge 2025 web platform top developer needs dashboard appeared first on Microsoft Edge Blog.

    ]]>
    Interop 2025 project is now operating at full speed and already bearing fruit: the overall interop score has now reached 50%, up from its starting 28% score at the beginning of the year. The Interop score chart from the Interop 2025 dashboard. It shows 5 lines going up and to the right, signifying that the 4 tested browsers are getting more interoperable across the selected focus areas, and that the overall interop score is also improving. Interop is the most effective way we have to collectively catch up on implementation differences and bugs. The project has a good track record of bringing implementations into alignment for the areas that are selected. However, there's more that web developers need. On the Microsoft Edge team, we're always listening to developers, whether through surveys, bug reports, or direct collaborations. Through this listening, we know that developers have been asking for more than what the Interop project's consensus process selects. We want to help raise the visibility of these needs and track progress from browser vendors to implement them. To that end, we're announcing our updated Edge 2025 web platform top developer needs dashboard. The Edge top developer needs 2025 dashboard webpage, showing the title, intro paragraph, and main chart, which shows the WPT scores for the tracked features, across all browsers. Like last year, our dashboard tracks compatibility and test success (as measured by the WPT project) of important features like:
    • Scroll-driven animations, which enable smooth, multithreaded animations in response to user scrolling.
    • Cross-document view transitions, which smoothly animates between multiple pages of a site.
    • Render blocking, which delays rendering until certain scripts or stylesheets have loaded; an important improvement for delivering smooth page transitions.
    • Container queries (including style queries), which apply styles to elements based on the dimensions, or styles, of a container element.
    • Fetch upload streaming, which sends ReadableStream objects to the server without punishing device memory.
    • The ::marker pseudo-element, which styles list item bullets or numbers.
    • Speculation rules, which hint the browser to proactively download pages in the background, providing near-instant page loads for a large fraction of sessions.
    • And more on the dashboard.
    If you have feedback or think there are items we've missed, please let us know by leaving a comment about the dashboard. The Edge web platform team is committed to transparency and openness. We hope that by providing a fuller picture of what we're hearing we can play a positive role in improving the platform for everyone.]]>
    https://blogs.windows.com/msedgedev/2025/06/26/the-edge-2025-web-platform-top-developer-needs-dashboard/feed/ 0
    Bring your PWA closer to users with App Actions on Windows https://blogs.windows.com/msedgedev/2025/05/30/bring-your-pwa-closer-to-users-with-app-actions-on-windows/ https://blogs.windows.com/msedgedev/2025/05/30/bring-your-pwa-closer-to-users-with-app-actions-on-windows/#respond Fri, 30 May 2025 16:01:13 +0000 https://blogs.windows.com/msedgedev/?p=25811 We're excited to announce that App Actions on Windows are now available for Progressive Web Apps (PWAs). Starting with Edge version 137, you can now publish your PWA to the Micro

    The post Bring your PWA closer to users with App Actions on Windows appeared first on Microsoft Edge Blog.

    ]]>
    App Actions on Windows are now available for Progressive Web Apps (PWAs). Starting with Edge version 137, you can now publish your PWA to the Microsoft Store to enable App Actions on Windows.

    Integrating your app smoothly with user workflows

    Many everyday workflows—like editing text, processing images, or managing files—involve switching between multiple apps, creating friction and lost focus. App Actions reduce that overhead by letting users invoke high-value features of your app directly from within their current context. For example, Goodnotes, a popular note-taking app that's built as a PWA, has enabled App Actions, so that users can select text in an article, and send it directly to the app as a quick note without manually switching windows. App Actions help users get more done—while driving engagement and discovery for your app.

    Enable App Actions in your Microsoft Store PWA

    To start using the App Actions framework in your Store PWA now, check out the documentation at Enable App Actions on Windows for a PWA. In short, you'll need to:
    1. Define an Action manifest. The manifest describes each action in a simple JSON file.
    2. Setup a custom protocol handler. So that the App Actions runtime can launch your PWA through a protocol URI.
    3. Setup your app as a share target. So that the App Actions runtime can pass input data to your PWA.
    4. Package your app for Microsoft Store with PWABuilder.
    That's it. Optionally, you can also define a PWA launch handler to define exactly how your PWA gets launched by the framework and test your actions by using the App Actions Testing Playground. We can't wait to see the creative ways you'll use App Actions to delight your users!]]>
    https://blogs.windows.com/msedgedev/2025/05/30/bring-your-pwa-closer-to-users-with-app-actions-on-windows/feed/ 0
    Simplified access to AI in Microsoft Edge: Introducing the Prompt and Writing Assistance APIs https://blogs.windows.com/msedgedev/2025/05/19/introducing-the-prompt-and-writing-assistance-apis/ https://blogs.windows.com/msedgedev/2025/05/19/introducing-the-prompt-and-writing-assistance-apis/#respond Mon, 19 May 2025 16:00:18 +0000 https://blogs.windows.com/msedgedev/?p=25798 Local AI models are a great way to bring AI capabilities to your web application with increased privacy, network independence, and, most importantly, reduced costs relative to cloud-based services. But hosting local AI models on the web, via existing

    The post Simplified access to AI in Microsoft Edge: Introducing the Prompt and Writing Assistance APIs appeared first on Microsoft Edge Blog.

    ]]>
    Prompt API and Writing Assistance APIs — now available as developer previews in Edge Canary and Dev channels — give you access to a powerful small language model, Phi-4-mini, that is built into the Edge browser. Whether you're trying out prompt engineering, summarizing and modifying content, or generating text, these APIs are designed to help you bring AI to your web code with a few lines of JavaScript. https://www.youtube.com/watch?v=FlXj9ZAtoAY

    Introducing the Prompt API in Edge 138

    We're excited to announce the availability of the Prompt API as a developer preview in Edge Canary and Dev channels, starting with Microsoft Edge 138. The Prompt API provides sites and extensions access to a built-in small language model via a simple API for prompt engineering. In its simplest form, prompting the built-in language model simply requires the following lines of client-side JavaScript code:
    const session = await LanguageModel.create();
    
    // Prompt the model and wait for the result
    const result = await session.prompt("Score this feedback into a rating between 0-5: “The food was delicious, service was excellent. Would recommend!”");
    The Prompt API can be used to support a wide variety of use cases, ranging from text analysis and generation, to data classification and sentiment analysis, and can easily be integrated into your existing application code. We have also added the ability to constrain model outputs by adding structured outputs to the Prompt API. This makes it easier and more predictable to work with language models programmatically and minimizes the variance of API results across different models and browsers.
    const schema = {
      type: "object",
      required: ["rating"],
      properties: {
        rating: {
          type: "number",
          minimum: 0,
          maximum: 5,
        },
      },
    };
    
    // Prompt the model and wait for the JSON response to come back.
    const result = await session.prompt("Score this feedback into a rating between 0-5: " +
      "The food was delicious, service was excellent. Would recommend!",
      { responseConstraint: schema }
    );
    
    const { rating } = JSON.parse(result);

    Introducing the Writing Assistance APIs in Edge 138

    We're also excited to announce the availability of the Summarizer, Writer, and Rewriter APIs as developer previews in Canary and Dev channels, starting with Microsoft Edge 138. These Writing Assistance APIs provide sites and extensions the ability to modify and generate text via simple interfaces that are scoped to the specific writing assistance task they serve. The Summarizer, Writer, and Rewriter APIs also use the built-in Phi-4-mini model in Edge but, unlike the Prompt API, are optimized to serve summarization, writing, and rewriting use-cases. A few lines of client-side JavaScript code can now help you generate or modify text in your web application:
    // Summarize an article with added context and desired style and length.
    const summarizer = await Summarizer.create({
      sharedContext: "An article from the Daily Economic News magazine",
      type: "tl;dr",
      length: "short"
    });
    const summary = await summarizer.summarize(articleEl.textContent, {
      context: "This article was written 2024-08-07 and is in the World Markets section."
    });
    
    // Write a blurb based on the provided prompt and tone.
    const writer = await Writer.create({
      tone: "formal"
    });
    const result = await writer.write(
      "A draft for an inquiry to my bank about how to enable wire transfers on my account"
    );
    
    // Rewrite a user review to remove problematic language while preserving intent.
    const rewriter = await Rewriter.create({
      sharedContext: "A user review for shoes from Contoso Inc."
    });
    const result = await rewriter.rewrite(reviewEl.textContent, {
      context: "Refine user feedback to remove harsh, profane, or negative language while preserving the core issue, ensuring clarity and professionalism."
    });

    Phi-4-mini

    In Microsoft Edge, the Prompt and Writing Assistance APIs leverage a local (i.e. no cloud calls, no per-token costs) version of Phi-4-mini. Phi-4-mini is a small language model that excels at text-based tasks, providing high accuracy in a compact form. The model is made available to devices that meet certain hardware requirements, and downloaded the first time a website or extension starts using any of the APIs in Microsoft Edge. Edge also handles the complexities of caching, optimizing, and updating the model.

    Try it out and let us know

    We can't wait to see how you'll use the Prompt and Writing Assistance APIs to enhance your web applications. These APIs are built to simplify AI integration for web developers – and we want to understand your use-cases and challenges to further improve these APIs and optimize models. It is optimized for general reasoning and instruction-following, and is built on high-quality synthetic data with fine-tuning, making it well-suited for real-time, energy-efficient AI experiences for the web. To get started, check out the Prompt API technical documentation and Writing Assistance APIs technical documentation, explore the playground demo and its source code, and let us know your thoughts by commenting on the Prompt API or Writing Assistance APIs feedback issues on GitHub.]]>
    https://blogs.windows.com/msedgedev/2025/05/19/introducing-the-prompt-and-writing-assistance-apis/feed/ 0
    Creating a more accessible web with Aria Notify https://blogs.windows.com/msedgedev/2025/05/05/creating-a-more-accessible-web-with-aria-notify/ https://blogs.windows.com/msedgedev/2025/05/05/creating-a-more-accessible-web-with-aria-notify/#respond Mon, 05 May 2025 15:59:58 +0000 https://blogs.windows.com/msedgedev/?p=25790 We're excited to announce the availability, as a developer and origin trial, of ARIA Notify, a new API that's designed to make web content

    The post Creating a more accessible web with Aria Notify appeared first on Microsoft Edge Blog.

    ]]>
    ARIA Notify, a new API that's designed to make web content changes more accessible to all users. You can try ARIA Notify today as an Origin Trial starting with Microsoft Edge 136, or locally by enabling the --enable-blink-features=AriaNotify feature flag. ARIA Notify is designed to address scenarios where a visual change that's not tied to a DOM change and not accessible to assistive technology users, happens in the page. Examples include changing the format of text in a document, or when a person joins a video conference call. Developers have come to rely on ARIA live regions as a limited workaround. ARIA Notify is an imperative notification API that's designed to replace the usage of ARIA live regions, and overcome its limitations, in these scenarios.

    The problems with ARIA live regions

    For individuals who are blind or have low vision, identifying non-user-initiated changes in the content of a web page can be very challenging. ARIA live regions are the only mechanism available today that communicates dynamic content changes to users of assistive technology. However, ARIA live regions are tightly coupled with DOM elements because they're built around the assumption that visual changes happen in sections or UI widgets of a web page. But many important changes can happen on a web page without the DOM of the page being modified. Consider these two examples:
    • The user is interacting with a text editing area. The user highlights a word and then presses the Ctrl+B shortcut to make it bold. In this scenario, no UI elements were used by the user, and the DOM didn't necessarily change. The user should still hear confirmation that the action was successful.
    • The user is composing an email and presses the Send button. In normal circumstances, the message is sent, and a focus change occurs, which confirms that the action was successful. But, if the action is delayed or later fails, the user should still hear a notification about the delay or failure.
    In these scenarios, developers tend to resort to using workarounds where they mimic dynamically changing content using DOM nodes that are placed offscreen. Unfortunately, this can lead to unexpected side effects for end users, like making the offscreen content accidentally discoverable by screen reader users with their virtual cursor, or not accessible if a modal dialog is opened and the offscreen content is not placed within it. In addition, using ARIA live regions in these scenarios also comes with timing issues that developers must deal with, such as having to wait for an undetermined amount of delay between creating a region and adding the content into it. The ARIA Notify API addresses these issues.

    Introducing the ARIA Notify API

    ARIA Notify is an ergonomic and predictable way to tell assistive technologies (ATs), such as screen readers, exactly what to announce to users and when. In its simplest form, developers can call the ariaNotify() method with the text to be announced to the user. The method is available both on the document object and on DOM nodes.
    // Dispatch a message associated with the document.
    document.ariaNotify("John Doe is connected");
     
    // Dispatch a message associated with an element.
    document.querySelector("#text-editor").ariaNotify("Selected text is bold");
    When called on the document object, the language of the provided notification string is assumed to match that of the document. When called on an element, the element's nearest ancestor's lang attribute is used to infer the language. The ARIA Notify API also lets developers hint to an AT about the importance of notifications to ensure that important messages that the user should be aware of are announced with urgency. To do this, developers can use the priority option. This option indicates how the AT should rank the notification with respect to other, pending, notifications:
    • high - The AT should add the notification to the end of any other pending high priority notifications but before all normal priority pending notifications.
    • normal (default) - The AT should add the notification to the end of all pending notifications.
    Here's an example showing how to set priorities:
    // Dispatch a normal priority notification about a background task status update.
    document.ariaNotify("Background task completed", { "priority":"normal" });
     
    // Dispatch a high priority notification that data may be lost.
    document.ariaNotify("Unable to save changes, connection lost", { "priority":"high" });
    In this example, assuming that the normal priority notification hasn't already been announced, the high priority notification is guaranteed to be announced first, followed by the normal priority notification.

    Try ARIA Notify today and let us know what you think

    We're excited that ARIA Notify is now ready to be tested by developers, either locally, or as part of a Microsoft Edge Origin Trial to gather developer feedback on the API. If you want to test ARIA Notify in Microsoft Edge on your own device only, start Edge from the command line and use the --enable-blink-features=AriaNotify argument to enable the feature. For example, if you're using Microsoft Edge Canary on Windows, run the following command in a command prompt: "C:\Users\<username>\AppData\Local\Microsoft\Edge SxS\Application\msedge.exe" --enable-blink-features=AriaNotify To test your entire website with users instead, register your website for an Edge Origin Trial:
    • Go to AriaNotify API on the Microsoft Edge Origin Trial site.
    • Sign-in to the site with your GitHub credentials.
    • And then register for the Origin Trial.
    To learn more about the API, check out the ARIA Notify explainer. And, if you're interested in using the API in other browsers, checkout out the ariaNotify-polyfill GitHub repository. We'd love to hear your feedback about the API, to ensure that our solution meets your needs. Let us know your thoughts by opening a new issue on our GitHub repository.]]>
    https://blogs.windows.com/msedgedev/2025/05/05/creating-a-more-accessible-web-with-aria-notify/feed/ 0
    Contextual logging with console.context() https://blogs.windows.com/msedgedev/2025/04/22/contextual-logging-with-console-context/ https://blogs.windows.com/msedgedev/2025/04/22/contextual-logging-with-console-context/#respond Tue, 22 Apr 2025 16:01:54 +0000 https://blogs.windows.com/msedgedev/?p=25774 If you work on a large enough code base involving multiple teams at your organization, you probably have to deal with large amounts of logs when inspecting your webapp.

    This is an area that we're interested in improving, and are Contextual logging with console.context() appeared first on Microsoft Edge Blog.

    ]]>
    proposing a new feature, based on the console.context() method, to enable helpful contextual logging in DevTools. Logging can be a very helpful way to debug problems, and we know that many web developers like the simplicity of logging, over the more involved process of breakpoint debugging. However, having to sort through hundreds of console log messages can quickly become difficult. It's hard to identify which log comes from which part of the application, and it's hard to filter logs. The Console tool in Edge DevTools, showing a long list of errors, warnings, and messages. We're proposing a way to log to the browser console in a contextual way, and we'd love your feedback about the proposal. To read the full proposal, see our explainer: DevTools contextual logging with console.context(), and provide feedback about it by opening a new issue on the repo.

    Enhancing console.context()

    The context() method of the console namespace is a method that already exists in Chromium-based browsers. This method accepts a context name and returns an object that implements the same interface as the console namespace:
    const myLogger = console.context("name-of-my-context");
    myLogger.log("This is a log message from my context");
    myLogger.warn("This is a warning message from my context");
    This allows you to create different loggers for the different parts of your application. Each log that's emitted by one of these loggers belongs to a context, and you can later filter by context in the Console tool in Edge. We think that console.context() is a great solution to the challenges of having to deal with many log messages, but we want to go further and address its limitations:
    • We want to help standardize the method so that other browsers can also implement it. See the specification discussion on the WHATWG repository.
    • We want to make contexts more visually recognizable.
    • And, we want to make it easier to filter messages by contexts.

    Making contexts visually different

    The first improvement we're proposing is to make each context truly unique and quickly recognizable by giving it a color. Currently, contextual loggers produce messages that look just like regular logs: The Console tool in Edge, showing that a contextual log created from console.context() looks like any other log. We want to improve this as follows:
    const myColoredLogger = console.context("storage", { color: "lemonchiffon" });
    myColoredLogger.log("This is a log from my contextual logger");
    The above code would display the log message in the Console tool, preceded by a badge that shows the context name and color, so that it's easy to quickly recognize where the log comes from: Mockup showing how the proposed contextual logs would look like. The log message displays a badge at the beginning of the line, that's colored, and that has the name of the context in it. We'd love to hear your feedback on this proposal as we're considering multiple alternatives such as:
    • Using %c formatting in the context name, instead of introducing a second parameter for the color. For example: const myColoredLogger = console.context("%cstorage", “background:red;color:white”);
    • Not requiring developers to define colors and letting DevTools do it. This would make it easier to use the context() method and DevTools would generate accessible background and text color combos for you.
    • Using the color as the outline of the badge rather than its fill color, which would avoid text contrast accessibility issues, but might be harder to quickly visually differentiate.

    Making it easy to filter contextual logs

    The second improvement we're proposing is to make it much easier to filter the messages that originate from a given context only. Currently, to filter the logs from a console context, you must enter context: <name of the context> in the filter of the Console tool. We think we can improve this. We're proposing to list the contexts that were created by an app in the Console tool's sidebar: The Console tool in Edge, showing the filtering sidebar. This mockup shows the contexts listed in the sidebar. In the above example, the app created two contexts: App and Storage. Clicking on any of these context names in the sidebar would show only the messages that belong to that context. In addition, it would be possible to expand a context and review the number of errors, warning, info, and debug logs in that context, and display only those messages.

    Let us know what you think

    Does the console.context() method seem useful? Do the proposed improvements match your use cases? Are there any other or different changes you would like to make? If you have any questions, comments, or suggestions, please let us know by opening a new issue on the MSEdgeExplainers repo.]]>
    https://blogs.windows.com/msedgedev/2025/04/22/contextual-logging-with-console-context/feed/ 0