IE at MIX06

One more MIX plug, since it’s coming up fast.  The IE talks have been posted to the MIX06 session list now, including “The Future of IE” discussion session where we will present an overview of our direction for IE beyond IE7, and hold an open discussion to take your input to shape the future of IE.  There’s also a breakout session led by myself titled “Open, De Jure, De Facto and Proprietary: Standards and Microsoft,” where I will lay out how HTML, Javascript, C#, XAML, XHTML, XML, SVG, and other standards fit together, and discuss our standards commitment.  I may even come out alive.

We also have an IE7 Overview session by Tony Chor, a session I mentioned before led by Markus Mielke about how to ensure your standards-based site works well in IE7, and a session by Rob Franco on IE7 security and how the enhancements in IE7 that make users safer.  Finally, we will have an ongoing IE7 Compatibility Lab where IE team members (myself included) will discuss IE with you one-on-one, and help you investigate site problems in IE7.

There’s a wealth of other “next web” topics, many companies talking and demoing their work, as well as lots of sessions on Windows Live, Atlas, WPF, Infocard, and many other technologies.  Check it out.

Hope to see you in Las Vegas,

 - Chris Wilson

Comments (39)

  1. forgetfoo says:

    "and discuss our standards commitment.  I may even come out alive."

    best line 😉

    que up the trolls on aisle 7…

  2. IE7 Beta 2 has some pretty major bugs for my site and the place I was suggested (via WASP) to make comments to help engineers working on IE went completely ignored.

    Since my site uses only valid code I have found and continue to find bugs in browsers. I have documented six major bugs for IE7 Beta 2 on this page…

    My site has a DTD and Mimetype switcher (accessible via the Personal Toolbar) so you can change between application/xhtml+xml and text/html (axx not served to IE by default) and XHTML 1.0 Transitional, 1.0 Strict, and 1.1 (default) in order to help engineers with testing.

    My main concern is that browsers are bending over backwards to support crap code but won’t support code that follows standards.

    If you guys want to go above and beyond with a little CSS3 give us multiple background and rounded corners support.

    Love to hear from some engineers if they need anything done at my end.

  3. alexander says:

    I must say I think your support for standards is plain out terrible. I have torn my hair more then once hacking workarounds for your browser.

    What I do think is great, however, is that you are aware of this and talk about it:

    Dedicating sessions to it, joking about it, linking to dean edwards IE7 etc. – you deserve praise for that.

  4. ieblog says:


    Where did WASP tell you to report bugs that went completely ignored?

    – Al Billings [MSFT]

  5. And now all the web developers wait with baited breath for 4 weeks…

    Teasers?  Will we need to bring tomatoes or roses?

  6. Fyrd says:

    As mentioned above, please keep working on those rendering bugs…

    One of my favorite lists is here:

    Fix everything in that list and you’ll make a lot of people very happy.

  7. Hey,

    Since I won’t be able to attend MIX06, here’s my two cents:

    – please support XHTML 1.0 (and in a proper way)

    – please support CSS 2.1

    – please support SVG Tiny 1.1 (at least) but preferably include the DOM and scripting

    The last should be fairly simple to do with VML and XAML/WPF support out there…



  8. Carl says:

    So is PNG Transparency (not opaque vs transparent… I mean real intermediate alpha blending) going to be fixed in IE7 before it is released?

    For those who don’t know.. it isn’t completely fixed yet.  Semi-transparency has some issues still.

  9. game kid says:

    " "

    Yes.  There’s still big issues there, like floats and data URIs.  We’ll wait…

  10. @Al

    Not sure if this link will work but…

    Do a search for "jabcreations" and there is only one post there.

    I’ve posted the bugs both there and on my site.

    Underneath my post (as I’m sure with all others)…

    "This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes."

    Most sites don’t validate so the people who own them have no logical right to post bug reports and are wasting everyone’s time.

    If Microsoft wants to greatly reduce wasted time with a lot of the junk on the internet I’d suggest the next version of IE to support application/xhtml+xml and to stop trying to add additional support XHTML 1.0 Strict or earlier and concentrate on supporting the latest standards. The main benefit to Microsoft is the time (which is the money part) saved by not dealing with junk pages.  If (say IE 7.5) broke pages served as application/xhtml+xml (AXX I’ll refer to) like Firefox (but not in Opera as it still attempts to render the page up to the break) the person who made the page would first have to fix it to at least render first before they could get any real attention from the engineers and time (money) could be spent on REAL problems.  That would make IE’s ascension in quality happen a lot quicker.  The benefits to designers would be that latest standards would become supported much quicker and they would actually have to be followed.  That benefits real designers (and not people mucking around with WYSIWYG editors like Dreamweaver) as the demand for actual skills would increase.

    That or Microsoft could continue to try and add support for older standards of (X)HTML but I’m not sure the ratio of junk reports (based on non-validating pages reported) to correctly coded pages.  The question there is, how much money is Microsoft loosing in regards to the junk status of the internet?  Moving to support XHTML 1.1 with the application/xhtml+xml mimetype and leaving XHTML 1.0 strict and older standards support at where they currently stand (with the release of 7.0) would immensely benefit both Microsoft on time/money and developers in regards to standards; a win win situation.  I’m not of course speaking in regards to CSS in this post. Web 2.0 should be about validity and accessibility and from my perspective most of the web is still sadly in 0.8 alpha.

  11. Alex T says:

    Hi guys, just a heads up on a serious bug in IE7 with dynamically adding elements to a select box – when options are added in JavaScript dynamically using the selectBox.add() methods, the select box is NOT re-drawn after each add() call to reflect the added elements.  The result is that the element gets added to the options array, but is not displayed in the select box itself.  I know you re-designed the select box element from scratch, so possibly this is one of the new bugs (or you may have already fixed it).


  12. "The Future of IE" – IMHO IE won’t *have* a future unless some serious improvements are made before IE7 is released fully.

    I’m impressed with IE7, it’s got some really good points, but the standards compliance is still really an enormous bad point. Firefox is (sadly) taking ground quickly and the only way M$ can fix this is by making IE7 whoop FF’s a$$… but unfortunately IE7b2 certainly DOESN’T do this.

    Until such elementary things as min-height and proper PNG support are fixed, what ACTUAL reason will Joe Bloggs on the street having for using IE (which craps up web pages and doesn’t display properly) rather than FF (which altho it isn’t perfect, it does a flippin better job).

    I’m not meaning to be too pessimistic, but please oh please get the standards sorted out properly. IE7 rips parts of some of my sites to shreads, when I *know* they’re coded correclty and FF/Mozilla displays them fine.

    And I was very impressed with someone’s comment a few days ago – PLEASE add (at least to the DevToolbar?) the ability to "View as previous IE version"….. if FF can view as IE, why can’t IE view as older IEs?

    Cheers 🙂

  13. Garry Trinder says:

    Jeff Schiller,

    What do you think you need to bring?  😉

    -Chris Wilson

  14. Chris,

    I really don’t know.

    I’ve heard from you in this blog that you’re planning on future support for XHTML and you want to do it the right way.  I would assume improved CSS2 compliance is also a big part of this from all the yammering out there.  

    We also know that XAML and C# are core technologies that Microsoft wants to heavily promote, so we know they’ll end up in the browser in some form.  

    The big question in my mind is on SVG.  I think this is the first time it’s been mentioned in an IEBlog post by a Microsoft employee.  Since it will be supported natively in every other major browser this year, I want to believe you’ll do the right thing here – but I also know that it’s a direct competitor to XAML in a lot of ways, that Microsoft has been spurned by the W3C before, and that VML was out there long ago and never went anywhere.  I expect you’ll add some SVG support eventually (this is the optimist in me) but it will always lag behind XAML support (this is the pessimist in me).

    And so I wait and wait and wait…

  15. EricLaw [MSFT] says:

    "serious bug in IE7 with dynamically adding elements to a select box"

    This is fixed in later builds, thanks!

  16. Erik says:

    While rounded corners would be extra cool, there are still some basic things like min-height to support.

    And the UI is strange with buttons in every corner, in different sizes and color themes.

  17. Mick says:

    "if FF can view as IE, why can’t IE view as older IEs"

    Oh come on, the 2 features are entirely different. FF’s ‘as IE’ features (whether ‘open link in IE’, or ‘IETabs’) either just open the iexplore.exe, or host an IE control within Firefox repsectively.

    Viewing something in a previous version is simply not the same thing (you can’t view pages of previous Firefox versions can you).

    It’s been mentioned many times that this simply isn’t possible.

  18. Garry Trinder says:

    Alex T: Thank you for your feedback on the SELECT element bug. Yes, that is a bad one.

    This is a known issue and has already been fixed on our internal builds (not on the public beta though).


  19. Daniel Glazman says:

    Could you provide us with a summary of your talk or, better, a link to your slides when it’s done ?

  20. lahmatiy says:

    CSS sttribute selectors like

    INPUT[type="text"] …

    INPUT[checked] …

    LABEL[for="some_id"] …

    doesn’t work. Is it a bug or missing functional?

  21. Dark Phoenix says:

    > CSS sttribute selectors like


    > INPUT[type="text"] …

    > INPUT[checked] …

    > LABEL[for="some_id"] …


    > doesn’t work. Is it a bug or missing

    > functional?

    Well, technically that’s illegal code, but the beta does seem to have some strange bugs related to the attribute selector.  I can’t seem to find a pattern in it, because the bug seems to be completely random.

  22. William J. Edney says:

    Dark Phoenix –

    Why would that be illegal code? All that’s trying to be done here is write a selector based on whether an INPUT is of type "text" or is checked or whatever. This is allowed by the spec and works in all of the other browsers.

    I had asked a question last time regarding attribute selectors and got a good, but less detail than I had hoped for, response regarding manipulating attribute selectors from script.

    In other browsers, it is possible to manipulate most attributes from script (via setAttribute()) and have the engine reflow / redisplay the affected elements dynamically. The reason I say ‘most’ is that certain attributes, like ‘type=’ on INPUTs cannot and should not be changed dynamically, per the spec.

    On the other hand, if you put yourself into an ‘expando’ world, you can imagine having an attribute ‘foo’ on a span element:

    <span foo="bar">This is a blue span</span>

    with a CSS rule:

    span[foo="bar"] {background-color: blue}

    Then, if you want to change the span to be red, you should be able to have another rule:

    span[foo="baz"] {background-color: red}

    and be able to set that from script (imagine mySpan is a handle to your span):


    and the span should now be red. Note that this works in modern browsers with CSS2 support.

    What I would like to see from the Microsoft guys ("Hi Microsoft guys!") is 2 pieces of information:

    1) That this works in IE7, both for some built-in attributes and for all ‘expando’ attributes.

    2) A list of the built-in attributes that this technique won’t work for. Note that I’m not asking for this list now ;-), just as part of the IE7 Developer Release Notes or whatever. In other words, "this technique works for all attributes except for attribute X on element Y"

    Thanks for all of the fixes! Keep ’em coming!


    – Bill

  23. Jon says:

    Not sure if this is the best place to post it but can I suggest you folks take a look at a VERY handy plugin for Maxthon called Disable Page Annoyances:

    It would be great if you could add similar functionality to IE 7.

  24. Mike says:

    @John A. Bilicki III

    You say your site uses valid code, but on checking it doesnt validate. You should fix those errors then retest and then report any problems.

    @William J. Edney

    CSS2 selectors should be in IE7. My concern is

    while creating your own attributes may work in "modern" browsers, it is non-standard and should not be allowed. But if your using standard attributes like "class" then thats alright.

  25. Nick says:





    li {

    float: left;


    This is still broken in IE 7 Beta 2 — the bullets vanish. To be honest, I can’t believe IE 6 has left this unfixed for FIVE YEARS. It’s so simple. Please.

  26. Dark Phoenix says:

    > Why would that be illegal code? All that’s trying to

    > be done here is write a selector based on whether an

    > INPUT is of type "text" or is checked or whatever.

    > This is allowed by the spec and works in all of the

    > other browsers.

    I’m referring to the uppercase tags.  Last time I checked, CSS Selectors are case sensitive, and HTML tags are only found in uppercase in (generally) malformed HTML.

    But you’re right, as I said.  At this point, IE’s implementation of the attribute selectors exhibit really odd buggy behavior.  For example, I found that if I attempted to style only a submit button, using


    IE7 will ignore it.  However, IE7 will not ignore it if it follows another attribute selector.  It looks to me like IE7 dumps the first attribute selector it finds, but I haven’t done enough tests to be 100% sure.

  27. Dark Phoenix says:

    > This is still broken in IE 7 Beta 2 — the bullets

    > vanish. To be honest, I can’t believe IE 6 has left

    > this unfixed for FIVE YEARS. It’s so simple. Please.

    The bullets are supposed to vanish.  CSS2.1 says that floated elements automatically become display: block, and block elements don’t have bullets.

  28. William J. Edney says:

    @Dark Phoenix –

    Ah right, gotcha (since HTML is case-insensitive, uppercase tags are allowed, its just that since CSS selectors are case sensitive, you can write CSS that won’t match).

    @Mike –

    I’ll have to disagree with you. Having ‘extended attributes’ on elements is a very powerful capability and allows one to ‘extend the data model’, if you will, of a particular markup language. Note that I absolutely don’t care, in this particular case, about validating against a DTD. I’m just trying to get the job done and using extended attributes is the most clean, elegant and powerful way to do this.

    Microsoft realized this when they introduced the ‘expando’ property. They knew that specification authors are not ‘all knowing’ when a spec is written – times change, business requirements change, etc.

    My 2 pennies worth.


    – Bill

  29. Daniel Glazman (editor of CSS Selectors spec) says:

    Phoenix: selectors have the case-sensitivity of the markup language they apply too. That means H1 and h1 are exactly the same in HTML 4 (zillions of web pages would be broken otherwise !) and not the same in XHTML.

    About the "illegality" of the selectors : the selectors above are clearly not "illegal". They are perfectly valid. The only question is "do they apply to any element in our current context ?".

  30. Ron says:

    Hey, I just saw the official IE7 website, the future is looking good!

    All my problems will be solved.

  31. IE Blog Commentator says:

    very funny….Ron

  32. anon says:

    When typing Shift+R in some (but not all) text boxes in IE7 it annoying brings up the Ruler and takes away focus from the box…. is that known bug??

  33. Dave Massy says:


    I believe you are referring to the developer toolbar here producing the ruler when you hit Shift+R. The latest beta 2 of the developer toolbar at fixes this issue so we no longer capture Shift+R.



  34. Nick says:


    > The bullets are supposed to vanish.  

    > CSS2.1 says that floated elements

    > automatically become display: block,

    > and block elements don’t have bullets.

    (1) This was correct in CSS 2, but most other browsers saw this idiocy and ignored it. It was corrected in CSS 2.1. Please see section 9.7 of the CSS 2.1 spec; it says that ‘list-item’ (which is a block-level element to begin with; see section 9.2.1) should be "same as specified," NOT "block". So it should stay ‘display: list-item’ but generate a new box formatting context.

    (2) It’s useful. Go into any American drug store, grab any medication, and look at the "Drug Facts". You’ll see what is basically a <ul> with all of its <li>s floated left; it works extraordinarily well when horizontal space is ample but vertical space is limited.

    (3) I could have gotten the CSS interpretation wrong, but, regardless, no other browser makes the bullets vanish. So if they’re all breaking the standard in this case, then MS should too, for the sake of complying to everyone else. It’s not like MS isn’t good at breaking standards.

  35. @ Mick

    "It’s been mentioned many times that this simply isn’t possible."

    I understand how running previous VERSIONS of IE on the system isn’t possible (and indeed would be silly, as security vulnerabilities in older versions may go unpatched).

    However, surely just the rendering engines could be preserved? It would be very useful to be able to see just how IE6,5.5 etc. *render* the pages…. I’m not asking for the entire versions, just how they render stuff. Could be an addition to the DevToolbar?

    It would save having to set up another PC *just* to run older browser/OS versions…. and it’s rather a waste of money having to buy a whole other XP licence [as of COURSE I would do ;)]to run on the other machine just to check the rendering of a web site…

Skip to main content