Working together for standards The Web Standards Project

You may recall that the DOM Scripting and Microsoft task forces, in collaboration with JS Ninjas, had been compiling a list of issues, needs, and wants for IE.next over the last few months (a list many of you contributed to as well, via your feedback). The list was to focus on what we wanted to see happen in terms of JavaScript support (as IE7 didn’t get much of an update in that area), but when it came down to it, there were other areas we really felt needed some love.

The list

Last week, our groups voted for what we each saw as priorities and those votes were tallied to create a final list for me to present in Redmond. Though there is obviously a great deal more we want to see in IE.next, we felt several things were critical and wanted to focus on those as a starting point.

Tied for first place, in order of priority, were some sort of fast, arbitrary node-matching API and better error reporting. In the realm of DOM Scripting, node-matching is key (just look at the number of scripts out there performing node matching based on CSS selectors, etc.), so being able to tap into a native XPath implementation (which we generally favored over the Selectors API) would greatly improve the speed of script execution. As for the error reporting, perhaps Justin Palmer (of JS Ninjas) said it best:

We could possibly find ways to fix all the other problems if we could tell what the hell was breaking and why. Without better error reporting, the remaining stuff on that list is just giving us a bigger gun to shoot ourselves in the foot with.

Next up in our list was a desire for mutable DOM prototypes. This would address the issues that arise from IE’s implementation of DOM objects in JavaScript, where elements of the core DOM are not derived from the standard Object prototype. While not technically a standards-support issue, this request does not conflict with standards and it does provide JavaScript developers with the ability to address some of the issues the IE team may not be able to address themselves in the next release. As Andrew Dupont (another Ninja) remarked, I think it’s reasonable to ask that a DOM implementation in JavaScript behave like it’s part of JavaScript.

Next up was a biggie: bring IE’s event system in line with the W3C event model. This has been an issue for a lot of developers and the code to equalize the two event systems makes up a significant chunk of all of the major JS libraries. Getting IE to implement the W3C event system would be a real boon for standards support and would drop the size of many libraries considerably.

Finally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.

Two “honorable mentions” were included in the list as well: fixing the issues with getAttribute() and setAttribute() and starting to implement some of the features of JS 1.7 (such as block-scope variables using let, etc.).

Not willing to let the IE team off that easy, the document presented also highlighted several other issues which really need addressing including (among others)

• fixing CSS bugs (including collapsing adjoining margins and z-index);
• various form control fixes (including implementations of the button element, labels, and the disabled attribute);
• correcting its support for object;
• adding support for the q element (which should be a breeze once generated content is enabled); and
• fixing attribute issues (such as alt being used for a tooltip, cite not being supported on q and blockquote, and summary not being supported on tables).

The meeting

In Redmond, I met with Pete LePage, a Product Manager at Microsoft Web Platform and Tools, and several other key members on the IE team. We discussed the list and its implications in great detail for nearly two hours. While I am not at liberty to discuss all of the details of the meeting, I can say for certain that the group I met with was keenly aware of the issues we brought up and are eager to address them. One team member even said that he could have easily guessed our top 5.

The one concern they have—especially with regard to the event model and getAttribute()/setAttribute()—is that any adjustments they make to bring IE in line with the standards not “break the web” for the large number of sites using the proprietary IE event model, etc. We discussed this particular topic at length as it is a valid concern and I’m happy to say that I think we’re close to a solution on that front.

I came away from this meeting with a real sense of hope about where IE is going and am really encouraged by their willingness to engage the standards community (and web developers as a whole) in dialog like this. We did not resolve every issue in our two-hour talk, but I was assured that this was only the first of many steps toward improving IE.next. The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.

Your Replies

#1 On February 4th, 2007 5:14 pm Circle Six Blog » Blog Archive » Regarding my pants and other news replied:

[...] The Web Standards Project posted an article about a chat with Redmond regarding IE.next. Check it out. [...]

#2 On February 4th, 2007 5:26 pm Brad replied:

I am particularly please that the document you presented included bringing IE’s event system with the W3C model + thanks for including the CSS suggested improvements.

#3 On February 4th, 2007 5:41 pm pauldwaite replied:

Bravo chaps. Your hard work is much appreciated. If Internet Explorer keeps improving its standards support, your work will be appreciated by web developers for years to come.

#4 On February 4th, 2007 6:33 pm Broken Links » Blog Archive » Good news on FF3 and IE.next replied:

[...] Good news for everyone: Microsoft look as if they’re taking web standards seriously. First came the news that standards guru Molly E. Holzschlag has signed up to work on standards and interoperability for the next release of Internet Explorer, then the Web Standards Group announced that they have had talks with the IE team about the five most-wanted features in IE. [...]

#5 On February 4th, 2007 7:29 pm bigDooky replied:

“Finally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.”

It’s great that MS is moving forward on standards-compliantcy but why is CSS a “nice to have” and at the bottom of the list? This is one of IE’s worst problems and causes countless companies mountains of money to create and maintain workarounds.

Why can’t they just release a quality product in the first place damn it?!

#6 On February 4th, 2007 8:55 pm WaSP Member agustafson replied:

@bigDooky: perhaps you missed it in the first paragraph, but, as I said, “[t]he list was to focus on what we wanted to see happen in terms of JavaScript support.” That’s why I singled out the final item on our list in that way. CSS is by no means a “nice to have,” Microsoft had specifically asked us about JavaScript stuff.

#7 On February 4th, 2007 11:29 pm Devon replied:

Would it make sense of IE.next to use something like: script type=”application/javascript;version=1.7″ …to trigger a more standards compliant version of the event model? Most likely, the places that any event model changes might break, wouldn’t be using such a technique and therefore wouldn’t be vulnerable to the changes until the site/intranet decided to change it.

#8 On February 5th, 2007 4:39 am Chris replied:

All this seems a monumentally hard task – to implement new features without breaking existing pages and apps. It’s like they’re trying to keep a relic going way beyond its retirement age. Even if they make all these changes, it will only introduce new bugs. Witness IE7. Why not face it that the IE Trident engine was never designed for today’s internet. It would be much simpler to scrap it altogether and use Gecko. Sure, people would have to get used to a few quirks and changes that would bring, but at least it would be a solid base for the future. (One that is improving yearly, witness Firefox 3.0 and Cairo.) This would also help developers no end, as they would be able to concentrate on one major rendering engine in a big way. Plus it would be light years ahead of IE7 or even IE8, giving you SVG for a start.

#9 On February 5th, 2007 4:51 am bruce replied:

I’d also beg for display:table-cell, so grid layouts no longer require voodoo magic.

And accessibility: it would be deeply lovely if IE would render in-page keyboard navigation when linking to an aribitray container that doesn’t have hasLayout set. (see http://juicystudio.com/article/ie-keyboard-navigation.php)

#10 On February 5th, 2007 8:28 am Asbjørn Ulsberg replied:

Excellent news! I’m a bit sceptic at what solution you may come to with regards to JavaScript 1.7, W3C DOM event embracement and such. What I’m thinking is, won’t using the Standard Mode of the rendering engine (and thus leaving Quirks Mode the way it is today) work for supporting this? Alternatively, introducing a CSS2Compat mode (an “upgrade” to CSS1Compat) that can be triggered with some sort of CSS inclusion mechanism or something could also do the job. Well anyway, great work! Keep those updates comping!

#11 On February 5th, 2007 9:55 am Max Design - standards based web design, development and training » Some links for light reading (6/2/07) replied:

[...] Talking with Microsoft about IE.next [...]

#12 On February 5th, 2007 1:05 pm Dominic Shiells replied:

Is there ever going to be a day when you can program a web page and you dont have to think about whether in one browser it will work or not work!!!
Will we ever see that with IE.next as they are behind on web standards on everything to XHTML to CSS

#13 On February 5th, 2007 1:43 pm Trails replied:

Progress! Good job WaSP, nice to read about these kinds of things!

#14 On February 5th, 2007 4:14 pm Gérard Talbot replied:

Aaron,

I appreciate the time and efforts you and others invested into the making of this list. If I can speak for all of us, we all want the next IE to be more (a lot more) W3C web standards compliant and more useful+correct+capable in javascript/DOM matters.

3 more comments from me.

1- In the Features section of the list, it is mentionned
W3C DOM Conformance Test Suite (DOM 1 Core).

IE7 failed 85 tests at W3C DOM Conformance Test Suite (DOM 1 Core) .

Opera 9.02 had 27 failures and Firefox 2.0 had 14
failures.

2- Regarding concerns to not “break the web” for the large number of sites using the proprietary IE event model,
I just want to say that one day, web authors will have to upgrade their coding techniques, their habits, etc. They will have to be told to upgrade their code, to use new+better authoring tools, to rejuvenate their design approach and implementation methods, to consult web standards references, documentation, to read this or that “Tip and trick” from a web standards guru (1). You can not expect badly designed, poorly coded, invalid or non-standards webpages to work endlessly, forever without any detrimental consequences while, on the other hand, browser manufacturers are spending thousands and thousands of hours into improving the rendering engine when triggered into standards compliant rendering mode. Support for legacy browsers has to stop somewhere, at some point.
(1) I am convinced this is the main and most important reason as to why Molly Holzschlag was hired by Microsoft.

3- Microsoft has to start addressing usability and accessibility matters too and to improve its UAAG 1.0 guidelines compliance.
- Site Navigation toolbar and <link rel=”…”> not implemented
http://webcoder.info/reference/LinkBars.html
http://www.w3.org/QA/Tips/use-links
- selecting via keyboard (placing caret and then arrow keys) or mouse dragging a selection of text from within an absolutely positioned block is impossible to perform. That should be treated and considered as a serious usability-behavior bug
- implement UI settings to allow users to override some specific HTML attributes or javascript features which are known to limit accessibility of content, to restrict accessibility and usability: noresize in frames, scrolling=no in frames, frameborder=no in frameset, window.open() features which remove resizability, scrollability, menubar in secondary windows and not allowing the user to override these author requests, alternate style selector UI (this has been a request from web standards since 1998), etc.

4- Regarding the implementation of the W3C DOM 2 event model, I am for a CSS2Compat mode in IE8 which will be triggered when using the same doctype declarations which triggered IE6 and IE7 into CSS1Compat mode (when querying document.compatMode).

Best regards,

Gérard Talbot

#15 On February 5th, 2007 10:06 pm Andreas replied:

application/xhtml+xml instead of just
text/html – this essentially means parsing
the html differently (as xml), don’t
know if it’s possible for ie7′s rendering engine (re) at all to accomplish this or if a new re is requrired, anyway I guess a new re wouldn’t hurt, and even though such a decision might not pay off immediatly, it is certainly a good investment in the long run and ie should make such long term decisions/investments the sooner the better. Also I guess a lot of existing xml
libaries/ground work can be reused,
being stricter/exacter/less sloppy
should make things easier after all.

#16 On February 7th, 2007 11:23 am Andrew replied:

I can’t see how the changes to the event model will affect the size of the “major JS libraries”. The libaries I use support most legacy browsers, and I assume still will if and when this change is occurs.

Does any other browser vendor support “arbitrary node-matching API and better error reporting” if not refer to above (forking hell!).

#17 On February 10th, 2007 9:48 pm La domo de karotoj » Novaĵoj pri TTT-legiloj replied:

[...] Mia favorata TTT-legilo estis eldonita ekde preskaŭ monato. Sed pri aliaj TTT-legiloj Mikrosofto malkovris iujn detalojn pri IE.next (la venonta eldono de Esplorilo), kaj Netskapo planas eldonon 9.0 (ne nurvindoza kiel 8.x) de sia eksa reĝo de TTT-legiloj. [...]

#18 On February 15th, 2007 7:48 pm Kem Apak replied:

It is great that you guys addressed the issues that has great importance to JavaScript development community. I cannot agree more everything that is mentioned. It is nice to talk, and I do believe they have great developers believe in standards. But somehow they cannot reflect this in IE. Lets hope Redmond starts to follow standards.

#19 On March 1st, 2007 2:47 am John Resig - Future-Proofing JavaScript Libraries replied:

[...] I was in the group of JavaScript developers who provided feature/bug fix recommendations to Microsoft for their next version of IE. A huge issue that we were faced with was that we were knowingly asking Microsoft to both break their browser and alienate their existing userbase, in the name of standards. [...]

#20 On March 9th, 2007 11:40 pm andrew woods replied:

I would like to suggest an include(“filename.js”) command. Every other programming language has this. isn’t enough. If I’m writing a class in javascript that is dependent on another file, i don’t want to have to remember to put a script tag for my support files.

Also, perhaps MSFT could use “text/ecmascript” for standards based scripting, and leave they existing javascript for backwards compatability. that would make it possible for everyone to phase out the current javascript implementation over time.

And yes, I agree with the need for better debugging tools. The Firefox Error Console is good, but the Firebug extension is even better. That would be a good place for MSFT to start.

#21 On April 6th, 2007 7:09 pm Uwe replied:

I can’t see how the changes to the event model will affect the size of the “major JS libraries”. The libaries I use support most legacy browsers, and I assume still will if and when this change is occurs.

Does any other browser vendor support “arbitrary node-matching API and better error reporting” if not refer to above (forking hell!).

Post a Reply

Comments are closed.