Building great browsers together

Building a great browser is complex; this is valid for Internet Explorer, Firefox, Chrome, Opera, Safari and any other browser out there.

When we started the planning of IE9, we decided to offer more visibility to developers over the progress of the platform – releasing a Platform Preview every eight week. Thanks to your help, we collected thousands of feedbacks and lastly to make IE a better product. It’s been a great journey so far – the partnership IE Team-community has been working really well!

I just ran across an article from Mike Dewey. Forgetting for a moment about the “sensational title” (which btw is funny), I believe there are also a lot of interesting observations and feedbacks. I also like the approach of suggesting (for the time being) workarounds. Thanks Mike!

1 - “my application that appeared to be possessed by some insane daemon“

Lol. Do you have a repro test? Should we call the ghost-busters?

Seriously, let me explain what (probably) happened.

IE9 by default uses the IE9 Standards Engine, which supports all the great new HTML5 stuff. Thus, if you create a plain page with the correct doc-type and you publish it on your server, it will just work.

For compatibility reason, it also allow you to specify an older engine (IE8, IE7, IE Quirks) by using the X-UA-Compatible meta tag. Note that some website specify this rule “at a server level” by setting an HTTP header on all the pages. Bottom line: even in this case, you are in control of what engine you want to use.

2- globalCompositeOperation

As you noted, globalCompositeOperation is not supported in Platform Preview 7. Or, better, we support only the source-over state. We do care about supporting this property, but we also care about it being interoperable across all browsers.

At the time we announced and shipped support for the Canvas, the other browsers were supporting the globalCompositeOperation, but they didn’t have the same rendering behaviors – making developer life very complex. Chrome and Safari in fact implemented the drawing model differently from Opera and Firefox. You can still see this in action today. For instance, navigate to this site. Firefox 4.0b8 and Chrome Canary 10.0.638 are rendering different results. [We obviously looked at all other browsers, even if I don’t mention them in this post].

Given that evident interoperability challenge, we decided it was critical to have first that conversations with the HTML Working Group – before shipping something unreliable for end-users.

Since then, we believe we made good progress – you should expect to hear more from us soon.

3 – Canvas Resizing

Good catch! It looks like you are hitting an old bug that has already been fixed (fix to come in the next build). If you see similar issues in the future, I’d strongly suggest to file a bug to Connect. More on “why Connect” at the bottom of this post.

4 – Limited Shadow Offset

I admit this is weird, but I can’t repro on my machine. It’s possible that this falls in the same bucket of (3).

What I noticed instead is that different browsers render your code in a different way. I created this dummy page using the code on your site (let me know if I missed something) and here’s what I get.

Personally I believe Firefox is closest to the result I was expecting. What do you think?

Microsoft Connect

As you know, we highly appreciate developer feedbacks and we encourage you to try (and try to break if you want) the Platform Previews of IE9.

Remember you can download the latest build from www.ietestdrive.com and you can file a bug on Microsoft Connect. This will ensure that:

1. The IE team get direct visibility (and can eventually follow up if more info are needed)
2. Other users can rate the bug (which helps a lot!)
3. Users have visibility over the progress of open/closed bugs

Again, thanks Mike for your feedbacks. Looking forward to the next build!

Comments

• Anonymous
  January 14, 2011
  The comment has been removed

• Anonymous
  January 14, 2011
  Put the source code up on a public repository with a license that lets us "build it together" until then... meh, lay off the it's a village hyperbole.

• Anonymous
  January 14, 2011
  Connect is and always has been utterly wretched. I find it hard to believe that Microsoft isn't aware of this, and, popular snark aside, most of their other web properties have improved a lot over the past few years, so I'm not sure why Connect still hasn't gotten better in any meaningful way. My only guesses are that either Connect is entangled with some internal infrastructure in a way that makes it hard/risky to fix, or else they're intentionally (or at least through willful negligence) making it hard to report bugs because they get more bug reports than they can deal with anyway. Pretty short-sighted from a customer relations perspective though.

• Anonymous
  January 14, 2011
  @Peter: 1: "what (probably) happened." You seem to be suggesting he either used such a header or none at all (ok, you probably meant that). I kind of doubt that. From the original poster's page "Unfortunately I took their word at face value and assumed that my existing HTML5 code would seamlessly start working once I changed X-UA-Compatible"

• Anonymous
  January 14, 2011
  @Peter 1: as I said, I don't know what happened to him. When possible, my suggestion is to use standard code without any header or XUA meta tag. 2: "when in doubt, follow the spec". You are making the assumption that the spec is finalized and correct. This is not the case: the spec is still a WD (although getting closer to Last Call). Exactly because it's a beta and because we didn't finish yet...we preferred to hold off. Sometime rushing the implementations is not a good thing, as I wrote before on this blog (search for Web Sockets). 3: Yes, there is. It's Microsoft Connect and it's available here: connect.microsoft.com/ie Once you log-in, you can view all the open bugs, track progress, rate them and submit new one. The reason we require registration is to filter the "spam". As you know we have several hundred millions IE users - I'm sure you can imagine the quantity of spam we do receive... blog: I'm not sure why the overflow-y property is there. All the msdn blogs are built on top of the blogging platform from Telligent. I trust they did test across all browsers, devices, ... Thanks for your honest comment! @contextfree: I'll be honest. Connect does its job (and proved to be succesful in the past with many other products) of collecting/aggregating bug and making sure those reach the product teams. I can assure you that each and every single bug on Connect is triage! At the same time, I agree with you the User Experience could be improved. I've seen a lot of good "architectural" (read: behind the scenes) updates to the platform recently and I'm confident the UX will keep improving in the future.

• Anonymous
  January 14, 2011
  I look forward to seeing that. People who try to report bugs on a product tend to be among the most passionate and influential users and an unpleasant reporting experience tends to sour their feelings about the product's developers and management.

• Anonymous
  January 14, 2011
  Giorgio - Thank you for your response.  Glad that you took my article in stride, I was just trying to have a little fun when I wrote it.  I wanted to clear up a couple points that you raised, and might not have been clear in my article. Regarding X-UA-COMPATIBLE, the app that I wrote always tries to avoid browser detection where possible, and instead relies on inspecting the browser to find its capabilities.  For example, to see if canvas is implemented it checks for getContext() on a canvas element.  If it does not find that it switches gears and serves a less feature rich version that uses VML.  When I switched X-UA-COMPATIBLE to use IE9's engine I was expecting the HTML5 version to kick in and for everything to be mostly correct with a few minor issues here and there.  Instead, there were really quite a few bugs, many of which were show stoppers. Your argument about globalCompositeOperation is a good one, and I can understand why you wouldn't want to be chasing a moving target.  From your response I gather that you will implement most or all of the different states soon, which is very good news indeed! The shadowOffset problem you point to is indeed a problem.  I have filed a bug with the webkit team about how they handle shadows, and have also been in contact with some engineers on the Google Chrome team regarding the issue.  In retrospect, I should have mentioned this in my original article.  At the time of writing I was more dismayed about not getting shadows at all, and was not particularly fussed over the degree of "softness" the shadows exhibited. As soon as I wrote my article I did submit it to Microsoft via Microsoft Connect.  I agree with you that the best way to make the web a better place is to make browser engineers aware of bugs.  As IE9 approaches full launch I will definitely be keeping an eye on your releases.  You should know, however, that Microsoft Connect is not very user friendly.  I actually had to try submitting for nearly an hour because it kept hanging when it was trying to authenticate.  I don't know if you were experiencing network issues at the time or something, but the point is that I really did go beyond the call of duty trying to go through the proper channels. I still felt that it was important to write an article describing the issues I found because I felt like developers were in the dark about what they could and could not do with IE9's canvas.  As I started my investigation into what was needed to make deviantART muro work on IE9, I searched all over for descriptions of known issues and workarounds, and I could not find anything.  I figured that I should try to save other developers from going through the frustrations that I did. All the best, Mike

• Anonymous
  January 14, 2011
  Thank you Mike, I'm glad this post answered your concerns. I'd appreciate if you could reflect these thoughts on your original post for all your blog visitors. Best Regards-

• Anonymous
  January 14, 2011
  The comment has been removed

• Anonymous
  January 14, 2011
  "more visibility to developers" what is means of it. it's means to spent more time for a thing who can be done in seconds in other browser like debug , development , testing and some other tasks. in IE addons site are their any plugin exist for development [any means any small or big]. but their are many plugin exist for advertising website or bookmark.it show that "IE are sold and a thing Microsoft used to make developer fool". How you can make developer fool whenever their are no tool exist in IE to test and debug the Web using IE. Because IE window integrated you can tell more blah blah blah. but believe if anyone use Chrome in Chrome OS they can tell more blah blah but it's blah is more truth then IE.

• Anonymous
  January 14, 2011
  "more visibility to developers" what is means of it. it's means to spent more time for a thing who can be done in seconds in other browser like debug , development , testing and some other tasks. in IE addons site are their any plugin exist for development [any means any small or big]. but their are many plugin exist for advertising website or bookmark.it show that "IE are sold and a thing Microsoft used to make developer fool". How you can make developer fool whenever their are no tool exist in IE to test and debug the Web using IE. Because IE window integrated you can tell more blah blah blah. but believe if anyone use Chrome in Chrome OS they can tell more blah blah but it's blah is more truth then IE.

• Anonymous
  January 15, 2011
  The comment has been removed

• Anonymous
  January 15, 2011
  Yep. How did you manage to architect the most distasteful browser in the universe? Keep up the good work. I die and never change my feelings toward this company.