If you’ve followed the discussion about the W3C HTML WG, you’ve no doubt read Chris Wilson’s comments on it. I’d like to bring one thing up in particular:
PS: On error correction standardization – I disagree with this goal of the WHAT WG because I don’t believe it is responsible for Microsoft to cause any unnecessary compatibility problems (e.g. the problems that would be caused if we changed error-handling behavior). If the WHAT-WG wants to standardize on EXACTLY what IE6 does for any given error case, no matter how funky it may be, great, but I don’t think that’s what they would consider doing.
See, that’s one thing I just can’t understand. I see a clear solution to this problem, or in fact, two. One is that IE at the moment doesn’t support a Content-Type “application/xhtml+xml” and that XML namespace recognition for the XHTML namespace “http://www.w3.org/1999/xhtml”. This gives you the chance – there’s NO backwards compatibility to take into account (only compatibility with other browsers). Implement the XML and HTML DOM, correctly this time. Axe problematic host objects such as document.all. Axe pollution of the global namespace with DOM references, or at least make sure that any ECMAScript variables trump out id and name attributes instead of the other way around. Make sure getElementsById doesn’t match name. Make sure if there is an element with an id or name attribute which is also used as a DOM property, that the DOM property wins out over the element. (e.g. an element with id="length" loses to the length property of a DOM collection if used as an ECMAScript member lookup.) Fix the DOM2StyleSheets and DOM2CSS trees, and axe the old proprietary version. Same goes for addEventListener, implement it and axe attachEvent (I know you can do this, you implemented it in Tasman for MSN/OSX). Fix mouse buttons to match the DOM standard. Axe window.event and replace it with a properly passed event as first argument to event handlers. Axe the use of event.srcElement and this (which doesn’t even work in attachEvent event handlers) to get event targets and implement the correct event.target and event.currentTarget. And implement bubbling and capturing events. Fix your JScript engine so that objects no longer return “[object]” instead of for example “[object HTMLElement]“, and also fix it and the host objects so that the this pointer is obeyed for method calls even to native functions, including full support for Function.prototype.apply on all host functions/methods with correct rebinding of this. Oh, and this is a great chance for you to be very much stricter with “Content-Type”. Make a statement – force servers to handle content types correctly if they want to serve you XHTML.
The second solution isn’t as safe to do, because there might be some compatibility issues. Not many I believe, but some. It involves “text/html” and HTML5. Namely, introduce a parser mode switch based on the HTML5 doctype, <!DOCTYPE html>. HTML5 parser mode should do the same axings and changes as the XML parser mode did for the host objects. But HTML5 should of course follow the HTML5 spec, including error handling. Let the legacy HTML tagsoup parser handle other “text/html” content, that will give you your vaunted backwards compatibility, but let HTML5 work. Don’t be afraid to axe host objects or correct implementations, this is a new parser mode. It’s not “Standards” mode, it’s HTML5 mode. It’s a new slate. Let it be a mode that follows the HTML5 and future standards, instead of stagnating by layer upon layer of backwards compatibility. And if web developers start complaining about “yet that other parser mode” as they are wont to do, then ignore them. You can’t cater to everybody, but this way is bound to give you a reasonable compromise – great forward compatibility, great backward compatibility. Give it a shot.
Posted in HTML |
You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
3 Responses to “The time to abandon backwards compatibility is now, Microsoft”
February 2nd, 2007 at 10:43 am
Hear, hear!
February 5th, 2007 at 10:32 am
AMEN!
Great suggestions, I hope that the boys in Redmond sees this as a very good opportunity to get their browser back on track before it’s too late.
September 5th, 2007 at 10:37 am
As Morgan said
AMEN
it’s near to be too late
Leave a Reply