Last week, Microsoft welcomed thousands of developers from around the world to Build 2017, where we shared our vision for the future of dozens of products and services. Build featured a number of exciting sessions for developers building sites and apps with web technologies, including a peek at what’s coming to the web platform beginning with EdgeHTML 16 the Windows 10 Fall Creators Update.
In this post, you’ll find a quick review of the web developer sessions at Build 2017. If you see something you’d like to learn more about, dive into the recording to get all the details!
What’s new and what’s next for the web on Windows
In this session, Kyle Pflug and Nadia Fortini take you on a whirlwind tour of what’s new in Microsoft Edge in EdgeHTML 15, and share a roadmap for our priorities in upcoming releases of Microsoft Edge.
You’ll learn about new features like Payment Request for standardized checkout experiences, WebVR for immersive mixed reality experiences built with immersive web technologies, and dramatically improved responsiveness and battery life. We also cover upcoming APIs in development for future releases, including an updated CSS Grid implementation, Service Worker and other features that enable Progressive Web Apps, and much more.
This session also shows an early look at upcoming changes to the design and personality of Microsoft Edge, as the new Fluent Design System begins to make to the browser beginning with the Windows 10 Fall Creators Update. Fluent Design brings depth, motion, and personality to the controls and browser frame in Microsoft Edge, allowing elements of the page and background to influence the color of the browser window.
Progressive Web Apps on Windows
In this session, Aaron Gustafson introduces Progressive Web Apps, a new vision for the future of web apps enabled by groundbreaking technologies like Service Worker, which will be coming to preview builds of Microsoft Edge for developer testing this summer.
You’ll learn how Progressive Web Apps enable world-class, cross-platform, native-like apps, build on web technologies and hosted on your own server. PWAs can work offline, update content in the background even when the browser or the app is closed, and intercept network requests to update content from a cache when the network is unavailable.
This session details how we will a first-class web app ecosystem on Windows by ingesting high-quality PWAs from across the internet, and making it easy for developers to participate in the Windows Store alongside native apps with no extra effort, using tools like Web App Manifests and PWABuilder.
WebVR: Immersive Mixed Reality powered by web technologies
In this session, David Rousset and Etienne Margraff describe how EdgeHTML 15 on the Windows 10 Creators Update enables any web developer to build an immersive mixed reality experience with Microsoft Edge, Windows Mixed Reality, and the WebVR 1.1 API.
Better checkout experiences with the Payment Request API
In this session, Molly Dalton, Stan Change, and Jonathan Cutler provide an in-depth look at the new Payment Request API, which allows you to build standardized, cross-browser checkout experiences on the web and in apps. Payment Request dramatically simplifies checkout by leveraging a payment app – in this case, the browser – to store and provide payment and shipping details, so your customers can enjoy less friction and a more delightful user experience.
Payment Request works in EdgeHTML 15 as well as in UWP apps, apps packaged with the Desktop Bridge, and the Microsoft Bot Framework, allowing you to build a faster and easier checkout experience across a variety of devices and platforms.
What’s new in ChakraCore
You’ll learn about the near-native performance enabled by experimental WebAssembly support in Microsoft Edge, and exciting new emerging tools like Time Travel Debugging. You’ll also learn about Chakra’s journey to other operating systems, and the work we’ve been doing with the Node.js core project to help solve key problems like providing a stable Node API for native module developers.
Get started today
Many of these new APIs – including WebVR 1.1, Payment Request, CSS Custom Properties, and more – are available and on by default in Microsoft Edge on the Windows 10 Creators Update, which is available now. To get started with experimental features like WebAssembly, you can simply navigate to about:flags in Microsoft Edge.
To make it as easy as possible to get started, we’ve partnered with BrowserStack to provide instant, free testing of Microsoft Edge from any device. You can test the latest stable and preview releases of Microsoft Edge, and even test localhost or using WebDriver.
We look forward to sharing more about upcoming features soon as they make their way to the Windows Insider Program. In the meantime, check out the Build sessions, and let us know what you think!
― Kyle Pflug, Senior Program Manager, Microsoft Edge
To provide a more secure experience, both the Windows 10 Creators Update and Cumulative Security Update for Internet Explorer-April 11, 2017 introduce an option to block VBScript execution in Internet Explorer for all document modes. Users can configure this behavior per site security zone via registry or via Microsoft Easy fix solution. Enterprise customers can also configure this behavior via Group Policy.
As a security best practice, we recommend that Microsoft Internet Explorer users disable VBScript execution for websites in Internet Zone and Restricted Sites Zone. Details on how to configure this behavior can be found in KB4012494.
In subsequent Windows releases and future updates, we intend to disable VBScript execution by default in Internet Explorer 11 for websites in the Internet Zone and the Restricted Sites Zone. The settings to enable, disable, or prompt for VBScript execution in Internet Explorer 11 will remain configurable per site security zone, via Registry or via Group Policy, for a limited time. We will post future updates here in advance of changes to default settings for VBScript execution in Internet Explorer 11.
Most customers have automatic updates enabled, and updates will be downloaded and installed automatically. Customers who have automatic updates turned off, will need to check for updates and install them manually.
Today, the Windows 10 Creators Update began rolling out to over 400 million Windows 10 devices. With the Creators Update, we’re upgrading Microsoft Edge with dozens of new features and under-the-hood improvements to make the best browser on Windows 10 faster, leaner, and more capable than ever.
This release updates the Windows web platform to EdgeHTML 15, the fourth release of EdgeHTML and a major step forward both in terms of the browser user experience, web platform capabilities, and fundamentals like performance, efficiency, and accessibility. In this post, we’ll share a quick overview of what’s new in each area, for both users and web developers. Stay tuned over the coming weeks, as we’ll be sharing a deeper look at many of these topics individually.
Introducing Microsoft Edge in the Windows 10 Creators Update
Over the last eight months, the Microsoft Edge team has been focused on exciting new features to make the browsing experience better than ever:
Organize your web with new tab management experiences
Windows users spend more than half of their time on the web, and it’s all too easy to get tangled up in the chaos of search results, sites, and other content that can build up over hours, days, or weeks of browsing. In this update, we’ve introduced two new features to take the pain out of tab management.
Microsoft Edge now lets you set your tabs aside for later, sweeping them aside and organizing them neatly in a special section for easy access when you’re ready.
Set your tabs aside for later
Simply click the new “Set these tabs aside” button next to your row of tabs, and they are moved out of sight. When you’re ready to come back to them, just click the “Tabs you’ve set aside” icon, and you get a tidy, visual view of previous sessions. Restore one tab, or restore the full set!
If you have a lot of tabs open, it can be daunting to tell them apart, or to find a specific page in the sea of tiny icons and titles. Microsoft Edge now includes the ability to preview all your open tabs at once, so you can get back to what you’re looking for in a snap.
Show tab previews to scan your tabs more easily
Simply click the “Show tab previews” arrow to the right of your new tab button, and your tabs will expand to show a preview of the full page. You can scroll through this list to see as many tabs as you have open – when you find what you want, just click it to get back to browsing!
New reading experiences in Microsoft Edge
Microsoft Edge now lets you read books from right inside the browser, putting your favorite e-books from the Windows Store or from EPUBs on the web alongside your reading list and other content you expect to find in your browser.
That’s just the beginning – you’ll find new features and extensions, and improvements to performance, usability, and more, all throughout Microsoft Edge. You can find tips on what’s new and how to get the most out of Microsoft Edge at Microsoft Edge Tips.
These improvements translate into hours more browsing time for our customers – time to finish a crucial report while you’re at a coffee shop with no power, or to watch an extra movie on a long flight. In a head-to-head video rundown test, Microsoft Edge outlasted Google Chrome by more than three hours when streaming video!
There are countless enhancements to improve efficiency in the Creators Update, and we’re methodical about measuring the impact of each fix or new feature to make sure you get the most out of your browser. Watch this space for a detailed update on the engineering work that enables our greater power efficiency, and more on how we measure power consumption, coming early next week.
Responsiveness that puts the user first
Comparing scrolling on a busy page, before and after the input responsiveness improvements in EdgeHTML 15.
That just scratches the surface – for example, over the past two releases, we’ve been working on an ongoing, multi-year refactoring of the Microsoft Edge DOM tree, which is now substantially complete. Together with a number of performance optimizations, this has resulted in a more than twofold improvement in performance in many real-world scenarios, as measured by the Speedometer benchmark, which simulates real-world app patterns using common frameworks.
Chart showing Microsoft Edge scores on the Speedometer benchmark over the past four release. Edge 12: 5.44. Edge 13: 37.83. Edge 14: 53.92. Edge 15: 82.67.
We’ll be exploring these performance and responsiveness improvements in more detail over the coming weeks – stay tuned!
Safer than ever
Microsoft Edge in the Creators Update includes two broad categories of security improvements which make the browser more resilient to typical attack strategies.
First, we’ve introduced a series of mitigations to prevent arbitrary native code execution: Code Integrity Guard and Arbitrary Code Guard. These mitigations make it much more difficult to load harmful code into memory, making it less likely and less economical for attackers to be successful in building a compete exploit. You can read more about this work in Mitigating arbitrary native code execution in Microsoft Edge.
Second, we’ve dramatically improved the resiliency of the Microsoft Edge sandbox. Microsoft Edge has always been sandboxed in a series of app containers on Windows 10 – in the Creators Update, we’ve tuned these app containers by reducing the access scope to only the capabilities that are directly necessary for Microsoft Edge to work properly. This work dramatically reduces Microsoft Edge’s attack surface area (including a 90% reduction in access to WinRT and DCOM APIs), and when combined with the exploit mitigations that apply to Microsoft Edge and its brokers, increases the difficult of exploiting any remaining vulnerabilities. You can read more about this work in Strengthening the Microsoft Edge Sandbox.
Modern capabilities for web developers
The Windows 10 Creators Update upgrades the Windows web platform to EdgeHTML 15, which introduces a number of new, modern capabilities for web developers. A few of these are highlighted below – you can find the full list of changes on the Microsoft Edge Dev Guide.
Simpler web payments with the Payment Request API
The new W3C Payment Request API enables simpler checkouts and payments on Windows 10 PCs and phones. In Microsoft Edge, the Payment Request API connects to the user’s Microsoft Account (with the user’s permission), allowing easy access to payment information. Because payment information is securely saved in a digital wallet, shoppers don’t have to navigate through traditional checkout flows and repeatedly enter the same payment and shipping address information repeatedly.
WebVR Developer Preview
Microsoft Edge now supports the WebVR 1.1 draft specification, which has been collaboratively authored by Mozilla, Google, Samsung, Microsoft, Oculus and others. Developers can now use this API to create immersive VR experiences on the web with the recently available Windows Mixed Reality dev kits. You can even get started without a headset using the Windows Mixed Reality Simulator. Acer, ASUS, Dell, HP, and Lenovo will ship the world’s first Windows Mixed Reality-enabled headsets later this year, starting at just $299 USD. Note that while WebVR is enabled by default in Microsoft Edge, using the Windows Mixed Reality Portal or Mixed Reality dev kits currently requires Developer Mode to be turned on in Windows settings.
Brotli is a compression format that achieves up to 20% better compression ratios with similar compression and decompression speeds (PDF). This ultimately results in substantially reduced page weight for users, improving load times without substantially impacting client-side CPU costs. As compared to existing algorithms, like Deflate, Brotli compression is more efficient in terms of file size and CPU time. Learn more about Brotli in our blog post, Introducing Brotli compression in Microsoft Edge.
At An Event Apart Seattle, we recently announced the development has begun on our updated CSS Grid implementation. With this announcement, every one of the features pictured are in development (or, in the case of CSS Custom Properties, shipping today!).
Beyond CSS, our roadmap for preview releases over the rest of 2017 is focused on three areas: doubling down on fundamentals like performance and reliability, delivering Progressive Web Apps on Windows, and continuing to innovate in the user experience of Microsoft Edge. We’re excited to share more about what the future holds soon!
Get started today on Windows 10, or test for free via BrowserStack
Migrating legacy web apps to modern standards can be both costly and time consuming. IT departments are generally cost centers, and it makes sense for enterprises to want to maximize the ROI on their existing LOB apps. Many of these sites may continue to exist without being upgraded for a while yet, and it’s important to us that these apps do not block Windows customers as they adopt newer versions of Windows. This is why Windows 10 includes Internet Explorer 11 alongside Microsoft Edge, to provide a consistent and predictable level of compatibility with existing legacy applications.
In this blog post, we will discuss how Internet Explorer and Microsoft Edge can work together to support your legacy web apps, while still defaulting to the higher bar for security and modern experiences enabled by Microsoft Edge. Working with multiple browsers can be difficult, particularly if you have a substantial number of internal sites. To help manage this dual-browser experience, we are introducing a new web tool specifically targeted towards larger organizations: the Enterprise Mode Site List Portal.
The future of Internet Explorer
Naturally, this is a question we get quite frequently. With Microsoft Edge and the modern web representing the future, what will happen to Internet Explorer?
While we encourage everyone on Windows 10 to use Microsoft Edge—our modern web browser designed for faster, safer browsing—we are cognizant of the sizable investment that many of you have in legacy web apps. Our guidance to developers and IT administrators is simple. Upgrading web apps to modern standards is the best long-term solution. With that said, you can still use Internet Explorer 11 for backward compatibility and upgrade web apps on your own schedule.
Internet Explorer 11 supports Document modes and Enterprise Mode, which are essential tools for maintaining this backward compatibility. Internet Explorer, and the aforementioned tools, are considered components of the Windows operating system. They follow the Lifecycle Policy for the product on which they are installed. For Internet Explorer 11, this includes the lifespan of Windows 7, Windows 8.1, and Windows 10.
Cataloging your internal sites
Show of hands: who knows the exact number of internal sites and web apps your company has today? The answer to this is, of course, dependent on the size of your organization and many other factors. However, if we were in a large room of IT professionals, chances are there wouldn’t be many hands up.
As your organization grows, it’s only natural that the number of web apps should grow proportionally. It’s tough to have a firm grasp of what constitutes your “intranet”, in the non-networking sense of the word. This is an inherent problem that most will face when modernizing their web apps. In order to determine your dependency on legacy technologies, you first need to identify all the sites that must be tested, then learn their optimal configuration. There are a few ways you can go about this. If you attended our session at Microsoft Ignite in Atlanta last September, you should be familiar with these approaches.
Let’s go through them one-by-one:
F12 developer tools. The first method is by far the most manual approach. With the F12 developer tools in Internet Explorer 11, you can emulate any site with different Document modes and Enterprise Modes. Cycling through these different options will help you determine the appropriate compatibility setting. There’s some user training required to understand the technology behind the process, but fortunately little configuration is needed. One-by-one, you can build a list of sites and the legacy technologies they require. You can learn more about this approach here.
Enterprise Site Discovery. The next approach is much more automated. Enterprise Site Discovery automatically collects inventory data on any set of computers you designate, effectively crowdsourcing the information you would learn from the F12 developer tools. Any time a user browses the web, data—such as the URL, domain, document mode, browser state reason, and number of visits—is captured. This information can be scoped to particular domains and zones for privacy. The more data you collect, the clearer of a picture you will have. Over enough time and with enough devices, the list will begin to build itself with increasing accuracy. You can learn more about this approach here.
Windows Upgrade Analytics. The final method is based on Enterprise Site Discovery, and is the most scalable solution. Windows Upgrade Analytics is a free service that helps IT departments easily analyze their environment and upgrade to Windows 10 through the Operations Management Suite. As a part of this solution, the same site discovery data is collected, which can be similarly scoped for privacy. Going one step further, the raw inventory data is automatically analyzed and snapshot reports, like the one pictured below, are generated. You can learn more about this approach here.
Now that we have all this site information, what do we do with it?
Microsoft Edge and Internet Explorer 11 work better together on Windows 10. Based on the size of your legacy web app dependency, determined by the data collected above, there are several options from which you can choose to configure your enterprise browsing environment:
Use Microsoft Edge as your primary browser
Use Microsoft Edge as your primary browser and use Enterprise Mode to open sites in IE11 that use IE proprietary technologies
Use Microsoft Edge as your primary browser and open all intranet sites in IE11
Use IE11 as your primary browser and use Enterprise Mode to open sites in Microsoft Edge that use modern web technologies
Use IE11 as your primary browser
This blog post goes into more detail on when to use which option, and which option is best for you.
Now that we have a catalog of legacy web apps, let’s define an experience where you can use a modern browser but still maintain compatibility with your older apps.
Managing your Enterprise Mode Site List
The Enterprise Mode Site List is an XML document where you can specify a list of sites, their compat mode, and their intended browser. With this schema, you can automatically launch a page in a particular browser. In the case of IE11, that page can be launched in a particular compat mode to always render correctly. You can also restrict IE11 to only the legacy web apps that need it, automatically sending sites not included in the Enterprise Mode Site List to Microsoft Edge, as of the Anniversary Update last year. Once implemented, users can easily view this site list by visiting “about:compat” in either browser.
There are equivalent Enterprise Mode Site List policies for both Microsoft Edge and Internet Explorer 11. The former list is used to determine which sites should open in IE11; the latter list is used to both (1) determine with which compat mode to load a site, and (2) determine which sites should open in Microsoft Edge. We recommend using one list for both browsers, where each policy points to the same XML file location.
The most straightforward way to build and manage your Enterprise Mode Site List is by using any generic text editor. However, we’ve provided a couple tools to make that process even easier.
Enterprise Mode Site List Manager
The first tool is called the Enterprise Mode Site List Manager. There are two versions: one for the old, v.1 XML schema, and one for the new, v.2 XML schema. This tool helps you create error-free XML documents, with simple n+1 versioning and URL verification. If your site list is of a relatively small size, this is the easiest way to manage your Enterprise Mode Site List.
On the other hand, if your site list is relatively large, you may encounter some difficulties with the client tool. It is not very scalable; it is designed for a single user. If you have more than one user managing your site list, there is the potential for overlap, among other complications.
The Enterprise Mode Site List Portal is a web tool originally built by our own IT department, now made open-source on GitHub. The web app is designed for IIS with a SQL Server backend, leveraging Active Directory for employee management. In addition to all the functionality of the client tool, the Enterprise Mode Site List Portal helps enterprises:
Manage site lists from any device supporting Windows 7 or greater;
Submit change requests;
Operate offline via an on-premise solution;
Provide role-based governance;
Test configuration settings before releasing to a live environment.
This new tool allows you to manage your Enterprise Mode Site List, hosted by the app, with multiple users. Updates are made by submitting new change requests, which are then approved by a designated group of people. Those updates are first made to a pre-production environment for testing, which can be rolled back if necessary. The final production changes can be deployed immediately, or scheduled for a later date. Users are notified of any updates in the request process via e-mail.
Already being used internally here at Microsoft, the Enterprise Mode Site List Portal has reduced site list management time by 65%. For some enterprises, processing a single change to their site list can take an entire week. What’s more, some enterprises have upwards of tens of thousands of entries in their site list. Using this new web tool can save you valuable time and expedite your modernization process.
Hopefully this helps illustrate the array of options to help manage legacy web apps in the enterprise. If you have any questions or concerns, please do not hesitate to reach out and ask. We are always looking for ways to improve your enterprise browsing experience!
Today, we’re thrilled to announce a partnership with BrowserStack, a leader in mobile and web testing, to provide remote virtual testing on Microsoft Edgefor free. Until now, developers who need to test against a specific version of Microsoft Edge have been limited to local virtual machines, or PCs with Windows 10 installed. However, there are many developers that don’t have easy access to Microsoft Edge for testing purposes.
BrowserStack Live Testing can run Microsoft Edge inside your browser on macOS, Windows, or Linux.
Today, we are excited to partner with BrowserStack, which provides the industry’s fastest testing on physical devices and browsers, so that you can focus on delivering customers the best version of your product or website. BrowserStack is trusted by developers at over 36,000 companies, including Microsoft, to help make the testing process faster and more accessible. Under this new partnership, developers will be able to sign into BrowserStack and test Microsoft Edge using their Live and Automate services for free.
Live testing provides a remote, cloud-based instance of Microsoft Edge streamed over the web. You can interact with the cloud-based browser just as you would an installed browser, within your local browser on any platform – whether it’s macOS, Linux, or older versions of Windows.
As testing setups are becoming more automated, we are excited to also offer BrowserStack’s Automate testing service under this partnership, for free. This method of testing allows you to run up to 10 Microsoft Edge test sessions via script, which can integrate with your local test runners via the standardized WebDriver API. You can even configure your machine so that the cloud-based browser can see your local development environment—see the Local Testing instructions at BrowserStack to learn more.
Testing Microsoft Edge in BrowserStack using WebDriver automation
To ensure you can test against all possible versions of Microsoft Edge that your users may be using, BrowserStack will be providing three versions of Microsoft Edge for testing: the two most recent “Stable” channel releases, and the most recent “Preview” release (via the Windows Insider Preview Fast ring).
BrowserStack currently serves more than 36,000 companies globally including Microsoft, AirBnB, and MasterCard. In addition to Microsoft Edge, the service provides more than 1100 combinations of operating systems and browsers and its Real Device Cloud allows anyone, anywhere to test their website on a physical Android or iOS device. With data centers located around the world, BrowserStack is trusted by over 1.6 million developers relying upon the service as it provides the fastest and most accurate testing on physical devices.
We’re very excited to partner with BrowserStack to make this testing service free for Microsoft Edge. Head over to BrowserStack and sign up to get started testing your site in Microsoft Edge today.
― Jason Weber, Director of Program Management, Microsoft Edge
Beginning with EdgeHTML 15 in the Windows 10 Creators Update, Microsoft Edge introduces support for CSS Custom Properties, a new primitive value type to fully cascade variables across CSS properties. You can preview CSS Custom Properties in Windows Insider Preview builds beginning with EdgeHTML 15.15061. Check out our Custom Properties Pooch demo to see them in action!
SASS/LESS and other pre-processors have been offering variables in CSS for years, which is one of the reasons why, in an informal poll, ~75% of polled web developers incorporate these tools in their day to day workflow. However, the biggest downfall of these tools is that they are effectively a “find & replace” of the specified value. This means that the variables can’t be updated without needing to recompile the stylesheets.
How to use Custom Properties
Here’s a practical example: setting up primary and secondary colors for your site.
Let’s look at what is happening here, to declare a new custom property you precede a valid ident with two dashes. In our example, we are setting up our color scheme by creating custom properties for our --primary and --secondary colors. Then to utilize these properties, we need to reference them using the var() function.
It’s worth noting that a custom property can store any valid CSS, so feel free to get creative with how you utilize them! For example, the following is a valid custom property:
A common use case for custom properties is in components. You may design a component, and you want to provide sensible defaults for all of your custom properties. Custom Properties follows the same pattern as other CSS values and allows you to set fallback values. Here’s an example:
This doesn’t work because blue is not a valid value for margin-top, but Custom Properties don’t know the syntax rules for properties they’re use in. All that matters is whether we have a value for --primary or not. Since we do have a value, we substitute it in, try to parse margin-top: blue, and discard it as invalid per normal CSS rules.
Custom property scoping
Custom Properties are scoped like other CSS properties, by harnessing the cascade. This is valuable when, for instance, a team might be collaborating to build components or aspects of a site. To illustrate, let’s take our previous example, and add in a component we’re building that also has its own --primary custom property:
This will result in a blue background for the body and a yellow background for the .my-component.
Detecting support for Custom Properties
It’s important to remember that CSS is designed to fail silently, so if a browser doesn’t support Custom Properties, you’ll only be able to see this if your styles have visual implications. An easy way to progressively enhance your site with Custom Properties is to provide different styles to browsers that don’t support Custom Properties. You can do this by wrapping your custom property work in a @supports declaration block.
It’s important to note that @supports only checks that --foo is syntactically correct, not that the property and value match what has been declared. For example, both the previous and following examples will result in the body having a green background in browsers that support Custom Properties, even though the current value for --foo is not false.
One of the primary benefits of native support for Custom Properties is the capability of dynamically modifying them via script. In order to do this you need to modify custom properties using the setProperty() and getPropertyValue() APIs. For example, to modify our --primary color on .my-component, we can do the following:
You can animate custom properties, but you can’t interpolate them. What exactly does it mean to be able to animate but not interpolate a custom property? Well, let’s take the following example:
Remember that you can store any valid ident in a custom property, so think of it as being stored as a string in an engine. The browser understands how to interpolate color: green to color: blue but it doesn’t know how to interpolate between “hello” and “world.” So, what does the browser do in the previous example? The browser takes the duration and assigns the possible values amongst the frames. For this example, that would result in a value of 50px for 500ms and 0 for the other 500ms; this is referred to in the spec as doing a 50% flip.
But I want them to interpolate!
We do too! The CSS Houdini Task Force is actively working on ways to make this happen with the Properties & Values API. If this work pans out, you’ll be able to register your custom property and inform the engine of its type, so that it can correctly interpolate values. Keep a look out for this API to start making its way into the wild, as browsers begin to experiment with these APIs to test their viability and help evolve the specification.
Improvements beyond Custom Properties
While working on our implementation of Custom Properties, we looked at a few demos that web developers had built. While some of them worked, others didn’t. When we reduced the broken demos to look for bugs, we narrowed the problems down to other gaps in our engine – not necessarily as a result of bugs in our Custom Properties implementation. For example, the largest gap we found was support for calc() within color functions (eg: rgb(), hsl()). Because this is an exciting use case where custom properties can be very powerful, we addressed this issue in our parser.
“A rising tide lifts all boats”
As we worked to fill gaps in our engine, we also wanted to be sure that web developers can rely on interoperable implementations for the feature to be useful. As we began our implementation efforts, we found that no browser had implemented the 50% flip behavior suggested in the specification for animating custom properties. Additionally, we found that no browser supported the capability of referencing variables via the var() function, within a keyframe at-rule. We worked with the CSSWG to resolve upon these issues and provide an implementation in Microsoft Edge.
Of course, the work in Edge is only one part of making sure the feature is interoperable. As we worked on our implementation, we found bugs in the implementations in existing browsers. As a result of this, we opened bugs against Blink, Gecko, and WebKit, and look forward to improved implementations across the board – including fixes shipping as early as Chrome 56 that will make Custom Properties more interoperable.
CSS Custom Properties not only solve a common developer request and makes your code more manageable, but it also unlocks a lot of potential for more creative work on the web. The future of the web looks bright and we’re just getting started. We’re excited to have CSS Custom Properties in the Windows 10 Creators Update, and can’t wait to see what you create!
We’re excited to announce the preview availability of the WebRTC 1.0 API, and support for the H.264/AVC and VP8 video codecs for RTC in Microsoft Edge, enabling plugin-free, interoperable video communications solutions across browsers and platforms.
Microsoft Edge introduced support for ORTC beginning in EdgeHTML 13 (Windows 10 version 1511), providing the initial foundation for real-time communications in Edge. Our priority with the WebRTC 1.0 API support is to provide interoperability with legacy implementations on existing websites, which leverage the WebRTC API as previously deployed in other browsers.
Our WebRTC 1.0 API implementation provides support for peer-to-peer audio and video based on a subset of the W3C WebRTC-PC API circa 2015, prior to the addition of the WebRTC object model. Because this implementation is focused on legacy interoperability (including mobile applications built from early versions of the WebRTC.org source code), we don’t plan to further update the native WebRTC 1.0 API beyond this release.
To utilize the most advanced features in the Microsoft Edge RTC stack, we recommend that considering the ORTC API, especially in situations where it is desirable to control individual transport, sender, and receiver objects directly, or to set up group audio and video calls. If you need support for objects or advanced features such as multi-stream and simulcast with the current WebRTC 1.0 API, we recommend the adapter.js library, which now supports Microsoft Edge.
The H.264/AVC and VP8 video codecs are supported in the Microsoft Edge RTC stack, which means video communications are now interoperable between Microsoft Edge and other major WebRTC browsers and RTC services. We have implemented the following congestion control and robustness mechanisms for both H.264/AVC and VP8 video codecs:
These features are available within both the ORTC API and native WebRTC 1.0 API, so you can make API and video codec decisions independently.
Note that while the Edge H.264/AVC implementation supports hardware offload within both the encoder and decoder, VP8 is implemented purely in software, and as a result may exhibit higher power consumption and CPU load. If your application uses VP8, we recommend testing on lower-end devices to ensure acceptable performance.
As we continue to chart our roadmap for real-time communications, our next priorities are adding support for the W3C Screen Capture specification, as well as improved support for enterprise scenarios. We look forward to sharing updates and preview builds as the work progresses. Meanwhile, we look forward to your feedback on WebRTC and our current RTC roadmap. You can try out WebRTC 1.0 in preview builds today, and if you encounter any bugs, share feedback on Microsoft Edge Platform Issues, via Twitter at @MSEdgeDev, or in the comments below.
― Shijun Sun, Principal Program Manager, Microsoft Edge
― Bernard Aboba, Principal Architect, Microsoft Skype
We are happy to introduce support for Content Security Policy Level 2 (CSP2) in Microsoft Edge, another step in our ongoing commitment to make Microsoft Edge the safest and most secure browser for our customers. CSP2, when used correctly, is an effective defense-in-depth mechanism against cross site scripting and content injection attacks.
This is available in the Insider Fast ring now starting with EdgeHTML 15.15002, and will ship to stable builds with the Windows 10 Creators Update.
Content Security Policy, supported in all versions of Microsoft Edge, lets web developers lock down the resources that can be used by their web application, helping prevent cross-site scripting attacks that remain a common vulnerability on the web. However, the first version of Content Security Policy was difficult to implement on websites with inline script elements that either pointed to script sources or that contained script directly.
CSP2 makes these scenarios easier by adding support for nonces and hashes for script and style resources. A nonce is a cryptographically strong random value generated on each page load that appears in both the CSP policy and in the script tags in the page. Using nonces can help to minimize maintaining a list of allowed source URL values, while also allowing trusted script declared in script elements to run.
In order to use a nonce in an existing template based web application a developer adds a nonce token for each of the trusted inline scripts:
&lt;script nonce=&quot;NonceToken&quot;&gt;alert(&quot;Allowed since NonceToken is declared&quot;)&lt;/script&gt;
&lt;script nonce=&quot;NonceToken&quot; src=&quot;https://trustedscriptsource.com.script&quot;&gt;&lt;/script&gt;
When the page is dynamically generated on load, the server generates a nonce value, inserts it into the NonceToken in the page and also declares it in the Content Security Policy HTTP header:
This CSP configuration allows script to be downloaded and executed from the page’s own domain, or from https://example.com. If a script source declaration in the page includes the correct nonce value, regardless of the source URL, that script can be downloaded and executed.
Script that does not meet these requirements would not even be downloaded by Microsoft Edge. In addition, any inline script that had the correct nonce value would be allowed to execute, but no other inline script would run.
CSP2 also adds support for the following:
The new directives base-uri, child-src, form-action, frame-ancestors and plugin-types are now supported. See supported CSP directives for more.
Background worker scripts are governed by their own policy, separate from the policy of the document loading them. As with host documents, you can set the CSP for a worker in the response header.
A new event, SecurityPolicyViolationEvent, is now fired upon CSP violations. As well, several new fields have been added to the violation report object including effectiveDirective (the policy that was violated), statusCode (the HTTP response code), sourceFile (the URL of the offending resource), lineNumber, and columnNumber.
CSP2 is an important step for Microsoft Edge to continue to improve the security stance and defense-in-depth capabilities of web application developers, but there’s plenty still to do. Next, we’ll focus on adding support for strict-dynamic from the CSP3 spec to enable developers and site administrators to reduce their reliance on whitelists and tighten their CSP implementations.
Another CSP directive on our radar is upgrade-insecure-requests. This directive is meant to make it even easier for a site administrator to move towards using all secure transports, while avoiding having to make massive updates to URL’s in their web applications.
A more secure web is better for developers, users, and browser vendors alike, and we would love to see more web applications taking advantage of the protections that CSP offers. A good resource for thinking through an implementation is Implementing Content Security Policy. Give it a try and let us know if you run into any issues in Microsoft Edge!
Beginning with EdgeHTML 15.14986, Microsoft Edge supports Brotli as an HTTP content-encoding method. This change will be released to stable builds with the Windows 10 Creator’s Update early next year, but you can preview it now via the Windows Insider Program. With this release, Brotli will be broadly interoperable across browsers, with support in the latest versions of Microsoft Edge, Firefox, and Chrome.
Brotli is a compression format defined in RFC 7932, previously available as part of the WOFF2 font format. When used as an HTTP content-encoding method, Brotli achieves up to 20% better compression ratios with similar compression and decompression speeds (PDF). This ultimately results in substantially reduced page weight for users, improving load times without substantially impacting client-side CPU costs. As compared to existing algorithms, like Deflate, Brotli compression is more efficient in terms of file size and CPU time.
In the current preview release, Microsoft Edge supports Brotli on HTTPS and HTTP connections. In a future preview release, we will update this behavior to only advertise Brotli support on HTTPS connections. Like Chrome, we will continue to decode Brotli content on HTTP connections. Note that in the current preview release, there is a known issue which results in the F12 Developer Tools incorrectly not showing the accept encoding response header. This is tracked as issue 9771399 on issues.microsoftedge.com.
As always, we welcome your feedback on Brotli in Microsoft Edge! Let us know on Twitter or in the comments below if you have any questions or issues. We’re very much looking forward to making the web just a little bit lighter with Brotli!
― Rob Trace, Senior Program Manager, Microsoft Edge
We’re thrilled to introduce a preview implementation of the Payment Request API in Microsoft Edge, enabling simpler checkout and payments on the web on Windows 10 PCs and Phones. Support for Payment Request in stable builds will be coming to EdgeHTML 15 in the Creators Update early next year.
Payment Request works with Microsoft Wallet on Windows 10 PCs and phones to make ecommerce faster and simpler for customers and merchants alike. You can begin to develop for the Payment Request API today in Microsoft Edge on preview builds, starting with Windows Insider Preview build 14986. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon.
Conversion rates in the checkout flow are a key measure for ecommerce sites. 46% of e-commerce shoppers abandon the checkout process during the payment phase, signaling frustration with the complexity and redundancy of re-entering form data or tracking down payment information. Even a small increase in the success rate of checkout make a direct impact on your site’s bottom line, while improving the shopping experience for customers.
In Microsoft Edge, the Payment Request API connects to Microsoft Wallet (with the user’s permission), allowing easy access to payment information associated with the user’s Microsoft Account. Because payment information is securely saved in a digital wallet, shoppers don’t have to navigate through traditional checkout flows and repeatedly enter the same payment and shipping address information repeatedly. The wallet can provide a faster and more consistent experience across websites, which saves shoppers time and effort by allowing them to securely share saved payment information.
How does it work?
Microsoft and the other members of the W3C Web Payments Working Group designed the API with the goal of standardizing communication across merchants, browsers, and payment methods to provide a better experience for users, and a single, consistent API for developers.
With the Payment Request API, payment information is provided by the wallet (once the user has granted consent), as opposed to being collected via a checkout form in the website. The browser mediates all the information passed between the wallet and the merchant.
Let’s look at how to implement the Payment Request API into a sample site.
We start with the constructor. The PaymentRequest object is constructed by passing the following parameters:
methodData: an array of dictionaries that contains the payment method identifiers and any pertaining data; a payment method identifier is a string that identifies a supported payment method
details: information about the transaction, such as the line items in an order
options: additional information that the Wallet may need to collect
In the snippet above, we are allowing users to pay with any debit or credit card that belongs to Visa, MasterCard, or Amex networks. The details object contains the subtotal amount, the sales tax, and the total due. These details will be shown to the user in the wallet. Please note that the API will not add up items or calculate the sales tax – it’s up to the merchant to provide the correct information. In this example, we are selling a physical good, so we’ll ask the wallet to collect the customer’s shipping address.
Showing the UI, processing the payment, and displaying the results
Once the PaymentRequest object is created, you can trigger the browser to display the wallet with request.show(). In Microsoft Edge, this will present the user with a checkout dialog from Microsoft Wallet:
Customers can then select the appropriate payment information, shipping address, and other fields, then click Pay when ready. At this point, the users will have to verify their identify. If successful, this will fulfill the request.show() promise and return to the website all the information that the customer provided to the Wallet. For the basic card payment method, the result object will contain the card holder name, card number, expiry month and other relevant fields. The merchant can then use this information to process the transaction on the backend.
After the response comes back from the server, you can use result.complete(‘success’) to display the success screen in the Wallet and result.complete(‘fail’) to indicate a failed transaction.
The price might change according to the shipping address and shipping options that the customer selects. You can listen to those changes with the shippingaddresschange and shippingoptionchange events to recalculate the prices accordingly.
The Payment Request API is on by default starting with the most recent Windows Insider Preview release (14986 or higher) on phone and desktop. The Microsoft Wallet user experience allowing for end to end testing will be available in an upcoming Insider build soon. During this preview period, Microsoft Wallet’s response for the basic card payment method will be a fake payment card response, to help developers perform early-integration testing without having to deal with the constraints of PCI.
Starting next Spring, the API will begin to return real payment card responses. Initially, the Wallet will support US billing and shipping addresses and the English language (en-US locale). Support for additional geographies and languages will be added in 2017.
Wrapping it up
Microsoft Wallet and the Payment Request API combine to provide a powerful tool for merchants to improve checkout conversion on the web, and to give customers a more pleasant and convenient shopping experience. This API is a great example of the power and flexibility of the web platform, and is on the road to broad interoperability, with Chrome for Android supporting the API starting with Chrome 54.