In the past months we worked with add-on developers to release new versions of their add-ons that follow IE’s guidelines and requirements for add-on development. We used the Upgrade Advisor to help update their users to the new versions. Some add-on vendors asked how IE determines and displays an add-on’s version. This post answers this question so that all add-on developers can design their versioning schemes to be compatible with IE features such as Manage Add-ons and the Upgrade Advisor.
There are two fields denoting the version of a binary file in Windows: file version and product version. Since IE add-ons are dynamic link library (DLL) files loaded into the browser, each add-on contains both of these version numbers. Here’s a screenshot of the properties dialog for one of our sample toolbars. Though the file version and product version are separate fields, they typically contain the same version string:
We have talked about our goal with IE9 to run the same standards-based markup as other browsers by default. It is also our goal for IE9 to successfully run the Web that you browse today. For sites that are designed to run in older versions of IE, IE9 includes support for compatible document modes and a Compatibility View (CV) List that’s similar to what shipped with IE8.
The CV List and compatible document modes are good for site developers because they enable developers to transition between IE8 and IE9 on their own schedule. We only add a site to the CV List when the site is designed to run in an older version of IE, doesn’t run well in IE9’s Standards mode, and doesn’t declare an X-UA-Compatible meta tag or header. The CV List is good for users because it means that IE9 works great with popular sites the day they upgrade and without users having to click on the Compat View button.
Internet Explorer is a universal product used by people young and old, new and experienced, speaking many different languages. A lot of people take advantage of IE’s built in accessibility features (like page zoom, caret browsing, find in page, etc) and additional assistive technology such as screen readers to use the web. Accessibility is beneficial to everyone no matter what their abilities.
As with every Internet Explorer release, we are committed to delivering a browser that’s accessible for all users. Part of achieving that goal is making sure assistive technology works well with IE. IE9 fundamentally changes how users interact with the browser and how the browser takes advantage of the entire PC. Those changes also impact how assistive technology interacts with IE, which necessitates updates from some assistive technology. For example, the new notification model is not read by many screen readers, and screen readers can no longer depend on the GDI display subsystem since IE9 uses Windows Direct2D and DirectWrite as part of enabling hardware-accelerated HTML5.
“IE9 started from the premise that the modern web will deliver HTML5 experiences that feel more like native applications than sites. Building on hardware-accelerated SVG, canvas, video, audio, and text, developers will use the power of the whole PC to achieve great performance. On the modern web, developers will use the same markup across different HTML5 browsers.” – Dean Hachamovitch, Corporate Vice President, Windows Internet Explorer
Why start a post on designing the new Windows Internet Explorer 9 logo with a quote from our post on IE9’s Developer Platform Preview 4? As logo designer Paul Rand said in his book Design, Form and Chaos, “It is only by association with a product, a service, a business, or a corporation that a logo takes on any real meaning.”
The decision to evolve the logo, and the choices we made in the redesign were driven by the fundamental improvements in performance and standards support. Leading up to the Beta release, Platform Preview builds have been the viewport into the engineering behind Internet Explorer 9’s platform. For all of us, IE9 is about making web sites shine. It’s about the web sites you go to every day on your PC. It’s about the developers who make those sites for you. It’s about a browser that helps you accomplish your everyday tasks faster than ever before.
Before we describe what a fast and modern web means for our logo, let’s look at the history of the Internet Explorer mark.
Our approach to building a faster web browsing platform, as seen in the Platform Previews, involves using everything the PC and its hardware have to offer. Before IE9, browsers used perhaps 10% of the PC’s capability. IE9 has shown the clear performance benefits with full hardware-acceleration of webpages.
Our approach in designing a site-centric web browsing experience also involves using everything available around the browser. We see all the pixels and code that people need for a significantly better browsing experience already there on the screen. The beta of Internet Explorer 9, available now at www.BeautyOfTheWeb.com in 33 languages, reflects this unique approach:
Many enthusiasts want a fast browser, and they want to consistently and easily measure the performance of different browsers. There are lots of “benchmarks” in the history of software, and lots of benchmarks around browsers. The challenge with benchmarks is generally understanding what the benchmark measures and deciding whether those measurements are important to customers, developers, and you.
This blog post takes a closer look at some of today’s most common benchmarks. We’ll provide context on their origins, talk about what they test, and show you what browser subsystems each benchmark executes.
Celtic Kane Celtic Kane is generally credited with being the first JavaScript benchmark. It was originally created in 2006 by a web developer (Sean Patrick Kane) and became popularized after the benchmark was featured on Digg.com. Celtic Kane consists of eight simple test cases which are each run once and measured in milliseconds. Celtic Kane claims to focus on core JavaScript and DOM performance; however the DOM tests inside Celtic Kane don’t actually measure the DOM.
Complete Web Standards with multiple browser implementations and comprehensive test suites are the backbone of the interoperable Web. Getting web standards through the complete standardisation process and turned into official W3C Recommendations takes a lot of effort. While it is tempting to view the latest editor’s draft of a specification as a “standard”, a large part of the complexity that ensures good interoperability happens in the “last mile”. In the last couple of weeks, several key web specifications have reached important milestones and these examples illustrate how the process works.
Last Call is the signal that the working group believes the spec is functionally complete and is ready for broad review from both other working groups and the public at large. The working group must respond to all the comments received during Last Call and this often results in changes to the specification. A further Last Call could be necessary if the changes are substantial.
The HTML parser is an important part of how we deliver on same markup because it plays a vital role in how the DOM is constructed. Therefore, it also plays a big role in how any DOM API or CSS rule is applied. While we’ve talked a lot about some of the high-profile API improvements in IE9 – getElementsByClassName, addEventListener, and so on – one important improvement we haven’t talked about is the HTML parser.
This is clearly important for developers, so we made interoperability improvements to our HTML parser in IE9 Standards Mode. This blog post provides practical guidance on how these improvements affect your site and how to avoid pitfalls in areas where all browsers still don’t behave the same way.
We’re excited that other browsers have started to use hardware to accelerate graphics performance. With different implementations starting to become available, now’s a good time to blog about the difference between full and partial hardware acceleration.
In November 2009, developers had their first look at hardware accelerated graphics in a browser at the PDC. In March 2010, we released the first IE9 Platform Preview with “GPU-powered HTML5” turned on by default. In that release, hardware acceleration applied to everything on every Web page—text, images, backgrounds, borders, SVG content, HTML5 video and audio—using the Windows DirectX graphics APIs. With Platform Preview 3 in July, IE9 introduced a hardware-accelerated HTML5 canvas.
Browsers can use hardware to accelerate none, some, or all of the steps in rendering an HTML pages. The diagram below illustrates the major steps in HTML page rendering in IE9.