IEBlog.com: About Web Browser

IEBlog
1. Follow Up on HTML5 Video in IE9

Our recent post generated many comments and questions. The discussion of intellectual property rights is complex and invites many different points of view. This is a good opportunity to talk through the certainty and uncertainty relative to our goals for IE9 from Microsoft＊s point of view.

Developers have consistently conveyed that they want certainty and predictability in the underlying browser platform. We want to deliver a great HTML5 experience in IE9 with great certainty.  The goal of certainty informs a lot of choices, such as which of the many standards still under construction we＊ll pursue. Browser developers have to make decisions like this all the time.

For many reasons, H.264 video offers a more certain path than other video formats and does so in a way that delivers a great HTML5 experience for developers and end-users. First and most important, we think it is the best available video codec today for HTML5 for our customers. Relative to alternatives, H.264 maintains strong hardware support in PCs and mobile devices as well as a breadth of implementation in consumer electronics devices around the world, excellent video quality, scale of existing usage, availability of tools and content authoring systems, and overall industry momentum 每 each an important factor that contributes to our point of view.

H.264 also provides the best certainty and clarity with respect to legal rights from the many companies that have patents in this area.  The rights for implementations of the H.264 standard (see this Wikipedia article about the standardization process) are managed by MPEG-LA as part of a program that has been in place for many years. This long-standing licensing program for a codec that is in broad usage today in the industry provides a stable system from which we can support our customers. As experts will note, there is never complete certainty in an area like this one.

Some comments asked for examples to support the statement in the previous post about ※The rights to other codecs are often less clear, as has been described in the press.§ One comment linked to a Streaming Media article; other examples are easy to find.

Intellectual property is a complex topic. As it＊s not an engineering topic and this is an engineering blog, the remarks here are by definition limited.  On the topic of whether one person＊s codec does or doesn＊t use someone else＊s intellectual property, the only opinion that ultimately matters is a court＊s.  Many people seem to assume that availability of source code under an open source license implies that there are no additional costs, or that the code has properly secured necessary intellectual property rights from all rightful owners.  Our experience and the experience of others indicate otherwise, and the web standards groups have discussed this issue as well. For other codecs, it＊s not clear today how the rights will be determined for commercial scenarios and what the costs will be. By virtue of existing commercial use in a wide variety of products implemented by a large number of companies, H.264 minimizes uncertainty for consumers and developers.

Several comments speculated about Microsoft＊s financial interest in the codec. (Microsoft participates in MPEG-LA with many other companies.) Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264. Much of what Microsoft pays in royalties is so that people who buy Windows (on a new PC from an OEM or as a packaged product) can just play H.264 video or DVD movies. Microsoft receives back from MPEG-LA less than half the amount for the patent rights that it contributes because there are many other companies that provide the licensed functionality in content and products that sell in high volume. Microsoft pledged its patent rights to this neutral organization in order to make its rights broadly available under clear terms, not because it thought this might be a good revenue stream. We do not foresee this patent pool ever producing a material revenue stream, and revenue plays no part in our decision here. 

There were many questions about royalties, and a lot of speculation in the comments about licenses and payments. The majority of H.264 video content on the web today is royalty-free.   MPEG has said that individuals can create video files in the H.264 format and distribute them and play them over the internet for non-commercial purposes without further obligation on licensed platforms like Windows. We are aware that this commitment is set to expire in 2016, but fully expect to commit to supporting the extension of this license and associated terms beyond that date. In general, distributing encoders or decoders or offering sophisticated pay-for-video requires a license from MPEG-LA.  Third-party applications that simply make calls to the H.264 code in Windows (and which do not incorporate any H.264 code directly) are covered by Microsoft＊s license of H.264. 

Some comments pointed to language in our Windows EULA that comes directly from MPEG-LA and reinforces many of these terms. As with all licensing programs, there are limitations and issues, which people have pointed out.  The functionality we provide is technology we license and we follow the terms of that license.

Several comments asked about Microsoft＊s support for plug-ins (like Flash and Silverlight). Of course, IE9 will continue to support Flash and other plug-ins. Developers who want to use the same markup today across different browsers rely on plug-ins. Plug-ins are also important for delivering innovation and functionality ahead of the standards process; mainstream video on the web today works primarily because of plug-ins.  We＊re committed to plug-in support because developer choice and opportunity in authoring web pages are very important; ISVs on a platform are what make it great. We fully expect to support plug-ins (of all types, including video) along with HTML5.  There were also some comments asking about our work with Adobe on Flash and this report offers a recent discussion.

We＊ve read some follow up discussion about support for more than the H.264 codec in IE9＊s HTML5 video tag. To be clear, users can install other codecs for use in Windows Media Player and Windows Media Center.  For web browsers, developers can continue to offer plug-ins (using NPAPI or ActiveX; they are effectively equivalent in this scenario) so that webpages can play video using these codecs on Windows. For example, webpages will still be able to play VC-1 (Microsoft WMV) files in IE9.  A key motivator for improving the codec support in Windows 7 was to reduce the need that end-users might have to download additional codecs.  The security risks regarding downloadable codecs and associated malware are documented and significant. By building on H.264 for HTML5 video functionality, we provide a higher level of certainty regarding the security of this aspect of browsing and our web platform.

The biggest obstacle to supporting more than H.264 today is the uncertainty. When there＊s industry consensus and confidence that the uncertainties are resolved, we＊ll be open to considering other codecs. Until then, we＊ll continue with our current plans to deliver great HTML5 video in IE9 with certainty for consumers and developers.

Dean Hachamovitch

List of articles referenced

AVC/H.264 Licensors

Fake codecs that drop widely spread malware

Google may face legal challenges if it open-sources VP8 codec

H.264 Already Won〞Makes Up 66 Percent Of Web Videos

H.264 licensing body won't charge royalties for HTML5, other Web streams

IE Blog: HTML5 Video

JPEG patent case steams forward

Mac OS X malware posing as fake video codec discovered

Malware Posing As Youtube Codec

Media Streaming with Windows 7

Microsoft Security Intelligence Report Volume 8

Microsoft Sued Over JPEG Patent

MPEG LA＊s AVC License Will Continue Not to Charge Royalties for Internet Video that is Free to End Users

NPAPI

Open letter to Steve Jobs: Thoughts on Flash

Re: Codecs for <video> and <audio> from Silvia Pfeiffer on 2009-07-29 (public-html@w3.org from July 2009)



2. HTML5 Video

There＊s been a lot of posting about video and video formats on the web recently. This is a good opportunity to talk about Microsoft＊s point of view.

The future of the web is HTML5. Microsoft is deeply engaged in the HTML5 process with the W3C. HTML5 will be very important in advancing rich, interactive web applications and site design. The HTML5 specification describes video support without specifying a particular video format. We think H.264 is an excellent format. In its HTML5 support, IE9 will support playback of H.264 video only.

H.264 is an industry standard, with broad and strong hardware support. Because of this standardization, you can easily take what you record on a typical consumer video camera, put it on the web, and have it play in a web browser on any operating system or device with H.264 support (e.g. a PC with Windows 7). Recently, we publicly showed IE9 playing H.264-encoded video from YouTube.  You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here. For all these reasons, we＊re focusing our HTML5 video support on H.264.

Other codecs often come up in these discussions. The distinction between the availability of source code and the ownership of the intellectual property in that available source code is critical. Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA.   The rights to other codecs are often less clear, as has been described in the press.  Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.

Today, video on the web is predominantly Flash-based. While video may be available in other formats, the ease of accessing video using just a browser on a particular website without using Flash is a challenge for typical consumers. Flash does have some issues, particularly around reliability, security, and performance. We work closely with engineers at Adobe, sharing information about the issues we know of in ongoing technical discussions. Despite these issues, Flash remains an important part of delivering a good consumer experience on today＊s web.

Dean Hachamovitch
General Manager, Internet Explorer



3. Product Feedback Systems

Several people on the Windows Internet Explorer team have written blog posts about our feedback mechanisms (our use of automated telemetry in Windows, how to write a great bug, how to submit bugs, etc) for IE9.  After looking at the many similarities and obvious differences between manual feedback systems and projects, we decided to use Microsoft Connect for IE9 and eliminate the invitation requirement for filing bugs.  In this post, I want to take a step back and talk about how we made that decision.

Every Internet Explorer user is a Windows customer.  Listening to customer feedback is vital to the success of any business.  As communication methods have evolved, how a business listens to its customers has changed as well.  Our customers have always been at the center of how we envision and design IE but the way we listen has evolved both with technology improvements and with the way our customers communicate with each other.

Our Internet Explorer 8 beta customers asked us to look at different options for how we listen.  We took their feedback to heart and looked deeply into all aspects of our feedback systems as well as those used by other software companies and in other industries.  We also looked into research regarding the effectiveness and efficiency of various ways of listening and responding to customers.  Most importantly, we listened to real customers, real enterprises, and real developers.

Each time we start a new project we begin by stepping back and looking across the feedback from the previous project and the engineering process by which we collected it.  We challenge all assumptions, especially those based on speed, size, or connectivity.  We also talk with people to see what they like and dislike about our competitors＊ product and engineering process choices to see if Microsoft＊s customers might benefit from something similar or more advanced.

One of the assumptions most software organizations appear to take for granted is the need for beta releases.  In fact, some companies have even taken this assumption well beyond its commonly understood meaning. So we asked ourselves, ※Should we do betas and, if so, how many?  Should we do nightly builds?  Should we continue to use Microsoft Connect or move to something else?§

A group of us sat down and thought through the customer benefits and drawbacks of various models.  Ultimately, there are two main benefits to public releases:

  1. Feedback 每 customers reporting bugs on what is not working correctly
  2. Readiness 每 testing sites with the new browser, adding newly possible features to pages, preparing product support, writing documentation and books, adjusting tooling, etc.

There is a continuum of feedback models that ranges from completely closed to completely open.  Examples of completely closed betas include new PC models, cars, toasters, etc.  Examples of completely open models include some academic open source projects, school PTA projects, etc.  We＊ve chosen something near the middle so we can get broad feedback on quality events but not completely anonymous or unstructured either because we believe in responsible engineering.

From our point of view, the most important thing about working on a consumer technology like a browser is respecting people＊s scarce time and energy.  You can do this while still achieving your goals of getting everybody ready (from web developers to support professionals to corporations) for product launch and getting feedback on quality issues that only surface in unique configurations.  I want to call out a few important aspects about feedback systems:

We also looked at various feedback tools when we started the project.  These included things like Bugzilla, Mantis, Launchpad, etc.  We compared them to Microsoft Connect, which is what nearly every Microsoft product uses to get beta feedback from customers.  It turns out that these tools are all amazingly similar.

We looked more deeply at Bugzilla and projects using it because it＊s a tool that at least two other browser vendors use today.  We looked at the tool itself and how it handles bug workflow both from a beta site perspective and a product engineering perspective.  We found some really interesting similarities and differences:

  1. All of them require some kind of login.  Mozilla＊s Bugzilla needs an email address to log-in. WebKit＊s needs an email to log-in.  Both of them warn you of being spammed if you actually use your primary email account so you should get a new email account if you want to file bugs.  By contrast, Microsoft Connect uses a Windows Live account with either your current email account or a free new one.  In either case, your email address isn＊t visible to people or web-bots mining the site to get email addresses for spamming campaigns.  We actually went one step further and require LiveID login to query the bugs, further reducing the risk to our beta users.  Connect also works for multiple Microsoft beta projects with a single account.
  2. They all handle entering issues by area, feature, or symptom.  All have some bug entry form where you fill out the details, including repro steps, title, etc.  They provide a way for you to give it a priority.  They let you provide great feedback (Bugzilla, Connect) or poor feedback (Bugzilla, Connect).
  3. Bug management differs considerably across projects though.  With IE8, we took action on every issue that was reported and we staffed our beta with Microsoft professional product support engineers so they could learn how to support the product while we built it.  By contrast, if you filed an issue with Firefox 3.5, it would sit at Unconfirmed until someone with ※Can Confirm§ privileges saw it, which may take years.  If a privileged person does happen to see it, it may eventually be seen by the engineers. 
  4. Bug closure also differs across Bugzilla and Connect.  For IE8, we took action on every bug and drove it to closure.  By contrast, as of 4/26/10, Mozilla＊s Bugzilla had 12,779 unconfirmed bugs.  Webkit＊s had 2,616 unconfirmed bugs across all versions but very few bugs against older versions.  Just like unemployment will never be 0%, it＊s important to note that in-development projects will always have a non-zero number of bugs just as a normal part of bug management.  Each project team needs to understand and manage their inventory of bug reports to ensure a reasonable response time for their project testers.  For a project as complex as IE, that can be as large as a couple thousand issues active at any point during the project.

We made some engineering decisions on how to get the best possible feedback from our beta customers after doing all the research into different release cadences, feedback models, tools, and bug management processes. We want to respect our customers＊ time and energy so we＊re going to distribute more focused Platform Preview builds when there are new platform features ready for people to test drive. 

Thanks for all the great feedback in IE8. We＊re looking forward to building a great IE9 release!

Jason Upton
Test Manager 每 Internet Explorer



4. Feedback on the IE9 Platform Preview

Since the release of the IE9 Preview, we＊ve gotten feedback on issues ranging from the tests we＊ve submitted to the standards body to problems running particular sites. First 每 THANK YOU for the feedback. We updated the feedback system specifically for this purpose: to get and act on your feedback. This post offers a high level overview of the feedback overall, and a deeper look at a couple of specific issues that many people have reported.

As of April 16th, people have logged 533 issues in Connect. We review each issue, and confirm we can reproduce the problem. If necessary, we ask the person who logged it for more information. We also consolidate duplicate items.

In looking through the confirmed issues, two are particularly interesting: displaying small fonts, and using GMail.  I＊ll use these as examples of how we use your feedback. 

Displaying Small Fonts

Several people reported that while fonts in general are smoother and clearer, in some scenarios small fonts look less clear. This type of issue has certain characteristics that make your feedback crucial:

This is a good example of how your feedback directs changes to IE, and helps us scale to the many different combinations of hardware and sites used across the web.  For example, there＊s a pattern around some scenarios, like light color fonts on dark backgrounds.

We＊re working on improvements in DirectWrite＊s ClearType font rasterization. Specifically, in the first Platform Preview, GDI logic was used to select fonts though DirectWrite was used to render them. That creates some text spacing differences. Future updates to the Platform Preview will use DirectWrite throughout and will address this spacing issue. In addition, we are making specific changes to the rendering algorithm when light text is displayed against a dark background.

Using GMail in the Platform Preview

Some users have run into an issue with button layout in Gmail. For some people GMail in the Platform Preview looks like this:

Gmail account looking normal

However, others reported that GMail looked like this for them:

Gmail account with some of the buttons in the wrong place

The content GMail sends to IE is different in these two cases, and apparently the difference results in GMail not working correctly for some people.  This is an example of when we may come back to you for more information on an issue reported in Connect, and ask about details like the Browser Mode and Document Mode. 

Another GMail issue involves some links on pages not working in the IE9 Preview＊s Standards Mode.  Standards Mode is where we build new features like SVG, DOM Events, and border-radius (Marc wrote about this and other modes previously) and thus it currently has incomplete features.  This issue is an example of trying to understand if the site isn＊t working properly because of a problem with a new feature or because we haven＊t finished implementing the features.  We use different debugging tools to make that determination.  For example, IE9 logs instances of unsupported events so we can quickly see if the issue might simply be a missing event.  Here＊s the output when loading GMail:

error console with many unsupported event errors.

That tells us not to expect the site to function perfectly since it＊s trying to use features that are not yet implemented.

We also have internal debugging tools to turn off the new eventing model entirely.  With the new eventing model disabled, GMail works correctly.  We further debugged and found the events register properly using addEventListener (good), they fire correctly (good), but fail to initiate any action (bad).  We＊re still working through this issue.  In the meantime, you can use GMail in the Platform Preview by clicking ＆Debug＊ and choosing ＆Force IE8 Document Mode＊. 

That＊s it for now.  Thanks again for taking the time to use the Platform Preview and sending us your feedback!

John Hrvatin
Program Manager



5. Meet WOFF, The Standard Web Font Format

On April 8, 2010, Mozilla, Opera and Microsoft submitted the WOFF File Format 1.0 specification to the W3C. The submission was published on Monday, April 19 at http://www.w3.org/Submission/2010/03/.

Browser vendors and a growing number of type foundries now agree on a common encoding format for web fonts, thus closing an era of cross-browser incompatibility that began when IE4 and Netscape 4 first added support for downloadable fonts in 1997.

At the time, both Microsoft and Netscape implemented incompatible proprietary solutions. Netscape supported and later dropped Bitstream＊s Portable Font Resource (PFR) format.  Internet Explorer＊s Embedded Open Type (EOT) supported the sub-setting and compression of fonts, as well as the definition of the origin policy for the font resource within the EOT file itself. Some font vendors have licensed their fonts for web use under EOT.

Ten years later, Apple added support for raw font linking to WebKit and Safari, allowing web authors to refer to raw TrueType or OpenType font files from their CSS stylesheets. Firefox and Opera followed but use of the feature was in practice limited to free fonts and specialist font obfuscation services like Typekit as font vendors were extremely reluctant to allow their intellectual property to be posted as-is on web servers. The typically large size of font files and the challenges involved in compressing HTTP responses for all users added practical challenges.

In March 2008, Microsoft submitted EOT for standardization to the W3C. Despite a large existing EOT-compatible IE installed base, a number of issues prevented consensus from emerging on the suitability of Microsoft＊s format as a web font standard. At the W3C＊s Technical Plenary that year, Microsoft indicated that a solution type foundries were comfortable with was essential to maximize author choice. In the summer of last year, such a solution emerged from a proposal by type designers Tal Leming and Erik van Blokland and Mozilla＊s Jonathan Kew. The Web Open Font Format (WOFF) - an open, compressed encoding for sfnt-based font resources - was born.

The new format＊s specification is a deliverable of the newly chartered Fonts Working Group on which browser vendors, type foundries and designers are represented. We are excited by some of the initial feedback to this announcement and look forward to contributing to the Working Group to advance the state of web font interoperability.

Sylvain Galineau
Program Manger

Update 5:25pm: small edits for clarity in the third paragraph.



6. IE9 Developer Tools: Network Tab

At MIX 10 we released the IE9 Platform Preview and showed some of the included developer tools. You can access these tools by pressing F12, or click Developer Tools on the Debug menu when you use the Platform Preview.

The developer tools include some new capabilities and improvements over the tools in IE8:

For this first blog post I＊m going to talk about the Network tab. The Network tab gives developers insight into what resources a web page is using including the data that is sent to and received from the server. Developers can use this information to see if network responses contain errors, such as file not found or a server side error. The tool also helps debugging AJAX requests as you can examine the data as it was sent and received from the server.

To find the Network tab, open the developer tools in the IE9 Platform Preview.

Debug menu in the Platform Preview Build. The first option is Developer Tools.
The Tab row in the developer tools

In the Network tab you need to click Start Capturing to begin recording network traffic. The network tool doesn＊t capture data until you click start because collecting network data has an impact on performance and consumes memory. Once you＊ve started capturing, refresh the page to see the recorded network requests in the Summary View as they occur.

Network Tab showing network traffic capture

The Summary View contains the list of all the requests made by the page; it includes:

Depending on the page, you may also see requests from:

For each request in the Summary View you can double-click on that request or click the Go To Detailed View button to open the Detailed View and see more information about the request.

Network tab showing detail view of a network request header

The Detailed View is broken up into 6 tabs:

Request Headers
A list of all the headers sent with the request including the request line.

Request Body
A text view of any data sent in the body of the request, typically used for POST requests such as form submissions.

Response Headers
A list of all the headers received with the response including the status line.

Response Body
A view of the body of the response. The tool has built in viewers for text and images.

Cookies
A view of the cookies sent and received with the request.

Timings
The last tab contains a graph of times associated with the request.

Network tab showing timing data

You can click each of the bars in the chart or list view to get more information about what the time represents.

Once you have a capture you can save it to a file. This is handy if you need to file a bug or send the report to someone else to look at. The save icon is on the tool strip just below the tab, and there are two formats to save the data to: XML or CSV.

Network Tab Save As menu options

The first option is to save the file as a CSV. This saves the summary view and is useful if you want to look at the data in a spreadsheet program like Excel. You can also just select the rows in the summary view and then copy and paste them into Excel.

The second option (the default) is to save the file as XML using a format based on the HTTP Archive. The saved file includes all the data associated with a capture and can be used to examine issues in other tools. For example, Eric Lawrence is extending Fiddler to import HTTP Archive files so you can view the contents using Fiddler. The HTTP Archive format contains useful information that can help assess the performance of a page. For example, the site at http://netrules.tablezengarden.com/, lets you paste the contents of an HTTP Archive file and run some of the YSlow rules against it.

Over on the IE test drive site, we published a new Network Monitoring demo which gives you a way to practice using the Network tab to debug your sites.

We will continue to improve the developer tools in future updates to the Platform Preview. In the meantime, we want to hear your feedback and would love to hear how we can make the developer tools in IE9 your developer tool of choice.

-- Andy Sterland
Program Manager



7. Inside The CSS Working Group

The IE team is active on several  W3C working groups such as SVG and HTML. As one of our three regular CSS Working Group (CSSWG) representatives, I wanted to follow up on the latest face-to-face meeting the group held at Apple in Cupertino at the end of last month by sharing some of the work and progress being made. While it aims to be representative of the three-day meeting, the list below is not exhaustive.

On behalf of the CSSWG, we very much welcome the feedback and insights of web designers on www-style.

I am looking forward to the next CSSWG meeting at Opera in Oslo this summer. Regular engagement with the W3C, developers of other browsers, spec editors and experts invited from the broader community is not just exciting; we strongly believe it is necessary to advance the state of the web for all users.

Sylvain Galineau
Program Manager

Edit 11:26am: correcting the link to proprietary extensions definition. 



8. Same Markup: Writing Cross-Browser Code

I recently presented a session at MIX10 covering the topic of cross-browser best practices. The key focus of the session was not on a particular feature, but on how web developers can reliably write code that adapts to cross-browser differences.

IE9 reduces these differences and enables developers to use the same markup across browsers. Enabling the same markup means supporting the right features to make the same HTML, JavaScript, and CSS "just work". Yet enabling the same markup on the web is an n-way street. Each browser must provide the right features, but developers also need to properly detect and use those features when they are available.

With respect to properly detecting features I'll share examples of issues and best practices I've seen on the web. Most importantly I'll offer patterns that can help you rewrite similar code to take advantage of the same markup. For now I'll focus on more basic examples to illustrate the core concepts, but future posts will cover more complex examples in greater detail. Let me start by sharing a set of guidelines:

Same Markup: Core Guidelines

These guidelines are important because most web pages today are a hybrid of code meant for multiple different browsers. Mixed in with this code are the tests for choosing what runs where. The conditions used in such tests determine how a page adapts to run on different browsers. From script at least, these tests generally take the following form: 

if( condition ) {
    // Primary Code
} else {
    // Alternate Code
}

The conditions used in such tests are often not based on whether a given feature is available, but rather on which browser is in use. Therein lies the problem: altering code based on a specific browser limits the adaptability of web pages. The end result can be as serious as the page breaking when a new browser is released. Other times a legacy workaround continues to be used, even when that workaround is no longer needed.

DON'T: Detect Specific Browsers - Event Registration Example

You can easily test the effects yourself. The code below switches between event models based on the detected browser (a bad practice). Running this in IE9 illustrates that addEventListener doesn't get used, even though it's supported. 

// [TR] Different listeners added for illustration
function f1() { document.write("addEventListener was used"); }
function f2() { document.write("attachEvent was used"); }

// DON'T USE THIS: Detecting specific browsers
if(navigator.userAgent.indexOf("MSIE") == -1) {
    window.addEventListener("load", f1, false);
} else {
    window.attachEvent("onload", f2);
}
Try It!

IE9 Output: attachEvent was used

DO: Feature Detection - Event Registration Example

The following code shows how to switch between event models correctly using feature detection. Instead of checking for IE, it checks for the availability of addEventListener itself. This code will continue to fallback correctly in legacy browsers without addEventListener, but more importantly will now ALWAYS use addEventListener when it is available. In short, this approach enables running the same markup in IE9 and other browsers. 

// [TR] Different listeners added for illustration
function f1() { document.write("addEventListener was used"); }
function f2() { document.write("attachEvent was used"); }

// Use this: Feature Detection
if(window.addEventListener) {
    window.addEventListener("load", f1, false);
} else if(window.attachEvent) {
    window.attachEvent("onload", f2);
}
Try It!

IE9 Output: addEventListener was used

The challenge of getting the right code to run in the right browser is why feature detection has been seeing increased adoption in pages and frameworks. Feature detection enables cross-browser code to "just work" without requiring you to know the capabilities of each and every browser ahead of time. One framework which relies almost entirely on feature detection is jQuery. In fact the jQuery.support documentation details how you can use jQuery's feature detection in your own site.

DO: Behavior Detection - getElementById Example from jQuery

In addition to straight feature detection, jQuery also makes extensive use of behavior detection. It does this by running a tests for known issues to determine if certain workarounds are needed. Below is a slightly modified snippet from the jQuery source code that tests whether getElementById includes elements with "name" attributes. This is a legacy IE bug that was fixed in IE8. 

// We're going to inject a fake input element with a specified name
var form = document.createElement("div"),
id = "script" + (new Date).getTime();
form.innerHTML = "<a name='" + id + "'/>";

// Inject it into the root element, check its status, and remove it quickly
var root = document.documentElement;
root.insertBefore( form, root.firstChild );

// The workaround has to do additional checks after a getElementById
// Which slows things down for other browsers (hence the branching)
if ( document.getElementById( id ) ) {	
    // ... Workaround code ...
		
    // [TR] Added for illustration
    document.write("getElementById workaround was used");
}
// [TR] Added for illustration
else document.write("No workaround was used");

root.removeChild( form );
Try It!

IE9 Output: No workaround was used

DON'T: Assume Unrelated Features - Real-World Example

The final piece I want to touch on is assuming unrelated features. This is something we saw a number of examples of as we did compatibility testing for IE8. Sites suffering from this problem would perform feature detection for one feature, then continue to use a variety of other features without testing whether they were supported. The following modified example illustrates a case where a site was using the postMessage and addEventListener APIs, but was only testing for the former. Support for postMessage was added in IE8, but addEventListener was not added until IE9. If you run this example unmodified in IE8, it results in a script error, preventing any following script from executing. 

// [TR] Try-catch block added to trap the script error in IE8
try { 
    function fn() {}

    if(window.postMessage) {
        window.addEventListener("message", fn, false);
	
        // [TR] Added for illustration
        document.write("Message listener registered successfully");
    } else {
        // ... workaround for when postMessage is unavailable ...
		
        // [TR] Added for illustration
        document.write("postMessage is not supported, using workaround");
    }
	
} catch(e) {
    document.write("Message listener registration FAILED");
}
Try It!

IE7 Output: postMessage is not supported, using workaround
IE8 Output: Message listener registration FAILED
IE9 Output: Message listener registered successfully

DO: Feature Detection - Test for Unrelated Features Independently

A corrected version of the above example is provided below. It checks for BOTH postMessage and addEventListener before using them. 

function fn() {}

if(window.postMessage) {
    if(window.addEventListener) {
        window.addEventListener("message", fn, false);
    } else if(window.attachEvent) {
        window.attachEvent("onmessage", fn);
    }
	
    // [TR] Added for illustration
    document.write("Message listener registered successfully");
} else {
    // ... workaround for when postMessage is unavailable ...
    // [TR] Added for illustration
    document.write("postMessage is not supported, using workaround");
}
Try It!

IE7 Output: postMessage is not supported, using workaround
IE8 Output: Message listener registered successfully
IE9 Output: Message listener registered successfully

Moving Forward

I've outlined the benefits of using feature and behavior detection over detecting specific browsers, but my intent is for this to be the start of a conversation, not the end of it. Watch for future posts covering more detailed examples of issues we've seen on the web and how they can be coded to work correctly across all browsers. We'll also be examining our own sites and encouraging them to update to follow these practices. Please feel free to ask questions and share insights, especially around specific issues you've encountered while developing your own pages.

Tony Ross
Program Manager



9. Running today＊s different markup

I want to follow-up on comments from a previous post that asked questions about how many modes and rendering engines are in IE9. It＊s worth noting that all browsers have multiple modes. This post is about the different modes in IE9 and the scenarios they accommodate.

First, there is IE9＊s Standards mode. It is IE9＊s most standards-compliant, interoperable and fastest mode. It includes support for  SVG, CSS3, DOM Level 3, and many other standards-based features. This is IE9＊s default mode.  We want site developers to use this mode as part of getting us all to the goal of running ※same markup§. To see IE9＊s Standards mode in action, check out the examples on the IE9 Test Drive site.

Many real world sites still rely on legacy modes. IE9 supports Quirks mode for sites such as atlaspost.com, chase.com, and zapak.com. The lack of doctype on these sites indicates that they want to render in Quirks mode. As Peter-Paul Koch points out with a set of test cases, markup that relies on Quirks mode behavior doesn＊t always render as intended in other modes.

For example, here＊s unibanco.com.br in Quirks mode:

unibanco.com.br in Quirks mode looking fine.

And the same site in IE9 Standards mode:

unibanco.com.br in IE9 standards mode with many elements out of place.

Some site developers have legacy code similar to this that relies on the behavior of Quirks mode across browsers. IE9 continues to run this markup. 

So far we＊ve covered IE9＊s Standards mode (the most standards-compliant mode) and Quirks mode.  There are other sites that rely on IE7-specific behaviors. For example, aapeli.com targets IE7 specifically with its CSS:


<!--[if IE 7]> 
<link href="http://st1.esp.playray.net/themes/ie7.v28494.css" type="text/css" rel="stylesheet" />
<![endif]-->

 

To make sure that IE9 continues to ※just work,§ IE9＊s engine supports both IE7 Standards mode and IE8 Standards mode. Without these modes in IE9, site developers would have to go back and re-work sites that relied on specific behaviors.

Ultimately we want the same markup to work across all browsers. In the meantime, we want the markup you wrote for IE7 and IE8 to continue to work in IE9. Site developers can add the X-UA-Compatible meta tag or HTTP header to give themselves time to update their sites to use the same markup across browsers.

IE9 supports the four modes described in this post: IE9＊s Standards mode (the most standards-compliant mode), Quirks mode, IE7 Standards mode and IE8 Standards mode.

Same markup

Writing sites so that the same markup runs in as many browsers as possible is important. Many sites today use feature and behavior detection to work across browsers and legacy IE versions. Here＊s an example from weather.com that shows how IE9 executes the same standards-based markup for DOM Level 2＊s getComputedStyle while IE7, IE8 and IE9＊s legacy modes will execute the legacy currentStyle markup:

code sample from weather.com. The site detects for the getComputedStyle functionality before falling back to legacy currentStyle.

As the above example shows, it＊s a good practice to write standards-based markup first and fallback to legacy markup. Stay tuned for a post that describes feature and behavior detection across browsers in much more detail.

To summarize, IE9 is optimized to display sites according to standards so developers can use the same markup. It is also able to display sites in legacy modes if site developers specify that. This means users can continue to use the web and web developers can move forward according to their own schedules.

One of the places where we＊d like your feedback is the consistency between IE8 and IE9. For example, are there differences between IE7 Standards mode in IE8 and IE9? Are there differences between the standards-compliant features we shipped in IE8 and the same features in IE9? Check out the Platform Preview and let us know.

Thanks!
Marc Silbey
Program Manager



10. Benefits of GPU-powered HTML5

At MIX 10 we showed how we＊re building on new Windows technologies like Direct2D, DirectWrite and XPS to enable Internet Explorer 9 to render all standards-based web content 每 text, images, video and SVG 每 using the power of the GPU.

In this blog post we＊ll review the major improvements for web developers and users that come from building on these Windows technologies. For more detailed information on Direct2D technologies, see this excellent PDC2008 talk.

Performance, performance, performance

The benefit of building on Direct2D technologies is that the browser makes the most of the underlying PC hardware that is optimized for rendering rich graphics. This results in faster web applications and a higher quality browsing experience for users and web developers.

As IE9 does more work using the GPU, there is less CPU load, enabling other browser subsystems to do more, as well as enabling higher frame rates for smooth animation and video playback.

The GPU is a much better choice for some graphical operations 每 for example, the GPU executes alpha blending and bilinear image scaling much faster than the CPU, and uses pixel shaders to perform complex per pixel calculations.

Super-fast zoomed browsing

IE9 uses the GPU to scale images and other content, making zoomed browsing very fast 每 this is what makes the map zooming demo on ietestdrive.com so fast.

Windows is still the only broadly used operating system that allows the users to change the size of all UI elements on the screen to improve readability and legibility on new high DPI displays on laptops and desktop computers. IE9 builds on the work done in Internet Explorer 8 (the first browser to zoom Web page content by default) to ensure that users can easily read the Web on high DPI displays.

Hardware accelerated HTML5 video using Windows Media Foundation

IE9 makes the most of your graphics hardware by using the Windows Media Foundation system to play HTML5 video, using the CPU or the hardware video decoder if available.

The reduction in CPU usage on machines with hardware video decoders greatly improves battery life 每 for example, in our MIX demo we played two 720p HD videos, using barely 30% CPU on a $400 netbook. (versus 100% CPU usage in other browsers, playing only one HD video while dropping frames.)

IE9 Platform Preview build playing two HTML5 videos.

The IE video engine decodes video directly with and into the GPU. Once the video frames are decoded, they can be treated like any other bitmap in the graphics pipeline with full compositing and integration into the rendering system.

High quality image and color support

IE9 uses the Windows Imaging Component (WIC) to decode PNG, JPEG and (new for IE9) TIFF and JPEG XR images. For a lot of uses, JPEG XR offers a good compression improvement over JPEG, allowing you to serve higher quality images at the same file size.

In addition to being up to 30% faster than IE8 decoders, the new WIC decoders understand embedded color profiles in images, making IE9 a color-managed browser that understands ICC v2 and v4 profiles.

Text quality and performance

IE9 uses the GPU (via DirectWrite) to do text output 每 up to twice as fast as IE8, and with higher quality. Text can be smoothly animated in IE9, and sub-pixel positioning is a more faithful representation of the Web (and font) designer＊s intent.

(We＊ve also heard your feedback about some fonts showing up ＆blurry＊ on some systems; we are working on addressing this.)

High quality graphics printing

To do high quality printing of HTML5, you need a high quality print subsystem. Internet Explorer 9 directly converts web content into XPS format when sending output to the printing system.

XPS is a more modern print system with native support for features such as opacity and complex paths, which results in increased fidelity and quality when printing modern web content.

What if my PC doesn＊t have a GPU?

Because IE9 is built on Direct2D, it has full software fallback support for every feature. The goal is to improve graphics performance and fidelity even for the small number of machines in the world without GPUs, via high quality software emulation.

New HTML5 experiences 每 with the power of the GPU

Taken together, all of these GPU-powered capabilities in IE9 make it easier than ever before to create amazing new class of Web applications using same markup. For example, it took just an hour to create the final MIX demo 每 a rotating carousel of four translucent videos (at the 28:00 mark in the video). The page uses simple HTML and JavaScript - the same markup that runs in other browsers, but with higher quality and performance made possible by harnessing the power of the GPU.

A rotating carousel of translucent videos

More to come

We are working with our GPU hardware partners to ensure that every Windows user, using any hardware, has a dramatically improved experience when browsing the Web. We want to enable web developers to create a new class of GPU-powered rich web applications that go far beyond what is possible with today＊s browsers.

As always, we welcome your feedback.

Thank you,
Frank Olivier
Program Manager



2008 © IEBlog.com ICP-09034118
Wallpapers | Learn Chinese Online | Answers | About China