February 2005 - Posts
Microsoft has publicly commited to releasing Internet Explorer 7 this year. Most of the hype so far has been around security and privacy with very little discussion about other new features. Perhaps that is the right move for now since security and privacy concerns with IE are top reasons that many experts and pundits have advised people to switch to Firefox. But beyond security and privacy there are several years of feature innovation for IE to catch up on:
I see a lot of hope in the blogosphere about tabbed browsing, which would be great - although you can already get browsers such as Avant that wrap the IE browser control in a tabbed interface.
A better model for browser extensions would be nice. I am a big Firefox fan, and one of the things I really like is the selection of extensions available. I usually have a few extensions installed and have considered writing my own a couple of times (though it's a pill I've yet to swallow - I have a long to-do list these days). The ieview plugin is a top pick: simple yet very practical for Internet developers. The ability to write managed extensions for IE would be superb!
My biggest concern with yet another version of IE is the union of new quirks with old quirks for the sake of backward behavior compatibility (for example, some people will want the new IE to act like previous versions of IE when it encounters markup that is invalid). It's a classic problem in which developers or end users rely on an idiosyncratic feature, buggy behavior, or an undocumented "feature" to accomplish something. And when a problem arises in a future browser versions, people cry foul.
I believe we are fast approaching a time when as an industry we will acknowledge that we've stretched HTML much too far and start coordinating on a better solution for thin clients. I have some thoughts on this already that I think are mostly practical with just a tiny bit of wishful thinking. I will try to get those ideas blogged this week.
Tonight I discovered that my tablet PC makes a suitable "flashlight" when I flip it into slate mode – useful for wandering upstairs after turning the lights off on my way to bed.
By the way, this is a test post from BlogJet instead of SauceReader (just experimenting). Does anyone know of a good blogging client specifically for writing in ink but posting only the resultant recognized text? I find the TIP (tablet input panel) gets tedious to use for a multi-paragraph post.
This quote is from Russ Cooper's recent Security Watch column (http://mcpmag.com/columns/article.asp?EditorialsID=896):
A new survey by the London's Licensed Taxi Drivers Association reported that almost 5,000 laptops and more than 60,000 mobile phones were left in London's black cabs by passengers over the last six months. Compare this with an August 2001 report for the same area which indicated that 2,900 laptops and 1,300 PDAs were left in the six months prior.
While typically such items are stolen purely for their resale value, one can only imagine the quantity of sensitive and confidential information they contained.
What I continue to find unsettling is how insecure most consumer mobile devices are, including laptops. There has been a somewhat pervasive attitude in the desktop computing world for a while now that once someone has physical access to your machine that it is already compromised. I buy into that line of thinking to some extent but with the sale of laptops outpacing desktops, information workers are very mobile and therefore very vulnerable. I'd hate to think about the potential consequences of mortgage brokers, investors, financial advisors, and lawyers who forget their devices in a cab. Or even developers - hey, there's IP on our laptops!
For Windows users, the encrypting file system (EFS) would add some extra security. But I would hesitate to recommend EFS to someone who was not part of a managed environment with a domain and system administrators who can assist with key or data recovery in the event of a forgotten password.
This aspect of computing has to get a lot better. I will be a lot happier when mobile devices start shipping with encryption turned on by default and biometric sensors for authentication (or at least password reset).
If you have ever created an ASP.NET page with only a single textbox, you probably know that with Internet Explorer a server-side button click event will not fire for the submit button when you press Enter. As far as I know it is caused by IE not sending the button name in the POST when Enter is pressed instead of clicking the button (Firefox doesn't have this quirk). I've seen people use JavaScript and server-side workarounds for this problem in the past, but when it cropped up on one of our projects the other day I didn't want the developer involved to be distracted with having to look up one of the workarounds and implementing it. So as an ultra low impact workaround I simply had him add another textbox to appease IE:
<input type="text" readonly style="width: 0px; visibility: hidden " />
Works like a charm, no mess, and the user doesn't know the difference.
Recently I encountered a very strange problem caused by markup that did not conform to the claim of the DOCTYPE for the containing HTML document. We were working on a Web site that used third-party JavaScript to dynamically generate a DHTML menu. The menu rendered perfectly in IE and Firefox. We were asked to reproduce the same menu in a Typepad hosted blog. Sounds simple, right? Just copy the same JavaScript and it will work.
It didn't work. Actually, it worked in Internet Explorer but in Firefox the submenus would render in the wrong position. If I put only the JavaScript in an HTML file, it worked in both browsers. So clearly the issue was something in the TypePad template. My initial hunch was that the problem was being caused by a TypePad-specific CSS file. But as I pulled elements out of the TypePad template in search of resolution, I noticed that the main Web site did not include a DOCTYPE. The TypePad template specified XHTML Transitional in its DOCTYPE. Removing the DOCTYPE fixed the Firefox rendering problem!
My best guess is that the JavaScript for the menu was generating HTML that was not well-formed (not valid XHTML). I don't know what the W3C says, but I assume that technically the results of rendering invalid XHTML should be undefined if the document claims to be using XHTML in its DOCTYPE. IE and Firefox certainly seem to handle the situation quite differently, although neither browser gave any sort of error or warning.
I will say this much: it's browser war deja vu all over again and it is frustrating that as an industry we did not learn our lesson the last time.
More Posts