Category Archives: Announcements

Auto Added by WPeMatico

Building a great touchpad experience for the web with Pointer Events

Most web pages don’t fit on one screen, so good scrolling behavior is an integral part of a good web browser. It’s so crucial to the user experience that we have spent a lot of time optimizing page scrolling, with great results.
Since launching Microsoft Edge, we’ve optimized most scrolling experiences — scrolling via touchscreens, page and content scrollbars. One particular focus in previous releases has been improving touchpads, specifically precision touchpads (PTPs), to provide a smooth, fluid, intuitive experience by default.
In this post, we’re introducing a new optimization coming in EdgeHTML 17 to allow developers to customize scrolling behaviors and gestures with Precision Touch Pads, without impacting scrolling performance: PTP Pointer Events.
Background
Precision touchpads are high-end touchpads that ship in Surface devices (Surface Pro 2 and later) and modern Windows 10 devices from our OEM partners. Windows 10 takes advantage of this hardware to enable system-wide gestures and better, more responsive scrolling than what was possible with older technology.
Microsoft Edge also utilizes PTPs to enable back/forward swipe and to enhance users’ scrolling experience via off-thread (aka independent) scrolling. Since PTP input is processed differently by the input stack in Windows 10, we wanted to ensure that we took advantage of this and that we gave users a scrolling experience that felt as natural as their experience with touchscreens everywhere on the web.
However, the web has traditionally had a bit of a design flaw when it comes to scrolling, in the form of scroll jank — that ‘glitchy’ feeling that the page is stuck, and not keeping up with your finger while you’re scrolling.
Often, scroll jank is caused by mousewheel or Touch Event listeners on the page (these are often used for tracking user interactions or for implementing custom scrolling experiences):

// Examples of event listeners that can negatively affect scrolling performance
document.addEventListener("wheel", handler);
document.addEventListener("touchstart", handler);

If one of these listeners is going to modify the default scrolling behavior of the browser, the browser has to cancel its optimized default scroll altogether (accomplished by web developers calling preventDefault() within handlers). Since browsers don’t always know if the listener is going to cancel the scroll, however, they always wait until the listener code executes before proceeding with the scroll, a delay which manifests itself as scroll jank:
An example page showing scroll jank due to a mousewheel handler with a 200ms duration.
Browsers identified this issue and shipped passive event listeners as a mitigation (available in Chrome 51+ and EdgeHTML 16+) to help reduce its scope:
The same example with smooth scrolling thanks to passive event listeners
Intersection Observers also help get around this issue by providing web developers with a mechanism to track user interactions with the page (to trigger lazy loading of infinite scrollers, for example) without affecting scrolling performance. These two approaches, however, still do not solve the cases where active event listeners are necessary, and require developers to be aware of the issues explained above and to change their sites in order for users to see improvements.
Given that we wanted to enable the best scrolling experience with PTP on as many sites as possible while minimizing developer work, we made the decision to not fire mousewheel events in response to PTP gestures (such as two finger pans). While this greatly reduced scroll jank and gave users a scrolling experience akin to the one they get on touchscreens, the lack of mousewheel events being fired unfortunately also meant that users were unable to zoom on sites such as Bing Maps and pan on sites that use custom scrolling controls (both of which expect mousewheel events coming from touchpads in order to operate).
Developers on our public issue tracker have made it clear that this has been a top pain point, however, the Microsoft Edge team wanted to ensure that the solution built to address these broken experiences not only fixed them, but also preserved the functional and performance benefits accrued by not firing mousewheel events.
PTP Pointer Events
As of EdgeHTML 17, Microsoft Edge will fire Pointer Events with a pointerType of “touch” in response to PTP gestures. While this is a departure from the mousewheel events of the past, we believe that the advantages to this approach more than justify the departure:
No additional overhead for modern websites
If your website already supports Pointer Events and touch, there is no additional work you need to do to take advantage of PTPs in Microsoft Edge; your site will just work!
If you have not yet implemented Pointer Event support, we strongly recommend you check out the MDN documentation for Pointer Events to prepare your site for the modern web. Pointer Events are available on Internet Explorer 11, Microsoft Edge, and Google Chrome and are in development in Firefox.
Enhanced scrolling performance
Scrolling with PTPs in Microsoft Edge will never cause scroll jank since Pointer Event handlers (unlike mousewheel and Touch Event handlers) are designed so that they cannot block scrolling.
With these new changes in Microsoft Edge, you can be certain that you are getting the best possible scrolling experience on PTP-enabled devices thanks to Pointer Events.
Improved Gesture Recognition/Site Functionality
Since PTP Pointer Events emulate touch Pointer Events, PTP gestures such as pinch to zoom and two finger panning will light up on sites that already support touch Pointer Events. This will allow developers to build near-native gesture experiences on the web, complete with the smooth animation and inertia curves that users have come to expect from interacting with pages via touch.
Using PTP Pointer Events
Using PTP Pointer Events on your site is as simple as registering for Pointer Events and using the touch-action CSS property to control how touches are handled by the browser:
In HTML, add the touch-action CSS property to your target element to prevent the browser from executing its default touch behavior in response to gestures (in Microsoft Edge, for example, this will prevent two finger swipes from triggering back/forward swipe behavior):

<canvas height=400 width=400 id="canvas" style="touch-action: none;"></canvas>

In JavaScript, attach a Pointer Event listener to your target element. You can determine the type of pointer that caused the handler to be invoked using the pointerType property of the event object passed into the event listener callback:

document.getElementById(‘canvas’).addEventListener(‘pointermove’, function(event) {
console.log(‘pointermove!’);
});

More detailed information on Pointer Events can be found on MDN here.
Once you have added Pointer Event support to your site, the only step that remains is understanding how Microsoft Edge exposes PTP gestures to sites as Pointer Events. Note that for both of the gestures below, the Pointer Events generated in EdgeHTML will be sent to the element that is directly under the cursor when the PTP gesture begins.
Two Finger Panning
The two finger PTP panning gesture is converted within EdgeHTML to a single contact gesture (identical to a single-fingered touch pan gesture) and is exposed to sites as such. The gesture originates at the cursor location and any movement of the fingers on the touchpad is translated to a scaled delta which results in a pan action. The CSS touch-action property can be used to control the way that a specific region can be manipulated by the user.
Zooming
The pinch to zoom PTP gesture is converted within EdgeHTML to a gesture that originates at the cursor location. Two contacts are placed at a scaled distance away from the cursor location and any movement of the fingers on the touchpad is translated into scaled deltas which results in a zoom action.

Rotation
PTP Pointer Events in Microsoft Edge introduce support for two-finger Rotation gestures for the first time, due to the fact that raw pointer data is exposed directly from the touchpad in all cases other than panning (where the two contacts on the touchpad are combined into one). Existing sites with Pointer Event handlers for touch that support rotation will light up with Precision Touchpads in Microsoft Edge as well.
What’s next
You can try out PTP Pointer Events in Microsoft Edge starting with our next Windows Insider release on any site that currently supports Pointer Events for touch gestures, including Bing Maps or Google Maps, on any device with a Precision Touchpad. The broader Windows 10 community will see PTP Pointer Events when EdgeHTML 17 ships with the next major release of Windows 10.
We are excited to enable jank-free and near-native touchpad experiences across the web using Pointer Events, and look forward to feedback on this feature from developers and end users alike! You can share any bugs you encounter in testing via Microsoft Edge Platform Issues or the Feedback Hub app on Windows 10, or give your feedback directly @MSEdgeDev on Twitter or in the comments below.
Try it out and let us know what you think!
— Scott Low

Introducing the Web Media Extension Package with OGG Vorbis and Theora support for Microsoft Edge

We’ve heard requests from many of our customers to support additional open-source formats in order to access a broader set of content on the web. To address this, ,we recently added support for the WebM container format and the VP9 and Opus codecs on supported hardware.
Today, we’re excited to announce a new mechanism which will allow our customers to add more formats on demand and increase our agility to add new formats in the future: Media Extensions. Alongside this mechanism, we’re releasing the Web Media Extensions package to the Microsoft Store as a free Media Extension for Microsoft Edge.
Media Extensions
Media on the web has been evolving at a furious rate for the last few years. Adaptive video streaming is now common, providing a simpler mechanism for professional-quality video under changing network and device conditions; HTML5 Premium Media provides the tools for interoperable, plugin-free protected media; plugin-free video and audio conferencing is now routine with tools like WebRTC and ORTC.
We’re proud to be at the leading edge of these features, providing a modern set of capabilities with more efficient and higher quality video in Microsoft Edge. At the same time, we’re always looking to make sure Microsoft Edge meets the needs of our customers and web developers alike, and to provide a seamless playback experience on the web.  The rapid growth in media capabilities has naturally resulted in a need to support more media formats in web browsers.
Media Extensions are Media Foundation components designed to extend the core Windows platform and enable Windows apps including Microsoft Edge to support an ever-increasing range of formats. Media Extensions, much like browser extensions, allow customers to extend their device beyond the core experience shipped as part of Windows 10. It also allows the developers of media technologies to update and enhance media components independently of the Windows 10 release schedule. This allows us to work with the community to deliver high quality, interoperable codecs to Edge customers quickly and reliably.
The Web Media Extensions Package
The Web Media Extensions package adds support for the open source OGG container and the Theora and Vorbis codecs, and it expands support for WebM VP9 to work with Theora in simple video elements.  Our support for these formats is based on proven implementations from the well-known FFmpeg codecs using the FFmpeg Interop library. We expect this set of formats to be useful for enthusiasts and customers with specific format needs and we’re excited to bring support for these FFmpeg formats to Microsoft Edge!
Our initial release of the Web Media Extension package is focused on supporting these developers and customers who know they need support for these formats – the seekers and enthusiasts on the web. In the spirit of flighting, this will allow us to learn and improve based on your feedback before we expand support to the broader range of Edge customers on the market today. Long-term, we expect to expand distribution of the Web Media Extension package to all Windows 10 devices so that these formats become a trusted and reliable part of the web platform available to developers.
Getting started
Developers and customers can get started with these new formats in Microsoft Edge by simply installing the Web Media Extension Package from the Microsoft Store. You can also find the package under the Microsoft Edge Extensions collection in the store. This package extends the base media platform in Windows, so the formats will be available to Windows apps and Microsoft Edge with no further action from the user.
We encourage you to install the extension and try it out today! Going forward, we intend to expand distribution, release more formats as Extensions and work with third parties on new formats for Microsoft Edge – your usage will help validate this approach and help us identify potential issues as we evaluate opportunities to provide these capabilities to our customers.
We’re passionate about providing a high-quality, interoperable media experience in Microsoft Edge. This extension package is a first step forward broadening Microsoft Edge’s playback capabilities while providing new mechanisms for us to deliver expanded support in response to the diverse needs of customers, devices, and different browsing contexts. We look forward to hearing your feedback as we work with the community to move our media platform forward!
— David Mebane, Senior Program Manager, Windows Media Platform— Jerry Smith, Senior Program Manager, Microsoft Edge

Breaking on DOM Mutations in the Microsoft Edge DevTools

Editor’s note: This continues the series we began last week, highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
As the web platform evolves, the line between web and application developers continues to blur. It’s common now for a web site to be more like a web app, with complex, single-page user interfaces built up by a combination of libraries and custom JavaScript code. This in turn has led to a web platform that requires more sophisticated tools to efficiently debug.
As we rely more and more on JavaScript to build up the DOM, and rely on tools that interact with and abstract away from us the nuances of DOMs across browsers, we lose the ability to easily know what caused a change to an interface node, especially if that change is unexpected. In EdgeHTML 16 (available with the Windows 10 Fall Creators Update), we’ve introduced the ability to break on mutations caused by any of the 450+ DOM APIs in the EdgeHTML platform and jump directly to the script that triggered the change.
For those who use Chrome DevTools, this will be a familiar and welcome addition to Edge debugging. It was our goal to implement and advance on a similar experience to make jumping between the two tools as seamless as possible. Read on for the changes you can expect in the Fall Creators Update (and can preview now via Windows Insider builds).
Breakpoint types
There are three breakpoint types:
Subtree modifications: when a node is added or removed from the subtree of the element on which the breakpoint is set
Node removal: when the node the breakpoint is set on is removed from the DOM tree
Attribute modifications: when an attribute of the node on which the breakpoint is set is modified
Setting and managing breakpoints
To set a breakpoint, right-click on a node in the DOM tree in the Elements tool. Under the DOM breakpoints item, you’ll see options to set and unset the supported breakpoint types.
Add new breakpoints by right-clicking a node in the DOM tree and selecting “DOM breakpoints.”
When you add a breakpoint, a red breakpoint indicator appears next to the node in the DOM tree. The breakpoint is also listed in the DOM breakpoints pane which exists in both the Elements and Debugger tools. You can disable and delete breakpoints by using the mouse to click the checkbox and delete icons, respectively. You can also right-click, or use the keyboard, on a breakpoint to invoke a context menu to apply the same actions:
Disable or delete breakpoints in the new DOM Breakpoints pane.
Triggering a breakpoint
A breakpoint is triggered whenever one of over 450+ DOM APIs are called by JavaScript. When the breakpoint triggers, you’ll jump to the Debugger tool with the file containing the triggering script opened and the line with the API call highlighted.
When a DOM API triggers a breakpoint, the Debugger tool will open with the API call highlighted.
In the Debugger tab, you’ll notice at the top of the call stack is an entry with the selector for the node the breakpoint was triggered on, and the type of breakpoint triggered.

Breakpoint persistence
We store breakpoints as part of your Edge DevTools settings and scope them to the URL of the page they’re set within. When you close and re-open Edge DevTools, or refresh the page, we’ll restore and attempt to automatically rebind the breakpoints to their respective DOM nodes. If we’re unable to automatically rebind them, we’ll indicate that they’re unbound in the UI with a warning icon on the breakpoint circle.
Breakpoints that cannot be rebound when the session is restored will show an alert icon in the Breakpoints pane.
You can use the context menus or shortcut icons in the DOM breakpoints panes to manually rebind any breakpoints we were unable to automatically rebind.
What’s next for DOM Breakpoints
We’re excited to launch this feature and hope to solve for as many developer scenarios as we can, but want to highlight a few gaps in the current implementation:
We don’t currently support rebinding breakpoints inside iframes. If you set a breakpoint in an iframe and close Edge DevTools or refresh the page, the breakpoint will be lost.
If your script encounters a synchronously-executed breakpoint before the DOM readyState is completed, you won’t be able to set a DOM breakpoint while the debugger is paused. You can typically remedy this situation by setting the defer or async script attributes.
For synchronous scripts, we trigger automatic rebinding of breakpoints when the window.onload event is called. In this case, we may miss binding breakpoints that would trigger during initial script-driven build-up of the DOM. For asynchronous scripts, we trigger a rebind attempt before the first script executes, so your breakpoints may rebind and trigger as desired.
We’re evaluating closing these gaps in future releases, as we continue to evaluate the prevalence of these scenarios. If you have feedback and find these unsupported areas to be blockers, please let us know!
Tell us what you think
We hope you enjoy this new addition and find it improves your productivity as you go about your developer workflows. If you find any bugs, please report them via the Feedback Hub. If you have questions or feature requests, don’t hesitate to leave a comment here, or reach out to us on UserVoice or Twitter.
— ­Brendyn Alexander, Senior Program Manager, Microsoft Edge DevTools

New and improved Event and CSS inspection for Microsoft Edge DevTools

Editor’s note: This is the first post in a series highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
EdgeHTML 16 is now rolling out to devices around the world as part of the Windows 10 Fall Creator’s Update—and with it, some great improvements to the Microsoft Edge DevTools.
In this post, we’ll walk through a slew of new updates to the Elements tab (formerly known as the DOM Explorer) with improvements to CSS at-rules, Event Listeners, Pseudo-Elements and the overall user experience.
CSS at-rules
In EdgeHTML 16, we’ve completely redesigned how at-rules appear in the Elements tab. Previously, usage of CSS at-rules were either missing or incorrectly displayed. The DevTools now show @supports, @media and @keyframes styles in separate sections within the Styles pane:

The new at-rules interface inspecting @keyframes on the CodePen example above
We also added a new pane for inspecting the rendered font of an element. In the Fonts pane, you can now see whether a font is served from the local machine or over the network and what, if any, fallback font face was used. If over the network, the DevTools will show the correlating @font-face rule:

You can now inspect the rendered font of an element in the Fonts pane.
Ancestor Event Listeners
The DevTools now allow you to inspect all event listeners on ancestor elements up to the current Window with the Ancestors option. You can also group event listeners by Element to see how the events will fire at each level of the element tree. This enables you to determine where a rogue event listener might be firing higher up the tree.

You can now inspect all event listeners on ancestor elements up to the current Window with the Acnestors option.
Ancestor Event Listeners can be grouped by Element or Event.
Pseudo-Elements
In the Styles pane, the DevTools now group styles by their respective pseudo-element, supporting ::before, ::after, ::first-letter, ::first-line and ::selection. This should make it easier to determine which style is winning the cascade.

Styles are now grouped by their respective psuedo-element.
User Experience
This release also includes some tweaks to the user experience of the DevTools to make it easier for developers who work in multiple browsers.
In particular, Layout pane has been removed and the box model is now at the top of the Computed pane, freeing up space for two new panes: Fonts and DOM breakpoints.

The box model is now at the top of the Computed pane.
Finally, to make it easier on developers who switch between multiple browsers, we’ve added two new ways to launch the DevTools: Ctrl+Shift+I and Ctrl+Shift+J. Ctrl+Shift+I will launch the DevTools just as the F12 keybinding does today. Ctrl+Shift+J will launch the DevTools (if not already open) and take you directly to the Console.
You can try out and file feedback for these new features starting with EdgeHTML 16, and find us on Twitter @EdgeDevTools to let us know what you think!
— Clay Martin, Program Manager, Microsoft Edge DevTools

Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16

JavaScript performance has always been a core area of focus for our team. Every release, we look for opportunities to improve end users’ browsing experience on real workloads with shorter start-up time, faster execution, and leaner memory usage. These efforts are guided by invaluable ongoing customer feedback and telemetry data.
In this blog post, we will share a few new performance enhancements in the Chakra JavaScript engine, as well as updates on the availability of on-by-default WebAssembly, SharedArrayBuffer and Atomics support in Chakra and Microsoft Edge in EdgeHTML 16 with the Windows 10 Fall Creators Update.
More memory savings from deferring/re-deferring functions
In EdgeHTML 15, Chakra introduced the capability to re-defer functions. To briefly recap Chakra’s deferral/re-deferral pipeline, at start-up time Chakra performs a quick pre-parsing pass to check for syntax errors, and then defers the full parsing of eligible functions until they are first executed. At a later point, if heuristics determine that a fully-parsed function will most likely never be executed again, Chakra dumps its metadata generated since full-parsing and returns to a lean state as if the function is just pre-parsed and being deferred (hence the name re-deferral).

The deferral/re-deferral feature helps sites boost start-up time and save memory on redundant functions (imagine pulling a bunch of libraries and only just using 30% of the code, sound familiar?).
In EdgeHTML 16, we’ve addressed the feature’s previous limitation on handling functions in lexical and parameter scopes, and allowed functions in all scopes to be deferred and re-deferred. For example, it is common to have large chunks of scripts wrapped in giant try blocks for error handling, and functions enclosed in a block are now eligible for deferral/re-deferral.

// foo can be deferred/re-deferred after the Fall Creators Update
// example 1 – lexical/block scope
try {
  function foo() {…}
  var bar = foo();
}

// example 2 – parameter scope
function bar(foo = function(){…})) {…}

This change further improves memory savings made possible by deferral/re-deferral. The exact effect varies depending on the coding patterns of the sites. According to our experiment on a small sample of popular sites, this change along with others in the past update typically reduce the memory allocated by Chakra by 4-9%. The impact can also be much larger in some cases―such as a ~35% memory saving on Gmail.
Polymorphic inline cache for property access using square brackets (object[‘property’])
Polymorphic inline cache (PIC) is an optimization technique employed in Chakra (and many other runtimes) since Chakra’s inception. Chakra has an internal type system that maps each value to its type. When the Chakra Just-In-Time compiler (JIT) generates optimized code for hot code paths, Chakra may deploy an inline cache at each call site (location for function/subroutine calls such as property access) to memorize and store fast paths for the types encountered.
Polymorphic inline cache is a kind of inline cache that can remember multiple types at a given call site. In EdgeHTML 16, Chakra added the ability to place polymorphic inline cache for the object[‘property’] syntax, allowing cases where object may be of different types to be optimized.

// example – obj can be of {a: Number} or String type
let arr = [{a: Math.random()}, Math.random().toString()];
arr.forEach(obj => {
  for (propNames in obj) {
    if (obj.hasOwnProperty(propNames)) {
      // without PIC, multiple types lead to generic slow path
      // with PIC, both types for obj
      console.log(obj[propNames]);
    }
  }
});

This change should benefit typical users browsing sites using bracket notation and shows up as up to 8% speedup on tests utilizing Angular and React frameworks.
Enable optimizations for functions with try/finally
In JavaScript, it is a best practice to use the finally clause to gracefully clean up resources following a try block. Until the latest update, Chakra did not optimize functions that include a try/finally block because it was a non-trivial job to account for exceptions and unwinding in JIT optimizations.
Starting with EdgeHTML 16, when the Chakra JIT analyzes functions and builds the flow graph, it separates the excepting and non-excepting cases and creates two paths for a try/finally block, allowing general optimizations to be applied on the non-excepting path and forcing a bailout in case of an exception.

More optimizations for try/catch/finally are just on the horizon. ChakraCore recently added support for inlining in functions with try/catch/finally and you can expect this change to propagate to Chakra and Microsoft Edge in the next major Windows update.
WebAssembly, SharedArrayBuffer, and Atomics on by default
In the previous update, Chakra and Microsoft Edge debuted WebAssembly Minimum Viable Product (MVP), SharedArrayBuffer and Atomics support behind the “Experimental JavaScript Features” flag. With a bit of tuning in the past few months, these features are now stable and enabled by default in EdgeHTML 16.
Several changes also help improve WebAssembly performance in Chakra by 20-25% on workloads we have been tracking. Try it out for yourself! Point Microsoft Edge at a fun WebAssembly game like Funky Karts to see the improvement with no flags required!

Demo of Funky Karts in WebAssembly in Microsoft Edge (demo by Ross Smith)
Microsoft has been and will continue to work closely with Mozilla, Google, Apple and others in the WebAssembly community to move the technology forward. Impactful post-MVP features such as threads and GC are currently being explored in the WebAssembly Community Group.
Get involved
We are excited to share these new performance optimizations as well as on-by-default WebAssembly, SharedArrayBuffer, and Atomics support in Chakra and Microsoft Edge.
As always, we’re making more enhancements in future releases, and your feedback is one of our key signals for what to do next. So stay tuned and be sure to share your thoughts with us on the ChakraCore repo, or via @MSEdgeDev and @ChakraCore on Twitter!
― Limin Zhu, Program Manager, Chakra

sonar: Linting the web forward

In addition to building a great browser and dependable web platform for Windows, we’re passionate about empowering developers to build great websites. With that goal in mind, we launched modern.IE in 2013 featuring a static scan tool to detect optimizations for old versions of IE, outdated libraries, missing prefixes, and more. The web has moved on since then, and it’s time to update our tools accordingly!
Introducing sonar
Today, we are excited to announce the next evolution of the static scan tool: sonar, a new linting tool and site scanner for the modern web.

sonar brings many improvements compared to previous scanners: execution of websites code instead of static analysis, a more flexible and modernized set of rules, parallel test execution, integration with other services, a completely open source code base from day one, and more. Additionally, sonar can also be used as a command line tool (CLI) that you can integrate directly into your local web development workflows.
Web development is more than HTML, JavaScript, and CSS: developers are expected to have a grasp of accessibility, performance, security, emerging standards, and more, all while refreshing this knowledge every few months as the web evolves.
Web development can be complex.
Linting the web forward
Simply put, the web is complex, and we want sonar to make it a bit easier for you to write great websites. To make sure that sonar can be helpful not only now, but in the future, we started with a set of guiding principles before we wrote a single line of code.
Put the user at the center
Rather than just telling developers what was wrong, sonar had to also say why. It is important to know the reason for an issue so developers can decide if that really applies to their work. The requirements from website to website can change a lot, for example, an intranet website and an online shopping experience will have vastly different needs. Therefore, sonar should also be easy to use, configure, and expand.
Build for the community’s best interests
The web belongs to everyone, and this project should too. Everything had to be open sourced since the beginning, but that wasn’t enough―we wanted to go even further and make it easier for the web community to get involved, and remove any possible doubt that this project has the community’s best interest in mind. For that reason, we decided to donate the project to the JS Foundation early during the summer.
Collaborate with existing tools and services
sonar should avoid reinventing the wheel, instead leveraging and integrating existing tools and services that help developers build for the web. We are happy to say that sonar now integrates with aXe Core, AMP validator, snyk.io, SSL Labs, and Cloudinary.

You can hear more about sonar’s history and guiding principles in our session at Microsoft Edge Web Summit.
sonar today, and what’s next
We’ve come a long way since we wrote down those principles a few months ago: sonar is now available as an open sourced command line utility, built on node, that you can install via npm. Additionally, it has an open-source online service, deployed on top of Azure, using docker containers, that can scan any publicly available website. sonar’s rules are backed by a collection of best practices for the web, with links to more detailed documentation that keeps growing with each new rule.
But this is just the beginning. We’re hard at work on a backlog of exciting features for future releases, such as:
A plug-in for Visual Studio Code: We want sonar to help you write better websites, and what better moment than when you are in your editor.
Configuration options for the online service: As we fine tune the infrastructure, the rule configuration for our scanner is locked, but we look forward to adding customization options here in the near future.
New rules for a variety of areas like performance, accessibility, security, Progressive Web Apps, and more.
If you are excited about sonar, making a better web, and want to contribute, we have a few issues where you might be able to help. Also, don’t forget to check the rest of the sonarwhal GitHub organization. PRs are always welcome and appreciated!
Take a few moments to try the sonar scanner and the CLI, and let us know what you think at @narwhallnellie on Twitter or in the comments below!
– Antón Molleda, Senior Program Manager, Microsoft Edge
 

Documenting the Web together

Today, we’re excited to share some big news for developers around the world wide web: We’re committing our resources towards making MDN Web Docs the best place to go for web API reference. To kick things off, today we started redirecting over 7,700 MSDN pages to corresponding topics in the MDN web docs library powered by Mozilla.
In conjunction with similar commitments from Mozilla, Google, the W3C, and Samsung, we’re teaming up to make MDN Web Docs the best place for web developers to learn and share information about building for the open web.

MDN is a core part of Mozilla’s overarching mission: to ensure the Internet is a global public resource, open and accessible to all. We believe providing web developers the best possible information will enable them to deliver great web experiences that adhere to established standards and work across platforms and devices. We are excited to have Microsoft, Google, The W3C, and Samsung on board as we continue on our journey to make MDN the premiere resource for developers.
— Ali Spivak, Head of Developer Ecosystem at Mozilla
Representatives from each of these organizations will also be serving on the MDN Product Advisory Board, a committee dedicated to making MDN your definitive place for useful, unbiased, browser-agnostic documentation for current and emerging standards-based web technologies. The MDN Product Advisory Board is also looking for active individuals from the web community to serve on the board. If you’re interested, find more details on MDN web docs.
Web docs should just work for everyone
Redirecting our API reference library to MDN is the next step towards consolidating our compatibility info in the same place you probably already frequent for general web documentation. Earlier this year, we began the effort to backfill the MDN browser Compatibility tables with a column representing the Microsoft Edge browser.
Over 5000 MDN edits later, the entire web API surface of Microsoft Edge (as of the 10/2017 Windows 10 Fall Creators Update, Build 16299) is now documented on MDN, and will continue to be kept up-to-date with each new release of Windows and our EdgeHTML browser engine.
Example of a Browser compatibility table on MDN Web Docs
One of our guiding principles in developing Microsoft Edge is that end users should never have to worry about which sites work in which browsers. This philosophy—”the Web should just work for everyone“—led to our choice to target the “interoperable intersection” of web APIs in our browser engineering.
Just like with end users, we think it’s well overdue for developers to have a simpler view of web standards documentation. Developers shouldn’t have to chase down API documentation across standards bodies, browser vendors, and third parties—there should be a single, canonical source which is community-maintained and supported by all major vendors.
For these reasons we’re all-in on making MDN the home of web standards documentation. Not only is MDN a veritable encyclopedia and thriving community of all things web development, it’s also an institution in itself–a living monument to our collective history—as web developers and enthusiasts, web standards advocates, and browser engineers–of developing the web forward.
Documenting the web forward
MDN was founded over 10 years ago in 2005 as the Mozilla Developer Center and later become known as the Mozilla Developer Network. Just as the Mozilla Organization was founded out of Netscape, the Mozilla Developer Center grew from the original Netscape Navigator browser docs.
Similarly, the Internet Explorer Developer Center was first published online from the Microsoft Developer Network (MSDN) several years before that in the late 90s to help introduce and showcase Dynamic HTML (“DHTML”), Microsoft’s precursor to the modern DOM and CSS object model.
Microsoft Internet Explorer Developer Center on MSDN Online, circa 2000. Courtesy of the Internet Archive Wayback Machine
Fast forward to the modern web platform of today. The competing Netscape and Internet Explorer browsers from the bygone era of the early web are now subjects of tech archaeology, not site compatibility testing. From the final releases of IE culminating with the birth of Microsoft Edge, we replaced earlier Microsoft technologies with emerging industry standards–the modern DOM and ECMAScript standards for DHTML and VBScript, HTML5 for ActiveX, a common browser extension model for Browser Helper Objects (“BHOs”).
Through all this change, MDN has grown up alongside the web, and today has over 34,500 documents, 6 million monthly users and 20,500 contributors. From its initial Netscape product docs, the breadth and depth of MDN’s content has radically expanded to encompass the state of the art of modern web development—so much so that recently the site was restructured and rebranded to reflect MDN’s commitment to being a browser-neutral community resource. We are excited to join Mozilla, Google, The W3C, and Samsung in making MDN our home for web standards documentation and dedicated to helping it grow even further to meet your needs.
We will continue to maintain Microsoft- and Windows-focused documentation on Microsoft Docs (docs.microsoft.com/microsoft-edge), including Windows-specific test guidance, information on the Edge DevTools, and upcoming details about Progressive Web Apps in the Windows Store. And you’ll still find the latest Microsoft Edge status, changelogs, and news at our Microsoft Edge Developer site (dev.microsoftedge.com).
Please join us in supporting and contributing to MDN web docs! We’re all building this Web together; let’s document our hard work!
— Erika Doyle Navara, Senior Dev Writer

What’s New in Microsoft Edge in the Windows 10 Fall Creators Update

Today, we’re beginning to roll out the Windows 10 Fall Creators Update to Windows 10 customers around the world. This release upgrades Microsoft Edge to EdgeHTML 16, the best version of Microsoft Edge yet. The Fall Creators Update also includes new enhancements like improved favorites management and pinned sites, new developer APIs like CSS Grid Layout and WebVR 1.1, and better-than-ever reliability and performance.
To get started with EdgeHTML 16, simply update your devices to the Windows 10 Fall Creators Update today. Developers on other platforms can get started testing with free remote testing via BrowserStack today. In this post, we’ll walk through some of what’s new in Microsoft Edge for Windows 10 customers and developers alike.
Stay productive and organized with new features
The Fall Creators Update introduces a set of new features to make you more productive as you browse and read web pages, PDFs, and books. We’re also previewing new features to let you browse on your phone in the new Microsoft Edge preview apps for iOS and Android, with Continue on PC functionality. You can learn more about everything that’s new by selecting the “…” menu in the top-right corner of Microsoft Edge and selecting “What’s new and tips.”
A refreshed look inspired by the Fluent Design System
In the Fall Creators Update, Microsoft Edge gets a subtle makeover inspired by the Fluent Design System.
A subtle use of Acrylic material provides depth and transparency to the tab bar and other controls, and we’ve improved button animations to feel more responsive and delightful.
Annotate your e-books and PDFs
When you’re reading an e-book or PDF, you now have a whole lot of new options to personalize your books.

You can add highlights in four colors, underline, add comments or copy text. You also have the ability Ask Cortana to find more information about the content you are reading without leaving the reading experience. To get started, simply select some text and choose one of the annotation options from the menu that pops up!
Or, if you’re reading a PDF, you can select the “Add notes” button next to the address bar to mark the PDF up with Windows Ink.

This feature lets you take notes with a pen or highlighter right on the page – perfect for marking up a draft, signing a document, or filling out a form!
Pin your favorite websites to the taskbar
Pinned Sites, a top-requested feature from our Windows Insider community, are now available in Microsoft Edge! You can now pin a website to the Windows taskbar for instant access in the future. The site will be saved with its icon so it’s just a click away.

To pin a site, go to More … > Pin this page to the taskbar and the site will be pinned for you to come back to again and again.
Hear the web read out loud
Microsoft Edge can now read web pages, e-books, and other documents out loud to make reading accessible to more people. To hear an e-book or PDF out loud, click or tap anywhere on the page and select the “Read aloud” button from the top-right corner.

For sites, right click where you want to start reading and select “Read aloud.” You can adjust the playback speed, pause, skip between paragraphs, or even change the voice from the Voice Settings menu at the top of the page.
Edit URLs for favorites
By popular demand, we’ve added the ability to edit the address for individual favorites in the Favorites Hub or on the Favorites bar.

To do this, simply right-click or press and hold a favorite and select “Edit URL.”
See and manage website permissions
New features like web notifications and location services mean more sites may ask for your permission to access your location, webcam, or to send notifications, among other things. To help make it easier to keep track of what permissions you’ve granted, we’ve added a new “Show site information” pane for every website you visit.

To see the permissions you’ve granted for any site you visit, simply click the icon to the left of the URL bar (either a lock icon or an “i” icon, depending on the site’s security configuration).
Or, to see and manage all the permissions you’ve set, select More … > Settings > View advanced settings > Manage under Website Permissions.
Browse in full screen
Another popular request from our Windows Insiders was to introduce a true full screen browsing experience to Microsoft Edge.

To browse in full screen mode, select the More … menu and click the “Full screen” arrows icon, or press “F11” on your keyboard. Full screen mode hides things like the address bar and other items from view so you can focus on your content.
To exit full screen mode, move your mouse near top of the screen or swipe down with your finger and select the “restore” icon in the top-right, or press “F11” again.
Browse on your phone and continue on your PC
The Fall Creators Update adds support for a new feature currently in preview on iOS and Android Devices, which allows you to start from a website on your phone and send it to your Windows 10 PC.

This feature requires the preview of Microsoft Edge for iOS or Android. Learn how to install the preview on your phone here.
New features for web developers
The Windows 10 Fall Creators Update upgrades Microsoft Edge and the Windows web platform to EdgeHTML 16, with major new features for web apps, modern layouts, payments, and more.
New CSS features: Grid Layout, object-fit, and object-position
Microsoft Edge now supports the unprefixed implementation of CSS Grid Layout. Grid Layout defines a two-dimensional grid-based layout system which enables more layout fluidity than possible with positioning using floats or scripts. The example below uses CSS Grid Layout to create the structure for a basic web page.

EdgeHTML 16 also introduces support for the CSS properties object-fit and object-position. These properties control the position and size of replaced content within the content box.
Improvements to the Microsoft Edge DevTools
EdgeHTML 16 marks the beginning of a major renewed investment in our DevTools, beginning with a new refactoring effort for improved robustness and performance.

We’ve also introduced a number of new features to the DevTools, including the ability to view ancestor event listeners, set DOM mutation breakpoints, view CSS “at” (@) rules on the Styles pane, and more – along with major improvements to the Console and Debugger and early support for debugging Progressive Web Apps.
We’ll be sharing more details on what’s new in F12 in separate posts coming soon – in the mean time, you can see everything that’s new in the Microsoft Edge F12 DevTools page on the Microsoft Edge Dev Guide.
Payment Request API
The Payment Request API is an open, cross-browser standard that enables browsers to act as an intermediary between merchants, consumers, and payment methods (e.g. credit cards) that consumers have stored in the cloud. The API in EdgeHTML 16 has been updated to match the latest W3C Payment Request API specification. This includes:
Support for the canMakePayment() method
Support for the requestId property
Support for the id property
The default value for the complete() method’s result parameter changed from ” ” to “unknown”
Service Worker preview
Service Workers are event-driven scripts that run in the background of a web page. Service workers enable functionality previously only available with native apps like intercepting and handling requests from the network, managing and handling background sync, local storage, and push notifications.
Support for service workers is still in development, but you can test out your Progressive Web App in Microsoft Edge with our experimental service worker support by enabling the service worker feature in about:flags.
Motion Controllers in WebVR
WebVR for Microsoft Edge has added support for motion controllers. These controllers have a precise position in space, allowing for fine grained interaction with digital objects in virtual reality.

The release of the Windows 10 Fall Creators Update also marks the beginning of the era of Windows Mixed Reality, with the first wave of consumer Windows Mixed Reality headsets coming to market to enable immersive, low-cost experience with WebVR in Microsoft Edge.
In anticipation of this upcoming release, we’re excited to announce (with big thanks to the community and contributors involved) that the popular WebVR frameworks A-Frame, BabylonJS, ReactVR and three.js have now added support for the Windows Mixed Reality platform to their current and upcoming releases.

Version
Immersive View
WebGL context switching
Motion Controllers

master


0.7.0


R88*


2.0.0



You can learn more about getting started with WebVR and Windows Mixed reality in our post on the Microsoft Edge Dev Blog: Bringing WebVR to everyone with the Windows 10 Fall Creators Update.
… and more!
There’s too much in EdgeHTML 16 for one blog post; fortunately, you can find our full documentation, including a list of all the new APIs in EdgeHTML, over at the Microsoft Edge Dev Guide. Or, see what’s new in a given preview build at the Microsoft Edge Changelog.
If you’d like to learn more about a given topic, check out our recorded sessions from Microsoft Edge Web Summit 2017, where we shared more about our plans for the future of Microsoft Edge and gave a detailed look at what’s shipping today.
Test for free with BrowserStack or free virtual machines
The Windows 10 Fall Creators Update is rolling out to Windows 10 customers starting today – you can learn how to get the update on your PC here.
In case you don’t have a Windows 10 PC, we’ve partnered with BrowserStack to offer remote testing via a streaming instance of Microsoft Edge. Just set up a free account on BrowserStack for unlimited cloud testing, or download a free virtual machine from Microsoft Edge Dev, to get started testing EdgeHTML 16 today.
As always, we’re passionate about building in the open, and encourage you to review our open platform roadmap and provide feedback on features that matter to you. We’re always listening here in the comments, or @MSEdgeDev on Twitter. We can’t wait for you to try it out and let us know what you think!
— Kyle Pflug, Senior Program Manager, Microsoft Edge
— Libby McCormick, Dev Writer, Microsoft Edge

Bringing WebVR to everyone with the Windows 10 Fall Creators Update

Last April, we introduced the WebVR 1.1 API in Microsoft Edge as part of the Windows Creators Update, providing a foundation for developers to create immersive virtual reality experiences with Windows Mixed Reality developer kits. We have been hard at work building on this foundation to provide an end-to-end mixed reality experience with Microsoft Edge, WebVR, and Windows Mixed Reality, in line with our goal to democratize virtual reality this holiday.
On October 17th, EdgeHTML 16 will be released with Windows 10 Fall Creators Update, and the era of Windows Mixed Reality begins as headsets and motion controllers become widely available, enabling low-cost, immersive experiences with WebVR in Microsoft Edge.
In anticipation of this upcoming release, we’re excited to announce (with big thanks to the community and contributors involved) that the popular WebVR frameworks A-Frame, BabylonJS, ReactVR and three.js have now added support for the Windows Mixed Reality platform to their current and upcoming releases.

Version
Immersive View
WebGL context switching
Motion Controllers

master


0.7.0


R88*


2.0.0



* Upcoming release
In EdgeHTML 16, we’ve made a few updates to our WebVR 1.1 implementation that you should be aware of, starting with added support for Windows Mixed Reality motion controllers.
New support for motion controllers
Developers now have the tools to create fully interactive, immersive experiences on the web with our new support for Windows Mixed Reality motion controllers.

When a site is presenting to a headset, connected motion controllers will be available via the Gamepad API.
Adding support to the browser is only half of the story. We have been working with 3rd party middleware libraries to make sure that integrating support for motion controllers into your experience is as seamless a process as possible.
Current releases of both BabylonJS and A-Frame have full support for Windows Mixed Reality headsets and motion controllers.
Controller support includes detection of connected motion controllers, rendering accurate representations of the controllers into the scene, mapping button presses to actions and casting pointing rays into the scene for point-and-commit interactions. For added realism, the controller models animate the buttons and thumbsticks as the devices are manipulated:

Image: Hotel Room, Reno, Nevada / Bob Dass / Creative Commons 2.0
Added support for more Windows Mixed Reality PCs
Windows Mixed Reality supports a wide range of desktop and laptop hardware, with many graphics card configurations. Microsoft Edge has extended support for running WebVR experiences on this broad range of hardware – including machines with multiple graphics cards.
To leverage this support as a WebVR application developer, make sure that you are using the most up to date version of BabylonJS, A-Frame (0.7.0), three.js (r87), ReactVR (2.0.0).
If you are using WebGL directly rather than through one of these libraries, you’ll need to handle the WebGL Context Lost and Context Restored events to take advantage of this wider range of hardware.
The first immersive experience that lets you enjoy the entire Web
Microsoft Edge is now the first stable browser to ship comprehensive support for Virtual Reality.  From within your headset you can view traditional 2D websites, manage your favorites, create new tabs (including InPrivate tabs), and seamlessly transition into WebVR experiences.  And when browsing with Microsoft Edge on the Desktop, you’re still only one click away from launching WebVR content directly into your headset.
Because Microsoft Edge is built on the Universal Windows Platform, it can be used alongside the thousands of other apps supported by Windows Mixed Reality out of the box.

When you encounter a WebVR experience in Microsoft Edge within Mixed Reality, you can seamlessly transition from a 2D page to an immersive experience and back again without ever switching apps or leaving your headset.
Start developing today!
Our updated WebVR implementation is coming in EdgeHTML 16 with the Windows 10 Fall Creators Update, which will be released alongside new Windows Mixed Reality headsets and motion controllers on October 17th. Developers can get started building for WebVR today (no headset required!) via the Windows Insider Program, using the built-in Mixed Reality Simulator. Or, if you have an Acer or HP developer kit, you can try out Mixed Reality today!
You can learn more about the WebVR API with our documentation online, where you’ll find everything you need to get started, including a checklist of things to consider when creating a WebVR experience.
More Information
Finally, check out the talk that Nell Waliczek and Lewis Weaver recently gave at the Microsoft Edge Web Summit for an overview of WebVR, a deep dive into how to use the APIs, and some more good practices and resources:

We can’t wait to see what you build!
Lewis Weaver, Program Manager, WebVR
Nell Waliczek, Principal Software Engineering Lead, WebVR

Microsoft Edge for iOS and Android: What developers need to know

As you may have read on the Windows Experience blog, Joe Belfiore announced today that Microsoft Edge is coming to iOS and Android, bringing the best browsing experience on Windows 10 to more pockets around the world.
Joe’s post has everything you need to know about availability and features of the preview app experiences. Here, we want to talk a bit about these new apps from a web developer point of view.

Getting the preview apps
As any developer can appreciate, testing and learning is a crucial part of launching a new product. It’s something we don’t take lightly. As such, we are beginning with a limited preview to get feedback and learn.
The iOS app is available today for a limited audience in Apple’s TestFlight system, and the Android app will be available shortly via Android’s Play Store Early Access. Consistent with our engineering approach for Windows 10, we’ll be listening to feedback throughout our preview and will update the apps regularly with fixes and new features. When our telemetry (and feedback) shows that the quality is great, we’ll make the apps available for public download – our goal is to do so later this year.
Engines and Platforms
One of the most common web developer questions we’re expecting is – what engine are you using? Did you port EdgeHTML to iOS and Android?
Our choices are directly related to how we think about the goals of the EdgeHTML engine itself on Windows 10.
A web platform is a complex piece of technology that in many respects duplicates aspects of an entire operating system in a single app. Part of our strategy with EdgeHTML is to build an engine that, instead of replicating (and, in some senses, competing with) the underlying platform, integrates and works with it to deliver the best possible security, accessibility, battery life, interactivity, just pure raw performance on that platform. We are proud of the work we’ve done with EdgeHTML on Windows 10, all while driving the web forward with new capabilities and supporting interoperable standards. We are fully committed to continuing to do so into the future, across the full spectrum of Windows 10 platforms and form factors.
Taken in that light, it should then not be a surprise that we have chosen to adopt the core web platform technologies on each of the app platforms we are announcing today.
On iOS, we are using the WebKit engine, as provided by iOS in the WKWebView control. That means that from a compatibility perspective, Microsoft Edge for iOS should match the version of Safari that is currently available for iOS.
On Android, we are using the Blink rendering engine from the Chromium browser project. This approach gives us more control and better performance than using the Android WebView control, but means that we are shipping our own copy of the rendering engine in the app. Much like other Android browsers based on Chromium, we expect to keep up with Chromium releases. You can expect that, from a compatibility perspective, Microsoft Edge for Android will match the version of Chrome that is currently available for Android.
User Agent String
A highly related question is – how can I detect Microsoft Edge from my site?
In most cases, you shouldn’t need to do anything different for your site to just work in Microsoft Edge for iOS and Android. But, we know that in some cases (for example, for analytics, or for choosing the right text in an onscreen instruction related to the browser experience), you might want to know that the user is using Microsoft Edge on an iOS or Android device.
Right now, the apps are using User Agent strings that exactly match the strings used by the primary browser on that platform.  Very soon, we will update the preview apps to include a new token in their user-agent strings, as below:
Microsoft Edge for iOS user agent string
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Mobile/14F89 Safari/603.2.4 EdgiOS/41.1.35.1
Microsoft Edge for Android user agent string
Mozilla/5.0 (Linux; Android 8.0; Pixel XL Build/OPP3.170518.006) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.0 Mobile Safari/537.36 EdgA/41.1.35.1
A few notes:
The app/OS identifier is chosen so that it does not contain the string “Edge.” This is to avoid triggering any existing UA detection logic that might accidentally decide that these browsers are Microsoft Edge for Windows 10, resulting in a desktop site or something equally confusing.
The version number “41” is the app version number aligned across all current versions of Microsoft Edge (note that for simplicity, the app version number is not currently exposed in Microsoft Edge for PC; only the EdgeHTML engine version number is exposed).
The sub-version number is a platform-specific version number that internal version number of the app on that platform.
Stay tuned
We are excited to be releasing these preview apps, bringing the Microsoft Edge ecosystem to the devices in your pockets with the features you expect, and plenty of unique new features to come.
Stay tuned to this blog (or follow us on Twitter) for more updates on Microsoft Edge, and be sure to try out the preview apps for yourself and let us know what you think. Help us build the best browsers we possibly can!
You can find out more about the preview apps on the preview site.
– Sean Lyndersay, Program Manager, Microsoft Edge