Tag Archives: Behind-the-Scenes

Register now for Microsoft Edge Web Summit 2017

Registration is now open for Microsoft Edge Web Summit 2017. Join the Microsoft Edge team in Seattle on September 13th for a jam-packed day of energetic technical sessions looking at what’s new, and what’s next, for the web on Windows. Space is limited and reservations are on a first-come, first-served basis, so book your seat today!

Duotone photo of Seattle with superimposed text reading "Microsoft Edge Web Summit 2017, September 13th, 2017, Seattle, WA"

Microsoft Edge Web Summit is a free conference presented by the engineers building Microsoft Edge. The main track consists of 14 jam-packed technical sessions, covering everything from performance, accessibility, and test guidance, to brand-new tools and APIs for building Progressive Web Apps on Windows, adding payments and biometric authentication to your sites, and building modern layouts with new CSS features like CSS Grid.

This year, we’re introducing a new Hallway Track, where you can meet with engineers from across Microsoft to solve real problems today, and build invaluable connections for the future. Looking to reduce a troublesome performance issue? Struggling with best practices for accessibility? Eager to get started with WebVR? Curious about Bash on Windows? We’ve got you covered. The Hallway Track connects you one-to-one with Microsoft engineers throughout the day for tangible results you can take back to your site or app.

We’re excited to meet developers around the world face to face, and look forward to seeing you here in Seattle, WA! Space is limited and reservations are on a first-come, first-served basis, so book your seat today. Can’t make it? Don’t worry – though there’s no substitute for attending in person, we’ll be streaming live on Channel 9 all day (no registration required), and recorded sessions will be available after the fact.

If you have any questions about the event, you can reach the event team on Twitter @MSEdgeDev or by email at edgesummit@microsoft.com. See you there!

Microsoft Edge Web Summit logo (two line-art alpine summits, with stylized angle brackets superimposed above them)

Kyle Pflug, Senior Program Manager, Microsoft Edge

Modernizing the DOM tree in Microsoft Edge

The DOM is the foundation of the web platform programming model, and its design and performance impacts the rest of the browser pipeline. However, its history and evolution is far from a simple story.

Over the past three years, we’ve embarked on an in-flight refactoring of the DOM in Microsoft Edge, with our eye on a modernized architecture offering better real-world performance and reduced complexity. In this post, we’ll walk you through the history of the DOM in Internet Explorer and Microsoft Edge, and the impact of our recent work to modernize the DOM Tree, which is already resulting in substantially improved performance in the Windows 10 Creators Update.

A diagram of the web platform pipeline, with the DOM Tree and cooperating components (CSS Cascade, DOM API & Capabilities, and Chakra JavaScript) highlighted.

What we think of as “the DOM” is really the cooperation of several subsystems. In Microsoft Edge, this includes JS binding, events, editing, spellchecking, HTML attributes, CSSOM, text, and others, all working together. Of these subsystems, the DOM “tree” is at the center.

Several years ago, we began a long journey to update to a modern DOM “tree” (node connectivity structures). By modernizing the core tree, which we completed in Microsoft Edge 14, we landed a new baseline and the scaffolding to deliver on our promise of a fast and reliable DOM. With Windows 10 Creators Update and Microsoft Edge 15, the journey we started is beginning to bear fruit.

Circular tree map showing "DOM Tree" at the center, surrounded by "JS Binding," "Editing," "Spellcheck," "Events," and "Attributes."

“The DOM” is really the cooperation of several subsystems that make up the web programming model.

We’re just scratching the surface, but want to take this opportunity to geek out a bit, and share some of the internal details of this journey, starting with the DOM’s arcane history and showcasing some of our accomplishments along the way.

The history of the Internet Explorer DOM tree

When web developers today think of the DOM, they usually think of a tree that looks something like this:

A diagram of a simple tree

A simple tree

However nice and simple (and obvious) this seems, the reality of Internet Explorer’s DOM implementation was much more complicated.

Simply put, Internet Explorer’s DOM was designed for the web of the 90s. When the original data structures were designed, the web was primarily a document viewer (with a few animated GIFs and other images thrown in). As such, algorithms and data structures more closely resembled those you might see powering a document viewer like Microsoft Word. Recall in the early days of the web that there was no JavaScript to allow scripting a web page, so the DOM tree as we know it didn’t exist. Text was king, and the DOM’s internals were designed around fast, efficient text storage and manipulation. Content editing (WYSIWYG) was already a feature at the time, and the manipulation paradigm centered around the editing cursor for character insertion and limited formatting.

A text-centric design

As a result of its text-centric design, the principle structure of the DOM was the text backing store, a complex system of text arrays that could be efficiently split and joined with minimal or no memory allocations. The backing store represented both text and tags as a linear progression, addressable by a global index or Character Position (CP). Inserting text at a given CP was highly efficient and copy/pasting a range of text was centrally handled by an efficient “splice” operation. The figure below visually illustrates how a simple markup containing “hello world” was loaded into the text backing store, and how CPs were assigned for each character and tag.

Diagram of the text backing store, with special positional placeholders for non-text entities such as tags and the insertion point.

The text backing store, with special positional placeholders for non-text entities such as tags and the insertion point.

To store non-textual data (e.g. formatting and grouping information), another set of objects was separately maintained from the backing store: a doubly-linked list of tree positions (TreePos objects). TreePos objects were the semantic equivalent of tags in HTML source markup – each logical element was represented by a begin and end TreePos. This linear structure made it very fast to traverse the entire DOM “tree” in depth-first pre-order traversal (as required for nearly every DOM search API and CSS/Layout algorithm). Later, we extended the TreePos object to include two other kinds of “positions”: TreeDataPos (for indicating a placeholder for text) and PointerPos (for indicating things like the caret, range boundary points, and eventually for “new” features like generated content nodes).

Each TreePos object also included a CP object, which acted as the tag’s global ordinal index (useful for things like the legacy document.all API). CPs were used to get from a TreePos into the text backing store, easily compare node order, or even find the length of text by subtracting CP indices.

To tie it all together, a TreeNode bound pairs of tree positions together and established the “tree” hierarchy expected by the JavaScript DOM as illustrated below.

Diagram showing the dual representation of the DOM as both text and (possibly overlapping) nodes

The dual representation of the DOM as both text and (possibly overlapping) nodes

Adding layers of complexity

The foundation of CPs caused much of the complexity of the old DOM. For the whole system to work properly, CPs had to be up-to-date. Thus, CPs were updated after every DOM manipulation (e.g. entering text, copy/paste, DOM API manipulations, even clicking on the page—which set an insertion point in the DOM). Initially, DOM manipulations were driven primarily by the HTML parser, or by user actions, and the CPs-always-up-to-date model was perfectly rational. But with rise of JavaScript and DHTML, these operations became much more common and frequent.

To compensate, new structures were added to make these updates efficient, and the splay tree was born, adding an overlapping series of tree connections onto TreePos objects. The added complexity helped with performance—at first; global CP updates could be achieved with O(log n) speed. Yet, a splay tree is really only optimized for repeated local searches (e.g., for changes centered around one place in the DOM tree), and did not prove to be a consistent benefit for JavaScript and its more random-access patterns.

Another design phenomenon was that the previously-mentioned “splice” operations that handled copy/paste, were extended to handle all tree mutations. The core “splice engine” worked in three steps, as illustrated in the figure below.

Timeline diagram of the splice engine algorithm

The splice engine algorithm

In step 1, the engine would “record” the splice by traversing the tree positions from the start of the operation to the end. A splice record was then created containing command instructions for this action (a structure re-used in the browser’s Undo stack). In step 2, all nodes (i.e., TreeNode and TreePos objects) associated with the operation were deleted from the tree. Note that in the IE DOM tree, TreeNode/TreePos objects were distinct from the script-referenced Element objects to facilitate overlapping tags, so deleting them was not a functional problem. Finally, in step 3, the splice record was used to “replay” (re-create) new objects in the target location. For example, to accomplish an appendChild DOM operation, the splice engine created a range around the node (from the TreeNode‘s begin TreePos to its end), “spliced” the range out of the old location, and created new nodes to represent the node and its children in the new location. As you can imagine, this created a lot of memory allocation churn, in addition to the inefficiencies of the algorithm.

No encapsulation

These are just a few of the examples of the complexity of the Internet Explorer DOM. To add insult to injury, the old DOM had no encapsulation, so code from the Parser all the way to the Display systems had CP/TreePos dependencies, which required many dev-years to detangle.

With complexity comes errors, and the DOM code base was a reliability liability. According to an internal investigation, from IE7 to IE11, approximately 28% of all IE reliability bugs originated from code in core DOM components. This complexity also manifested as a tax on agility, as each new HTML5 feature became more expensive to implement as it became harder to retrofit concepts into the existing architecture.

Modernizing the DOM tree in Microsoft Edge

The launch of Project Spartan created the perfect opportunity modernize our DOM. Free from platform vestiges like docmodes and conditional comments, we began a massive refactoring effort. Our first, and most critical target: the DOM’s core tree.

We knew the old text-centric model was no longer relevant; we needed a DOM tree that actually was a tree internally in order to match the expectations of the modern DOM API. We needed to dismantle the layers of complexity that made it nearly impossible to performance-tune the tree and the other surrounding systems. And finally, we had a strong desire to encapsulate the new tree to avoid creating cross-component dependencies on core data structures. All of this effort would lead to a DOM tree with the right model in place, primed and ready for additional improvements to come.

To make the transition to the modern DOM as smooth as possible (and to avoid building a new DOM tree in isolation and attempting to drop and stabilize untested code at the end of the project—a.k.a. the very definition of “big bang integration”), we transitioned the existing codebase in-place in three phases. The first phase of the project defined our tree component boundary with corresponding APIs and contracts. We chose to design the APIs as a set of “reader” and “writer” functions that operated on nodes. Instead of APIs that look like this:


our APIs looked like this:

TreeWriter::AppendChild(parent, child);

This API design discourages callers from thinking about tree objects as actors with their own state. As a result, a tree object is only an identity in the API, allowing for more robust contracts and hiding representational details, which proved useful in phase 3.

The second phase migrated all code that depended on legacy tree internals to use the newly established component boundary APIs instead. During this migration, the implementation of the tree API would continue to be powered by the legacy structures. This work took the most time and was the least glamorous; it took several dev-years to detangle consumers of the old tree structures and properly encapsulate the tree. Staging the project this way let us release EdgeHTML 12 and 13 with our fully-tested incremental changes, without disrupting the shipping schedule.

In the third and final phase, with all external code using the new tree component boundary APIs, we began to refactor and replace the core data structures. We consolidated objects (e.g., the separate TreePos, TreeNode, and Element objects), removed the splay tree and splice engine, dropped the concept of PointerPos objects, and removed the text backing storage (to name a few). Finally, we could rid the code of CPs.

The new tree structure is simple and straightforward; it uses four pointers instead of the usual five to maintain connectivity: parent, first-child, next, and previous sibling (last-child is computed as the parent’s first-child’s previous sibling) and we could hide this last-child optimization behind our TreeReader APIs without changing a single caller. Re-arranging the tree is fast and efficient, and we even saw some improvements in CPU performance on public DOM APIs, which were nice side-effects of the refactoring work.

Diagram of Microsoft Edge’s new DOM tree structure, showing all four possible pointers

Microsoft Edge’s new DOM tree structure, showing all four possible pointers.

With the new DOM tree, reliability also improved significantly, dropping from 28% of all reliability issues to just around 10%, and at the same time providing secondary benefits of reducing time spent debugging and improving team agility.

The next steps in the journey

While this feels like the end of our journey, in fact it’s just the beginning. With our DOM tree APIs in place and powered by a simple tree, we turned our attention to the other subsystems that comprise the DOM, with an eye towards two classes of inefficiencies: inefficient implementations inside the subsystems, and inefficient communication between them.

Circular tree map showing "DOM Tree" at the center, surrounded by "JS Binding," "Editing," "Spellcheck," "Events," and "Attributes."

The DOM tree is at the center of many cooperating components that make up the web programming model.

For example, one of our top slow DOM APIs (even after the DOM tree work) has historically been querySelectorAll. This is a general-purpose search API, and uses the selectors engine to search the DOM for specific elements. Not surprisingly, many searches involve particular element attributes as search criteria (e.g., an element’s id, or one of its class identifiers). As soon as the search code entered the attributes subsystem, it ran into a whole new class of inefficiencies, completely unrelated to those addressed by the new DOM tree.

For the attributes subsystem, we are simplifying the storage mechanism for element content attributes. In the early days of the web, DOM attributes were primarily directives to the browser about how to display a piece of markup. A great example of this is the colspan attribute:

     <td colspan="2">Total:</td>

colspan has semantic meaning to the browser and thus has to be parsed. Given that pages weren’t very dynamic back then and attributes were generally treated like enums, IE created an attribute system that was optimized around eager parsing for use in formatting and layout.

Today’s app patterns, however, heavily use attributes like id, class, and data-*, which are treated less like browser directives and more like generic storage:

<li id="cart" data-customerid="a8d3f916577aeec" data-market="en-us">
     <span class="total">$12.34</span>

Thus, we’re deferring most work beyond the bare minimum necessary to store the string. Additionally, since UI frameworks often encourage repeated CSS classes across elements, we plan to atomize strings to reduce memory usage and improve performance in APIs like querySelector.

Though we still have plenty of work planned, with Windows 10 Creators Update, we’re happy to share that we’ve made significant progress!

Show me the money

Reliably measuring and improving performance is hard and the pitfalls of benchmarking are well documented. To get the most holistic view of browser performance possible, the Microsoft Edge team uses a combination of user telemetry, controlled measurement real-world scenarios, and synthetic benchmarks to guide our optimizations.

Venn Diagram with three labelled circles: "User telemetry," "Synthetic benchmarks," and "Performance Lab"

User telemetry “paints with a broad brush”, but by definition measures the most impactful work. Below is an example of our build-over-build tracking of the firstChild API across our user base. This data isn’t directly actionable, since it doesn’t provide all the details of the API call (i.e. what shape and size is the DOM tree) needed for performance tuning, but it’s the only direct measurement of the user’s experience and can provide feedback for planning and retrospectives.

Screen capture showing Build-to-build user performance telemetry for firstChild

Build-to-build user performance telemetry for firstChild (lower is better)

We highlighted our Performance lab and the nitty-gritty details of measuring browser performance a while ago, and while the tests themselves and the hardware in the lab has changed since then, the methodology is still relevant. By capturing and replaying real-world user scenarios in complex sites and apps like Bing Maps and Office 365, we’re less likely to overinvest in narrowly applicable optimizations that don’t benefit users. This graph is an example of our reports for a simulated user on Bing Maps. Each data point is a build of the browser, and hovering provides details about the statistical distribution of measurements and links to more information for investigating changes.

Screen capture showing build to build telemetry from the Performance Lab

A graph of build-over-build performance of a simulated user on Bing Maps in the Performance Lab

Our Performance lab’s fundamental responsibility is to provide the repeatability necessary to test and evaluate code changes and implementation options. That repeatability also serves as the platform for synthetic benchmarks.

In the benchmark category, our most exciting improvement is in Speedometer. Speedometer simulates using the TodoMVC app for several popular web frameworks including Ember, Backbone, jQuery, Angular, and React. With the new DOM tree in place and other improvements across other browser subsystems like the Chakra JavaScript engine, the time to run the Speedometer benchmark decreased by 30%; in the Creators update, our performance focus netted another improvement of 35% (note that Speedometer’s scores are a measure of speed and thus an inverse function of time).

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.

Release-over-release performance on the Speedometer benchmark (higher is better)

Of course the most important performance metric is the user’s perception, so while totally unscientific, we’ve been super excited to see others notice our work!

We’re not done yet, and we know that Microsoft Edge is not yet the fastest on the Speedometer benchmark. Our score will continue to improve as a side effect of our performance work and we’ll keep the dev community updated on our progress.


A fast DOM is critical for today’s web apps and experiences. Windows 10 Creators Update is the first of a series of releases focused on performance on top of a re-architected DOM tree. At the same time, we’ll continue to improve our performance telemetry and community resources like the CSS usage and API catalog.

We’re just beginning to scratch the surface of what’s possible with our new DOM tree, and there’s still a long journey ahead, but we’re excited to see where it leads and to share it with you! Thanks!

Travis Leithead & Matt Kotsenas, Program Managers, Microsoft Edge

Better battery life with Microsoft Edge

There’s a good chance you’ve noticed that Microsoft Edge and other popular browsers have recently been focused on improving battery life. We’ve been paying particular attention to this with Windows 10, and the response has been great. Windows users spend more than half their time on the web, so improvements here have a significant effect on your device’s battery life.

We’re committed to giving you the best, fastest, and most efficient browser possible. In this post, I’ll share some of the new energy efficiency improvements available with the Windows 10 Creators Update.

Comparing the latest versions of major browsers on Windows, the trends are similar to what we’ve seen with previous releases. According to our tests on the Windows 10 Creators Update – based on an open-source test which simulates typical browsing activities across multiple tabs – Microsoft Edge uses up to 31% less power than Google Chrome, and up to 44% less than Mozilla Firefox.

Bar chart measuring power consumed by Microsoft Edge and the latest versions of Chrome and Firefox. Microsoft Edge uses 31% less power than Chrome 57, and 44% less power than Firefox 52.

Direct measurements of average power consumption during typical browsing activities (source code).

Let’s dive in to some details of how we measure power consumption to optimize for battery life, and how we’re engineering Microsoft Edge to be the most efficient browser on Windows 10.

Our approach: open, transparent, and reproducible

Measuring and improving battery life are both complicated problems, and while we want to show off our leadership here, we also want to be a part of a constructive dialog that improves the entire web. That’s why we always share our measurements alongside filmed rundown tests, or through open source tests freely available on GitHub. These tests are repeatable by other browsers or curious users, backed by methodology documents and open source code.

One of the most important tools for our energy efficiency engineering is BrowserEfficiencyTest. It automates the most important tasks that people do with their browser, and runs through those tasks while measuring how much power a device is consuming, as well as how hard the CPU is working, how much traffic is being sent over the network, and more. It can be used to look at specific sites and patterns, or measure complex workloads composed of many different sites in multiple tabs. This test supports Microsoft Edge as well as Google Chrome and Mozilla Firefox, so we can compare results across browsers over time.

Surface Books instrumented for direct power measurement, running a looping browser test in a performance lab.

Surface Books instrumented for direct power measurement, running a looping browser test in a performance lab.

Using an open test has also enabled us to work closer with partners to deliver a better experience to you. As we built the Windows 10 Creators Update, we collaborated with hardware teams like Surface and Intel to understand what’s going on at the hardware level when you’re on the web. By designing the software and the hardware to work with each other, we can make your device run even faster and last even longer.

Battery life improvements in the Windows 10 Creators Update

Our improvements in EdgeHTML 15 are focused not only on improving the average power consumption in Microsoft Edge, but also making it more consistent. The below chart shows the 90th percentile power consumption during a multi-tab workload that went through email, social media, video, news, and more.

Bar chart comparing Edge power consumption in the Anniversary Update and in the Creators Update. In the Creators Update, Edge uses 17% less power at the 90th percentile.

As you can see, the 90th percentile has improved by 17% from the previous version of Microsoft Edge to the latest version. What does this mean for you? You can be more confident about getting consistent, all-day battery life with Microsoft Edge.

Let’s look at the specific things we’ve improved:

iframes are more efficient

Today, lots of web content is delivered using iframes, which allow web authors to embed documents (even from different origins) within their own webpages. This is a flexible, powerful, and secure tool used on many popular sites, often in the context of advertisements or embedded content. Iframes are essentially small webpages contained inside another web page.

Until now, these mini-webpages have been able to run JavaScript timers and code without restriction, even when you can’t see them. An iframe down at the bottom of an article could be running code, measuring if it’s visible, or performing animations while you’re still reading the headline at the top. With this release, we’ve made Microsoft Edge much more intelligent, throttling the JavaScript timers for iframes that aren’t visible, and stopping them from calculating animations that will never be seen. Users won’t notice any difference: the iframes still load and behave normally when you can see them. We’re simply reducing the resources they consume when they’re not visible.

Hit testing is more efficient

A common pattern we’ve found on sites is that pieces of a webpage want to know if they’re visible to the user or not, referred as hit testing. This is necessary for advertisers to judge the effectiveness of ads, as well as for creating infinite scrolling lists and other advanced layouts. In the past, this has been computationally expensive, especially since it’s done a lot. Sometimes, elements on a page will check to see if they’re visible on every frame, 60 times per second.

With the Creator’s Update, we’ve reworked what happens when the webpage needs to know if iframes or other elements are visible. We’ve added an additional layer of caching and optimizations to perform this common operation with less CPU and less power. Web developers don’t need to do anything different to take advantage of these improvements, and users won’t notice any difference, other than a faster experience and more battery life.

Intersection Observer

On top of these improvements, we’ve implemented a standards-based framework for webpages to accomplish the same thing without needing to constantly check for visibility themselves. This framework is called Intersection Observer; it’s supported by other major browsers and is documented with a working draft through the W3C.

When websites and ads take advantage of Intersection Observer, Microsoft Edge will do the work for them, calculating if they intersect with the main viewport or any other element. The page will be notified when any element’s intersection with the viewport changes, so constantly checking on every frame is no longer required. This is a much more efficient pattern, and will make the web better for everybody.

Encouraging HTML5 over Flash

In the Creator’s Update, we’re giving users even more control over their experience and helping transition the web to more secure, standards-based, and energy-efficient content by encouraging HTML5 over Flash and giving users control over where Flash is allowed to run. Not only is this good for battery life, but it will help improve security, speed, and stability.

Screen capture of a prompt in Microsoft Edge reading "Adobe Flash content was blocked."

Countless efficiency improvements based on telemetry

As with any release, we’re tweaking and improving what’s happening under the hood in Microsoft Edge. Recently, we’ve been using telemetry from real devices to measure how much time we’re spending responding to different APIs in JavaScript. This view tells us which functions we spend the most total time responding to across all devices, so we can improve those first and get the most bang for our buck.

Screen capture showing aggregated telemetry measuring how much time we’re spending responding to different APIs in JavaScript.

An interesting note: the top 10 functions account for about 50% of the total time that JavaScript spends waiting for Microsoft Edge to respond. Using this data, we’re improving not only battery life, but making webpages feel faster and snappier as well.

What’s next?

As always, this work is a step in our ongoing journey to improve your experience on the web and maximize what you can get out of your browser and your device. When it comes to making Microsoft Edge faster and more efficient, we’re never done! We look forward to continuing to push the limits of efficiency, speed, and battery life in upcoming releases.

– Brandon Heenan, Program Manager, Microsoft Edge

What’s new in Microsoft Edge in the Windows 10 Creators Update

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.

Web developers can start testing EdgeHTML 15 today by updating their Windows 10 device, or by downloading a free virtual machine from Microsoft Edge Dev. You can also test Microsoft Edge for free in BrowserStack, which offers instant cloud-based testing from a Mac or PC, including WebDriver automation. BrowserStack will be updated to include the final release of EdgeHTML 15 in the coming weeks.

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.

Find ebooks in the Microsoft Edge Hub

You can find books in the new “Books” section of the Microsoft Edge Hub, and a wide selection of books for every taste in the Windows Store.

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.

More efficient, more responsive, and more secure

We’ve made no secret of our ongoing obsession with making Microsoft Edge get more out of your battery, run the web faster, and keep you safer. We’ve been busy on these fronts, and EdgeHTML 15 is better than ever by any measure.

Pushing the frontier of energy efficiency

In the Creator’s Update, we’re taking the longest-lasting browser on Windows and supercharging it yet again. Thanks to major improvements in Microsoft Edge, like encouraging HTML5 content over Flash, improving the efficiency of iframes, and optimizing hit testing, Microsoft Edge on the Creators Update uses 31% less power than Google Chrome 57, and 44% less power than Mozilla Firefox 52, as measured by our open-source efficiency test that simulates real-world browsing.

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

In the past, we’ve been happy to share our leadership in synthetic JavaScript benchmarks like Google’s Octane benchmark, Apple’s Jet Stream, and others. Microsoft Edge continues to lead by those measures, but ultimately any single benchmark can only tell part of the story. In EdgeHTML 15, we’ve focused on making Microsoft Edge feel faster and more responsive, even when the page may be busy or hung, by prioritizing the user’s input above other activity, and optimizing rendering for real-world scenarios.

Comparing scrolling on a busy page, before and after the input responsiveness improvements in EdgeHTML 15.

These improvements dramatically reduce input blocking on busy sites – put simply, the browser responds much more quickly to user input like clicking links or scrolling with the keyboard, even when a page may be busy loading or executing JavaScript in the background.

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.

Screen capture of a Microsoft Wallet dialog box with shipping and payment information.

This 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. Learn more about the Payment Request API in our blog post, Simpler web payments: Introducing the Payment Request API, or see the Payment Request API samples on Microsoft Edge Dev.

CSS Custom Properties

CSS Custom Properties (formerly called CSS Variables) are a new primitive value type to fully cascade variables across CSS properties. Custom Properties enable the same fundamental use cases as variables in CSS pre-processors, but have the additional benefits of being fully cascaded, being interacted with via JavaScript, and not requiring the additional build step to work. Learn more about CSS Custom Properties in our blog post, CSS Custom Properties in Microsoft Edge, or see Custom Properties Pooch: a Microsoft Edge demo on Microsoft Edge Dev.

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.

And lots more…

There’s simply too much to list in one post – the list goes on with features including WebRTC, async-await, TCP Fast Open, Intersection Observer, experimental support for WebAssembly, and more. You can find the full list of what’s new in the Microsoft Edge Dev Guide, or a comprehensive view of which standards are supported, planned, or in preview at Microsoft Edge Platform Status.

Built in the open

We’re proud to continue building Microsoft Edge in the open, using the voice of our community to drive product planning, and sharing our roadmap transparently. Windows itself is on an exciting journey with 10 million Insiders. These initiatives are better together – Windows Insiders are essential to building Microsoft Edge faster and with better quality, and Windows itself has been able to leverage tools like Microsoft Edge Platform Status and Microsoft Edge Platform issues – for the first time launching an open backlog and bug tracker for the Windows platform.

The voice of our community is helping us chart the course for 2017 and beyond. Nolan Lawson recently shared a look at the top highest-rated CSS features on the Microsoft Edge UserVoice:

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

You can try Microsoft Edge on the Windows 10 Creators Update today! If you’re on a Windows 10 device, simply check for updates – see the instructions here for more details. If you’re on another platform, you can test EdgeHTML 15 instantly for free via BrowserStack, or download a free virtual machine from Microsoft Edge Dev.

Kyle Pflug, Senior Program Manager, Microsoft Edge

Strengthening the Microsoft Edge Sandbox

In a recent post, we outlined the layered strategy that the Microsoft Edge security team employs to protect you from vulnerabilities that could be used to compromise your device or personal data. In particular, we showed how Microsoft Edge is leveraging technologies like Code Integrity Guard (CIG) and Arbitrary Code Guard (ACG) to break some of the techniques that hackers rely on when exploiting vulnerabilities to obtain Remote Code Execution (RCE). This is where the attacker seeks to escape from web code (JS and HTML) in the browser to run native CPU code of the attacker’s choosing. This lets the attacker violate all of the browser’s rules for the web, such as same-origin policy, and so it is important to web users that we try as hard as possible to block RCE attacks.

However, despite our best efforts, sometimes attackers get RCE anyway. In this post, we’ll explore some of the significant improvements we’ve made in the Windows 10 Creators Update to strengthen our next line of defense: the Microsoft Edge sandbox.

The history of the Microsoft Edge sandbox

Because RCE can happen, and in the past, often did, browser vendors have sought to sandbox the browser to defend the rest of the user’s PC from attack. In 2007, IE7 introduced Protected Mode, the first web browser sandbox. Windows 8 added app container to the OS, primarily to support the new Windows Store app model and support the confidence promise that apps are safe to use. IE10 and IE11 leveraged app container to create EPM (Enhanced Protected Mode) a stronger browser sandbox. However, the EPM sandbox restrictions were incompatible with older ActiveX controls that predated app container, and so EPM was provided as a security enhancing option.

Microsoft Edge does not support ActiveX, so it is able to run entirely inside app container sandboxes at all times. Since the beginning, Microsoft Edge has used several app containers. At first there was a parent app container for the Manager, which created a small number of additional app containers to host content from the internet separate from intranet content. The Windows 10 Anniversary Update moved Flash into its own, separate AC. Today the Microsoft Edge app container model looks like this:

Diagram of the Microsoft app container structure. A manager app container governs individual app containers for the Internet, Intranet, Extensions, Service UI, and Adobe Flash.

The Manager provides browser features such as the URL bar, the back button, tabs, and your favorites list. The other app containers are:

  • Internet AC: hosts content from Internet sites.
  • Intranet AC: hosts content from Intranet sites. For enterprise users, that is enterprise web sites. For consumers, that is “web sites” that are control interfaces for devices on your home network, such as your Wi-Fi router, or IoT devices. Separating this RAC from the Internet e.g. protects your home Wi-Fi router from Internet attackers.
  • Extensions AC: hosts the new extensions for Microsoft Edge.
  • Flash AC: hosts the Adobe Flash player, to isolate it from the main content processes.
  • Service UI AC: hosts special web pages, such as about:flags, and the default home page.

The Internet AC is where the action is. Its job is to host web pages from anywhere, including the JS code provided by that web page, images, and multimedia. Hosting web pages is extremely complex, due to the richness of the modern web; this is the platform of the Internet, and developers need to be able to create any application and run it in this environment. Because it is complex, and hosts web pages from anywhere, this is where web security attacks begin. A malicious web site presents content intended to exploit bugs in the content hosting system, to take over control of the content process.

If an attacker gains control of an Internet AC process, they need to find some way to achieve their goals. If their goals involve compromising the user’s device or personal data stored on the device, then they’ll need to contend with escaping from the sandbox first.

Reducing the attack surface of the Microsoft Edge sandbox

One of the most effective ways to eliminate vulnerabilities in complex applications is to minimize the amount of code that an attacker can try to find vulnerabilities in. This is often referred to as attack surface reduction and it is a key tactic in our overall strategy security. To this end, Microsoft Edge in the Creators Update of Windows 10 has significantly reduced the attack surface of the sandbox by configuring the app container to further reduce its privilege.

To understand how we tuned the Microsoft Edge AC, it is first necessary to know how app container itself works. An app container process is deny-by-default for any secured object unless the object security descriptor has an allow access control entry (ACE) that would permit the app container to have access. There are three kinds of SIDs that can be used in such ACEs:

  • Capabilities: if a Capability SID based allow ACE is in the security descriptor, and the requesting AC has that Capability SID in its token, then it gets access. E.g. Webcam-related devices are accessible to processes that have the WEBCAM Capability SID such as Microsoft Edge.
  • AppID SIDs: if a specific AppID SID based allow ACE is in the security descriptor, and the requesting AC is that specific AppID, then it gets access. The main use for this is per-app storage, which uses the AppID of that app in the security descriptor, ensuring that its storage is private to that app.
  • “ALL APPLICATION PACKAGES” (“AC” SID): this is the AC wild card, allowing all app containers to access the resource. The “AC” SID exists so that Windows can provide an app platform that is useful to developers, allowing rich UWPs in the Windows Store. For instance, most of the WinRT API surface is open to the “AC” SID, so that all UWP apps can access the WinRT APIs.

The Microsoft Edge AC has been made different in only one way: the “AC” SID is not sufficient to let a requesting process access a resource. To get access, the AC must either have a matching Capability SID, or be precisely one of the named AppIDs in the security descriptor.

Thus the AC loses access to the entire WinRT API set, and every other resource that app containers normally can access. That’s great for security, with the slight problem that it would break everything about the browser, turning it into a highly secure brick.

Diagram showing the AC access scope. The Edge content process only has access to a specific subset of the AC access scope, based on capabilities.

Microsoft Edge “Tuned” AC

Diagram of a normal app container, consisting of a full AC access scope authorized by the AC SID.

“Normal” app container

So to make Microsoft Edge work again, we used specific Capabilities to light up specific areas of functionality. For instance, we created a Capability that enables COM to work. We similarly added other new capabilities, granting access to specific resources, until Microsoft Edge worked again. Then we added some telemetry to detect access control failures for the content process and shared it to users in the Windows Insider Program (WIP) to ensure that we had granted access to all resources needed for all scenarios.

What we just did here was to create a tuned sandbox for the Microsoft Edge content process, with a much tighter fit to the functional needs of the software than a normal app container provides. That is a lot of work, which is why this is not how the UWP platform works. But because web browsers are among some of the most threatened software there is, it is worth it in this case.

We repeated this work of hand-tuning a sandbox for the Flash AC, because it also is subject to a lot of attacks. Placing Flash in a tighter sandbox complements our work in this release to make Flash be click-to-run.

Making it more difficult to exploit sandbox escape vulnerabilities

The main threats in a sandbox are the broker interfaces that provide access to resources according to a defined policy. So why have brokers at all? Brokers exist to grant access according to policy, e.g. the File broker allows a website to say “upload a file by browsing your files” and the user gets to pick the file to be uploaded, without giving the web site access to all of the user’s files.

Brokers are a threat to sandboxes because brokers are code (and therefore can have bugs) and because the brokers run outside the sandbox. If an attacker can hack a broker and run code in the broker, then the attacker can escape, similar to an inmate mugging a prison guard and then putting on the guard’s uniform to escape.

The tightened Microsoft Edge content process sandbox cuts off access to many brokers (reduced attack surface) but leaves the needed brokers accessible (residual threat). An attacker might try to exploit bugs in the accessible brokers to elevate privileges and execute arbitrary native code in the broker, and thus escape. To mitigate this threat, we have applied many of the same exploit mitigation technologies to the brokers that provide service to Microsoft Edge.

Microsoft Edge also has some surprising brokers, because the exploit mitigation work forced several components to move out-of-process (OOP), including the Chakra JIT code generator and the Flash runtime process. These components had to move out of process because they necessarily do code generation (JIT) and that is not compatible with the ACG mitigation applied to the content process. Thus, these components function as the “JS code generator” broker and the “Run Flash bytecode” broker.

They can be viewed as brokers precisely because they have permission to do something that the content process is not permitted to do for itself. They are also a threat, because an attacker that can gain control of OOP JIT or the Flash sandbox could e.g. create executable code and use that for further exploitation, bypassing ACG. Because they are a threat, we have also have put these processes into tuned, less privileged app containers, again with a custom-crafted container profile built from capabilities.

Impact to attackers

Making the Microsoft Edge content process run in this tighter sandbox reduces the sandbox attack surface, but by how much? As it turns out, the reduction is quite significant:

  • 100% reduction access to MUTEXes: allow a process to lock up a resource, causing hangs.
  • 90% reduction in access to WinRT and DCOM APIs: this is the large win here, dramatically reducing Microsoft Edge’s attack surface against the WinRT API set.
  • 70% reduction access to events and symlinks: symlinks are especially interesting, because they are often used in creative bait & switch attacks to escape sandboxes.
  • 40% reduction in access to devices: Windows supports many device drivers, and their quality is somewhat beyond Microsoft’s control. The tuned sandbox cuts off access to any device that Microsoft Edge does not explicitly need, preventing attackers from using vulnerabilities in device drivers to escape, or from abusing the devices.

While attack surface reduction does not guarantee that an attacker cannot escape the sandbox, it does dramatically reduce the opportunities for attack, much like reducing the number of windows and doors in a fortress. In addition, the enabling of additional exploit mitigations for the brokers that Microsoft Edge is legitimately able to access also increases the difficulty of exploiting vulnerabilities that remain.


Security is a process, not a destination, so we will continue to invest in both RCE and sandbox mitigations for Microsoft Edge. These exploit mitigations combined with the strengthened sandboxing should make Microsoft Edge significantly more work for attackers to exploit, and thus discourage attackers from trying in the first place.

Crispin Cowan, Senior Program Manager, Microsoft Edge

Balancing user-friendliness and developer convenience

As a part of our mission to make the web a better experience for all Windows customers, we spend a lot of time looking for ways to improve the Microsoft Edge user experience for end users and developers alike.

Introducing a “soft developer mode” for Microsoft Edge

Starting with the Windows 10 Anniversary Update, we introduced a change to how developer items are represented in the Microsoft Edge context menu. This change is designed to reduce end user confusion and accidental invocation of the F12 Developer Tools, while preserving full fidelity for developers and minimizing the need for settings toggles.

Graphic showing the new right-click context menu in Edge, which removes "Inspect element" and "view source" by default.

The Windows 10 Anniversary Update introduces a “soft developer mode,” which disables context menu entries for the F12 Developer Tools by default. Developer-specific options like “View Source”, and “Inspect Element” are hidden, but developers will still be able to open the developer tools using the keyboard shortcuts (F12 & CTRL+SHIFT+I) or from the “…” menu in Microsoft Edge.

The first time a user invokes the F12 Developer Tools, they will be alerted that the developer tools have been enabled and developer options will be shown in the context menu, with an option to undo the change.

Screen capture showing the prompt to keep "inspect element" and "view source" in the context menu after opening the developer tools.

This setting can also be configured manually in about:flags:

About-flags settings for developer tools

The motivation and data behind this change

In recent customer studies, we found many non-developer users of Microsoft Edge were confused by accidentally invoking the F12 Developer Tools. Specifically, we saw user confusion about the “Inspect element” item in the right-click context menu. Correlating this feedback with our telemetry data, we found a significant number of sessions lasting less than 15 seconds in duration with 5 or less actions taken within the F12 Developer Tools. This usage pattern made it clear to us that there was room for improvement.

Chart showing F12 duration in seconds. By session count, many sessions are clearly accidental, with session lengths under 60 seconds.

We expect this change to provide a better experience to the overwhelming majority of Microsoft Edge users, while surfacing developer context menu items in a convenient and persistent way to the users who need them – the web is for everyone, not just developers.

We look forward to any feedback on this change in the comments below or on Twitter @MSEdgeDev.

Kenneth Auchenberg, Program Manager, Developer Tools

A peek into the WebAssembly Browser Preview

Following the introduction of asm.js, we have been working with other browser vendors including Mozilla, Google, Apple, along with the rest of the WebAssembly community group, to push the performance boundary of the web with WebAssembly. WebAssembly is a new, portable, size- and load-time-efficient binary compiler target, which promises near-native performance on the web.

As the community group comes close to consensus over the final design of the MVP (minimum viable product) release, we are pleased to share that the WebAssembly standard is in browser preview and invite the community to provide feedback on the WebAssembly design. We’re continuing to make progress towards a public preview implementation in Microsoft Edge, and today we’re excited to demonstrate WebAssembly in our internal builds.

The Browser Preview

The WebAssembly browser preview is effectively a release candidate for MVP, and includes the latest:

  • Binary format, generalized from previous AST formats to a more efficient stack machine format;  a more compact binary format generally means better loading time.
  • Equivalent human-readable text format for the purpose of reading, debugging, and occasionally handwriting WebAssembly.
  • Built-in JavaScript APIs to integrate WebAssembly modules to the web platform.
  • Up-to-date tools to produce WebAssembly modules, such as the Emscripten/Binaryen toolchain to convert C++ source to asm.js to WebAssembly, and WABT to convert between text and binary format.

To give you a taste of what WebAssembly looks like now, here is an example C++ recursive factorial function with its corresponding WebAssembly:

C++ factorial WebAssembly factorial function body
binary   | text
int factorial(int n)
  if (n == 0)
    return 1;
    return n * fac(n-1);
20 00    | get_local 0
42 00    | i64.const 0
51       | i64.eq
04 7e    | if i64
42 01    |   i64.const 1
05       | else
20 00    |   get_local 0
20 00    |   get_local 0
42 01    |   i64.const 1
7d       |   i64.sub
10 00    |   call 0
7e       |   i64.mul
0b       | end

The WebAssembly factorial function is extracted from the WebAssembly spec test.

We are eager to hear feedback from the community on WebAssembly. App authors should still expect changes and recompilation of apps for the MVP release, but any feedback from developing an app during the preview will help us make a better standard.

Implementation Progress in Microsoft Edge

We’ve been hard at work developing support for WebAssembly in Microsoft Edge at the open-source ChakraCore project repo. Microsoft Edge and ChakraCore are close to shipping the browser preview, which we expect to come when the full JavaScript APIs are implemented.

To demo the current capability of ChakraCore, we are also excited to showcase the AngryBots demo (with an updated WebAssembly binary) running in an internal build of Microsoft Edge. The demo loads faster than earlier versions compiled to asm.js or older WebAssembly formats, due to a more compact binary and ChakraCore’s new ability to defer parsing WebAssembly functions.

Over the next couple of months, our team will be focused on bringing the browser preview to Microsoft Edge. We look forward to continuing to contribute to the standardization of WebAssembly with the other browser vendors and the community, and would love to hear your thoughts about WebAssembly via @MSEdgeDev and @ChakraCore, or on the ChakraCore repo.

Limin Zhu, Program Manager, Chakra

Building in 10k: Designing for Optimization and Performance

Editor’s note: This is the third in a series of posts from the team that built the 10k Apart contest page, exploring the process of building for interoperability, accessibility, and progressive enhancement in less than 10kB.

In the previous post in this series, I talked a lot about how the 10k Apart contest began to take shape in terms of markup. While I was busy doing that, Stephanie Stimac was tucking into the project form the design end of things.

I’ll step back for a bit and let he talk about her process.

Where do I begin?

As I started poking through the wireframes and information architecture documents for the 10k Apart website, I realized I would have to approach this a little bit differently than other microsites I’ve designed in the past. I knew I needed to keeping the code light and avoid excessive use of unique margins, padding, fonts, and font sizes. I needed to identify the patterns in the wireframes and focus on creating shared properties where possible—font-family, font-size, margin, and padding. Consistency and repetition would be key in keeping the CSS as small as possible.

Incidentally, consistency is a key tenet of design, so we had some solid alignment there.

With this in mind I set about creating three “themes” in Illustrator, following the style tiles approach championed by Samantha Warren. I’ll circle back to the style tiles, but first I want to touch on a few other things that I was thinking about during the design process.

What can I do in terms of typography?

10kB is not a lot to work with when you start to think about fonts. Heck, most fonts clock in at double or triple that weight for a single face! Custom fonts were out the window. Instead, I focused on picking a pair of fonts—serif and sans-serif—that were web safe, were system fonts, or had a similar looking fallback font.

I considered Times New Roman—for a hot second—as the primary header and logotype font, but my personal aesthetic could not allow it. Georgia is thicker and softer around the edges. It sits a little more heavily on the page. But in the event Georgia isn’t available, falling back to Times New Roman wouldn’t be the worst thing in the world. We took it a but further though and came up with a well-supported font stack for all serif text:

font-family: Georgia, Times, "Times New Roman", serif;

For body copy and other content blocks longer than a headline, my original style tiles used Arial. It’s pretty universally supported (and almost equally despised). In the end, though, we realized we could offer something a little better to our readers and built a stack around Segoe UI. We still use Arial in the rather exhaustive fallback list though:

font-family: "Segoe UI", Frutiger, "Frutiger Linotype",
             "Dejavu Sans", "Helvetica Neue", Arial,

If you’re looking to use default fonts like this, CSS Font Stack is an incredibly useful resource. It contains information about availability on both Windows and Mac and offers suggestions for alternatives as well as font size recommendations.

Screen capture showing Font Stacks, with title and body text styles open in a selection of different fonts.

Can I compress colors?

Color was a little bit trickier to work with. The color scheme is limited to three main colors with either a shade or a tint of one of those as an alternative for hover events, so you know when you’ve hovered or clicked on an item. I chose a limited palette, again, in order to reduce the amount of code it would require to build.

Once I picked my colors, I took things a bit further—some might say too far ;-)—and tuned them to create hex codes that were either alternating characters (e.g., #232323) or that used only a three-character hex code (e.g., #ccc).

The light and dark greys were not a problem; they were easy to pick with alternating characters. The initial blue and orange swatches took more time to match up with a three-digit hex code. When I converted the six-digit code to a three-digit code, the color difference was sometimes staggering. So I went through and tweaked a few of my initial colors in order to get as close as possible to the ones I wanted.

Of course, through all of this I was checking my color contrast to ensure the design would not cause accessibility issues. This led to further color adjustments along the way. Our goal in terms of color contrast was WCAG Level AA and we were able to achieve that. Of course it helped that we used rather large fonts across the board—a font size equivalent of 20px was our baseline.

Screen capture of Lea Verou's Contrast Ratio checker, showing contrast ratio comparisons for different color pairs.

Lea Verou’s Contrast Ratio tool.

How many themes should I create?

Even with all of these constraints, I had a bunch of ideas for how the site could look. I ended up sharing three approaches with the team, using style tiles to convey how each would apply to the various patterns and components throughout the site. They all shared many characteristics, but with varying color palettes, different header designs, and slightly different typography (Georgia rather than Times New Roman, for instance). As I was very confident in the overall design of patterns like projects, forms, and such, color was the primary differentiator across the three themes.

The green monochromatic style was developed after looking at An Event Apart and the original 10k Apart website from 2010. The colors were mostly muted with the exception of the buttons, which were red to draw your eye. Ultimately this direction didn’t provide enough contrast between elements with the monochromatic scheme.

Using that as a baseline, I created an alternate approach with a more serious, rigid tone. This option provided more contrast between the green and gold. I brightened up the green because the muted green did not offer enough contrast with the gold. I also introduced a dark grey to help punch up the contrast between elements.

The third theme ditched the green completely. I have a hard time using green and red together without a design screaming Happy Holidays! and I also wanted this third approach to have a completely different tone than the other two. In the end, I opted for a palette based on orange and a blue. The inspiration for this palette came from the call-to-action buttons on An Event Apart’s website, which are a bright, vivid orange.

Screen capture showing the An Event Apart page with vivid orange call-to-action buttons.

I toned the orange down just a little bit and paired it with a blue that wasn’t too heavily saturated in order to balance the orange. The tone of the design changed completely—the orange immediately gave the design more energy. It made the whole design feel more creative and inviting. Ultimately, I think that’s why it was the direction we decided we should go.

We did end up using the header style from the monochromatic design in the end. Normally I don’t like to mix ideas from different designs, but without that big block of color at the top, the whole design felt lighter. It didn’t feel like a compromise… it just worked.

Screen capture showing the final style tile for 10K Apart

I’m normally a full page mock-up kind of designer, but I found that the style tiles worked really well. Perhaps it was because this was such a small site with only a handful of patterns, but they helped speed the visual design process along. And I was happy to see how well they translated into the final, realized design in code—after all, that’s where it really matters.

What about that hero illustration?

With the basic design handled (and Aaron busily implementing it), I turned my attention to the homepage hero. I knew I wanted the illustration to be a metaphor for the 10k Apart site and for the entries that would eventually be submitted to it. I also liked the old-time contraption design used in the 2010 edition of the contest.

Screen capture of the 10K Apart 2010 page, with a hero illustration of a pedal-powered flying machine.

After seeing her amazing talk on SVG animations at SmashingConf, we approached Sarah Drasner about getting involved with the illustration. After all, what could be cooler (or smaller) than an animated hero shot in SVG? She was enthusiastic about the contest, and the challenge of building something both really cool and really small, so we set to work.

After a brief chat, we were all loving the idea of something antique and interactive. And so Sarah went away for a few days and came back with an early version of the hero you see today. She even figured out how to get the size of the SVG under 10kB while still keeping it interactive and highly detailed. (Aaron will discuss how it’s lazy-loaded in a future post.)

Sarah nailed the concept of a vintage contraption that required a lot of machinations to pop out something simple. And that’s really what this process and this contest is all about: working hard, iterating and re-iterating until we come up with something small, simple, and amazing!

What did we learn?

Stephanie’s walkthrough covered a lot of territory, so here’s a little summary of the takeaways:

  • Consistency matters — not only are consistent designs more usable and cohesive, they’re also smaller;
  • Fonts can be a bandwidth hog — even single typefaces can be quite large, consider using web safe or standard system fonts;
  • “Web Safe” doesn’t have to be boring — just because you’re using a web safe font stack doesn’t mean you can’t get creative, you can even take things further by exploring larger font stacks with options that cater to the different platforms;
  • Colors can compress — repetitive hex values and hexidecimal shorthand can help make your CSS smaller;
  • Contrast is key — design is not painting a pretty picture, people need to use your work so make sure they can read it;
  • Design systems, not pages — style tiles are a great tool for exploring design themes and get you to think in terms of a design system rather than a collection of pages; and
  • SVG is amazing — it’s incredible how much you can do with SVg illustrations: they’re small, they scale, and they can even be animated.

Where to next?

With a beautiful and highly usable design direction in place, it’s time to write some CSS. Stay tuned!

Aaron Gustafson and Stephanie Stimac

Building in 10k: Content and Strategy

Editor’s note: This is the first in a series of posts from the team that built the 10k Apart contest page, exploring the process of building for interoperability, accessibility, and progressive enhancement in less than 10kB.

When Jeffrey Zeldman first approached me about bringing back the 10k Apart contest, my mind began to race. I’d been a judge on the 2011 incarnation of the contest, so I had seen it from that angle before, but he presented me with an amazing opportunity… not just bring it back, but to evolve it into the 10k Apart contest our industry so desperately needs today.

The 10k Apart (and the 5k before it) have never operated in a vacuum. They’ve always taken the pulse of industry trends and and then challenged us to do more, to do better, and with less. In 2010, the contest pushed us to embrace HTML5. In 2011, we were challenged to make our work responsive. And so I began to ask myself: what are the challenges we, as an industry, are struggling with today. Anyone who has followed my work could probably have guessed my answer: progressive enhancement.

And so I put together a list of changes to the contest that would help us move away from the very JavaScript-heavy entries I’d judged last time toward entries that would be usable by anyone. Entries that respected low-bandwidth connections, were considerate of users who rely on assistive technology, and embraced the inherent flexibility and malleability of the Web. And, of course, entries that broke the stereotype of progressively-enhanced projects being “boring”.

I was so excited when Jeffrey and Eric Meyer responded to my suggestions with overwhelming enthusiasm. Their encouragement challenged me to think about the rules I’d drafted to govern the contest and inspired me to make the contest site abide by those very same rules as a way of demonstrating how progressive enhancement can enable our web projects to do so much more. It’s not a yoke, holding us back; it’s a powerful philosophy that challenges us to look at experience as a continuum and pushes us to think outside of our comfortable high-tech bubble.

This is the first in a series of posts about the process of building the 2016 10k Apart contest site. I, and the wonderful team that helped me make it a realty, wanted to share what we did, but moreover why we did it. We’ll talk about the sacrifices we made in designing and building the site as well as the ways markup, style, and script took a simple transactional site and gave it the polish it so richly deserved.

Thanks for joining us on this journey…

What are you here to do?

Before tucking into code, information architecture, or even copy, I took some time to stroll through previous incarnations of the contest. I poured over the structure of the sites and examined the tone of voice they used, of course, but I also took the time to examine the purpose of every page. Who were the different audiences coming to the sites? What did they want to do? Did their goals change over time?

Asking all of these questions helped me to break the site’s audience into two main camps: Folks interested in entering the contest and folks interested in spectating. I also recognized that the motivations and goals of these groups would change as the contest progressed. Folks who entered might become spectators once they’d submitted their entry. Some spectators might be inspired to enter the contest themselves after seeing someone else’s project. And so I set about organizing the site to not only support these different, potentially overlapping audiences, but to make it easy to transition back and forth between them.

To accomplish this, the site would need to evolve with our audience through several phases:

  1. Launch – When we don’t have any entries (which is what is live as I am writing this);
  2. In progress – When we have entries that we want to show off, but the contest is still open (this phase will be kicking in soon);
  3. Close – When the contest is over and we aren’t accepting new entries, but instead focus on highlighting the folks that entered and ask you to vote for your favorites; and
  4. Winner announcement – When we celebrate the awesome works judged by our expert panel and you, the community, to be the best of the best.

With that outline in place, I began putting together lists of the sorts of content we would need on each page in each phase of the contest. I was ruthless in stripping away the cruft and the nice to have bits. In many ways, I followed the model Luke Wroblewski wrote about in Mobile First, by focusing on the core purpose of each page. I got rid of any bit of content or UI was a distraction from that purpose or that simply failed to propel people toward accomplishing their goal on that page. Each page, each step in the process, was ruthlessly stripped to its essence. And then the real work began.

How do we talk to one another?

Steph Hay is often quick to point out that every interface is a conversation we’re having with out users. With that in mind, I set about authoring copy that embodied that idea. I wanted your experience of the site to be just like sitting down next to me and talking about the contest.

In their book Nicely Said, Kate Kiefer Lee and Nicole Fenton offer a ridiculous amount of great advice on not just how to write, but how to write for people. In it, they talk about writing like you speak and even go so far as to recommend you read your work aloud. Looking to the future of “headless” UIs—Cortana, Alexa, Siri—and the current crop of screen reading options out there, it was pretty obvious that this was not only good advice… it was beta testing!

I applied the wisdom I learned from these amazing content strategists (and no doubt countless others) to everything from the page titles and body copy all the way down to form labels and error messaging. I read the content aloud and in many cases had my computer read it to me as well. I know there’s room for improvement (there always is), but I’m pretty happy with the way it turned out.

Where are the patterns?

Once I had drafted copy for each page in the site, I began to organize the content into basic wireframes. In the interest of time, I focused on wireframes for large-screen views of each page, making note of the content priorities so I would know how to arrange things on smaller screens as well.

Example wireframe from https://a-k-apart.com

While working on the wireframes, I made notes (some mental, some in the wireframes themselves) about where we could shave off some page size or where certain content was helpful, but more of an enhancement than core to the purpose of the page. I also looked for places where we could use markup or style to improve the experience greatly for very little cost. HTML5 input types, for example.

For more complicated interactions, I used Interface Experience Maps (IxMaps, which are effectively flowcharts) to outline the different ways users might be able to experience an interface. For example, on an entry page the most important information is the name of the project, the name of the person (or people) who made it, the description of the project, and a link to view it live. A screenshot, while helpful, is unnecessary. So I used an IxMap to explore lazy loading the screenshots only when JavaScript was available.

IxMap exploration of lazy loading screenshots when JavaScript is available. This IxMap depicts lazy loading a picture element and supplying alternate image formats for browsers that support WebP.

In that exploration, it dawned on me that I didn’t have to settle for only one image format—I could lazy load a picture element and supply alternate image formats for browsers that support WebP (which tends to be much smaller than JPGs and PNGs). That’s one of the reasons I love IxMaps: they allow for low-cost exploration and discoveries like this.

Once the wireframes and IxMaps were complete, I went through them and teased out repeating patterns and unique components, copying them to a new page in the wireframe document. In doing so, I also found opportunities to reuse enhancements I’d come up with for specific page components. Taken together, this pattern guide have our designer, Stephanie Stimac, a good overview of the site’s overall UI needs. It helped her avoid the trap of designing pages and let her create a design system instead. Stephanie will join me to talk about the design process in the third installment of this series.

What did we learn?

They may seem obvious, but in case you’re a fan of takeaways, here are a few relating to content, strategy, and information architecture:

  • Minimize distractions – Focus on the core purpose of every page, get rid of anything that is not supportive or detracts from that;
  • Write like you speak — Write for people like you would speak to them in person and read your work aloud;
  • Set content priorities — Ensure the flow is right and leads your users where they want (or need) to go;
  • Look for opportunities to enhance — Some supportive content may be nice to have but non-essential, consider removing it by default and bringing it back in certain scenarios; and
  • Look for patterns — Focus on creating a design system rather than individual pages.

Where to next?

With a good set of bones in place, the next step for me was to tuck into the markup, but that’s the story for another post. Stay tuned!

Aaron Gustafson, Web Standards Advocate

Building a more accessible web platform

In February we shared our roadmap for empowering all Microsoft Edge customers through accessibility and inclusive design. Today, we’re excited to share more about Microsoft Edge’s native support for the modern UI Automation accessibility framework, coming with the Windows 10 Anniversary Update. UI Automation enables Windows applications to provide programmatic information about their user interface to assistive technology products such as screen readers, and enables a comprehensive ecosystem.

New Microsoft Edge accessibility architecture

Providing a great experience for users of all abilities requires the right architecture. Over the last year we’ve rethought our approach, and designed an accessibility system which inherently supports modern web standards including HTML5 and CSS3. Let’s take a look at the simplified browser pipeline that follows the webpage content into an accessible presentation layer:

Flowchart showing the simplified browser pipeline. Figure 1. Content transformed to the engine model is projected into visual and accessibility views that are presented either as visual or accessible presentation.

Content transformed to the engine model is projected into visual and accessibility views that are presented either as visual or accessible presentation.

In our previous architecture, accessibility objects were generated and tightly associated with the DOM tree, in fact it was a subset of the tree itself. This presented many engineering challenges to maintain and evolve.

With Microsoft Edge an accessibility view is now generated from the same engine model used for visual presentation. Our accessible view creates native accessible objects which can be mutated and invalidated with script changes, just like visual view elements.

Our new accessibility architecture is available in the latest public flight behind the “Enable experimental accessibility features” flag under about:flags, and assistive technologies can take advantage of this using the “MicrosoftEdge” UIA_FrameworkIdPropertyId.

Try it today and let us know what you think!

Navigating web content faster with document structure and landmark roles

To transform content, styles and attributes into accessible objects browsers use HTML and Core Accessibility API mapping specifications. These define how semantic HTML elements gain ARIA roles and are transformed into accessibility entities, such as UI Automation objects.

Using semantic elements, developers can greatly improve the content navigation experience. Microsoft Edge and Narrator now support document structure and landmark role elements in heading, paragraph and landmark navigation modes.

For example, using the <main> elementdevelopers can provide a hint to assistive technology indicating where the primary content is. This makes it easier for their users to get to this content quickly from anywhere on the page. This experience will light up in Microsoft Edge and Narrator, and in other browsers, with assistive technologies supporting those roles.

Getting more information with accessible names and descriptions

Site authors commonly use ARIA attributes and well known patterns and techniques to enhance presentation of the elements on the page. Browsers then take the available information on that element, including contextual elements nearby, and compute accessible name and description. Microsoft Edge now supports the computation algorithm, providing users access to the full information available in the markup.

Better user experience with forms, controls and new semantic elements

Form data entry is a core scenario on the web, and based on user feedback we’ve greatly improved the form entry experience including:

  • Improved accessibility of the error validity states
  • Made <datalist> element accessibile
  • Improved accessibility of all the controls that support lists, including <select>
  • Improved keyboard experience for input types, including Up and Down keys to change the input type=number value
  • Implemented input type=color, which stores the value in computer readable form, and which now presents the information in human readable percentages of Red, Green and Blue.

Code: <input type="color" value="#ff0000" />

Result: UIA Value: “100% Red 0% Green 0% Blue”

Improved web legibility in high contrast

Microsoft Edge provides full support for the Windows high contrast themes, including custom user themes. Many modern web sites use background images as foreground content, which doesn’t provide a great experience for users who need increased contrast.

Screen capture showing xbox.com in IE's high contrast mode. The main foreground content is entirely blacked out with only a heading and secondary content elements visible.

Xbox.com in the legacy high contrast mode.

After working closely with visually impaired users and prototyping different solutions, we decided to try something different for high contrast mode in this release. Microsoft Edge will no longer remove background images, and instead will render an opaque layer behind text to improve legibility while maintaining the site design.

These improvements speak for themselves:

Screen capture showing Xbox.com in the updated high contrast mode. Only the area immediately surrounding each text block is blacked out, allowing the page structure and imagery to show through without impairing readability.

Xbox.com in the redesigned high contrast mode.

Along with the changes we have retained full developer control over browser implicit enhancements with -ms-high-contrast media feature and -ms-high-contrast-adjust property.

These high contrast improvements are available in current Windows Insider releases, enabled by default. Users can disable the “Render backgrounds in high contrast” feature under about:flags to get the previous behavior.

More improvements and platform features

Alongside these platform, user experience, and legibility improvements, we’ve had a chance to add a few user experience features and fixes:

  • Implemented the Web Speech Synthesis API
  • Improved caret browsing on Windows Phone with external keyboards
  • Improved Microsoft Edge frame-to-content focus transitions

Journey towards a more accessible web platform

As we finalize these features on the road to the Windows 10 Anniversary Update, we’ve also begun work on a few additional areas targeting a future release. Below are some of the features we’re currently considering:

  • Improving the UIA TextPattern reading experience based on user feedback
  • Enabling the web platform to take into account the “Text size” slider, available in Ease of access > More options on Windows 10 Mobile
  • Improvements to input controls and scrollbars in high contrast mode
  • Improvements to the text contrast ratios of controls
  • Improvements to touch and keyboard experience with Narrator on the web for desktop and mobile
  • Tweaks to the focus outlines to make finding and tracking elements in the browser easier

In upcoming posts we’ll have more to share about our user experience improvements as measured by HTML5Accessibility.com, as well as our approach to automate accessibility testing for the web.

We’re excited to share the current improvements and look forward to building an even more accessible web with you! As always, we welcome your feedback.

– Bogdan Brinza, Program Management Lead, Microsoft Edge
– Rossen Atanassov, Software Development Lead, Microsoft Edge