IEBlog

Web Performance APIs Rapidly Become W3C Recommendations

ieblog — Wed, 22 May 2013 02:12:12 GMT

The W3C Web Performance Working Group recently published three specifications as W3C Recommendations with full implementations from all major browser vendors, advancing developers’ ability to accurately measure the performance of Web applications and make the Web faster. Over the last three years, companies including Microsoft, Google, Mozilla, Intel, Facebook, and others have been working towards standardizing the Navigation Timing, High Resolution Time, and Page Visibility interfaces in the Working Group. Rapid adoption of these recommendations demonstrates what’s possible when the industry and community come together through the W3C.

To make the Web faster, developers need the ability to accurately measure the performance characteristics of Web applications and the ability to effectively use the underlying hardware to improve the performance of their applications. To solve these problems, the Web Performance Working Group worked on 15 different specifications that address those issues. The table below shows the maturity level of all the specifications currently edited by the Working Group.

Specification	Editor’s Draft	First Public Working Draft	Last Call	Candidate Rec	Proposed Rec	Rec
Navigation Timing	Sept 2010	Oct 2010	Jan 2011	Mar 2011	July 2012	Dec 2012
Resource Timing	Sept 2010	May 2011	Aug 2011	May 2012
User Timing	Oct 2010	Aug 2011	Sept 2011	July 2012
Performance Timeline	July 2011	Aug 2011	Sept 2011	July 2012
High Resolution Time	Feb 2012	Mar 2012	Mar 2012	May 2012	Oct 2012	Dec 2012
Page Visibility	Apr 2011	June 2011	July 2011	July 2012	Feb 2013	May 2013
Display Paint Notifications	May 2011	June 2011	Feb 2012
Navigation Timing L2 (NEW)	Jan 2013	Jan 2013
Efficient Script Yielding	June 2011
High Resolution Time L2 (NEW)	Apr 2013
Beacon (NEW)	Mar 2013
Resource Priorities (NEW)	Apr 2013
Navigation Error Logging (NEW)	Apr 2013
Resource Error Logging (NEW)	Apr 2013
Prerender (NEW)

The Navigation Timing, Resource Timing, User Timing, and Performance Timeline specifications help developers accurately measure the timing of the navigation of the document, fetching of resources on the page, and developer script execution. Prior to these APIs, this data wasn’t easily obtainable. Navigation Timing was published as a W3C Recommendation, and all major browser vendors support it. The other three interfaces are currently at the Candidate Recommendation stage awaiting two full implementations from browser vendors. IE10 is currently the only browser that implements all of these interfaces, however, other vendors are working on implementations.

To ensure these performance metrics are measured in the most accurate way possible, the High Resolution Time specification allows developers to measure operations with sub-millisecond accuracy. This interface not only benefits accurate measurements of performance metrics, but also allows better frame rate calculations and synchronization of animations or audio cues. This interface has been published as a W3C Recommendation, with all major browser vendors implementing the performance.now() method defined in the specification.

The Page Visibility API allows for programmatically determining the current visibility state of the page. Developers can use this data to make better CPU- and power-efficiency decisions, e.g., throttling down activity when the page is in the background tab. This specification has also been published as a W3C Recommendation, with all major browser vendors implementing it.

The Timing Control for Script-Based Animations, and Efficient Script Yielding specifications help developers write more CPU- and power-efficient Web applications. The requestAnimationFrame API, from the Timing Control for Script-Based Animations specification, allows for creating more efficient JavaScript animations. All browser vendors fully support this interface, with the Working Group actively working on publishing this specification as a Candidate Recommendation. The setImmediate API, from the Efficient Script Yielding specification, allows developers to efficiently yield control flow to the user agent and receive an immediate callback, efficiently leveraging the CPU. IE10 is the first browser to implement this interface.

This year the Working Group also started to look at new ideas, with editor’s drafts of those ideas currently being discussed in the Working Group. The Beacon API is intended to help scripts asynchronously transfer data to a Web server without blocking the unload event, which can negatively impact the perceived performance of the next navigation. The Resource Priorities API defines a means for Web developers to give the browser hints on the download priority of resources to help improve the page load time. As a corollary to the Timing specs, the Navigation Error Logging and Resource Error Logging specifications help developers understand the errors and availability of their applications. The Navigation Timing Level L2 specification adds High Resolution Time and Performance Timeline support to Navigation Timing, and High Resolution Time L2 specification adds Web Worker support. These are just some of the drafts the Working Group is currently defining, with more specification drafts on Prerender and other diagnostics areas forthcoming.

The W3C Web Performance Working Group is a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers. Together with industry and community leaders who participate in the Working Group, we hope to continue to make rapid progress on interoperable standards that will help developers make the Web faster.

Thanks,
Jatinder Mann
Internet Explorer Program Manager

IE Dev Center: Finding the resources you need, quickly

ieblog — Mon, 20 May 2013 16:55:44 GMT

Last week we launched a remodeled Internet Explorer Developer Center (msdn.com/ie) to make it easier for developers to find the comprehensive documentation quickly. Based on your feedback, we’ve adjusted our site structure as part of a larger Windows Dev Center redesign in order to:

Make it easier to find developer topics across versions of IE
Find more comprehensive API documentation faster
Learn best practices from developer guides, tutorials, and sample code

We organized the new IE Dev Center into three main areas:

Get Started

Here, you can download IE, learn more about F12 developer tools, and access our Developer Guides and Compatibility Cookbooks to learn about what’s new and changed in the latest versions of IE.

Plan

Find inspiring ideas, tips on updating to Web standards, details on the browsing experiences of IE10 on Windows 8, useful info about going plug-in free, building adaptive and touch-ready sites, and integrating your site with Windows.

Develop

Access portal pages for Web platform features, our API reference, samples gallery, and community forums.

The Develop section represents the heart of the IE library content. To help you find the content you need quickly, we reorganized our most highly-trafficked pages to bring together all the relevant resources on the same topic.

With the new organization of the IE Developer Center, you don’t have to know which version of IE introduced or changed a feature in order to find all of our information about it. Instead, you can conveniently find our Dev Guide topics through an alphabetical list of the modern Web platform features supported by IE, or you can browse them thematically by area. Of course, we will continue to publish these same topics within the particular IE Dev Guide versions in which they were introduced.

There are more improvements underway, but hopefully you’ll find the new IE Developer Center immediately more useful and usable. We’ll continue to listen to your feedback and look for ways to make our content easier to access and more relevant to the work you do. We welcome your feedback here in the blog or on the site.

Erika Navara, Content Developer

May 2013 Internet Explorer Updates

ieblog — Tue, 14 May 2013 19:38:57 GMT

Microsoft Security Bulletin MS13-037 - Critical

This security update resolves eleven privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited the most severe of these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, Internet Explorer 9, and Internet Explorer 10 on Windows clients and Moderate for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, Internet Explorer 9, and Internet Explorer 10 on Windows servers. For more information, see the full bulletin.

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

Microsoft Security Bulletin MS13-038 – Critical

This security update resolves one publicly disclosed vulnerability in Internet Explorer. The vulnerability could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 8 on Windows clients and Moderate for Internet Explorer 8 on Windows servers. This security update has no severity rating for Internet Explorer 9. For more information, see the full bulletin.

This security update also addresses the vulnerability first described in Microsoft Security Advisory 2847140.

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

Microsoft Security Advisory (2755801)

Today, we also announced the availability of an update for Adobe Flash Player in Internet Explorer 10 on all supported editions of Windows 8 and Windows Server 2012. The details of the vulnerabilities are documented in Adobe security bulletin APSB13-14

The update addresses vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10. For more information, see the advisory.

Most customers have automatic updating enabled and will not need to take any action because this update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

— Ceri Gallacher, Program Manager, Internet Explorer

W3C Transitions Pointer Events to Candidate Recommendation

ieblog — Thu, 09 May 2013 22:35:02 GMT

Today, the W3C published Pointer Events as a Candidate Recommendation, an important step towards a standard and interoperable way to handle input from touch, pen, mouse, and more. This fast 5-month progression from First Public Working Draft to Candidate Recommendation is a mark of the effective collaboration between Microsoft, Google, Mozilla, Opera, Nokia, jQuery, and others to help sites take advantage of new interactive hardware on the Web.

Candidate Recommendation indicates the W3C considers the specification widely reviewed and satisfying the Working Group’s technical requirements. It signals a call for additional implementations to inform the group. The Pointer Events Working Group is also now actively producing tests to validate implementations of the specification. The recent Test the Web Forward event, sponsored by Microsoft, helped fuel this effort with nearly two dozen new test cases.

Increasingly, consumers browse the web with a broad range of devices; with touch, mouse and keyboard. By using pointer events, developers can write to a unified model that allows sites to be responsive to many types of input. Web developers can take advantage of pointer events in IE10 today, and in other browsers using polyfills like Hand.JS. We’ve also created a new portal on WebPlatform.org to help you learn more and try pointer events out. Pointer Events is one of many ways we’ve made touch fast and fluid on the Web.

Jacob Rossi

Program Manager

Test the Web Forward – Seattle 2013

ieblog — Fri, 26 Apr 2013 16:39:16 GMT

On April 12-13, Microsoft hosted a record-setting Test the Web Forward event to advance the Web by creating interoperability tests. Dozens of volunteers from Adobe, AT&T, Blackberry, Mozilla, and many other local companies joined us at our Seattle offices to learn about Web standards testing, how to write CSS and HTML tests, as well as the tools available for test suite management. Attendees from around the country - and even Canada – contributed to create a record-breaking 514 overall new tests.

Why Tests?

The quality and correctness of different browsers’ HTML and CSS standards compliance continues to vary widely. The W3C requires independent tests of all normative requirements in a specification in order to move a W3C Web specification from a candidate recommendation to an official recommendation. These tests are used to ensure that at least two browsers fully support each normative statement. As you might imagine, creating all of these tests is daunting; HTML5 is expected to need well over 100,000 tests, to say nothing of CSS3 modules, WebApps, Media Extensions, etc. We have submitted thousands of test cases for HTML, CSS, and SVG that can be viewed at the W3C and the Internet Explorer Test Center, however more tests are still needed. These tests benefit all browsers – and ultimately the entire Web developer community – by ensuring a consistent, predictable behavior. As different browsers improve their same-markup support, we can all realize the promise of HTML5 and CSS3.

A few years ago, several members of the standards community turned to crowd-sourcing to help create new tests, this resulted in Test the Web Forward events.

With the sponsorship of major players like Microsoft, Adobe, Google, and Mozilla, the Web community has come together, running local test-writing sprints around the world—France, China, Australia, and the US. Each sprint not only generates hundreds of tests, but also engages with and educates Web developers about the specifications that make up the Web platform.

Inside the Seattle Event

Our friends at Adobe were instrumental in setting up a successful event, building upon their experience in running previous events. In Seattle we kicked off the hack-a-thon on Friday night, with inspirational and informative presentations from Mozilla's fantasai (Elika Etemad), Adobe's Rebecca Hauck, and Microsoft's Kris Krueger, explaining why we need tests, what type of tests are available, and how to create them. Here’s a quick outline:

Stand-alone tests typically rely on visual verification: if a failure condition occurs, red content will show.

Reference tests compare a test against a visual reference that has no dependency on the feature being tested. Note that the test includes a link to the reference test against which is should be compared. For example, if you wanted to test that DIVs render background colors correctly, you might make a ref test using TABLEs.

Object Model tests depend on a JavaScript test harness; they verify that the object model reflects what static style sheets specify. For instance, this CSS media query test.

These presentations were followed by 2-minute pitches from Saturday's session test leaders on why participants might want to pick a particular focus (CSS Flexbox, Pointer Events, CSS Transforms, CSS OM, Backgrounds & Borders, Exclusions, or HTML5), though session participants were free to write tests against any API or spec they felt passionate about.

Following breakfast the next morning, participants broke up into three rooms with session leaders helping out in each. Each area was staffed by experts (in addition to the speakers from the previous evening): Arron Eicholz (Microsoft, CSS); Jacob Rossi (Microsoft, Pointer Events); Sylvain Galineau (Adobe [formerly Microsoft], CSS); Alan Stearns (Adobe, CSS); Dave Methvin (President of jQuery, HTML).

The leaders instructed everyone on how to determine where tests were needed and how to create code that tested the specific assertion that we wanted to capture. Volunteers could either work on their own, work in small groups, or get 1:1 help with the experts.

When all was said and done, the sprint generated 514 submitted tests, just edging out the record set by the Paris test sprint and setting a new bar for upcoming sprints to beat. After a few celebratory drinks, the end of the night saw the raffling off of a Surface Pro which was won by a student volunteer who joined us from the University of Washington.

You Can Help Too!

In IE10, we have added support for a long list of new standard features across CSS, HTML, SVG and the DOM. We have published some of our test cases for these new features on our IE Test Center. We will be submitting more, but we still need help from the community to get the right tests written and move these specs forward.

We are excited to be part of the community working towards a more innovative and interoperable Web. We support several initiatives in this direction, like the recent donation of JavaScript documentation to Webplatform.org, or our continued efforts to simplify cross-browser testing with modern.ie. If you want to help move the Web forward, too, come and join us at one of the next Test the Web Forward events! In the meanwhile, you can learn how to contribute tests, or review existing tests online. To hear about upcoming events and to stay in touch with the rest of the Test the Web Forward community, please subscribe to our W3C mailing list: public-testtwf. If test writing sounds too intense, but you are still knowledgeable and passionate about the Web, you can get involved with the WebPlatform Docs project and help document the Web.

For more info and updates, follow our Internet Explorer developer relations handle on Twitter @IEDevChat, this initiative’s handle @testthewebfwd and in particular #testtwf.

We will keep you posted on upcoming events and we are looking forward to meeting you soon!

—John Jansen, Kris Krueger, Arron Eicholz, and Jacob Rossi – Internet Explorer

Enabling Professional-Quality Online Video: New Specifications for Interoperable Captioning

ieblog — Thu, 25 Apr 2013 15:58:34 GMT

Video captioning on the Web is about to get significantly better, putting in place another critical building block for enabling professional-quality online video delivery and playback. To achieve the experience of broadcast television, the Web needs to provide captioning capabilities including word highlighting, tight synchronization between captions and spoken word, flexible caption positioning, caption styling, and caption animations – all of which are part of a recently published profile specification from the W3C Timed Text Working Group (TTWG). Microsoft has joined with content owners, video distributors, and device providers in developing the specifications to ensure interoperability and streamline closed caption authoring and delivery. For content and tool providers, the specification enables authoring of interoperable caption files for delivery to a wide variety of software and devices, while meeting evolving industry requirements.

Captioning is an intrinsic part of any professional-quality video experience—and the impact goes far beyond enabling the hearing impaired to gain full access to the video content. Captions are turned on in loud environments, such as at the gym. Captioning is used to help us all understand foreign language films. Of course, I’m surely not the only person who turns on captions to better understand difficult accents in movies streamed on Netflix.

In February 2013, Microsoft joined industry stakeholders in the W3C Timed Text Working Group (TTWG) to deliver the TTML Simple Delivery Profile for Closed Captions (SDP-US) profile specification. This new profile was created with input from media industry experts from DECE, SMPTE, EBU and industry players including Adobe, MovieLabs, NBC Universal, Cox, Apple, Netflix and Microsoft.

SDP-US is based on Timed Text Markup Language (TTML) (a caption interchange specification that has been used in the professional video industry for years) and clearly defines key caption format features like layout, style, timing and content requirements, enabling content authors and tool providers to easily create interoperable caption files that meet evolving industry requirements. SDP-US will help streamline creation of closed captions to deliver media content to the Web across a wide variety of software and devices – in a browser like Internet Explorer, on devices such as Xbox or through applications built using the Microsoft Media Player Framework.

Internet Explorer was one of the first browsers to include early support for HTML5-based video captioning via the <track> element with TTML and WebVTT file formats. Since then, we’ve heard clear feedback from content authors: They need an interoperable, simple and full-featured captioning solution that meets emerging requirements for browsers and other software on Internet-connected devices. SDP-US will meet this need by defining a streamlined set of captioning capabilities for the HTML5 <track> element. Developers will be able to add captioning to an HTML5 video by providing a caption file that contains a styled text representation of the video dialog or actions and by using the <track> element to render and display the contents of that file.

To illustrate some of the power of the new SDP-US captioning specification, here’s an example of how Internet Explorer renders captions with a default plain text style and position:

With SDP-US, caption authors have much more flexibility in caption positioning and styling, as shown in the below examples:

Professional-quality online video is a forthcoming reality, enabled by emerging Web specifications and powerful content delivery infrastructure. Captioning is an important building block for enabling professional-quality video, and Microsoft is actively working with industry partners to enable rich captioning experiences. If you are working on Internet video, we invite you to review the new SDP-US profile, join the industry discussion, start considering how your caption content can adapt to SDP-US, and let us have your feedback.

-- Sandeep Singhal, Group Program Manager, Internet Explorer

April 2013 Internet Explorer Updates

ieblog — Tue, 09 Apr 2013 18:17:44 GMT

Microsoft Security Bulletin MS13-028 - Critical

This security update resolves two privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Microsoft Security Advisory (2755801)

Today we also released an update that addresses vulnerabilities in Adobe Flash Player in Internet Explorer 10 on Windows 8. The details of the vulnerabilities are documented in Adobe security bulletin APSB13-11. The majority of customers have automatic updates enabled and will not need to take any action because the update will be downloaded and installed automatically. For those manually updating, we encourage you to read the advisory and apply this update as quickly as possible.

This update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash binaries contained within Internet Explorer 10. For more information, see the advisory.

— Ceri Gallacher, Program Manager, Internet Explorer

New on modern.IE: Free VM Downloads, Windows 8 QuickStart Kits, Enhanced Code-Scanning Tools, and More

ieblog — Tue, 02 Apr 2013 14:12:00 GMT

Today, we are updating modern.IE with enhanced tools and resources to help you test your sites for modern browsers like Internet Explorer 9 and 10, while also helping you support older versions of browsers. These enhancements address the most common feedback, suggestions, and requests that we have received from enthusiastic users since introducing the site in January.

With today’s update, we are making available a new offer, new downloads, and tool enhancements on modern.IE. Some highlights include:

Order a Windows QuickStart Kit for Mac Developers, including Parallels Desktop 8 and Windows 8 on a USB stick shipped to you for a $25 donation to select charities (Update 10:45am PDT 4/2/2013: The Windows Quickstart offer sold out quickly. Given how popular these were, we will look into making other offers available in the near future.)
Download new virtual machines for IE10 on Windows 7 and IE8 on Windows XP
Scan a Web page URL now identifies more interoperability issues, even for sites located behind a firewall.
Availability in 18 languages

We continue to offer 3 months of free BrowserStack access so you can easily test across browsers and OS platforms without changing your primary development environment.

We are excited to see the developer reception to modern.IE so far. We appreciate the thoughtful feedback in tweets and suggestions you have offered on ways we can help save time and improve how you test your Web experiences. Today’s modern.IE release incorporates much of that feedback. Please do keep the comments coming, as we will continue to update the site regularly.

For the Mac user: Get the Windows QuickStart Kit including Windows 8 with Parallels Desktop 8

We heard that the most common way you test across browsers is through virtualization of browser and operating system combinations using your favorite virtualization platform, such as Hyper-V, VMWare, VirtualBox, or Parallels. However, costs to purchase software and licensing can be difficult if you’re that startup looking for your first big breakthrough.

Today we’re making it just a little easier with a new combo offer: We’ll ship you a copy of Windows 8 and Parallels Desktop 8 for Mac virtualization on a USB stick for a $25 donation to your favorite charity, courtesy of our friends at Swish. (Update 10:45am PDT 4/2/2013: The Windows Quickstart offer sold out quickly. Given how popular these were, we will look into making other offers available in the near future.)

We only have a limited supply available. You can get the details and pre-order here.

Download new virtual machines

You told us that you want to be able to access as many testing environments as possible with minimal extra effort. Today we announce new virtual machines that are available for free:

IE10 on Windows 7
IE8 on Windows XP

We also received lots of feedback from developers on Mac and Linux concerning how to simplify your testing experience. We have added Parallels for Mac images for all IE versions. Many of you had some challenges downloading the VMs previously, and in response, we have updated the VM installation process to be simpler. Complete download information is available here.

Scan a Web page URL for common coding issues: Enhanced tools now also run behind a firewall

Based on your feedback and experience, we have enhanced the scan a Web page URL tool to provide more flexibility and to offer more detailed and actionable guidance. Over the past two months, you have scanned hundreds of thousands of URLs – from top sites like Facebook, Pandora, and Yahoo! to the local pizza store near you. We have studied the most common coding issues reported on these sites and looked at which issues resulted in fixes or enhancements to the site. We also received hundreds of new ideas directly from the community. The result was a set of new enhancements that make the scanner a more complete testing solution for your site:

Scan your Web pages behind a firewall: The most common feedback we heard is that today, so many sites include authentication, are internal or commercial line-of-business Web apps, or are otherwise not available to the public Internet. Now, you can install a local instance of modern.IE to scan your code while keeping your project secure from others (including Microsoft). Install it through node.js and access your site via localhost.
Deeper scan for common IE compatibility issues: We heard from you that the first step when testing for IE is knowing whether your site is on the Compatibility View list, but what you really want to know is how to fix the underlying compatibility issues. Now on modern.IE, you can scan your site using our Compat Inspector tool using browser automation, provided by Sauce Labs, without adding a single line of code to your site. The result is a line-item list of suggested fixes.
Breakpoint detection for responsively designed sites – We found that you were most interested in learning how to adapt your Web experiences to support the growing range of devices – from phones and tablets to the big screen IE on XBOX. About 20% of top traffic and influential sites now offer some form of mobile-optimized experience – a significant growth in the past year. The scan a Web page URL tool now has built-in logic to detect when a Web page has been optimized for the common horizontal screen resolutions (or “breakpoints”). While we recommend that you let your site’s content determine which breakpoints to build for, we do suggests the most common ones across a range of devices.
Touch-optimization detection: As touch support evolves toward a Web standard, we also learned that sites currently implement touch support in a variety of ways. modern.IE now detects Touch functionality across multiple JavaScript-, HTML-, and CSS- based techniques.
Browser plug-ins: Recently we announced that Internet Explorer 10 in Windows 8 and Windows RT have been updated to enable Flash content to run by default. If you want to check to see if your site is on the Flash CV block list, you can now scan for this on modern.IE.

We have also made dozens of bug fixes in the scanning tool to handle Web pages that used less common practices or frameworks & libraries. If you scanned a Web page and got an error, we encourage you to try it again!

modern.IE for the World-Wide Web

modern.IE will be available in 18 languages throughout the next two days, making it a bit easier for site developers around the world. The supported languages include Arabic, Bahasa Indonesia, Chinese (Simplified, Traditional, and Hong Kong), Dutch, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Russian, Spanish (Spain and Latin America), Swedish, Thai, Turkish, and Vietnamese.

modern.IE – Testing made easier

We will continue to enhance modern.IE with your help. Please continue to share your feedback on this resource. Please continue to let us know what you like, and what we’re missing!

-- Sandeep Singhal, Group Program Manager, Internet Explorer

Spring Forward: Advancing Historical Date and Time Calculations on the Web

ieblog — Mon, 25 Mar 2013 18:10:00 GMT

Spring Forward: Advancing Historical Date and Time Calculations on the Web

Web developers want to create world-ready applications to reach a global audience. Internet Explorer 10 brings the historical Daylight Saving Time, already available on the underlying OS, to the Web developer. This enables apps and sites to interact with historic dates and times across various time zones more accurately.

Earlier this year we explored the emerging ECMAScript Internationalization APIs that will enable things like currency representation and locale sensitive string comparison from within the Web standards platform, scenarios that previously required native interoperability or use of a plug-in. Along the same theme of making the Web platform world-ready, we published a demo exploring how browsers interact with historical date and time zone information.

Challenges with historical date and time calculations

When interacting with historical dates, like interpreting historical stock prices or birthdays or historical events, Web developers often have to perform validation on the server. Developers have to rely on server because Daylight Saving Time adjustments done to the dates by JavaScript engines today are not as accurate as platforms commonly run on the server like .NET, PHP / Perl, and Java. In addition to historical JavaScript dates being inaccurate, they are often not interoperable among browser platforms. Hence, developers are not able to take reliable dependency on the DST adjusted dates generated in JavaScript.

IE10 is the first browser with more accurate DST adjusted dates aligned with the changes made to section 15.9.1.8 of the ECMAScript 6 draft specification. We expanded the capabilities of the Web platform based on the scenarios where Web developers have to interact with the server for accomplishing their needs. We looked at how JavaScript engines interpret historical dates and adjust for DST. We noticed a shortcoming in the ECMAScript standards specification that prevents existing JavaScript implementations from being more accurate in adjusting for daylight savings time. We worked with the ECMAScript standards committee and proposed a specification change to drive more clarity into the next version of the ECMAScript specification.

Exploring the Test Drive Demo

To illustrate this problem and see how your favorite browser deals with historical dates, you can play with the Historic Dates Test Drive demo by clicking on any icon of an event in aerospace history at the bottom of the demo. When you do so, the browser reads the historic date when the event occurred, and shows the date and time by applying the daylight saving rule that the browser defaulted to for when the event occurred. The demo then verifies if the historic date and daylight saving is correct or not.

In the above case, when viewing the historic date for when the IMAGE spacecraft was launched, IE10 running on a Windows 8 machine in Pacific Standard Time zone is now accurately able to determine the correct date and daylight saving time for the historic event.

Note: Daylight savings time is not applicable to all time zones, and there do exist time zones where the daylight savings rules have not changed ever. In case your system is currently in such a time zone, we’d recommend you to change your system’s time zone to one where the daylight savings rules exist and have changed over a period of time (like Pacific Standard Time) and re-run the demo. While IE10 does immediately picks up the system time zone change, in case you are using any other browser, you might need to restart the browser for the updated time zone to take effect.

Improved handling of historic dates and times in IE10

Let us take a closer look at to see how the current ECMAScript specification impacts the accuracy of adjusting dates for DST in JavaScript:

Section 15.9.1.8 of ECMAScript 5.1, specifies that JavaScript implementations like Internet Explorer’s Chakra engine should typically follow while dealing with historic dates:

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result.

In simplified words, this means that to deal with a historical date, a JavaScript implementation should either apply the current daylight saving time algorithm to a historic date, or determine the day for Jan 1st of a year, calculate if it was a leap year, find the current daylight saving time rules for a year with the same attributes (start day and leap year), and apply that particular daylight savings time to the historical date. As an example for the latter, the year 1972 was a leap year that started on a Saturday. And, the next leap year that started on a Saturday was 2000. According to the language specification, JavaScript implementations could either use the current, or use the daylight saving rules for year 2000 while manipulating any dates for the year 1972.

There are two key problems when either of the above rules is used to apply daylight saving time rules to historic dates. First, the daylight saving rules for a particular time zone are not constant and change over time. This could lead to wrong rules being applied to a historic date. Second, for the time zones where daylight saving rules have changed over a period of time, Web applications are no longer able to maintain parity for those historical dates as calculated by the OS platform that they are running on, often forcing developers to hack around such interoperability problems between Web applications and the platform that they run on.

The ECMAScript 5.1 specification text in 15.9.1.8 as we saw above allows implementations to be as wrong as they would like about daylight savings adjustments, but constrains how correct they should try to be. This is somewhat counterintuitive, and in practice, has not succeeded in producing consensus between browsers. Instead of constraining time zone offset behavior as in section 15.9.1.8, the specification should leave DaylightSavingsTA implementation dependent.

Our testing showed that, none of the existing browser implementations (latest versions) fully adheres to either the behavior specified in the standard across platforms or accurate in DST adjustments when dealing with dates. Here are some examples that show the difference in the US Pacific time zone:

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
4/1/2000	420	420	420	420	420	420	480	480	480	420

Note that on this date Chrome, FireFox and Node are inconsistent between OSes. Almost everyone is actually wrong though, the actual DST adjustment was 480.

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
3/10/2011	480	480	480	480	480	480	480	480	480	480
3/10/2109	480	480	480	480	420	480	480	480	420	420

Note that on this date, a few environments are again violating ES5.1 rules (these two years both start on Tuesday and are not leap years), but here there are disagreements even on a single OS (both on Windows and Mac).

Looking Ahead

Starting with Internet Explorer 10, the Chakra engine now uses the daylight saving time information available from the Windows platform that the browser runs on for conversions between local time and UTC.

After we reported the spec issue and worked with the ECMAScript standards committee to drive more clarity into the next version of the ECMAScript specification to enable the Web platform to be interoperable and more accurate, the latest draft of the ECMAScript 6 specification now details how enhanced and accurate support for daylight saving time rules should be applied to dates to produce more accurate information. IE10 the first browser that conforms to the updated specification and we hope that other browsers will also enhance their support to address the issues in their next releases, allowing Web developers to create rich world ready applications.

As the Web platform continues to grow in importance, rich application logic is now often written entirely in JavaScript, including that used by calendaring applications, spreadsheets, project management software, etc. To allow developers to maintain compatibility, this change is only enabled in IE10’s standards mode. In case you calculate historic dates in your Web applications and have custom logic to work around the inaccuracies of the browsers, you might want to ensure that the custom logic still works properly as you upgrade your Web applications to work on IE10.

-- Suresh Jayabalan, Program Manager, JavaScript Team

IEAK 10 now available for Windows 7 and Windows 8

ieblog — Fri, 22 Mar 2013 18:11:30 GMT

Internet Explorer Administration Kit 10 (IEAK 10) now supports building custom Internet Explorer 10 packages for Windows 7 and Windows 8. IEAK 10 simplifies the creation, deployment, and management of customized Internet Explorer 10 packages. You can download IEAK 10 from http://ieak.microsoft.com.

Kevin Luu, Program Manager, Internet Explorer