The future of style

The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.

Latest articles

CSS Basic User Interface Draft Updated

Source: CSS WG Blog Florian Rivoal • 20 May 2015 07:19 PM

The CSS Working Group has published an updated Working Draft of CSS Basic User Interface Module Level 3 (CSS3 UI). This module describes CSS features which enable authors to style user interface related properties and values.

All known issues have been resolved, and the CSS Working Group invites everyone interested in this topic to do a complete review of this draft (under the old process this draft would be another last call).

Barring significant issues, we expect to publish this document as CR in 4 weeks (2015/06/18), with changes that are only non-normative, editorial, dropping of at-risk features, or at most resolutions for minor issues.

Significant changes since the previous draft are listed in the Changes section.

As always, please send feedback to the (archived) public mailing list www-style@w3.org with the spec code ([css-ui]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

The CSS WG updated the Working Draft of CSS Basic User Inter…

Source: W3C's Cascading Style Sheets home page20 May 2015 12:00 AM

20 May 2015 The CSS WG updated the Working Draft of CSS Basic User Interface Module Level 3 (CSS3 UI). This is intended to be the last WD before CR

Using Chakra for Scripting Applications across Windows 10

Source: IEBlog Microsoft Edge Team • 18 May 2015 05:00 PM

In Windows 10, the Chakra JavaScript engine powers Microsoft Edge and Windows applications written in HTML/CSS/JS. However with JavaScript’s increasing popularity in beyond-the-browser scenarios, developers have been requesting to host the Chakra engine outside the browser to enable JavaScript programmability in their native/managed applications across the client and the server.

Starting in Windows 8.1/IE11, Chakra added support for a new set of public hosting APIs called the JavaScript Runtime (JSRT) APIs, which shipped as part of the Windows SDK. While these APIs allowed hosting of Chakra outside the browser, the set of functionality exposed by these APIs during Windows8.1/IE11 was mainly focused on specific server side scenarios across Microsoft products and services like Outlook.com and Azure DocumentDB.

In Windows 10, we have made significant advancements to the JSRT APIs, making them a true first class citizen for hosting Chakra across various application types supported on Windows 10. Developers can now utilize these APIs to host Chakra for scripting in both Classic Windows (Win32) applications and Universal Windows applications. These APIs now provide native access to the underlying Universal Windows Platform (UWP) and ECMAScript 6 support. For the curious, and as an example, the recently announced Node support based on Chakra for Windows 10 IoT devices is built using these APIs.

Design Choices: Scalability, Performance and Resource Throttling

Ever since JSRT APIs were first introduced in IE11/Windows 8.1, they have supported features that help build scalable, reliable and efficient applications and services by hosting Chakra.

Threading flexibility: Rental Threading for Scalability

Multithreading is a common approach to improve parallelism in computing, particularly in server environments where I/O commonly causes apps to pause while waiting for an I/O request to be serviced.  However, multithreading imposes significant difficulties on the developer; locks must be used in order to protect critical data structures from being corrupted. COM tackled this problem by creating threading models and then requiring individual components to declare whether they were apartment-threaded (single-threaded) or free-threaded (any thread can interact with it), and then COM would provide automatic binding and marshaling between different threading models.

JSRT APIs utilize a different threading model, called rental-threading. In a rental threading model, a script execution context (defined here) is always single-threaded, but is not hard-bound to the thread it was created on. In other words, at any given time, script operation from one context can be executed in one thread only, but the context can change its thread affinity from time to time.  For example, the application may do some work and then decide to relinquish the thread to wait for an I/O request to complete.  Once the I/O request completes, the script context can pick any idle thread to continue script execution by using the JsSetCurrentContext API, which allows the script context to start operating again, albeit on another thread.

Diagram showing script threading

Each time a different thread calls JsSetCurrentContext, the script context starts executing JavaScript on a different thread.

In a rental-threaded model, hosts could create thread pools to ensure that they do not exceed a particular thread (and CPU) utilization quota. Such a model enables high scalability at low cost as it does not require the application to create a new thread for every request that comes in and requests need not block for other requests to be serviced.

With JSRT APIs, hosts also get the flexibility for managing the runtime’s background operations. Chakra provides a high-performance concurrent JIT compiler and garbage collector.  By default, each runtime manages its own set of threads for both background compilation and background garbage collection.  Based on the app needs, hosts can provide their own threads for those operations or can force the runtime to perform those tasks on the primary thread, ensuring that applications have predictable behavior and performance characteristics.

Startup and execution efficiency: Script Serialization

To support startup and execution efficiency, JSRT APIs provide the capability of pre-parsing, generating syntax trees and caching the bytecode for a given piece of JavaScript code. For server scenarios in which the same code might be executed perhaps thousands of times, the performance savings this introduces can be substantial.

Consider that a typical execution of a given JavaScript does an initial check for syntax errors, creates an abstract syntax tree, generates bytecode, and then starts executing the outermost scope.  Most but the last step can be pre-calculated ahead of time and JSRT APIs supports doing so with the JsSerializeScript function.  Once the JavaScript code has been serialized, it can be cached and loaded by the application at any point. Not all hosts will need to do this, but script serialization allows a host balance memory and disk footprint for faster startup performance based on the specific needs of the application.

Resource Throttling: Managing Memory & CPU Utilization

Because JSRT provides in-app JavaScript programmability, the embedded JavaScript can often come from sources other than the application authors. Therefore, a metered and reliable service architecture is required, and JSRT APIs provide mechanisms by which the host process can impose limits on memory consumption and CPU utilization.

Limits on memory utilization

The host can manage the memory limit of any given runtime (a complete JavaScript execution environment with its own isolated garbage collected heap and just-in-time compiler thread – more here) by calling the JsSetRuntimeMemoryLimit function. Hosts should typically set the limit before starting up script, because if called after the runtime has already exceeded the memory limit, the attempt to limit memory usage will fail.

Limits on CPU utilization

Avoiding runaway execution is often scenario specific as the host best knows when to limit or throttle utilization. While there could be valid long running scripts, a malicious script might force running an infinite loop, like below.

(function hang() {       
    while (true) { }
})();

By default, the JIT code emitted for the above function is optimized for execution speed and does not have any “script interruption” checks inserted by default. By executing the emitted code, a thread will become a runaway, making it impossible to break the loop.

Developers can configure the runtime to allow such loops to be interrupted by passing the AllowScriptInterrupt flag when creating a runtime. When used, a supervisor thread can request that the runtime terminates execution by calling JsDisableRuntimeExecution at any point, which in turn terminates the script runtime and exits any executing code. The runtime can later be re-enabled by using the JsEnableRuntimeExecution function. This provides developers with a straightforward way to terminate script while keeping the script environment alive.

Edge JSRT: Universal Windows Platform & ECMAScript6 support

In Windows10, to align with the evergreen Microsoft Edge browser strategy, Chakra JavaScript engine has forked into two separate components (or binaries)

  1. Jscript9.dll, a version of Chakra that is supported by IE11 and retains full backward compatibility
  2. Chakra.dll, a version of Chakra that is supported by Microsoft Edge, will be actively developed and be ever evolving, just like the rendering engine for Microsoft Edge

As a result of this change, JSRT APIs have also split into two

  1. Legacy JSRT APIs, which use jscript9.dll and provide full backward compatibility for Classic (Win32) Windows applications that were built using JSRT APIs that shipped with Windows8.1/IE11
  2. Edge JSRT APIs, which use Chakra.dll and become the actively developed JSRT APIs that leverage the continuous performance and language updates that will be coming to Chakra

All of the design choices mentioned in the above section are still supported in Edge JSRT. However, unlike the legacy JSRT APIs, Edge JSRT APIs enable support for hosting Chakra in any Universal Windows applications providing scripts native access to the underlying platform, provide ECMAScript6 support on par with ES6 support enabled by default in Microsoft Edge, and enables debugging of scripts in Universal Windows applications via Visual Studio. The whitepaper on Targeting Edge vs. Legacy Engine with JSRT APIs provides more information about the API split and how to target Edge JSRT APIs.

JSRT and Universal Windows Applications

Universal Windows platform supported by Windows 10 allows developers to use the same code to build applications that run across a family of Windows 10 devices including Desktop, Mobile, Xbox, and IoT. To use Chakra for scriptability in Universal Windows applications, developers can use all the Edge JSRT APIs, with the exception of the following profiling APIs – JsStartProfiling, JsStopProfiling, JsEnumerateHeap, and JsIsEnumeratingHeap, which are currently supported only in Classic (Win32) Windows applications.

The sample JavaScript console app showcases the use of Edge JSRT APIs in a Universal Windows application.

Edge JSRT APIs also allow scripts to natively access UWP APIs. An example of this feature is the uwp npm package that allows UWP access in Node.js apps running on Windows 10 using Chakra. The JsProjectWinRTNamespace allows exposing a UWP namespace to scripts. The following example utilizes UWP APIs to create an http client to get content from Uri:

JsProjectWinRTNamespace(L"Windows.Foundation");
JsProjectWinRTNamespace(L"Windows.Web");
// Get content from an Uri.
JsRunScript(
     L"var uri = new Windows.Foundation.Uri(\"http://somedatasource.com\"); " \
     L"var httpClient = new Windows.Web.Http.HttpClient();" \
     L"httpClient.getStringAsync(uri).done(function () { " \
     L" // do something with the string content " \
     L"}, onError); " \
     L"function onError(reason) { " \
     L" // error handling " \
     L"}", JS_SOURCE_CONTEXT_NONE, L"", &result);

While Universal Windows applications have full support, to use asynchronous UWP APIs and events in a Classic (Win32) Windows application, a COM initialized delegate pumping mechanism needs to be enabled through JsSetProjectionEnqueueCallback. A sample is provided here.

ECMAScript 6 Language Support

ECMA-262 6th Edition (ES6) is the most significant update to the JavaScript language ever and brings various new capabilities and syntactic sugar to the language. By leveraging the ES6 functionality that is available in Chakra for Microsoft Edge, Edge JSRT allows executing simpler and more powerful JavaScript code like ES6 Arrow Function to write lexically-bound single-line anonymous functions and ES6 Promises to perform asynchronous tasks.

Scripts using ES6 language features require no setup to run with Edge JSRT, except for ES6 Promises. For ES6 promises, a hosting application needs to provide an EnqueueJob abstract operation to queue up the promise tasks. JsSetPromiseContinuationCallback allows application to provide an EnqueueJob style callback to process the promise task queue. The following sample showcases how to store the promise tasks and execute them after the current execution context is finished:

static void CALLBACK PromiseContinuationCallback(JsValueRef task, void *callbackState)
{
     // save async task in the callback.
     *(void **)callbackState = task;
}

void runPromiseSample()
{
     JsValueRef result;
     JsValueRef task = JS_INVALID_REFERENCE;
     JsValueRef callback = JS_INVALID_REFERENCE;
     JsSetPromiseContinuationCallback(PromiseContinuationCallback, &callback);
     JsRunScript(
          L"//The JavaScript ES6 Promise code goes here" \
          L"new Promise(" \
          L" function(resolve, reject) {resolve('basic:success');}" \
          L").then(function () {return new Promise(" \
          L" function(resolve, reject) {resolve('second:success')}" \
          L")});", JS_SOURCE_CONTEXT_NONE, L"", &result);
     // execute async tasks stored in callback
     while (callback! = JS_INVALID_REFERENCE) {
          task = callback;
          callback = JS_INVALID_REFERENCE;
          JsCallFunction(task, nullptr, 0, &result);
     }
}

Apart from providing ES6 support for scripts, Edge JSRT also provides APIs to maneuver new ES6 types and objects, such as Symbol or TypedArray, in native code for better JS/native integration and performance.

Debugging applications

JSRT APIs support script debugging with Visual Studio. In legacy JSRT, the host needs to provide an IDebugApplication pointer to put the script context in debug mode. In Edge JSRT, instead of using IDebugApplication, scripts can be debugged using the following steps:

  1. In Visual Studio, right click on your project -> Select “Properties” -> Select “Debugging” -> In “Debugger Type”, select “Script Only” or “Script and Native”.
  2. In your application, after creating an execution context, call JsStartDebugging to put the current context in debug mode. When working with multiple contexts, JsStartDebugging should be called every time a new context is set as current context.
  3. Debug the script!

Summary

We are excited to share some of the JSRT features that have been long completed – rental threading, script serialization, memory & CPU throttling, and the more recent Edge JSRT specific updates – availability in Universal Windows Applications, native UWP access and ECMAScript 6 language support. These changes put together make Chakra a great option to add scriptability to applications and services running on Windows10.

The JSRT APIs with all features mentioned above are available in the latest Windows 10 Insider Preview and Windows SDK, which can be download from here. A sample Universal Windows application and the JSRT API documentation are resources that might be helpful to get started. We are eager to see applications use Chakra for scriptability and would love to hear your feedback to advance these APIs. You could reach us and share your feedback on Twitter at @MSEdgeDev or on Connect. Thanks!

– Limin Zhu, Program Manager, Chakra Team
– Gaurav Seth, Principal PM Manager, Chakra Team

WWW 2015, the 24th International World Wide Web Conference, …

Source: W3C's Cascading Style Sheets home page18 May 2015 12:00 AM

18 May 2015 WWW 2015, the 24th International World Wide Web Conference, will be held in Florence, Italy, May 18–22, 2015.

CSS Flexbox Level 1 Update, Call for Comments

Source: CSS WG Blog fantasai • 15 May 2015 08:02 PM

The CSS Working Group has published an updated Last Call of CSS Flexible Box Layout Level 1 to fold in feedback from the last LCWD. Flexbox is a new layout model for CSS: the contents of a flex container can be laid out in any direction, can be reordered, can be aligned and justified within their container, and can “flex” their sizes and positions to respond to the available space. This is an update, mostly to fix various errors reported against the last draft. As before, the CSSWG is not revoking the call for implementations: we’re just issuing an LCWD to process the changes.

To help with review and with correctly updating implementations, exact diffs since the previous Last Call Working Draft and since the original Candidate Recommendation, and their justifications, are available in the Changes section. A Disposition of Comments is also available. The Last Call comment period ends 11 June 2015.

We are particularly looking for feedback from authors on the percentage margins issue, and will accept comments posted through that post on CSS3.info.

And as usual, we will welcome and track any feedback to the (archived) public mailing list www-style@w3.org with the spec code ([css-flexbox]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Job: Web Standards Technology Expert

Source: W3C Blog Coralie Mercier • 15 May 2015 07:16 AM

The World Wide Web Consortium (W3C) is looking for a new, full-time staff member to be located at Beihang University in Beijing, where W3C currently has its China Host, to assist, as team contact, W3C Working Groups developing technical specifications in the fields of Ubiquitous Web or Technology and Society.

This is an opportunity for a unique individual to be part of the team responsible for the design of next generation World Wide Web Technologies and to lead a variety of industry and user groups toward the development of technologies that enhance the functionality of the Web. As the recognized leader for the technical development of the World Wide Web, we are seeking an individual with both Web technology and project management experience, an excellent understanding of the Web industry, and enthusiasm for the mission and spirit of W3C.

Responsibilities

The individual will work within standard groups to edit specifications, develop change proposals, monitor progress, reach out to different stakeholders, produce tests, and to respond to clarification requests, bugs and issues.

We would welcome candidates with specific technology or business skills such as:

Generic Skills Required

Work starts 1 August 2015

The Position is based at the School of Computer Science & Engineering of Beihang University, No.37 Xueyuan Road, Haidian District, Beijing. There will be regular international travel including to W3C Host sites, and regular remote work with the Working Groups and the W3C Global staff.

To apply, please send a motivation letter, your resume or CV and (if at all possible) copies of your Diplomas (including High School or equivalent) in electronic form to <team-beihang-position@w3.org>.

Minutes Telecon 2015-05-13

Source: CSS WG Blog Dael Jackson • 14 May 2015 12:19 AM

Full Minutes

A look at new feedback-driven improvements to the network tool in our F12 Developer Tools

Source: IEBlog Microsoft Edge Team • 08 May 2015 05:00 PM

In January this year, we described new features and experiences for developers in the F12 developer tools that enable you to be more effective with a range of updates (e.g. new performance and network tools as well as Debugger enhancements and UI improvements.

The latest Windows 10 Insider Preview brings more improvements, including a refined network tool experience and an early look into the tooling support that will be available for Microsoft Edge.

Microsoft Edge F12 developer tools

To access the Microsoft Edge F12 developer tools, open the settings menu and select “F12 Developer tools,” which will launch the tools undocked.

Screenshot of F12 Developer Tools in Microsoft Edge menuScreenshot of undocked F12 Developer Tools

Network tool

We’ve heard feedback from developers regarding the network tool’s capabilities and ease of use. Some examples include the lack of auto-start capturing, export to JSON HAR, and filtering. To address this feedback, we’ve been working to redesign the network tool to provide a cleaner experience that makes you more productive when identifying and resolving network related issues.

Network issues can appear at any time from the initial page request, to loading and interacting with the app. It’s therefore important that the tool allows you to collect network HTTP-based traffic without the need to start a capturing session (e.g. issues might occur between page requests, loading and interacting with the page). Per your feedback, we also added the Start & Stop toolbar buttons to give you the flexibility to manage your session.

Screenshot of Start and Stop toolbar buttons

The toolbar gives you the power to zero-in quickly on specific types of traffic (for example, an image may not be displayed or you may not be getting the latest version of an image) by filtering out all unrelated content. The “Content type filter” toolbar button supports multiple filters that allow you to become more productive by skipping over dozens of unrelated network calls and only focusing on the relevant ones.

Screenshot of Content Type Filter in Network Tools

Once a filter is applied, the status bar at the bottom of the tool will reflect the captured network traffic currently displayed in the summary view. At a glance, it provides information about network errors (responses with 4xx or 5xx status codes), the number of requests, how much response data was transferred from the server, and how long it took to download. This is helpful when measuring how much data was consumed in a particular scenario or trying to better understand how long it might take to download certain resources.

Screenshot of Network Traffic summary view

There are cases where you might want to share your network traffic log with other developers or use tools like Fiddler to run a performance analysis session. For these, you can use the export button to export the captured network traffic into a JSON HAR file.

Screenshot of exporting network traffic

There are many other interesting features in the toolbar that provide capabilities to help diagnose issues:

Summary view

The summary view in the network tool is very descriptive and we have described how you can filter its content. Each row has the following data about the captured traffic:

We also added some productivity enhancements to improve the visibility of important debugging details:

Error highlighting in Network Tool

Details view

Details of a request are accessed by opening the summary view and by double clicking on a request. The details panel will open up to expose relevant details about that request and response.

Screenshot of Details Panel;

The details panel is divided into the following sections:

Screenshot of Timings section

The new network tool is available for developer tools in IE11 and Microsoft Edge on Windows 10. If you are a Visual Studio developer, you will also benefit from the same tooling experience that is now available in Visual Studios 2015, which allows you to debug your JavaScript, managed and native Windows and Windows Universal apps.

We are currently refining the experiences and we’ll provide more updates as changes roll out in preview builds. This is a preview, so you may notice some rough edges that will be addressed in future updates. In the meantime, we encourage you to continue providing suggestions, bugs, or requesting experiences you believe can make your daily development activities easier and more effective.

Let us know your thoughts about the features announced today by leaving a comment below, reaching out on Twitter, or visiting our User Voice site to express your opinion on what we should work on next!

— Ruben Rios, Program Manager, Internet Explorer

Minutes Telecon 2015-05-06

Source: CSS WG Blog Dael Jackson • 07 May 2015 05:29 PM

Full Minutes

Bringing Asm.js to Chakra and Microsoft Edge

Source: IEBlog Microsoft Edge Team • 07 May 2015 05:00 PM

A couple of months back, we announced that we had started development on Asm.js. Support for Asm.js has been one of the top 10 most-requested items at the Microsoft Edge Developer Suggestion Box on UserVoice since we launched it in December 2014. Since that time, we’ve made good progress, and in Windows 10 Insider Preview builds starting with 10074, we are now previewing the early work that we’ve been doing to enable Asm.js support in Chakra and Microsoft Edge.

What is Asm.js?

Asm.js is a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. As a sublanguage, asm.js effectively describes a sandboxed virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ techniques like type specialized compilation without bailouts and ahead-of-time (AOT) compilation for valid asm.js code. Such compilation techniques help JavaScript execute at “predictable” and “near-native” performance, both of which are non-trivial in the world of compiler optimizations for dynamic languages like JavaScript.

Given the complexity of writing asm.js code by hand, asm.js is currently produced principally by transpiling C/C++ code using toolchains like Emscripten to run on the Web platform, utilizing technologies such as WebGL and Web Audio. Game engines like those from Unity and Unreal are starting to land early/experimental support of plug-in free games on the web using a combination of asm.js and other related technologies.

How do I experiment with Asm.js in Microsoft Edge?

To enable and experiment with the current Asm.js support in Microsoft Edge, navigate to about:flags in Microsoft Edge and select the “Enable asm.js” flag as below:

Screenshot of about:flags interface for asm.js

Engineering Asm.js into Chakra’s Execution Pipeline

To enable Asm.js in Chakra, the components marked in green below have been added or modified vis-à-vis the typical code flow though Chakra’s pipeline outlined and explained in this blog.

Diagram of the Chakra pipeline

Key changes include:

JIT Compiler Optimizations for Asm.js

Apart from changes to Chakra’s execution pipeline described above, Chakra’s JIT compiler has also been enhanced to take advantages of the constraints laid out by the asm.js specification. These enhancements help Chakra’s JIT compiler to generate code that could execute at near native code performance – the golden target for all dynamic language JIT compilers. Let’s drill into two such optimization techniques.

Helper and bailout call elimination

Helper or bailout code acts like a power backup for compiled code in dynamic languages. If any of the assumptions that the JIT compiler makes while compiling the code is invalidated, there needs to be fail safe mechanism to continue execution with correctness. Helpers can be used to handle un-anticipated situations for an operation, and control can then return to the JIT’d code. Bailouts handle situations where the JIT’d code cannot recover from the un-anticipated conditions and control needs to be transferred back to the interpreter to execute the remainder of the current function. For example, if a variable is seen as integer and the compiled code is generated with that assumption, the occurrence of a double should not impact correctness. In such cases, helper or bailout code is used to continue execution, albeit with slower performance. For asm.js code, Chakra does not generate any helper or bailout code.

To understand why, let’s take an example of a function square in an asm.js module, which has been over simplified to help explain the concept.

function PhysicsEngine(global, foreign, heap) {
    "use asm";
    …
    // Function Declaration
    function square(x) {
        x = +x;
        return +(x*x);
    }
    …
}

This function square in the code sample above translates to two x64 machine instructions in asm.js code, excluding the prolog and the epilog that is generated for that function.

xmm1 = MOVAPS xmm0 //Move native double value to a temporary register
xmm0 = MULSD xmm0, xmm1 //Multiplication

In contrast, the compiled code generated for the square function when asm.js is not enabled generates over 10 machine instructions. This includes:

Chakra’s JIT compiler is able to generate efficient code for asm.js by taking advantage of the type information of the variable, which cannot change through the lifetime of the program. The Asm.js validator & linker ensure the same. Given that all internal variables in asm.js are native types (int, double, float or SIMD values), internal functions freely pass native types without boxing them to JavaScript variables between function boundaries. In compiler terminology these are often called direct calls and avoid boxing or conversions when operating on data in asm.js code. Likewise for external calls into or from JavaScript, all the incoming variables are converted to native types and boxed while all the outgoing native types are converted to variables.

Bounds check elimination for typed array accesses

In a previous blog, we explained how Chakra’s JIT compiler supports auto-typed array optimizations, as well as hoisting of bounds check outside of loops thus improving the performance on array operations inside loops by up to 40%. With asm.js type constraints, Chakra’s JIT compiler completely eliminates bounds checking for typed array accesses for all of asm.js compiled code, regardless of the location (inside or outside loops or functions) or the type of the typed array. It also eliminates bounds checks for constant and non-constant index accesses for typed arrays. Together, these optimizations help bring near native performance when operating on typed arrays in asm.js code.

Following is a simplified example of typed array store at a constant offset and the single x64 machine instruction generated by the Chakra’s compiler for that code in asm.js.

int8ArrayView[4] = 25; //JavaScript code
[Address] = MOV 25 //Single machine instruction to store value

When compiling asm.js code, Chakra’s JIT compiler is able to pre compute the final address corresponding to int8ArrayView[4] during link time of asm.js code (first instantiation of the asm.js module) and hence can generate a single instruction corresponding the typed array store. In contrast, the compiled code generated for the same operation in non-asm.js JavaScript code results in around 10-15 machine instructions with path length being considerable. The steps include:

The above checks are removed from asm.js code due to the strict constrains on what can be changed inside an asm.js module. For example, a variable pointing to typed array in an asm.js module is immutable and cannot change. If it does, it’s not a valid asm.js code and the asm.js validator fails to validate it as asm.js code. In such cases the code is treated like any other JavaScript function.

Scenario light-ups and performance wins from Asm.js

From the early work that shipped in the latest Windows 10 preview, we have started to see some great scenarios light-up apart from the performance wins by bringing asm.js to Chakra and Microsoft Edge. If you want to take it for a spin, try out games like Angry Bots, Survival Shooter, Tappy Chicken, or try out some fun asm.js demos listed here.

Unity WebGL Player | Prime World Defenders

 In terms of performance wins, there are a crop of asm.js benchmarks that are emerging. With the preliminary asm.js support, Chakra and Microsoft Edge now perform more than 300% faster on Unity Benchmark and around 200% faster on individual tests like zlib, which features in Google’s Octane and Apple’s Jet Stream benchmarking suites.

Unity Benchmark scores for 64-bit browsers

Unity Benchmark scores for 64-bit browsers (Click to enlarge)
(System info: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (4 cores), 12GB RAM running 64 bit Windows 10 Preview)
(Scores have been scaled so that IE11 = 1.0, to fit onto a single chart)

 

So, what’s next?

This is an exciting step towards bringing asm.js to the web platform underneath Microsoft Edge. However we are not fully done yet. We are working on fine tuning Chakra’s pipeline for ASM.js support – gathering data to validate if the current design approach performs well for real world asm.js payloads, understanding and addressing outstanding performance, functionality and tooling issues etc. before enabling this feature by default. Once enabled, asm.js would not only be available in Microsoft Edge, but would also be available in Windows store apps written using HTML/CSS/JS as well as Web Views that target the new EdgeHTML rendering engine that is shipping with Microsoft Edge in Windows 10.

We’d also like to thank Mozilla, with whom we’ve been working closely since we started implementing asm.js, and Unity for their support and partnership in helping bring asm.js to Chakra and Microsoft Edge. And a big thanks to all the developers and users of Windows 10 and Microsoft Edge, who have been providing us with valuable feedback in this journey. Keep it coming! You could reach us and let us know your feedback on Twitter at @MSEdgeDev or on Connect.

– Abhijith Chatra, Senior Software Engineering Manager, Chakra
Gaurav Seth, Principal PM Manager, Chakra

A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…

Source: IEBlog Microsoft Edge Team • 06 May 2015 06:00 PM

We recently posted “A break from the past: the birth of Microsoft’s new web rendering engine”, an in-depth look at the background and motivation behind building a new rendering engine to power Microsoft Edge. A key factor described was the ability to make a break from legacy Internet Explorer-specific technologies that had been built up over the years.

In this post, we are sharing a list of legacy IE technologies and features that are not part of Microsoft Edge. Not supporting these legacy technologies in Microsoft Edge has a number of benefits: better interoperability with other modern browsers, improved performance, security & reliability, and reduced code complexity, just to name a few. And just like all good developers, ours love to delete code – over 220,000 lines of code in MSHTML have been removed from Microsoft EdgeHTML!

Graphic showing lines of code removed and interoperability fixes

We’re also sharing more about how we plan to introduce new web platform features to Microsoft Edge using concepts like feature flags and API trials, with the goal of preserving the ability to experiment with new capabilities which eventually lead to stable, interoperable implementations across browsers.

Technologies and APIs not supported in Microsoft Edge

Here are some key technologies which will not be supported in Microsoft Edge. A number of these had been deprecated in the past few releases, but moving to a new engine allows us to remove support completely. To ensure future compatibility with Microsoft Edge and other modern browsers, we recommend against any future development or deployment of these technologies. These technologies will continue to be supported in Internet Explorer on Windows 10 for users and enterprises who depend on them.

Technology Why it existed Why we don’t need it anymore
ActiveX ActiveX is a binary extension model introduced in 1996 which allowed developers to embed native Windows technologies (COM/OLE) in web pages. These controls can be downloaded and installed from a site and were subsequently loaded in-process and rendered in Internet Explorer. The need for ActiveX controls has been significantly reduced by HTML5-era capabilities, which also produces interoperable code across browsers. Microsoft Edge will support native PDF rendering and Adobe Flash as built-in features rather than external add-ons.We recently demonstrated our early work on a modern, HTML/JavaScript-based extension model to provide extensibility beyond what is available with HTML5. We will enable this new model after our initial release of Microsoft Edge this summer and we look forward to sharing more details soon.
Browser Helper Objects (BHO) BHOs are a binary extension model introduced in 1997 which enabled developers to write COM objects that were loaded in-process with the browser and could perform actions on available windows and modules. A common use was to build toolbars that installed into Internet Explorer.
Document modes Starting with IE8, Internet Explorer introduced a new “document mode” with every release. These document modes could be requested via the x-ua-compatible header to put the browser into a mode which emulates legacy versions. Similar to other modern browsers, Microsoft Edge will have a single “living” document mode. In order to minimize the compatibility burden, features will be tested behind switches in about:flags until they are stable and ready to be turned on by default.
Vector Markup Language (VML) VML is an XML-based format for 2D vector graphics, originally proposed in 1998 and originally supported in IE5. 2D vector graphics are supported via Scalable Vector Graphics (SVG) which provides interoperability across modern browsers.
VBScript VBScript is a scripting language modeled after Visual Basic. It was introduced in 1996 to provide web developers with a language option when scripting on the web. JavaScript has become the de-facto language of the web and is evolving quickly with ECMAScript 6 and beyond. Microsoft Edge delivers the leading implementation of ES6.
attachEvent / removeEvent IE8 and below supported a proprietary model for DOM events, which supported bubbling but not capture and used a global event object rather than passed as an argument to the event listener. IE9 and above support the DOM Level 3 Events standard with addEventListener/ removeEventListener.
currentStyle The currentStyle property retrieves the cascaded style of the element. IE9 and above support the getComputedStyle property (part of DOM L2 standard) to retrieve the final computed style of any element.
Conditional Comments Conditional comments provided a way to embed code that was only targeted at specific versions of Internet Explorer. It is more effective to use feature detection and other progressive enhancement rather than browser specific code in conditional comments.
IE8 layout quirks IE8 specific layout behaviors that were then emulated in later versions of Internet Explorer. Most websites are written for standards-based layout. Sites that require IE8 specific behavior on the intranet can be rendered using Enterprise Mode.
DirectX Filters and Transitions DX filters and transitions enabled web developers to apply various visual effects to elements on the web page. Similar effects can be achieved using standards-based features in CSS3 and SVG.

In addition to ActiveX and BHOs, there are a number of other legacy extensibility points that are not in Microsoft Edge and will be replaced by a unified, modern extensibility model. These include:

There are also hundreds of other non-interoperable APIs which have been removed. In most cases, these APIs now have interoperable, standardized replacements—removed APIs do not necessarily mean removed capabilities. All too often, the presence of these non-interoperable APIs cause site compatibility issues. Removing them makes a substantial improvement to user experience in Microsoft Edge and doubles down on our commitment to the web’s best feature: interoperability.

Preserving interoperability and experimentation on the web

Some of the more notable removals are those where Microsoft Edge supports the latest standard API definition and removes support for MS prefixed versions of the APIs. Examples include CSS Transforms, Fullscreen API, and Pointer Events. This brings up an important topic: vendor prefixes. You’ll see a trend in the vendor prefixes in Microsoft Edge compared to IE:

Graphic showing vendor prefixes in IE11 versus Microsoft Edge

Our support (or lack thereof) of prefixed APIs is data-driven with compatibility as the sole purpose for any that remain. As examples, -webkit-border-radius is still in use on over 60% of page loads and the MS-prefixed Encrypted Media Extensions APIs are still in use on top video streaming services. Because of the impact on interoperability across the Web, these are supported in Microsoft Edge for the time being.

The consensus across the industry is that vendor prefixes cause more harm than good and the necessity of browsers supporting other vendor’s prefixes is a good example of why. Going forward, we’re using feature flags (accessible by navigating to about:flags) to introduce experimental APIs and minting new vendor prefixed APIs sparingly, if ever. Today, you’ll find examples like early implementations of CSS Filters, Touch Events, and HTML5 date inputs in about:flags. We’re also working with other browser vendors on exploring new approaches to experimental APIs that enable easier and broader access to experimental APIs while minimizing the compatibility burden that prefixes incur. Check out this talk (starts around 31 min mark) for an initial proposal we’ve made, tentatively named “API Trials”.

Ready for the future

We hope that this provides some insight into of how Microsoft Edge is leaving behind some legacy in order to provide a great foundation for the future. Please continue to test your sites in Microsoft Edge via the Windows Insider Program or RemoteIE, and give us your feedback via @MSEdgeDev or Connect.

If you have any questions about legacy technologies in Microsoft Edge, or about Microsoft Edge in general, join us live at 2:30 PM PDT on Channel 9 for an open Q&A with the Microsoft Edge engineering team! We’ll be taking audience questions from Microsoft Edge Web Summit attendees, as well as questions to @MSEdgeDev on Twitter with the hashtag #AskMSEdge.

Charles Morris, Principal Program Manager Lead, Microsoft Edge
Jacob Rossi, Senior Program Manager, Microsoft Edge

Flexbox and Grid Percentage Margins: Feedback Needed

Source: CSS WG Blog Tab Atkins Jr. • 05 May 2015 08:42 PM

The CSS Working Group has reached an impasse on the issue of percentage margins (and padding) in flex and grid layout, and needs your input to help decide it.

Option 1: Flex and grid items resolve percentages in margin-top and margin-bottom against the height of the element’s containing block.

Option 2: Flex and grid items resolve percentages in margin-top and margin-bottom against the width of the element’s containing block.

Option 1 makes vertical margins consistent with horizontal margins (which resolve percentages against the width of the element’s containing block). This is a theoretically simpler model, and works well with Flexbox and Grid’s dimension-agnostic layout concepts. However, it is inconsistent with CSS block layout, and causes the margins to collapse to zero when used in an auto-height container.

Option 2 is consistent with the behavior of vertical margins in block and table layout. It has usable behavior in auto-height boxes, and enables the “aspect ratio hack”. However, it is a less obvious behavior, and means the layout interactions change based on whether a flexbox is “row” or “column”.

(For more background, see discussion on www-style.)

We’re looking for comments from authors explaining which behavior they think is better for Flex and Grid layout, and why. Do you have use-cases that can only be achieved with one behavior or the other? Show us in a comment on CSS3.info!

Flexbox and Grid Percentage Margins: Feedback Needed

Source: CSS3 . Infofantasai • 05 May 2015 08:37 PM

The CSS Working Group has reached an impasse on the issue of percentage margins (and padding) in flex and grid layout, and needs your input to help decide it. Option 1: Flex and grid items resolve percentages in margin-top and margin-bottom against the height of the element’s containing block. Option 2: Flex and grid items […]

Minutes Telecon 2015-04-29

Source: CSS WG Blog Dael Jackson • 30 April 2015 01:19 PM

Full Minutes

Minutes Telecon 2015-04-22

Source: CSS WG Blog Dael Jackson • 23 April 2015 03:46 PM

Full Minutes

The CSS WG published the first Working Draft of CSS Cascadin…

Source: W3C's Cascading Style Sheets home page21 April 2015 12:00 AM

21 Apr 2015 The CSS WG published the first Working Draft of CSS Cascading and Inheritance Level 4

The CSS WG updated the Candidate Recommendation CSS Cascadin…

Source: W3C's Cascading Style Sheets home page16 April 2015 12:00 AM

16 Apr 2015 The CSS WG updated the Candidate Recommendation CSS Cascading and Inheritance Level 3

Minutes Telecon 2015-04-15

Source: CSS WG Blog Dael Jackson • 15 April 2015 11:15 PM

Full Minutes

Minutes Telecon 2015-04-01

Source: CSS WG Blog Dael Jackson • 09 April 2015 10:39 AM

Full Minutes

Minutes Telecon 2015-04-08

Source: CSS WG Blog Dael Jackson • 09 April 2015 09:18 AM

Full Minutes

The CSS WG published the first Working Draft of Motion Path …

Source: W3C's Cascading Style Sheets home page09 April 2015 12:00 AM

9 Apr 2015 The CSS WG published the first Working Draft of Motion Path Module Level 1 and an update to the draft of CSS Basic User Interface Module Level 3 (CSS3 UI)

New Extended Units and Gradients Draft

Source: CSS WG Blog fantasai • 01 April 2015 10:58 PM

The CSS Working Group is pleased to announce a new Editor’s Draft of CSS Expressive Generalizations and Gadgetry Level 1 (renaming suggestions welcome). This new module adds:

We are currently debating the publication of an FPWD. If you have comments, please contribute to the discussion on www-style!

Minutes Telecon 2015-03-25

Source: CSS WG Blog Dael Jackson • 26 March 2015 10:25 AM

The CSS WG published the first Working Draft of CSS Scroll S…

Source: W3C's Cascading Style Sheets home page26 March 2015 12:00 AM

26 Mar 2015 The CSS WG published the first Working Draft of CSS Scroll Snap Points Module Level 1 and published a Note with an update to the draft of CSS Template Layout Module

Minutes Sydney F2F Part II – 2015-02-09 PM: Sizing, Text, Writing Modes, Multi-line/Block-Ellipsis

Source: CSS WG Blog Dael Jackson • 25 March 2015 03:47 PM

Sizing

Full Minutes || Spec Referenced

Text

Full Minutes || Spec Referenced

Writing Modes

Full Minutes || Spec Referenced

Multi-line/Block-Ellipsis

Full Minutes || Spec Referenced

Minutes Sydney F2F Part I – 2015-02-09 AM: CSS2.1 Issues, Font Loading API, Selectors, Text Level 4

Source: CSS WG Blog Dael Jackson • 25 March 2015 03:45 PM

CSS2.1 Issues

Full Minutes || Spec Referenced

Font Loading API

Full Minutes || Spec Referenced

Selectors

Full Minutes || Spec Referenced

Text Level 4

Full Minutes || Spec Referenced

Partnering with Adobe on new contributions to our web platform

Source: IEBlog Microsoft Edge Team • 23 March 2015 05:00 PM

In recent releases, we’ve talked often about our goal to bring the team and technologies behind our web platform closer to the community of developers and other vendors who are also working to move the Web forward. This has been a driving motivation behind our emphasis on providing better developer tools, resources for cross-browser testing, and more ways than ever to interact with the “Project Spartan” team.

In the same spirit of openness, we’ve been making changes internally to allow other major Web entities to contribute to the growth of our platform, as well as to allow our team to give back to the Web. In the coming months we’ll be sharing some of these stories, beginning with today’s look at how Adobe’s Web Platform Team has helped us make key improvements for a more expressive Web experience in Windows 10.

Adobe is a major contributor to open source browser engines such as WebKit, Blink, and Gecko. In the past, it was challenging for them (or anyone external to Microsoft) to make contributions to the Internet Explorer code base. As a result, as Adobe improved the Web platform in other browsers, but couldn’t bring the same improvements to Microsoft’s platform. This changed a few months ago when Microsoft made it possible for the Adobe Web Platform Team to contribute to Project Spartan. The team contributes in the areas of layout, typography, graphic design and motion, with significant commits to the Web platform. Adobe engineers Rik Cabanier, Max Vujovic, Sylvain Galineau, and Ethan Malasky have provided contributions in partnership with engineers on the IE team.

Adobe contributions in the Windows 10 March Technical Preview

The Adobe Web Platform Team hit a significant milestone with their first contribution landing in the March update of the Windows 10 Technical Preview! The feature is support for CSS gradient midpoints (aka color hints) and is described in the upcoming CSS images spec. With this feature, a Web developer can specify an optional location between the color stops of a CSS gradient. The color will always be exactly between the color of the 2 stops at that point. Other colors along the gradient line are calculated using an exponential interpolation function as described by the CSS spec.

Syntax:
linear-gradient(90deg, black 0%, 75%, yellow 100%)
radial-gradient(circle, black 0%, 75%, yellow 100%)

CSS Gradients in the Windows 10 Technical Preview

You can check this out yourself on this CSS Gradient Midpoints demo page. Just install the March update to Windows 10 Technical Preview and remember to enable Experimental Web Platform Features in about:flags to enable the new rendering engine. This change will bring IE to the same level as WebKit Nightly, Firefox beta and Chrome.

Another change that Adobe has recently committed is full support for <feBlend> blend modes. The W3C Filter Effects spec extended <feBlend> to support all blend modes per the CSS compositing and blending specification. Our new engine will now support these new values like the other major browsers.

New blend modes expand existing values normal, multiply, screen, overlay, darken and lighten with color-dodge, color-burn, hard-light, soft-light, difference, exclusion, hue, saturation, color and luminosity.

To use the new modes just specify the desired mode in the <feBlend> element. For example:
<feBlend mode=’luminosity’ in2=’SourceGraphic’ />

Internet Explorer 11

feBlend in Internet Explorer 11

Project Spartan

feBlend in Project Spartan on the Windows 10 Technical Preview

You can try this out today at Adobe’s CodePen demo in Internet Explorer on the Windows 10 Technical Preview by selecting “Enable Experimental Web Platform Features” under about:flags.

We are just getting started

Congratulations to the Adobe Web Platform Team on their first commit! We are looking forward to a more expressive Web and moving the Web platform forward! Let us know what you think via @IEDevChat or in the comments below.

— Bogdan Brinza, Program Manager, Project Spartan

Improving interoperability with DOM L3 XPath

Source: IEBlog Microsoft Edge Team • 19 March 2015 06:00 PM

As part of our ongoing focus on interoperability with the modern Web, we’ve been working on addressing an interoperability gap by writing an implementation of DOM L3 XPath in the Windows 10 Web platform. Today we’d like to share how we are closing this gap in Project Spartan’s new rendering engine with data from the modern Web.

Some History

Prior to IE’s support for DOM L3 Core and native XML documents in IE9, MSXML provided any XML handling and functionality to the Web as an ActiveX object. In addition to XMLHttpRequest, MSXML supported the XPath language through its own APIs, selectSingleNode and selectNodes. For applications based on and XML documents originating from MSXML, this works just fine. However, this doesn’t follow the W3C standards for interacting with XML documents or exposing XPath.

To accommodate a diversity of browsers, sites and libraries wrap XPath calls to switch to the right implementation. If you search for XPath examples or tutorials, you’ll immediately find results that check for IE-specific code to use MSXML for evaluating the query in a non-interoperable way:

In our new rendering engine, the script engine executes modern Web content, so a plugin-free, native implementation of XPath is required.

Evaluating the Options

We immediately began to cost the work to implement the entire feature. Our options included starting from scratch, integrating MSXML, or porting System.XML, but each of these was too costly for its own reasons. We decided to start implementing a subset of XPath while working on the full implementation at the same time.

In order to know what subset of the standard to support, we used an internal crawler that captured the queries used across hundreds of thousands of the most popular sites on the Web. We found buckets of queries that had the form

Each of these queries maps cleanly to a CSS Selector that could return the same results that would be returned from our performant Selectors API. Specifically, the queries above can be converted to

The first native implementation of XPath thus involved supporting queries that can be converted to a CSS selector and exposing the results through the DOM L3 XPath interface objects. Alongside this implementation, we added telemetry to measure the rate of success across broader Web usage, which accounted for the number of successful queries, number of failed queries, and the query string of the first failure.

Our telemetry from internal testing showed that 94% of queries successfully converted to selectors to unblock many Web sites. Of the failures reported through the telemetry, many took the form

which can both be converted to the selector “element.className.” With these additional changes, the success rate improved to 97%, making our new engine ready for broader usage to support the modern Web.

Internal telemetry showing XPath query success rate over time in our testing
Internal telemetry showing Xpath query success rates

Addressing the Remainder

While this supports the vast majority of the Web, converting XPath queries to Selectors is inherently limited. Additionally, we were still left with the 3% of failing queries that require support of more of XPath’s grammar, such as functions, support for non-element and document nodes, and more complex predicates. Several sites mention various polyfills for XPath, including Mozilla Development Network, for platforms that do not provide adequate support for XPath. One of the polyfills commonly cited is wicked-good-xpath (WGX), which is an implementation of XPath written purely in JavaScript. Running WGX against our internal set of tests across the XPath spec showed 91% compatibility with competitor native implementations. The idea of using WGX as a fallback for the remaining 3% became a compelling bet because it was performant and our tests already measured its functionality against other implementations. Further, wicked-good-xpath is an open source project under the MIT license, and our usage of it would align with our goals to embrace and contribute back to code from the open source community. However, JavaScript had never been used within IE to build this kind of platform feature before.

In order to support WGX without polluting a Web page’s context, we created a separate, isolated script engine dedicated to WGX. With a few modifications to WGX that provide entry points for invoking functions and accessing results, we marshal the data from the page to the isolated engine and evaluate expressions with WGX. With WGX enabled to handle native XPath queries, we see immediate gains from sites missing content in our new engine rendering the modern Web.

Before: Available prices for products don't appear on tomtom.com After: Available prices for products appear on tomtom.com

Before and after: Available prices for products now appear correctly on tomtom.com

Before: Lotto numbers are not displayed After: Get the latest Lotto numbers

Before and after: Lottery numbers now correctly display where they were previously missing

While browsing the Web with WGX, we found a few bugs that exhibit behavior which diverges from other browsers’ implementations as well as the W3C spec. We plan to make contributions back to the project that make WGX more interoperable with native implementations.

Our new rendering engine now has support for XPath to run the modern Web to enable more functionality and show more content for our customers. With data-driven development from the modern Web, we landed on a data-driven outcome of a low-cost and performant implementation on existing technologies and standards as well as open source code. Grab the latest flight of the Windows 10 Technical Preview to try for yourself! You can reach us with feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.

– Thomas Moore, Software Engineer, Microsoft Edge

Minutes Telecon 2015-03-18

Source: CSS WG Blog Dael Jackson • 18 March 2015 09:36 PM

Full Minutes

Rendering engine updates in March for the Windows 10 Technical Preview

Source: IEBlog Microsoft Edge Team • 18 March 2015 07:00 PM

Based on feedback from Windows Insiders, we are working to release preview builds more often. Today we flighted the first update to Insiders on this accelerated cadence, which includes the latest updates to our new rendering engine. Due to the change in cadence, this build does not yet include the Project Spartan preview, which will be available in the next release.

Today’s build has a number of updates to the new engine, including new features and improvements to existing features. Some of these include:

In addition, you may notice some features partially implemented and available for testing in Internet Explorer under about:flags. These features are under active development and will continue to evolve in future preview builds.

Watch this space over the next week as we’ll be diving into these in more detail in a series of individual posts. In the meantime, you can try these improvements out in the latest preview by signing up for the Windows Insiders program and joining the “Fast” update ring. To enable the new engine in Internet Explorer on preview builds, navigate to about:flags and select “Enable experimental Web platform features.” We’ll also be updating RemoteIE with the new preview soon. Don’t forget to share your feedback via the Internet Explorer Platform Suggestion Box on UserVoice, @IEDevChat on Twitter, and in the comments below.

Kyle Pflug, Program Manager, Project Spartan

Feeds

The Future of Style features:

If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.

fantasai

Made with CSS! Valid CSS!Valid HTML 4.0! RSS feed Atom feed