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!
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.
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.
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.
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?
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:
Again, thanks Mike for your feedbacks. Looking forward to the next build!
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.
2: "you should expect to hear more from us soon."
When in doubt, follow the spec. Offering some support is better than none, regardless of what the others do. Of course that might only be true with a stable update cycle. But the last line tells me support is going to be added, so the discussion becomes kinda moot. It's still a beta, right?
3: "old bug that has already been fixed"
If there was some kind of public bug tracker where you did not have to sign up to read reports or post new reports, maybe people would be more likely do help. And you would be more likely to prevent this kind of problem from experienced developers, who usually try to check bug trackers before bitching. Yes, Opera suffers from the same problem (albeit no registration is required to post, you still don't get feedback on progress) but that doesn't make it right.
As for this blog... May I suggest to turn off the silly msn smileys? They make the blog look like the facebook page of a 14 year old. And the overflow-y: hidden on the text-area is ... well I can't really explain why you'd do that. But perhaps you'll explain it as something that is working in IE and the others are doing wrong.
This might seem like an (moderately?) agressively negative comment, but try to remember it's mostly due to the constant PR bullshit every Microsoft-originated blog post seems to suffer from. It's really annoying and kind of insulting to developers who've been dodging the IE bullets for so long. Thanks.
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.
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.
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"
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.
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.
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,
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.
The connect platform is now on an almost monthly update schedule. If you have suggestions, you should post them in the offical connect team connection at connect.microsoft.com/connect
"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.
@Peter said "This might seem like an (moderately?) agressively negative comment, but try to remember it's mostly due to the constant PR bullshit every Microsoft-originated blog post seems to suffer from."
To MSFT -
Marketing 101 - Sell Benefits, not features.
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.