What's IE.next?

The MSIE team has asked for input on features that the next version of Internet Explorer should support. Please take a moment to help them out.

Explorer 7's improvements were almost wholly targeted at CSS; but the next version (which we'll call IE.next until Microsoft announces an official version number) will also feature JavaScript improvements; and it's these latter that interest me most.

We've set up a WishList Wiki to gather issues that web developers would like to see addressed; note, however, that this wiki is invitation-only. Therefore you can leave your suggestions in the comments below. Aaron Gustafson has posted the same question on the WaSP blog; please take a moment to go through the comments there. Anything that's on the WaSP site doesn't have to be repeated here.

Microsoft wants test pages for all issues. Therefore, comments that include a URL to a simple test page have a better chance to be incorporated into the final advice. (In fact, I personally will vote against the inclusion of any item that does not have a test page. Bug reporting means creating test pages!)

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Nick on 6 November 2006 | Permalink

I'd love to see support for showing multiple tabs at once, so you have the option to scale tabs down to less than full window size and view some of them side-by-side.

2 Posted by Jeremy French on 6 November 2006 | Permalink

Two JavaScript features I would like to see. The first would be the ability to put nodes from the XML response into the document DOM

test case here
http://www.jeremyfrench.co.uk/testcases/XMLcopy.html

The second would be a non active X way to serialize and de-serialize from the XML to the DOM

test case here
http://www.jeremyfrench.co.uk/testcases/DOMString.html

There are non JS features I would like to see too.
XML parser for XHTML docs sent as XML and an Xforms implementation.

3 Posted by jun on 6 November 2006 | Permalink

your link over on the wiki that says "Implement DOM Level 3 Events" actually links to DOM Level 2 Events spec

4 Posted by Alex Lein on 6 November 2006 | Permalink

I'd love to see object.watch(), but I don't know if it's part of the DOM Level 3 Events.

5 Posted by Dustin Diaz on 6 November 2006 | Permalink

I think you and I both agreed to have Msft leave alone the whitespace parsing bug... and hopefully one day Firefox will strip out the parsing of textnodes between html tags (that of which rarely ever has any real practical use).

I'm glad the wiki has been set up.. I had no idea who or when it was set up until now.

6 Posted by Jonathan Snook on 6 November 2006 | Permalink

Dustin: I added the request for including whitespace as I conjecture that whitespace may be wanted in the XML (and thus XHTML). The best example I could come up with where whitespace would be wanted is DOM walking through a PRE element. Not necessarily sure why I'd be doing that but that's the best I came up with. :)

7 Posted by Luke Breuer on 7 November 2006 | Permalink

This isn't in any spec so it might not be valid, but I'd like to see support for so-called "freeze panes" or "sticky rows/columns" in tables, such that a table can be scrolled while one or more rows and/or columns only scroll horizontally/vertically, respectively. Without this, displaying large sets of data without paging is hard, if one needs the table's ability to adjust size based on changing contents.

Note: I could not connect to Aaron's blog entry, but I don't believe this is a duplicate.

8 Posted by Niels on 7 November 2006 | Permalink

Dustin: I think it's better if the DOM is non-destructive, which means the reproduction (by parsing the DOM and putting TAGs) of a X(HT)ML contains the whole original, and not only a part (but maybe more). It should be a reversible transform XMLDOM.

As for the whitespace, I prefer to let my newlines and tabs survive automatic processing, I'm quiet bad at reading single-line documents. :-)

9 Posted by Dustin Diaz on 8 November 2006 | Permalink

Lets put it this way. I think it would beneficial to at least tweak the Node API by adding a backwards-compatible flag to denote whether or not you want to parse whitespace (between nodes) or not.

Eg:
<div id="foo"></div>


<div id="bar"></div>


var el = document.getElementById('foo');
var next = el.nextSibling;

console.log(next); // returns [Text]

var realNext = el.nextSibling(true);
console.log(realNext); // returns HTMLDivElement

10 Posted by Sean on 8 November 2006 | Permalink

I'd like to see Javascript getters and setters.

A test case is trivial to come up with, but would also be pointless since it is a well-understood feature, not a bug.

What is needed is a compelling case for their inclusion... which is beyond me at the moment.

11 Posted by Matt Snider on 8 November 2006 | Permalink

I'd like to see a Venkman style debugger for javascript in IE. Complete with stack traces and the current state of variables as you step through your code. At the very least they should improve the debugging messaging system. I think microsoft would gain the respect of web developers with a feature like this.

12 Posted by jun on 9 November 2006 | Permalink

"The best example I could come up with where whitespace would be wanted is DOM walking through a PRE element."--Snook And IE already preserves spaces in pre tags according to the wiki, so I don't get why anyone would want that extened to all tags unless they want to have to type all their code on one line.

13 Posted by Erik Arvidsson on 10 November 2006 | Permalink

Matt Snider: Have you tried MSE or Visual Studio? The only thing I miss in those is to get to the line where the first exception was thrown when there are multiple layers of try/catch/throw. (and profiling of course)

Regarding whitespace and nodes. See http://www.whatwg.org/specs/web-apps/2005-09-01/#elementtraversal

14 Posted by John Oyler on 10 November 2006 | Permalink

How about an .onload for their new "native" XmlHttpRequest object?

That's about the only thing that comes to mind js-wise. I could write a few volumes on the CSS I wish they'd implement, and a few more on the ones I wish they'd fix.

Hell, how about just putting a -ie- prefix on filter and the scrollbar properties?

15 Posted by Dannii on 11 November 2006 | Permalink

Some form of getElementsByCSSSelector or xQuery support would be very nice. Especially if it worked the same as other implementations.