I've been trying to disable script using the IE Developer Toolbar for a while now. Well, at least I've wanted to for a while, but its was greyed out so I couldn't select it in the menu. Its a fine little menu, with "Disable" well placed between "Find" and "View", then when you click the Disable item from the menu, three options pop up: Script, Popup Blocker, and All CSS.

The All Css menu item worked fine, it would drop any styles applied to the page and show me the raw, unstyled HTML content. Yet for some reason the top two items were disabled.

I poured myself a fresh cup of coffee from the French Press sitting on my desk and thunk about it real hard. Then, I opened Internet Explorer, clicked Tools, Options and then navigated to the Advanced tab. Sure enough, the Disable Script Debugging options were selected.

I cleared the checkbox and restarted IE. Low and behold, I could now disable the JavaScript because it was no longer greyed out in the IE developer toolbar.

Drat!

One of my teammates recently had a problem with some Flash injection code. She was setting some properties and then calling a function on a JavaScript object that threw an error. We got a message that said "Object doesn't support this property or method".

We isolated it down to a timing issue by dropping an alert() into the code just before we called the method. With the alert() pausing execution for a few seconds, the browser had enough time to fully instantiate our object. Without the alert(), the method was called before it was built. Its a problem that can make your brain hurt.

Here's how you can test for the existence of a JavaScript method before you call it. You might need to do this if you're working with asynchronous calls or dynamic objects that take a while to build.

I created a sample page to demonstrate the issue and how to deal with it. I put three hyperlinks on the page that each call a JavaScript method. Here's the JavaScript code.

At the bottom of the previous code block, you'll see some JavaScript in the mainline section. This code gets executed as soon as the browser sees it. JavaScript is an interpreted language and the browser processes it in a top-down fashion. So, by definition, the browser already knows about my three methods before it runs my code in the mainline.  This is where I define an empty object to test and then create an instance of that object. Just two lines, not much so far.

When I click the link that runs the function named TestForFunction(), I perform some due diligence tests by checking for an undefined object as well as a null object. The last test with the arrow pointing to it is the key part. This will tell me if the method exists without actually running the method. I show one of two messages based on the existence of the method.

The top function named CreateFunction() just spot welds a method onto my object. Even though I've already created an instance of my object, I can still see this method in my instance because I've added the method to the prototype. When this function returns, I've got my new method. When I run TestForFUnction() again, it will see the method.

The bottom method just executes the function I added on the fly. When my DoWork() method fires, it shows a message in the alert() pop-up.

If you find that you need to deal with this type of problem in your code, inspect the object for the method before you call it. If the method doesn't exist, refactor your code to call the window.setTimeout() function for a few milliseconds and check again. Once it exists, your code can continue executing.

I attended the Software Association of Oregon (SAO) event today. The Development Special Interest Group (DEV SIG) hosted a discussion about Microsoft CardSpace, the open source framework of OpenID, and basic identity management.

Stuart Celarier walked the audience through Kim Cameron's paper called The Laws of Identity that articulate seven desired aspects of a good identity system.

Microsoft CardSpace was formerly named "InfoCard". This is a joint effort to implement the identity metasystem defined by the laws of identity. CardSpace is the "identity selector" for Windows. It needs IE7 and Microsoft .Net Framework 3.0 to operate. It implements the WS-* specifications in this service.

OSIS - Open Source Identity System: This is an open source group that's involved in the identity space.

Stuart also showed a demo of a system he's been working on. It logs a user into Wachovia banking site using CardSpace.  Scott Kveton of JANRAIN presented OpenID to the SAO DEV SIG group. OpenID hopes to solve the problem of having too many usernames and passwords.

• Single Signon for the web
• Simple, light-weight
• Easy to use, easy to deploy
• Open development process
• Decentralized

Your OpenID is a URL: http://kveton.myopenid.com/

• OpenID comes from the blogosphere
• Biggest problem with identity; namespace
• OpenID solves this by using DNS
• Your identity is a destination
• You have a unique endpoint on the web

Scott Kveton explained how sites enabled with OpenID enable users to authenticate. Visitors type in their OpenID, and the browser redirects to your OpenID provider. The visitor makes the appropriate decision and the browser redirects back the website.

Scott's site is http://scott.kveton.com

Last week Bill Gates announced support for OpenID. AOL announced support for OpenID this morning. More companies are about to make similar announcments. Here's some interesting stats on adoption:

• 12-15 million users with OpenIDs.
• 1000+ OpenID enabled sites
• 10-15 new OpenID enabled sites each day
• 7% grown each week with new sites

Kveton also brought up "Microformats" - a way to describe data in an HTML format (contact info, social network, calendar). These can be embedded on pages. There are some interesting ways to use OpenID with these technologies:

• OpenID + iCal
• OpenID + hCards
• OpenID + Social Networking (XFN, FOAP or FOAF?)
• OpenId + Reputation (jyte.com)

OpenID Predictions from Kveton:

• 7500 sites supporting OpenID
• 100 million users with OpenID
• Big players adopt OpenID

OpenID.net has a ton of info.

Scott Hanselman explained how he enabled OpenID on his blog. Hte added two HTML <link> tags to his website. Simon Willison has an OpenID enabled blog. A visitor can click Sign in with OpenID. The OpenID logo lives inside the textbox. Scott entered his OpenID in the textbox on Simon's site. Using a web service, Simon's blog discovered Hanselman's OpenID provider, then it redirected the browser to Scott's OpenID provider.

Scott's website indicates the OpenID provider is www.myopenid.com. 

The OpenID provider prompts Scott to authenticate. After a successful login, the browser redirects back to Simon's page and recogizes Scott Hanselman. This is how Simon doesn't need to keep track of usernames and passwords for his blog; a huge benefit.

Stuart helped explain the difference between self-insued cards and managed cards: Business Cards from Kinko's versus a card issued from Visa.

Scott Hanselman displayed a different identity selector using Firefox on Windows. The page contains an HTML <object> tag of type "application/x-informationCard". It wasn't as pretty as the CardSpace in IE7 and .Net 3.0, but it had the same behavior.

There was some last minute discusson on "I-Name", an XRI technology (extensible resource identifier). It sounds like its still being baked.

2idi relays comments on Scott's blog. They will issue an I-Name. =kveton is Scott's I-Name. They have an DNS resolver where visitors may enter xri://=scott.hanselman/photo to redirect to his Flickr account.

This link went around the office a few days ago about the rendering engine used to display HTML email messages in Outlook 2007. Evidently, the folks from Campaign Monitor are not impressed.

The issue is that Outlook 2007 uses Word to render the HTML email messages instead of Internet Explorer. This leads to some limitations on the HTML and CSS that authors can use in their message.

Zeyad Rajabi and Erika Ehrili wrote this document to help folks understand the rendering capabilities of the Outlook 2007 email client. Its well done and easy to understand.

It looks like a fair number of people are in a tizzy over this. If you make a large percentage of your revenue by designing complex email templates for your marketing clients, you're probably interested in how the email renders in the reader's email client program. Just thinking about the number of email client programs is startling. That's a lot of testing to do before you send out your mass e-mail message. Plus, you have to comply with the federal anti-spam laws. I suppose the marketing folks deserve a little bit of a hassle for all of their networking events and schmooze fests...

I like a pretty e-mail as much as the next person, provided that its relevant to my interests. I don't like the crippling affects that I see when one is forwarded to me by the original recipient. It seems to me that the message needs to be short, with a clear call to action, and trackable. I'm fine with a details link to a web page.

These are some of the choice excerpts from the comments on the Campaign Monitor page:

---

jaw - floor.... Where is the frick'n sense in this? Is it 'cuz they didn't employ people who can understand CSS?? WTF??!!

---

Hey there... I guess this is attrubuted to Vista's. IE has been split from the windows shell thus meaning that if IE is not installed on the computer Internet Explorer cannot render the HTML. See when you are in XP if you type in a url in Explorer it will go to the page "inplace" however if you open up Vista and try to put in the URL windows will open up your default browser to open the page. :)

---

I like it. I've gotten emails from clients using the background images just b/c they look "pretty" and it ends up destroying the message formatting when I try to reply. Also, it's less junk taking up bandwidth. If you need graphical pretty things sent to specific people, find another way.

---

Hate to be a spoiler, but I long for the days when my email didn't look like a webpage.

Email should be fast and efficient.

Graphical email is not.

---

I'm no fan of using the Word rendering engine, but the real problem lies in the overuse of HTML mail. Anyone who doesn't use Outlook already has problems similar to the ones this switch will cause, and there are only two ways to ensure perfect rendering; Use plain text for emails, and use PDFs for pizazz.

---

I'm almost positive it has to do with the whole Anti-Trust issue. The answer that would make the most sense to me would be the word rendering engine is part of Office. IE is not and therefore instigate the issue that people are being forced to upgrade and use IE versus alternatives. I think its a step in the right direction but i believe that it has hindered the users experiance because of it. Only time will tell if they stick to their guns and give some resolution on it.

---

I think this is a great move. I'm sick and tired of html email and hopefully this will reduce the number of people that think its cool to put html, background images, and all that other crap in an email.

---

Currently using Vista and Office 2007 and I do not see these problems problems. I even make HTML based newsletters an I have do do not changes to the way i create them. It looks like FUD to me.

---

stop crying... BUY A MAC!!!

---

Hey, maybe now we can get email back to what it's supposed to be. Text-based. HTML email has always been problematic and you've never been really sure about what the other person would see depending on their email client.

---

Let's talk a little bit about spamminess, and why HTML might not be the way to go in email.

We run SpamAssassin, a requirement when each email account averages 150+ spam messages per day.

HTML is already suspicious and gets -10 -- -40 if HTML only. Since -50 is quarantine, your beautifully crafted HTML only message is precariously close to deletion already.

---