Platform Improvements for IE8 Beta 2


We’ve been sharing plenty about the work we’ve done in Internet Explorer 8 Beta 2 for browser users; we also want to share some of the notable advances we’ve made in the web developer platform in Beta 2. This post serves as an overview of the web platform changes since beta 1 that will be covered in more detail in the coming days and weeks.  

The Layout Engine

First and foremost, we’ve been hard at work improving our standards support – we are now “CSS2.1 property complete,” meaning we’ve implemented every property in CSS 2.1 and are closing in on our goal of complete support for the CSS 2.1 specification by the time we release. This work includes improved support for many existing CSS 2.1 scenarios such as selectors, visual formatting (display, positioning and sizing) and text; significant progress on the features first introduced in Beta 1 such as generated content, counters and outline; and some new and improved features such as the CSS3 writing-mode property (currently behind –ms prefix.) In addition to the standards compliance work we have done, we have contributed more tests for the CSS 2.1 Test Suite including tests in support of the Accessibility Rich Internet Applications (WAI – ARIA) draft standard.

The Programmability Engine

We’ve also been improving our programmability engine. In addition to working on performance gains across the entire programmability stack, including in the core JavaScript engine, we’ve implemented mutability in our Document Object Model prototypes as well as attribute getters and setters in order to enable web developers and framework builders to extend our object model.

We’ve continued our Beta 1 investments in cross-domain requests (XDR) by working together with the Web Applications Working Group on improving the Access Control specification, and supporting it from XDR. This makes building interoperable cross-domain requests easier for everyone! Additionally, we updated our DOM Storage implementation to better align with the recent rounds of changes to the HTML 5.0 spec, especially in the localstorage method.

Last, but not least, we’ve added toStaticHTML/toJSON/fromJSON which is a set of code that sanitizes HTML and JSON content sent through the wire. It’s a great partner to the XDR (cross domain request) feature as well as HTML 5.0’s XDM (Cross Document Messaging) and delivers safer mashups to the user!

Developer Tools

While Beta 1 introduced the tools and provided helpful features like live HTML editing and a JScript debugger, Beta 2 is significantly more powerful with live editing of CSS, save to file, and console.log support. And because you need to make sure your site is not just correct, but fast, Beta 2 also includes a JScript profiler to help you find hotspots and compare design patterns. We’d love feedback on the tool and suggestions on ways to make it even more helpful.

In Closing…

With all the posts about the great things for the people who use the web with Beta 2, we wanted to remind those of you who build the web about the great opportunities you have to give visitors to your sites a fabulous experience. Moreover, we wanted to make sure that you developers had a reference (Internet Explorer Readiness Toolkit) checklist to vet against so your visitors to your site have a good experience as you ponder how to make it great with IE8. As always, you can find more information at the IE Development Center, http://msdn.microsoft.com/ie.

Thanks,

Doug Stamper
Lead Program Manager
Developer Experience

Update 11/20/08: changed reference to toSafeHTML to toStaticHTML 

 

Comments (24)

  1. Anonymous says:

    Did I just read this correctly???!?!?!?!?!?!?!?!

    "mutability in our Document Object Model prototypes" – implemented??? OMG!

    Yippeeeee!!!!

    Totally Awesome! now anything that IE8 doesn’t fix in terms of its standards support, (and remaining broken features and bugs) **WE** can fix!!!

    Nice, Wicked, Awesome!

  2. Anonymous says:

    Still absolutely no word from you about what you are going to do about opacity support??? Not even as much as a "We heard you guys and are actively working on it". Grrrrrrrrrr!!!

    This seems to be the number one requested feature, not to mention that it’s a regression from existing versions !

    I don’t get why you spend so much time on CSS3 features that seemingly no one requested, but nothing on either bringing back the filters or preferably introducing the CSS3 opacity property!

  3. Anonymous says:

    I was having an email conversation with Ahmed Kamel about the Developer Tools in IE8, but it seems I’ve been blocked by MS’s Exchange Server, so I can’t send my feedback to him.

    So here’s my Dev Tools feedback that everyone can see: http://test.rowanw.com/node/9

  4. Anonymous says:

    Could I beg for CSS3 border-radius, to kill millions of little corner images once and for all?

  5. Anonymous says:

    So correct me if I’m wrong, but are you saying that all of the following are now possible in IE8 Beta 2?

    Array.prototype.doFoo = (){};//and won’t destroy/alter the length

    XMLHttpRequest.prototype.newMethod = (){};//this now works?!

    HTMLSelectElement.prototype.setInnerHTML = (){};//we can fix what IE can’t?!

    HTMLFormElement.prototype.submit = (){};//we can fix AutoComplete once and for all in IE now?!

    HTMLInputCheckboxElement.prototype.onclick = (){};//do native stuff, then fix IE by firing an onchange event rather than waiting for a blur event?!?!

    Tell me I’m dreaming!  Oh if only this was backported to IE6/IE7… when will those development nightmares end.

  6. Anonymous says:

    @Rowan I saw your screen cast. I wish I could have expected something better but I’ve used the IE dev tools enough to know that they are very poorly implemented.

    Outline? not a chance.  Background? nope, that would make too much sense.  Easily add/edit attributes? not in that interface.  Have you guys not looked at Firebug?  It blows the IE dev tools away in every aspect.  Inline editing is the *ONLY* way to go.  No CaMeL cAsE aTtRiBuTeS just pure DOM.

    One question for the Dev team though. What happens when IE9 comes out? Are we going to have an IE9 Standards mode? then an IE10 Standards mode?

  7. Anonymous says:

    All nice, but I like to use Google Reader, and there seems to be no way to let another RSS reader handle/collect feed URLs from a web page. You obviously have taken great pains to be fair in the search and accelerator features for other third parties. So why not with RSS feeds???

    Thanks for listening at least.

  8. Anonymous says:

    @Mitch

    >>Outline? not a chance.  Background? nope, that would make too much sense.  

    Can you elaborate?  How would you like to see the ‘outline’ functionality differ?  And i’m not sure what you mean by "background".

    >>Easily add/edit attributes? not in that interface.

    Are you referring to the ‘Attributes’ pane on the right?  If so, there are definitely issues that didn’t exist in the original IE Developer Toolbar.  If that attribute editing doesn’t meet your needs, how would you prefer the editing to work?

  9. Anonymous says:

    @Mitch

    one more question…

    >>Inline editing is the *ONLY* way to go.

    The Dev Tools let you edit attributes inline.  Click in HTML or CSS and the value becomes editable.  Are you looking for something different?

    Thanks!

  10. Anonymous says:

    @ivan

    No, you’re not dreaming.

    >>Array.prototype.doFoo = (){};//and won’t destroy/alter the length

    If this isn’t fixed in Beta2, I already saw the checkin that fixes this. See http://alex.dojotoolkit.org/2008/01/how-ie-mangles-the-design-of-javascript-libraries/ (point #1 for the problem for those who are curious).

    >>XMLHttpRequest.prototype.newMethod = (){};//this now works?!

    Yep. Note that the other two legacy "constructors" from IE7 and previous versions are still available: Option and Image. Consequently, HTMLOptionElement and HTMLImageElement are "mirrors" of those two legacy constructors and also support the JS "new" operator.

    >>HTMLSelectElement.prototype.setInnerHTML = (){};//we can fix what IE can’t?!

    Yep. Consider applying a setter here as well:

    HTMLSelectElement.prototype.__defineSetter__(‘innerHTML’, function(x) { /* … */ }); for a "cleaner" override of innerHTML (which is defined on Element.prototype, BTW.)

    >>HTMLInputCheckboxElement.prototype.onclick = (){};//do native stuff, then fix IE by firing an onchange event rather than waiting for a blur event?!?!

    This would be "HTMLInputElement" (same constructor for all input element types). As you dig into this you might find that some of the constructor names are different. To find the right constructor name, you can always check the constructor property:

    console.log(someElement.constructor);

    I’ll have a lot more to say about DOM prototypes in an upcoming post, so stay tuned.

    (You are probably dreaming about getting this backported to IE7/6 though 🙂

  11. Anonymous says:

    @Morten

    Hi Morten, the filters will still be there 🙂

    http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx

    (if you haven’t alreade seen the post)

    And to the IE team: The Developer Tools is absolutely great! Thanx!

  12. Anonymous says:

    It would be fascinating to hear more about the rewrite of the layout engine. Did you rewrite from scratch, or heavily refactor?

  13. Anonymous says:

    Is there sufficient programmability in IE8 to allow developers to create mouseless browsing plugins, such as "Hit-A-Hint" on Firefox?

    As I understood it, there was insufficient programmability in IE7 to make this possible.

  14. Anonymous says:

    Wow guys, this looks great!!!

    Can we find a way to upgrade ALL instances < IE8 now? really, please, help us with that final step.

  15. Anonymous says:

    @Travis, @John and all Microsoft folks –

    These are wonderful additions indeed. The ability to put stuff on prototypes and use getters & setters means a much more polymorphic code base for some of us going forward. Thank you and make sure to thank the members of your team(s)!!!

    As far as the new ‘localStorage’ stuff is concerned – its great that you guys are keeping up with the ever-changing HTML5 standard, but I think your documentation is out-of-date. AFAIK, the concept of specifying a ‘domain’ was thrown out when things got changed from ‘globalStorage’ to ‘localStorage’. Now you just say ‘window.localStorage’ and you’re good to go (i.e. you don’t get to specify a domain). It looks like someone on your end may have just gone into the online docs and done a simple search & replace with s/globalStorage/localStorage/g. Please take a closer look. I may be wrong here.

    Also, will it be possible in the final release to use ‘localStorage’ from a script in a page loaded via the ‘file://’ URL scheme? I’ve been communicating and filing bugs with both the Mozilla and Webkit teams regarding this. The spec says that ‘localStorage’ should be ‘per-origin’ and they do specifically say that ‘file://’ is an origin. I tried to file a bug into the IE feedback system, but it seems like filing new bugs is now closed to us "regular folks" (maybe too much spam 😉 )?

    Anyway, one last word of thanks to the person(s) involved in making the navigator.onLine property and online/offline events work when network connectivity is lost or gained on Windows XP (it was previously only available for Windows Vista). BTW, your online docs need to be updated there too to reflect this new functionality for XP (I posted a comment at the end of the pages for online/offline to let folks know that these all now work for XP too). It’s nice to see that Microsoft is really listening :-).

    Cheers,

    – Bill

  16. Anonymous says:

    Bug Report:

    ———–

    In IE6, when I wanted to clear out old favorites, I’d click on the favorites menu, choose the sub-folder I’m interested in cleaning up, and then do right-click delete, OK on each one I wanted to drop. The sub-folder would remain open during this repeated procedure and it would be quick and easy.

    As IE7 appeared, this behavior changed substantially for the worse. When you right-click to delete a favorite, the favorites drop-down disappears. So for every favorite you want to delete, you have to go back up to the favorites menu and navigate yourself to the folder you were cleaning up.

    It changed what was a case of repeated instances of (right-click, delete, yes) into (right-click, delete, yes, mouse up to favorites again, click favorites, mouse down to chosen sub-folder, then right-click, delete, yes).

    I’m not running on my (virtual) machine that has IE8 on it right now, but I doubt it’s been fixed.

  17. PatriotB says:

    The thing that worries me the most whenever I read things like "we updated [foo] implementation to better align with the recent rounds of changes to the HTML 5.0 spec" — what happens when the spec changes after IE8 ships?  Are you going to break everyone?  Should people be using these new HTML5 features with caution that they may break in the future?

    This isn’t really an IE problem — it’s an unfortunate byproduct of the way that the W3 process works — the spec isn’t finalized until there are 2+ compatible implementations, however by providing an implementation you are risking the standard changing after you release.  The fact that HTML5 is a single gargantuan spec, rather than modularized, makes it much more likely that this will happen than with, say, CSS3.

  18. Anonymous says:

    About time MS confirms to some standards. IE has been a pain.

  19. Anonymous says:

    I know this gets mentioned fairly often, often ignored, occasionally responded to with a "later" option.

    What is the status of DOM 2 Events?

    Considering the much of the web 2.0 stuff is based on behaviors, not layout, it would seem logical that full support of Events would be beneficial to everyone.

  20. Anonymous says:

    @PatriotB:

    The WG has to make a decision about whether the change it worthwhile breaking existing documents for. The more widely used it is, the less likely it is to be broken.

  21. Anonymous says:

    I would like to suggest Microsoft to develope IE to other operating systems.

  22. Eghost says:

    Definitely not satisfied with the minor UI allowances, Come on Doug how is this an improvement?  We still had more ability to change the UI in 4,5,and 6 than we do 7 and 8. Why can’t Microsoft give us back what we always had? I want to be able to move the address bar, I want to be able to move the left and right arrows, I want to be able to put icons along side of the address bar. I am so frustrated by Microsoft because you CONTINUE to totally ignore this issue and I can not understand why? Microsoft Internet Explorer 6.0 was released on August 27, 2001, and it is now September 13 2008, and Microsoft still has chosen to give us a weaker and more inferior product when it comes to giving customers a choice with the UI.

    Doug in closing I will state this, I see it as Microsoft doesn’t care and you are just refusing to allow users access to full ui customizations. It is deplorable, and it’s a shame, you gave us back not even half of what we use to have you touting this as a GREAT NEW FEATURE!  

    For many Doug, from a customer experience it is Disappointing, totally; absolutely Disappointing…

  23. Anonymous says:

    Opacity still doesn’t work in IE8 beta 2.

    The silence around opacity is making me to place div to each designed web site with message "Microsoft IE8 does not support CSS standards", and place it to opaque to make it visible when opacity is not working in browser.

    What about action like this? Are you guys think about how much time we spent to do our job?

    I have researched all of related topics and everywhere same results – DOES NOT WORK?

    Ok, if you cannot place this functionality why not to keep back capability?