I Am Officially An IE Hater

by Jon Davis 27. June 2008 09:41

Over the last 24 hours, I crossed a certain threshhold.

Originally, I was 100% biased in favor of IE (back in the days of IE3 and IE4). When Firefox came around I thought it was good that IE got some competition. But it wasn't long before I realized that IE was not competing anymore, it had dropped out of the race.

Eventually comes CSS 3 proposal drafts and HTML 5 proposal drafts, and the Webkit/Safari and Mozilla teams are on top of them, but IE is pooping along still trying to figure out how to spell "CSS 2.1". So I got angry and frustrated and started suggesting that IE8 had better clean up its act or boycotting of IE may commence on my part.

Now I am officially an IE hater. I applied the following CSS style:

div.ProfileQuestions {
    background-color: white;

.., overriding a default light gray color, and suddenly, erratically, about 1/3 of the off-black colored text vanished. Where did it go? I do not know! I fired up the IE Developer Toolbar, used the inspection tool, and as my mouse hovered over the areas where the text belonged, once again, erratically, text showed up while the hover border surrounded it, then disappeared when I moved my mouse away.

Could my computer be out of resources? I closed Internet Explorer, all instances, and then opened up the page again. The text showed up. I hit refresh. Now half the text was missing. I used my mouse to select the page's rendered text, some of the missing text appeared.

Safari 3, Firefox 3, Opera 9.5, all of these showed the page fine.

Surely I have a corrupt IE installation! I sent the URL to a co-worker and asked her to look at it. She, too, was using IE 7. She, too, was finding that there was text that was just plain gone.

I tried forcing the text to be black. I tried variations of background colors. Nothing I did, except to leave the background color defaulting to the body background of light gray, could stop IE from making random lines of text just vanish.

Internet Explorer 7 is used by a MASSIVE portion of the Internet browsing community. I am flabbergasted by this cheap rendering behavior, and that statistic of IE7 usage NEEDS TO CHANGE or else we will have a broken web indefinitely.

Let the boycott commence.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Highlighting a TR (HTML Table Row) With A Border

by Jon Davis 29. March 2008 15:44

Here's another workaround to fix another elementary problem in Internet Explorer. Again, this isn't anything new, but if anyone is coming across this blog looking for an answer to this problem, here's the solution.

(And by the way, yeah, this is really elementary. I should be focusing on real problems.)

Someone in a local technology mailing list asked for help on how one highlights a table row in Javascript. He tried the following function, but it did not work for him.

function OutlineTableRow(RowID,BColor,BWidth,BStyle)
 var TableRow = document.getElementById(RowID);
  TableRow.style.borderColor = BColor;
  TableRow.style.borderStyle = BStyle;
  TableRow.style.borderWidth = BWidth;

So how to you border-highlight a row in HTML? Internet Explorer doesn't support CSS on the TR like it should. You have to do it on the cells themselves. You also have to be careful not to divide the cells with borders; the leftmost and rightmost cells should be the only cells to get left or right borders, respectively. Finally, you must also set the border-collapse CSS property on the table to "collapse", otherwise the border itself will have seperation points on the inner edges of each cell.

Here's my workaround in Javascript, feel free to copy:

            <tr id="aa">
        <script type="text/javascript" language="javascript" >
            function outlineTableRow(rowId, borderColor, borderWidth, borderStyle){
                var tableRow = document.getElementById(rowId);
                if (tableRow) {
                    var table = tableRow.parentNode;
                    while (table.tagName.toLowerCase() != "table") {
                        table = table.parentNode;
                    table.style.borderCollapse = "collapse";
                    var tableCells = tableRow.getElementsByTagName('td');
                    if (tableCells.length > 0) {
                        for (i = 0; i < tableCells.length; i++) {
                            if (i == 0) {
                                tableCells[i].style.borderLeftColor = borderColor;
                                tableCells[i].style.borderLeftStyle = borderStyle;
                                tableCells[i].style.borderLeftWidth = borderWidth;
                                if (i == tableCells.length - 1) {
                                    tableCells[i].style.borderRightColor = borderColor;
                                    tableCells[i].style.borderRightStyle = borderStyle;
                                    tableCells[i].style.borderRightWidth = borderWidth;
                            tableCells[i].style.borderTopColor = borderColor;
                            tableCells[i].style.borderTopStyle = borderStyle;
                            tableCells[i].style.borderTopWidth = borderWidth;
                            tableCells[i].style.borderBottomColor = borderColor;
                            tableCells[i].style.borderBottomStyle = borderStyle;
                            tableCells[i].style.borderBottomWidth = borderWidth;
            window.onload = function(){
                outlineTableRow('aa', '#f00', '2px', 'outset');

1 2 3
1 2 3
1 2 3

But one should use CSS for this. Rather than explicitly setting [element].style.[cssproperty], instead one should set the className property, then define the details in CSS. If you really want to pass arbitrary styles to a function, jQuery would also be essential for doing this. Come to think of it, jQuery would be essential, regardless.

Currently rated 3.0 by 1 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Web Development

innerXHTML DOM-to-XHTML Generator in Javascript

by Jon Davis 13. March 2008 00:25

Developers often need XHTML-compliant HTML markup when they fetch DOM elements' innerHTML. Since the W3C hasn't standardized on this property (and I don't know why?!), the browsers have been inconsistent in their approaches to innerHTML. Firefox doesn't put the trailing slash in <br> tags, for instance, while Internet Explorer shows tags in all-caps and strips the quotation marks from some attributes.

This week after my rant got posted on Ajaxian.com, I figured I'd do my part to express my sincerity with the situation of by creating innerXHTML() and outerXHTML() functions in Javascript. Not the first-ever effort, but seemed appropriate considering the strong weight of my public rant. I intended to add it to the prototype of HTMLElement, but *gasp* .. wouldn't you know it, Internet Explorer doesn't expose a prototype for DOM elements!! Ack!! (Dang it, IE team, get out of your cave. :P )

So, take it or leave it, I wrote the innerXHTML() and outerXHTML() functions anyway, added them to the HTMLElement prototype for browsers that support it (yay Firefox), and added xhtml() for innerXHTML() equivalence for jQuery.

I posted it up at http://cachefile.net/scripts/xhtmljs/ with a lightweight test for initial coding efforts. More code than desirable is devoted to formatting (pretty line breaks and tabs), and if you don't like any of that fluff you can turn it off by setting the global variable xhtmlFormatting to "none" or, for now, to anything other than "formatted".


Hope everyone likes it. Please give feedback (ideas, concerns, complaints, bug reports, etc) to jon@jondavis.net. I might post this on CodePlex if I get a lot of feedback, but in the absence of feedback I don't see much point.  

kick it on DotNetKicks.com

Currently rated 4.0 by 4 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , , , , , ,

Web Development

IE8: Love or Hate?

by Jon Davis 5. March 2008 23:04

Been playing with IE 8 for a few hours. Here are some initial observations.

  • Love: WebSlices. I don't like WebSlices entirely, but there's something that feels just so Web 2.0-ish and, well, evolved. If you don't know what WebSlices is yet, let me try to describe it. I'll assume anyone reading this is famiilar with either the Firefox or Internet Explorer web developer toolbar. Both toobars have the ability to hover over any DOM element and you can click on it and it will tell you all about the CSS styles and classes associated with that element, as well as perhaps give you a look into where the element is in the DOM tree. Okay, .. uh, well, that's NOT WebSlices. But that thought in mind, imagine if a web site developer marked some tags such as some div tags as "webslices". They gave them GUIDs (not literally GUIDs but, unique IDs) to make them unique. With WebSlices, forget about introspecting the element with the web dev toolbar, imagine if you could subscribe to that element, as if the element was itself a web page, or an RSS feed. Yes, you can literally put a DOM element into your Favorites. That is way cool. I am not entirely comfortable wth its implementation, though, partly in the same way I felt about IE4 channels; it's sort of a browser-centric, stuff-it-in-your-toolbar way of managng personal data, the last thing I think people want is even more junk in their Favorites menu or yet another toolbar. Microsoft got RSS subscriptions right by retaining a more modular approach, allowing for an Explorer Bar or MS Outlook integration, hopefully they'll figure something out in this respect for WebSlices.
  • Hate: Activities. It's not the technology I hate. It's the branded spam. For those unfamiliar with IE8's "Activities", it's basically the same as the Windows File Explorer's "Send To" context menu option. You can basically right-click on a selection on the web and invoke an Activity which happens to mean a URL + querystring. Will be useful, no doubt, I'm just sick of all the MS Live and MS MSN and Encarta this and Yahoo that and Wikipedia and Google Maps and, oh good grief, stop shoving it all in my face already. But I'll give it to Microsoft, they didn't do nearly as much damage as Adobe did when I installed Acrobat Professional. There are literally eight (8) (!!!) individual PDF options in my browser context menu from Adobe Acrobat. Aargh.. [~silence as I go to Options and disable ...~] I also hate the name "Activities". It sounds like calendaring or meetups.
  • Love: Inline Javascript debugger. I haven't even tried it yet, but .. OMG, Yaaay! Microsoft came through on this one! We finally get a Javascript debugger built into the browser! No more mandatory installations of Visual Studio tools, which in the script debugging department has tended to get corrupted in the integration bits more often than I've managed to debug. Mind you, this ain't Firebug. But it most certainly is an essential part of a web browser, and Microsoft is showing that they are finally starting to see the light on this one.
  • Hate: Beta 1 form fields performance in Standards mode. I'm not sure what the deal is, but on this editor page, using BlogEngine.net, I was forced to enable the Emulate IE7 mode because in Standards mode I literally had to wait about five seconds for my keyboard cursor to respond after each individual keystroke. This is just a beta glitch, though; I'll live.
  • Love: Standards mode. ACID2 passes. 'Nuff said.
  • Hate: XHTML compliance exists in parsing and rendering only. Microsoft is still using an internal IE-HTML DOM that is not XHTML-compliant, even in XHTML documents. All you have to do prove this out is, in script, alert(document.documentElement.outerHTML); and what do you see? The most obvious observation is a total disregard for XHTML 1.0 § 4.2, which reads, "Element and attribute names must be in lower case; XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags." Why does this matter? It matters because of DHTML. It matters because there is an implemented and oft-used setter on DOM elements' innerHTML. It matters because people actually use the DOM programmatically, both in evaluating and assigning markup. It matters because the browser has a Content-Editable mode that is often used with online content editing whereby the innerHTML contents are posted to the server for viewing as content. It matters because Internet Explorer has a COM interface that can, and often is, used to parse and tidy HTML markup, or to provide a WYSIWYG rich text editor for applications. It matters because it's broken, has been all along, and has never been deemed acceptable.
  • Love: It's in my hands. Huh. That was fast, I mean it was just, what two months ago that IE8 was even named? Well, um, .. thanks, Microsoft.
kick it on DotNetKicks.com

Last Anticipated Tidbit Of Suck Finally Removed From Internet Explorer 8

by Jon Davis 4. March 2008 17:08

Not long ago, I suggested the unthinkable, of boycotting Internet Explorer, if the IE8 team does not catch up with the rest of the Internet (with standards compliance, etc). And by "boycott" I literally mean to not only jump on the "don't use Internet Explorer" hatred bandwagon, but to completely stop building sites out and testing on Internet Explorer and just apologize later to visitors of my work that I did not double the amount of time that is involved in building a web application or site in order to get it to render correctly in IE, and to encourage to everyone that they do the same, and let Microsoft take responsibility for their own failures. After all, web technologies (HTML, Javascript, CSS, et al) are not Microsoft technologies, so if a web site is built using 100% standards compliant markup, really, it should just work, period.

But I'll hand it to Microsoft, as sincere as I was, and genuinely spiteful I was quickly becoming for their lame excuses, they have won back my respect.

First, they started blogging about IE8. The initial post really ticked me off, as my "boycott" link suggested, because they muttered something along the lines of "don't confuse silence with inaction". The Internet does NOT work that way, and the IE8 team should be the most pronounced and involved division of Microsoft, more so than any other division including the Visual Studio team. But each blog post related to IE8 has shown some kind of attempt to get feedback from the Internet community while at the same time giving answers to community feedback. Those answers were not always acceptable. But they have been thoughtful, or at least exposing thought processes. Transparency is a good thing in oneself; there's nothing that can bring about inner change for the better than exposing one's inner workings or thought patterns to people who care. The IE8 team still has a lot to learn about transparency, but it's one small step in the right direction.

Then, they passed the ACID2 test. That says a lot. It says that they care about standards compliance, and getting their product up to speed on what the industry has already established. And heck, it even shows that Microsoft even cares about having a competitive advantage again in Internet Explorer, for the first time since v4. (Needless to say, they'll have to work hard to keep that up while working against the productivity of the Webkit and Firefox teams.) Time will tell if the IE8 team is paying close attention to the new ACID3 test.

Yesterday, though, they reversed their rediculous proposal that demanded that the standards group require web developers (like you and me) to insert a version tag to every @#$% standards-compliant web page that they produce if they want it to render correctly in Internet Explorer 8. That Microsoft even attempted to push this still floors me, but that they heard the outcry from the developer community definitely reverses most of my animosity towards their behaviors. I mean, the audacity to ask the whole world to outwardly apologize for IE6 glitch behavior, rather than the IE team taking the heat for their past mistakes, really blows me away. But with their reversal of this move, I suppose I'm one step closer to getting warm and fuzzy about IE again.

I'm not there yet; I don't suppose I will be there until I see the "extend" part come back with Microsoft's old "embrace and extend" philosophy, and that only by way of the IE team getting actively involved with the open standards community and proposing innovative and acceptable additions and/or changes to HTML 5 and CSS 3, and then being the first to implement those extensions.

Some things I am still wishing browser vendors including Microsoft would innovate for are:

  • Open standards automation innovation. Not only do I want to see plug-ins like Silverlight having COM (or similar) automation so that one plug-in can talk to Javascript or to another plug-in using a native tongue (literally), but I wish there was an open standard way of going about deploying binary componentization, so that whether for the Mac or for Linux, and whether for Safari or for Opera, you could write one plug-in that worked well with both the browser's Javascript engine as well as with other plug-ins. The whole thing in the 90's with OpenDoc and ActiveX being the Next Big Thing for componentizing software really just sort of fizzled, even though COM objects did materialize and moved forward, but I'm looking for a good reason why this is still not a big area of support and interest between web browsers and standards committees. Then again, there's XPCOM, that plus COM might've sufficed but it looks like it's being discontinued so I'm confused, where's the native componentization love?
  • CLR scripting. We get this with Silverlight. But I want it in HTML. Microsoft, gimme!! The CLR is an open specification, just as Javascript is with ECMAScript. C# is an ECMA spec, as is the CLI (Common Language Infrastructure). Internet Explorer could make the CLR the replacement for ActiveX Scripting and it would automatically be "standards compliant" as long as the DOM is exposed with full W3C compliance, and JScript.NET is ECMAScript compliant. Meanwhile, the puzzle for COM marshaling with ActiveX controls was already resolved in .NET's v1 implementation with RCWs. So, no excuses on this; I'm sure that there is an engineering challenge in exposing the full W3C DOM, etc., to the CLR, but then again, is there really? I think the payoff is there. This could also be the answer to the previous suggestion, an open standard to plug-in automation, if something like XPCOM doesn't fit the bill. But once CLR is the "native tongue" of the browser runtime, Microsoft and the other browser vendors could easily throw in multiple CLR languages. Imagine Internet Explorer natively supporting: <script type="application/C#"> or <script type="application/IronRuby"> (or whatever it would be for IronRuby) or <script type="application/IronPython">. Heck, even <script type="application/javascript"> could run on JScript.NET. Couldn't it? I assume that JScript.NET is ECMAScript compliant, isn't it?
  • Window framing. We have windowing with window.open() but there's no window framing support, and by that I mean to support things like alpha channels and shapes on the window itself. One look at eBay's AIR-based Desktop application and I'm thinking, cool, a desktop app that looks and feels like a rich desktop application but under the covers it's an Internet app. But the thing about AIR is that it really is nothing but HTML, Javascript, and Flash, on a proprietary windowing framework, plus some OS integration bits for Windows' Start menu access and an Add/Remove Programs entry. Right? So I mean, why can't there be an HTML+Javascript specification that allows for the user experience that one enjoys in AIR, without having AIR installed?
  • Canvas. Oops, that's proposed in HTML 5. Yay!
  • Native menuing. Oops, that's proposed in HTML 5 as well. Yay! Microsoft, are you listening to this? ;)

Just a few ideas. It's fun to think forward now that the present frustrations are fading into the past.

kick it on DotNetKicks.com

Silverlight vs. ActiveX: Give me automation or give me death!

by Jon Davis 8. January 2008 18:49

In the wonderful IE4 days when ActiveX was the big new thing, you could create an ActiveX control -- that is, a first class COM object - in full Visual Basic. In fact, Microsoft released a free version of Visual Basic just for creating ActiveX controls. It was ridiculously easy to create COM objects in this way.

Then you could instantiate the object in the browser scripting engine and do things like:

myActiveXObject.HtmlDocument = document;go

With that one line of code, (popping knuckles) the full-blown Visual Basic programming environment had access to the Internet Explorer web browser document object. There was no wrapper, just a COM interface!!

Visual Basic:

Call Me.HtmlDocument.window.eval("alert(""Hello from full-blown Visual Basic via the browser's Javascript scripting engine"");")

Me.HtmlDocument.body.innerHTML = "<h3>Muahahaha!</h3>" & Me.HtmlDocument.body.innerHTML
Me.HtmlDocument.body.style.backgroundColor = "#00000"
Me.HtmlDocument.body.style.color = "#ffffff"

Call Me.PlayVideo()

' etc.

Likewise, the COM interfaces of the ActiveX control were directly and effortlessly exposed to the browser Javascript runtime.


This opened all kinds of doors of opportunity. Event sinks and controllers could be dropped in every which way. Flexibility of writing code was virtually limitless.

This WAS doable before Microsoft abandoned Visual COM (Visual Basic 4/5/6). The ActiveX Script runtime engine was a marvelous invention. I'll admit that it's proprietary to Internet Explorer, though, but Mozilla has traditionally supported COM in some fashion. I don't know how Mozilla's plug-in and scripting runtime integrations work.

Fast forward to today. Rich client applications are now written in Javascript and AJAX, making use of only one specialized COM object (or other automation object, depending on the browser) now known today as XMLHttpRequest. Rich client apps also make heavy use of objects-based programming.

In order to create user experiences that are outside of the capabilities of Dynamic HTML, plug-ins are still used. This is where plug-ins like Silverlight come in. But those plug-ins, especially when they have broad and powerful runtimes like Flash (ActionScript) or Silverlight (CLR), need to be able to be interopable with the browser's script runtime in order for utilization to be fully realized. In the Internet Explorer world, the answer to this was simply IUnknown / COM / ActiveX.

Browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa.

ActiveX componentization is now virtually deprecated. Microsoft no longer sells nor supports Visual COM (Visual Basic 4/5/6, which was the only tool Microsoft ever created to allow users to be able to effortlessly create COM objects). ActiveX controls are also a security concern, and in Internet Explorer 7, users are discouraged from installing them.

But what I'm looking for is unwrapped interop support between the Silverlight CLR and the browser's runtime. Silverlight doesn’t have access to the Javascript DOM. It has access to a limited set of objects and properties of the HTML DOM using a wrapper API.


The CLR in Silverlight introduces a secure but powerful runtime engine to the web environment and an extent of sophistication that previously never existed, not even with old Visual COM (Visual Basic 4/5/6). Now that Silverlight 2.0 is coming out soon with a rich programmatic runtime like Visual COM (VB) used to have, I’d like rich COM automation back. The value is more fully realized when you can pass browser Javascript objects to the CLR or pass CLR-declared objects to the browser Javascript runtime.

(I'll post better examples of what used to work versus what doesn't work later this week. But yes, full COM interop was possible between VB and ActiveX Scripting, and yes you could pass objects back and forth. It even supported dynamically generated COM interfaces. For example, you could declare and instantiate a class in VBScript in the browser, pass the instance to a method on an ActiveX control written in VB where the VB OCX property expects a Variant, and then VB OCX could call upon the functions within that class.)

Obviously, what this means is that Safari, Mozilla, and Microsoft would have to agree on an interop strategy. I thought they had already accomplished this, but it'd be surprising to me if they didn't. It would, however, further cement my frustrations with Microsoft that they allowed too many years to go by without staying involved with the browser standards communities like W3C and ECMA to work those issues out.

ActiveX componentization is not deprecated because COM is a security concern. It is deprecated because the technologies that implemented ActiveX were not sandboxed like Java applets, Flash, and Silverlight are. The Silverlight CLR is neatly sandboxed--this means that there are no longer serious security concerns that developers otherwise had with the ActiveX plug-in support--so if security is a concern, it shouldn't be.

But, practically speaking, browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa. Put as succinctly as I can, if I cannot declare a function in the browser script with parameters, and call on it from the CLR while passing CLR objects, I feel stuck with preferring old ActiveX over the Silverlight CLR for dynamicizing HTML. The same is true going the other way. The way things are right now, it's an all-or-nothing deal--either you completely rewrite the AJAX web application so that it no longer users the browser Javascript and uses the Silverlight CLR, or you don't use the Silverlight CLR and stick with the browser Javascript. These two options are completely unrealistic, from a business perspective.

Microsoft's position on this matter has so far been that they think the "wish is valid, but it is challenging since we are dealing with a scripting world, a native world and a managed world all in one wish."

I'm sure it is challenging. But this and true DHTML are precisely why I thought Internet Explorer v4 was the greatest invention that came out of Redmond after the Windows NT kernel. It's why Internet Explorer had been Microsoft's preferred generic COM host for SDKs and development for many years.

I don't care if it is challenging. It was Microsoft who invented COM. It was Microsoft who implemented the ActiveX Scripting engine. It was Microsoft who invented the fully programmable browser DOM. It was Microsoft who invented .NET and the Visual Basic and C# languages. I have no doubt that the most profitable corporation on the planet can figure something out in this matter.

But this is an issue I have that goes beyond Silverlight, it is about Microsoft's leadership role in the Internet client software industry. It's like they fired their automation visionaries as soon as IE4 went gold.

Perhaps that isn't fair; the CLR is certainly quite visionary. It's just that the current state of things shows abandonment of the industry necessity to keep striving to bridge the gap between the browser script runtime and the plug-in runtime; this is a problem that has been around for over a decade, and that the industry leaders aren't still pushing for a cross-browser automation solution really befuddles me.

There is one "trick" that I can think of, though, to make window.eval() happen from Silverlight that may or may not work efficiently. Perhaps you can get Silverlight to change the text value of a hidden HTML element. This HTML element is strictly used for window.eval(). Javascript would need to be notified that the value changed. A setInterval loop? An onchange event hook? Dunno. But once it sees it it can fire it off and then populate some other hidden element for the eval result. I'd prototype this but I don't think onchange will work and a setInterval loop frightens me, not to mention only being able to use text (or XML) for params and return values. The whole idea seems terribly kludgy... Yuck.

kick it on DotNetKicks.com

Currently rated 3.8 by 6 people

  • Currently 3.833333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , ,

Software Development | Microsoft Windows | Web Development

Option Of The Unthinkable: Boycott Internet Explorer

by Jon Davis 6. December 2007 18:26

I'll confess, I am a Microsoft fanboy. I always have been. I really got started in programming as an adult trying to make a living when I got inspired by Microsoft's migration from Internet Explorer 3.0 to Internet Explorer 4.0. I had already wholeheartedly embraced Internet Explorer 3.0. Microsoft had gone way out of their way to recognize the value of rich client plug-ins (ActiveX) and a strong scripting engine (Active Script) that, frankly, kicked Netscape Navigator's butt. But then Internet Explorer 4.0 was announced, and the world beheld the news with much awe. Netscape 4.0 had, only months prior, announced support for "dynamic HTML", which in retrospect was little more than what I call "flying layers" and dynamic styles. It didn't really have a DOM. It didn't support dynamic content, for example. You couldn't say, "element.innerHTML = ...", for example. All you could do was put stuff in <layer> tags and position them on different parts of the web page or hide them -- flying layers. Whoopty doo. I'm a programmer, give me an object model, argh! But Microsoft knew the need. They are a developer platform company. They get it. Or got it, in the days of IE4. Internet Explorer 4 revolutionized the way software was made. Even just by introducing the Internet Explorer document object model, Microsoft gave us a powerful yet simple object lesson (pun unintended) about objects (again, pun unintended). It was the combination of playing with the DOM and reading Java books that my comprehension about OOP and the value of objects-based programming (a la business objects in VB5) began to sink in. And then I became a man.

Fast forward to 2007. The genuises behind Microsoft's Trident team, who built the amazing and spectacular browser that was Internet Explorer 4.0, had long ago abandoned Internet Explorer to go off and develop a Windows technology that was more suited for scalability and rich graphical layout. That technology was code-named Avalon, and released as Windows Presentation Foundation. Apparently, either some of them, or a completely different group of engineers (Macintosh engineers, perhaps) went off and developed WPF again, from scratch, duplicating WPF's efforts, in a microcosmic bundle called WPF/Everwhere or, as we now call it, Silverlight. Meanwhile, who knows who else was involved in the building of Expression Web, but apparently a whole spanking new layout and rendering engine was created for Expression Web, rather than the traditional Trident that was used previously with FrontPage.

All this while, Internet Explorer has been resting on its laurels, improving only by making minor bug fixes in CSS support and security, and adding tabs. The tired old Trident engine is still a powerful one, but it has apparently become too kludgy to risk too many more changes, and it is too heavily used throughout the industry with its COM interface to risk breaking third party apps by rewriting it.

At the same time, Safari, Netscape Navigator, and Opera are constantly evolving. Now Firefox has componentization, not unlike Internet Explorer's COM object. Now they're the ones embracing and extending, leaving Internet Explorer trailing behind. Now they're the ones setting the rules. They're the ones teaming up, forming working groups like WHATG to demand improvements on the development environment that is the web browser. Now Safari, Opera, and Firefox are innovating with proposing HTML 5, with or without Microsoft's cooperation, rendering up a canvas using simple Javascript and markup, and, most importantly, winning and maintaining respect from the community by trying to maintain openness about standards and interopability using open Internet protocols and standards.

Microsoft knew what they needed to do to play their cards right. They demonstrated this with their openness with Visual Studio 2008 and related tools, sharing CTP releases more than a year before its release. They demonstrated it in Internet Explorer 4 by making jaw-dropping, astounding promises that were not only kept but demonstrated many months ahead of release.

These days, however, Internet Explorer has become something akin to Microsoft Excel. It gets a revised toolbar, but the core engine is a tired old bag that doesn't want to be exercised. Microsoft's IE team apparently retains a few dedicated and hard-core developers to sit around and poke at its CSS support and security issues. All the while, though, it finds itself too heavily patched, too bloated, too encumbered with baggage, that it simply cannot keep up with the world in which it lives--the Internet.

So it comes as no surprise to me that a blog post like this would pop up on Microsoft's web site:


This kind of communication is extremely forthcoming about what Microsoft thinks of Internet Explorer. It tells us just how much they have forgotten their first love of their browser. It tells us that there are people over there who are doing their jobs, day in, day out, keep their mouths shut, keep the gears turning, make some improvements, go home to the kids, sleep well, come back in and do it again. They're not passionate; they're corporate grunts. It reminds us that Microsoft forgot what "laurels" means in the dictionary:


rest on (one's) laurels
To rely on one's past achievements instead of working to maintain or advance one's status or reputation. 

It also reminds us that Microsoft has completely forgotten that Internet Explorer is a development platform. Not only that, but it is a Windows-only development platform, one that Microsoft should care deeply about for their own proprietary sake. And development platforms, as was demonstrated in Visual Studio, demand early communication.

My first love with programming came from Internet Explorer itself. DHTML jumpstarted me to make me who I am as a developer. It's what made me proud to be a Microsoft bigot, proud to choose Microsoft over the others, proud even to break the common sense rules of web site design and actually not bother to build web sites that worked okay in Netscape Navigator, knowing that the huge market saturation that became of Internet Explorer was sufficient to tolerate the losses of those who could not experience what I was implementing into the browser. (I haven't done that in many, many years. For this long, I have respected the expressions of frustrations throughout the Internet of animosity with this practice. However, my patience is wearing thin with Microsoft's incapacity to keep up with the rest of the community with regard to established standards, the perfect opposite and equally disruptive practice of what they did back in the days of IE4.) Sure, Active Server Pages and Visual Basic's powerful COM objects and MTS and SQL Server--the whole DNA platform--contributed to my attitude about Microsoft early on. I saw it all as extremely powerful and leveragable, a developer's dream. But it was IE that made the Microsoft platform fulfilling and enjoyable.

But now I am feeling such an aching burden in my heart. I feel like Microsoft's complacency has developed into betrayal. They don't care about client-side web developers anymore, I feel, not unless those are Silverlight folks.

The above-referenced link to that blog post is really what riled me up to post my blog post here. These words in its comments from other readers describe how I feel as well:

  • "'In the meantime, please don’t mistake silence for inaction.' Too late... while MS might not be keen to adapt to the culture of the web, the internet as a whole generally values openness, transparency and communication. For such an important tool that holds huge influence on the web, the pain caused to web developers and users alike by the MS's silence is magnified."
  • "In the end, silence is a good way to create false expectations and alienate your developers and customers who care enough to follow this blog.  People who follow this blog are not exactly your casual users.  We are your power users.  We are your core developers.  We are your fans."
  • "I cannot believe that 1 year after the release of IE7 that the first "news" about the next version is that you have FINALLY decided on a name?  As Microsoft proved with with IE6, it would totally be irresponsible of anyone to mistake silence with inactivity - oh wait - that is exactly what silence meant.  Given Microsoft's recent track record with IE, why should anyone assume otherwise?"
  • "The next version of Internet Explorer will likely have hundreds of millions of users during its life-cycle. By ignoring the developer community you once had, and now making light of your horrendous business strategy, you've done nothing but destroy what credibility you once had and you've earned the animosity and contempt of people who will eventually work with your product on a daily basis. Also, you hurt my feelings."

There were a few that I couldn't help but laugh at -- I don't agree (of course) but, knowing where they come from and what pain caused to provoke them, they are appreciable. Like, "Kill it and kill yourselves. Douse yourselves in gasoline and set yourselves on fire."

Let me just say this about Silverlight. Dude, you're stealing from us what matters, which is Microsoft's time, money, and infatuous love and devotion. A decade of HTML 4 and XHTML 1 (which Internet Explorer never fully supported) is a REALLY long time in Internet years. My co-workers have been working in the industry for half that much time; perhaps most of Microsoft's development teams are in the same boat! I'll care about Silverlight when it goes beyond being a toy video player, and beyond being a plug-in viewer that can run C#/Python/Ruby apps (with flying layers), and becomes the basis on which a new Internet Explorer engine is built.

Now perhaps Expression Web's new layout engine is better suited to replace Internet Explorer's layout engine. Neither Expression Web nor Silverlight support IFRAMEs, framesets, COM/ActiveX controls, Java applets, or browser plug-ins of some other kind. I'd place my bets that Expression Web is much further along in being available to support these things, as it already supports HTML whereas Silverlight does not.

On the other hand, perhaps I was mistaken, or heard incorrectly, that Expression Web has a new layout engine that's completely distinct from Trident. I don't know.

In any case, I am so disgusted by Internet Explorer's complacency that I've decided to draw a line. Microsoft will surely prove that they care about Internet Explorer in the context of client-side web developers, and give the browser the kind of innovations that a competitive browser market demands, then there will be no more room to grumble. I can understand Microsoft's dissatisfaction with the industry that it would provoke Microsoft into the courtroom with regard to browser tie-ins with the operating system. To that, all I can say is, lighten up, pretend, just pretend, that you were wrong and they were right, and figure out how to plan your operating system integrations more adaptable in the future.

Microsoft of all people have a great rendering engine in WPF that they can leverage into HTML 5's canvas, and another great rendering engine in Expression Web that they can pound into the browser shell we know as Internet Explorer, if they can be sure to get their network stack, COM support, and more, all working correctly.

If, however, Internet Explorer 8 is just another name, with a prettier toolbar, a few new CSS additions, and no real look at HTML 5, then I'd say, forget 'em. By then, which will be at least another year from now, the clock will be reset, and we will be waiting for IE 9, hoping that that one will have something worth shouting about. That clock will require another two years. And it's really just not worth it.

So here, I'm drawing a line. What's it going to be? Does Microsoft care?

Microsoft is family. I've never been employed by Microsoft--and believe me, I used to dream of being employed by Microsoft but I couldn't handle being over there without making splashes of rocking the boat as one of their annoying little junior programmers--but I've invested almost entirely into them and placed all of my chips on them. I've "worked with" them, as a third party, for a decade now, and I know how they think. Yes, they've been complacent with Internet Explorer. Yes, they've forgotten how to innovate on that platform.

However, I think they have the talent and technology bases available at their disposal to make an overhaul of Internet Explorer possible.

While little if any of the following is going to happen, just imagine the innovative integration of all of these into the same web browser:

  • Expression Web's layout engine, add CSS2 flawlessness, limited CSS3 support, full support for frames, plug-ins, and COM objets
  • Silverlight's "script engine" (Jscript, C#, VB.NET, Ruby, Python) fully exposed two-ways between the CLR and the W3C DOM, and the basis for a Canvas context and SVG support
  • Scaled-down implementation of Visual Studio 2008's powerful and introspective script debugger (but perhaps integrated into the browser, and without the vulnerability of registry/tie-in corruption of the script debugger)

Add to this HTML 5 support and proper XHTML support (with in-line DTD extensions support) and you've got a winner.

Chances are, we'll see less than half of this. But if we only see a few security improvements and a few new improvements to CSS, or somesuch, I'm sorry, I'm afraid I will find myself returning the favor of betrayal, and get on board with the other bandwagon. I will tinker with Firefox's componentization, something I've been wanting to tinker with anyway for a long time, and I'll start building my client-side code out based on features that Internet Explorer just doesn't have, like next-gen ECMAScript support and Canvas support.

IE will be there as a standby for plain old HTML 4 apps. But meanwhile, if I want Silverlight, I'll host it in Firefox or use Firefox's canvas, thanks.

So here's where I stand on this. Microsoft, if you're reading this, and care at all about my mere opinion, let me tell you what I think. When you say, "don't confuse silence for inaction," I think that your actions are meaningless. We don't want timely deliverables, so much as we want quality and feature-complete ones that are kept in check with the demands and expectations of your user base. I'll gladly wait until 2010 if I can JUST KNOW by your own word when it is coming, and that it is feature-complete. We don't necessarily want you to tell us what you're up to on your blog. We want to know that you to listen to what we think of the product when we all say the same things about your product in our blogs. We want to know that you care not for your reputation in your keeping silent, but for your user base, which means the web developer, not just the end user. We don't want your authortiative declarations of what is coming. We want your outspoken observations of what you are finding us most commonly demanding.

And we want those observations converted into promises. Promises that can be kept. Promises that you care about Windows playing nice with the Internet community by submitting to standards bodies outside of your own ego--CSS3, HTML5, SVG, and PNG, not just XAML, C#, and VBxx.

Project manager(s), you've got a big responsibility on your shoulders, millions of people are depending on your product. Deal with it. Stop cowering under your desk--get out there and shake hands with the people who care the most about your product, the web developers.

You're losing us.

See Also: http://people.opera.com/howcome/2007/msft/


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar