Jon Galloway

Running Silverlight 2 on Google Chrome using the Chrome Dev Channel

When Google Chrome first came out and I read that it used Webkit, the same rendering engine that powers Safari, I tried browsing a few Silverlight 2 sites. It kind of worked, as long as the sites didn’t exclude browsers that weren’t on Microsoft’s official Silverlight support list. The controls loaded, but didn’t animate or update smoothly. While Microsoft still isn’t officially supporting Silverlight on Chrome, Chrome’s latest Dev Build (0.2.151.2) includes some specific fixes to support Silverlight 2 Beta 2. The information about the updates is in the release notes, specifically revision 1735:

The basic issue here was that the plugin would not paint correctly. The URLs mentioned in this bug load windowed silverlight plugin instances, which invoke the NPN_InvalidateRect API to paint. We send over the rects to the renderer, however these don't generate paints as the plugin is windowed. A peek at Safari's webkit implementation revealed that they merely invoke the InvalidateRect windows API in this context.

I followed the link in Jonas Follesø’s post over to the Chromium Developer instructions for running the Chrome developer build, which are really simple:

1. Download and run the Google Chrome Channel Chooser (http://chromium.googlecode.com/files/chromechannel-1.0.exe).
2. Click the circle next to Dev.
3. Click Update to save your choice.
4. Click Close.
5. In Google Chrome, click the wrench menu and choose About Google Chrome. Note: On Windows Vista, updates from the About box require Service Pack 1. With 0.2.149.29 (the current release), on demand updates do not work in Vista SP1 if User Account Control is disabled.
6. Click Update Now to install the current Dev channel release.
7. Restart Google Chrome.

And yes, it really is that easy – I had it running in under 5 minutes. First, I ran the Chrome Channel Switcher. It’s a simple EXE, not an install. Select Dev, press the Update button, then press the Close button:

Then open the about box (in the wrench menu) and click the Update Now button:

The update runs:

After the update finishes, close and reopen Chrome. If you want to verify you’ve updated, check the about box – you’ll see the version number is different:

That’s it. The whole process took just a few minutes for me. Now, off to view some of my favorite Silverlight 2 Sites! First, the Hard Rock Memorabilia page. There’s a check to see if the browser is supported, but it still lets me in if it’s not on the list (which is a good policy anyways, since it allows Linux / Moonlight users to view the site):

I hit okay, and we’re in. The site is snappy and everything works just fine:

How about the Mojave Experiment site, which uses a fancy Deep Zoom / video cloud thing? Yep.

Jonas has some screenshots of other Silverlight sites, which also worked well for him, and it worked for Samiq as well. From the release notes, this Dev release also fixes issues with Flash, such as YouTube videos freezing when you use the slider. Go get it!

Note: All the computers I tested this on had Silverlight installed before upgrading Google Chrome to the dev build. One had Safari / Windows installed, the other didn’t. Google Chrome doesn’t include Silverlight; you’ll need to install Silverlight separately if you don’t already have it.

Silverlight and Relative URI’s for Image and Video Sources

One of the main use cases of Silverlight is to enable rich media experiences, which requires referencing media files (images, audio, and video). That’s a little trickier than you’d expect, and it’s not very clearly documented. For instance, we ran into difficulty getting this set up in our Silverlight Advertising demo for MIX – we wanted to allow for a drag and drop experience to add a video as a canvas background without requiring additional downloading code to pull the video. Here’s an overview on how that works (thanks to Tim Heuer and for much of this information).

NOTE: This is especially important if you’re including a video or lots of images. The wrong way to include large media assets is to include them as resources (either compiled into the DLL or included in the XAP), since that will require your users to download everything before the Silverlight control is displayed. It’s important to keep your Silverlight XAP’s small so your users have a smooth load experience. For instance, the Hard Rock Memorabilia site browses gigabytes of images, but the XAP size weighs in at a tiny 69KB.

Silverlight URI References Are Relative To Your XAP

Short story is, Silverlight media Uri references don’t work the way you’d think, largely to keep compatible with WPF Uri’s which aren’t living inside a website. Relative Uri’s are relative to the Silverlight application, not the website. There’s no way to do site relative Uri’s without writing code. For example, using the following site structure:

Note: Screenshot has been updated since original post.

In this case, a source Uri could reference VideoB.wmv, but couldn’t reference VideoA.wmv or any images in /Images. So these are valid:

<MediaElement Source="/VideoB.wmv" />
<MediaElement Source="Subfolder/VideoC.wmv" />

These are not:

<Image Source="/Images/Logo.png" />
<MediaElement Source="/VideoA.wmv" />

Some Workarounds

1. Include the content in a subfolder of ClientBin. Set the content type to “Content” rather than “Resource” unless you want it downloaded with the XAP. Don’t include the media as a resource, or your users will have to download all the video and images before the Silverlight element is displayed.
2. You can manually move the XAP in the root of the site, and site relative paths will work. This solves the Uri issue, but then you’re on your own a bit because you’ve stepped outside of what Visual Studio’s tooling supports. Shawn Wildermuth recommends moving your XAP to the root of an application and has a good post on how to do it.

Pete Brown wrote a nice overview explaining how relative URI’s work in the three possible cases:

Images with Leading Slash (like <Image Source="/foo.jpg" />)

This type of references, with a leading slash, is root relative to the application root (the XAP). These files should by Content and have CopyToOutputDirectory set so that they are added into the XAP. If you inspect the Xap, you'll find the image in there.

When not found, the resource loading mechanism falls back to the application's site of origin and looks for the image under the same dir as the XAP is located. Note that this is the application's site, not the hosting page's site. That is an important distinction if you are creating cross-domain applications (where Site X has the page and Site Y has the XAP). If not found, an exception is thrown.

Images without Leading Slash (like <Image Source="foo.jpg" /> )

This type of reference, without any leading slash or anything, expect to find the image compiled into the assembly as a Resource. The path is relative to the path of the Xaml file from which they are being referenced. When not found, the ImageFailed event is raised

If you inspect the XAP, you will not see the image, because it will be in the assembly.

Absolute URLs (like <Image Source="absolute http url" />)

This will look at the named absolute Url as you would expect.

The absolute URL sounds like the simplest approach, and it is – from the Silverlight point of view. It’s not the simplest for web development, though, because your references won’t stay the same between your development, test, and production machines. In general, I use the leading slash references with the media files hosted at the “site of origin”, meaning the site at which the XAP file is hosted.

One More Gotcha / Workaround – WebClient and HttpWebRequest Don’t Follow The Above Rules

WebClient and HttpWebRequest use the browser’s network stack, so they work the way you’d expect for normal web applications. For example, in the following code:

var webClient = new System.Net.WebClient();
webClient.OpenReadCompleted += ProcessResult();
webClient.OpenReadAsync(new Uri("/info.zip"));

The web client request is routed through the browser’s networking stack, so it would be looking for info.zip regardless of where your XAP file is located in your site. I guess the downside there is that your location context changes depending on how you’re accessing resources (via Uri reference or by explicitly connecting to it via WebClient/HttpWebRequest). However, there’s an upside – your XAP can reference content anywhere in your site via WebClient/HttpWebRequest, even if the XAP is located in a subfolder. That’s handy, because in some cases that can be a lot simpler than determining the absolute URL of your resource.

MSDN Low Bandwidth Bookmarklet

There’s a semi-hidden feature in the MSDN Library website: Low Bandwidth view. We’ll talk about how to use it, why I like it, and some tips for switching it on and off. We’ll end up with an MSDN Low Band bookmarklet I whipped up to make it even easier.

The Low Bandwidth view has been available for a few months, but you wouldn’t know about it unless someone told you, since the only way to turn it on is to monkey with the URL. Try it - browse to:

http://msdn.microsoft.com/en-us/library/system.object.aspx

Now we’ll add the magic word: “(loband)” right before the “.aspx” at the end:

http://msdn.microsoft.com/en-us/library/system.object(loband).aspx

Magic!!!

Why LoBand is High Value

Simpler Layout

The obvious difference is that it replaces the navigation treeview on the left with a simple link. There are other subtle differences – simpler layout, fewer superfluous images. Higher signal to noise in my book.

Smaller Page Weight

The High Bandwidth version of this page weighs in at 100KB of HTML, but 400KB total by the time all the images, javascript, and CSS are loaded. Compare that with 66KB HTML / 70 KB total for the low bandwidth version. In this case (which is pretty representative) the low bandwidth version slimmed the page weight by 82.5%.

Faster Page Load

I’m not just talking about the smaller HTML here. The navigation tree on the left contains tons of nested unordered lists (ul>li>ul>li etc.). It’s actually a big improvement over the former HTML for that treeview, which (if I remember correctly) included a bunch of horrible nested tables with inline styles and javacript attributes. The new treeview uses a Telerik control, and outputs relatively clean HTML. Still, that treeview takes a while to load up – on my relatively quick development machine (with a very fast internet connection), the low band page loads twice as quickly – most of the time is spend in rendering the page. I’m not talking about milliseconds of difference here, I’m talking about 1 second load / draw time for low band vs. 4 second load / draw time for high band.

Who Cares?

Well, if you’re a Microsoft developer, you spend a lot of time on MSDN. There’s the time saver factor, sure, but more important is that fast load times removes the barrier to exploring the site.

Getting To The LoBand

The simplest way is to just add that (loband) bit before the .aspx file extension. If you’re on a page which already has one of those funky filters in the URL (like this: http://msdn.microsoft.com/en-us/library/cc189009(VS.95).aspx) you can just add a comma and put it in afterwards: http://msdn.microsoft.com/en-us/library/cc189009(VS.95,loband).aspx

When you switch to low bandwidth view by tweaking the URL, you  get a a “persist low bandwidth view” link at the top, which is nice. Clicking that link sets a cookie, so all MSDN you visit will be in low bandwidth view. That sounds great, but I find there are times where the low bandwidth is too low. Some pages (especially articles) are hard to read, and when learning a new object model the navigation tree is helpful. In that case, there’s a link at the top (where the “persist low bandwidth view” link used to be, before we clicked it) which unsets the cookie and returns us to the normal, high bandwidth view.

That all works, and I’ve used it since I heard about the low bandwidth view a few months ago. Still, it gets old – especially editing the URL the loband bit every time I’ve removed it.

Enter The Bookmarklet

Bookmarklets are great – they’re short Javascript functions that you bookmark, so you can run the Javascript on any page by opening the bookmark. They’re kind of like tiny Firefox addons. You can read more about bookmarklets, of course, on Wikipedia.

Well, after messing with that MSDN URL enough times, I figured it was time for a bookmarklet. So here it is: MSDN Low Band

It’s just a simple toggle – when you’re in the normal view, clicking the bookmarklet will switch you to Low Bandwidth view. Clicking it again will return you back to the normal view again. In Firefox / Opera / Safari, you can just drag that peachy colored button to your Links toolbar. In Internet Explorer, you’ll need to right click the link and select “Add To Favorites”, making sure to save to the Links favorite folder. I’ve tested it in IE, Firefox, and Safari.

The Delicious.com Bookmarklet installation help page has some nice screenshots and more information on installing Bookmarklets. If you’re interested in writing your own bookmarklets, I recommend you use a web based Bookmarklet helper page to simplify the grunt work, like this one.

So How Does It Work?

It’s really simple. At first I messed with the URL, but then I figured out that it was simpler to just modify the cookie and reload the page. Here’s the code, formatted so it’s easier to read:

javascript:
if(document.cookie.indexOf('LoBandEnabled=yes')<0){
  document.cookie='LoBandEnabled=yes;path=/;domain=.microsoft.com;%20expires=Wed,%2001-Aug-2040%2008:00:00%20GMT';
}
else{
  document.cookie='LoBandEnabled=no;path=/;domain=.microsoft.com;%20expires=Wed,%2001-Aug-2040%2008:00:00%20GMT';
}
window.location.reload();

Subtext 2: OpenID Login Support

The recent Subtext 2 release includes a feature I worked on: OpenID login support. Let’s take a quick look at how you use it, then we’ll talk about the how the code works and why it’s a useful feature.

What’s OpenID?

I’m a big fan of digital identity, and could ramble on about OpenID for a while. But if I did that, this blog post would be published sometime after Windows 7 ships. Fortunately I pushed OpenID on some people who are a bit more prolific than I’ve been of late, so I’ll refer you to this post by Jeff Atwood (CodingHorror) and this webcast by Rob Conery. Scott Hanselman wrote a great overview of OpenID, as well.

The elevator pitch: Rather than being issued an account at every single website you login to, you issue them one. You establish an OpenID URL, which only you can login to, and then you give it as your account information to sites which support OpenID authentication. You’re in control of your account, you’ve got a central place to manage your password, etc.

OpenID is a generic account that you can reuse on other websites.

Too Hard! Couldn’t I Just Fax Someone My Birth Certificate?

If you haven’t used OpenID, this is going to look complex. That’s because I’m showing you the hard case – it’s like learning to play Stairway To Heaven when you don’t have a guitar or amp. The first time through, we’re going to have to run down to the pawn shop to get you a Fender knockoff and a thrasher amp, but the next time you’re ready to rock you’ll be all set. So hang with me while we get setup, and at the end I’ll show you how it will work when you log in to your site tomorrow.

Step 1: Get an OpenID

There’s a good chance you’ve already got an OpenID, since many popular services like Flickr, Yahoo, and Blogger are OpenID providers, meaning that you can user your account with those services as an OpenID identity:

If you don’t have an account with any of those services (or these on the OpenID public providers list), I recommend signing up with MyOpenID.com – they’ve got great support, and rich security features if you want to use them, such as InfoCard integration and phone verification.

Step 2: Tell Subtext What OpenID URL You’ll Be Using

The Security / Options tab has a new location where you can enter an OpenID URL. It’s important that you get this right – we’ll try to clean this up for you, but I recommend you type this as exactly as possible. In my case, my OpenID URL is http://jongalloway.myopenid.com/, not jongalloway.myopenid.com. Even the trailing slash is important.

Note that to in order to make this setting, I’ve logged in to Subtext using my standard Subtext username and password. That login doesn’t go away when I setup OpenID authentication, I’ve just enabled an additional security feature – I’ve got two ways to login to my blog now.

Step 3: Login Using OpenID

Now that Subtext knows my OpenID URL, I can use it to login to the site. The login dialog includes an OpenID sign-in prompt at the bottom, so I enter my OpenID URL in the prompt and click Login.

Now here’s the part you may not be expecting if you haven’t used OpenID – I need to login at my OpenID provider. That’s not such a big deal, though, because myOpenID (and many other providers) have a “Stay Signed In” option option, which is appropriate if you’re logging in from a computer which is in a secure location (your home, a work computer you keep locked, etc.). The Versisign Seatbelt Firefox Extension is a pretty handy way to sign in to your OpenID identity once for a browser session, too.

Now, the first time I log in to myOpenID from my Subtext blog, myOpenID is going to ask me if that’s cool. Again, a little unexpected if you haven’t used OpenID before, but this is a one time thing. We’re telling myOpenID that my Subtext blog is going

So, I type in my password and click the Sign Button, and my OpenID provider redirects me back to my Subtext instance (with an “authenticated” message), and Subtext logs me in:

Fine. Now Show Me Easy.

Thanks for hanging in there. Here’s how it looks tomorrow, providing you’ve checked that “Stay Signed In” checkbox. First, we browse to the login screen, enter our OpenID URL, and click Login:

Now, we’re automatically logged in and brought to our admin screen:

If you hadn’t checked that Stay Signed On checkbox, you’d get one screen in the middle – the login page for your OpenID provider’s page.

How’s It Work?

That’s the subject of another post, but let me show you one quick screenshot which shows the HTTP traffic during that last login.

That shows the general sequence of events:

1. I requested the Login page (it’s running on my local machine – 127.0.0.1)
2. The DotNetOpenID login control makes a request to the URL I provided, saying “Yo. My URL is 127.0.0.1:2732, can you authenticate the user and verify that I’m on their list of sites?”
3. There’s a little negotiation between the two sites, after which myOpenID returns an “Okay” message via SSL.

Show Us Your Code

Sure. For this release, I just used the DotNetOpenID.OpenIdLogin control, which is as simple as dropping the control on the page and handling the LoggedIn event. Scott Hanselman wrote about this before when he set up OpenID on DasBlog. In the case of Subtext, here’s the code I added for that LoggedIn event:

protected void btnOpenIdLogin_LoggedIn(object sender, OpenIdEventArgs e)
 {
   e.Cancel = true; //required to prevent logging everyone in
   if (e.Response.Status == AuthenticationStatus.Authenticated &&
       SecurityHelper.Authenticate(e.ClaimedIdentifier, chkRememberMe.Checked))
    {
         ReturnToUrl(Config.CurrentBlog.AdminHomeVirtualUrl);
    }
} 

You can see it in context in the Subtext SVN browser. Now that I’ve worked with it, I’d like to ditch the OpenIdLogin control for a future release. It works just fine, but it generates HTML that I’m not very happy with (table based markup, not CSS friendly). In the future, I’d probably write my own control and just use the libraries which are included in DotNetOpenID – they’ve been great.

OpenID Passthrough

There’s another new OpenID feature in Subtext 2.0 – OpenID Passthrough. The idea there is that you can use your blog URL as your OpenID URL, and it just redirects over to your “real” OpenID provider. Let’s assume that my blog was deployed to http://jongalloway.com; in that case I could make the following OpenID Passthrough settings on the Subtext / Configure screen, after which I could use http://jongalloway.com as my OpenID URL.

Upgrading to Visual Studio 2008 / .NET 3.5 SP1

Have your Visual Studio Installation Media Handy

I was prompted for the original installation media both when uninstalling the SP1 Beta and when installing the SP1 RTM. The file it’s looking for is vs_setup.msi in most cases, but they’re not all created equal. If you installed from a Visual Studio 2008 Professional DVD or image, you can’t just insert a Visual Studio 2008 Standard DVD. In my case, I installed of in ISO image, so I mounted the iso file (en_visual_studio_team_system_2008_team_suite_x86_x64wow_dvd_X14-26461.iso) as my F:\ drive and browsed to vs_setup.msi.

You don’t need it yet, but you don’t want to get half way through the upgrade and realize your install media is back at home, or that you deleted the ISO file and you have to wait for the 4GB download. Got the install media? Great, onward!

Use the Visual Studio 2008 Service Pack Preparation Tool

I think the biggest tip here is to use the Visual Studio 2008 Service Pack Preparation Tool. The original help information SP1 Beta (since updated) had a long, involved un-installation process, so people who’d had to uninstall that before figured we’d have to go through that process again. I had to a month ago, and it didn’t go very smoothly for me – probably due to some internal, pre-release builds of Silverlight 2 I’d installed at the beginning of the year. I ended up having to uninstall everything developer related to fix a Silverlight Package Load Failure error.

So – that’s all been simplified now, and in most cases it sounds like it’s working great. I ran it on two of my computers (which have been littered with alpha and beta stuff) and the Visual Studio 2008 SP1 install ran flawlessly. I’ve been listening on Twitter, and it’s been a smooth upgrade for most people (notable exceptions: Rick Strahl, Sam Gentile).

Heath Stewart's post on the Service Pack Preparation tool indicates that the SP1 install will block says the SP1 install if you've installed the SP1 beta at any point, so the main reason I'm calling the Service Pack Preparation Tool out here is to save you from going through an unnecessary manual install only to get the prompt indicating that you still need to run the Service Pack Preparation Tool.

According to Heath:

The tool will verify Visual Studio integrity and remove previous Visual Studio 2008 updates or pre-release software

• Microsoft Visual Studio 2008 - KB945140 (Beta)
• Microsoft Visual Studio 2008 - KB944899
• Microsoft Silverlight Tools Beta 1
• Microsoft Visual Studio 2008 - KB949325

So if you've never installed any of those betas you don't need to run the prep tool, however based on my experience installing Visual Studio over the years, I like the sound of "verifying Visual Studio integrity" before installing. I'd expect that the tool would run really quickly if you haven't installed the beta.

So, I'd recommend that you grab the Service Pack Prep Tool and let ‘er rip!

Allow some time for the Service Pack Prep Tool - it took 45 minutes on one machine, and others have reported that it ran for 8 hours or more. For those reasons, you might want to take some precautions to make sure you don't have a prompt holding up your install if you're going to be away from your computer while it's running. Here are a few tips there:

1. As I mentioned before, you should expect to see a prompt for the installation media during the uninstall. If you can insert the media into the same drive you installed from in the first place (easy if you installed off a DVD drive, not so easy if you just attached an ISO file), you won't have to watch your computer for the media installation prompt.
2. There's a check for process which will require a reboot when you're done. If you're going to be away from the computer while, I'd make sure to shut down your browsers and the Vista Sidebar (not sure why, maybe uses managed code).

Running the Visual Studio 2008 SP1 Installer

There are four installs listed on the Visual Studio 2008 Service Pack 1 (SP1) and .NET Framework 3.5 SP1 Downloads page:

• Visual Studio 2008 SP1
• .NET Framework 3.5 SP1
• Visual Studio 2008 Express Editions with SP1
• Visual Studio Team System 2008 Team Foundation Server SP1

The Visual Studio 2008 SP1 install includes .NET 3.5 SP1, so that'll do it. Again, be ready for that installation media prompt and the incompatible processes check.

Reinstalling The Silverlight Tools

The Service Pack Prep Tool removes the Silverlight Tools (as it should) so you need to reinstall those when the SP install completes. They've just updated the Silverlight Tools installer (silverlight_chainer.exe) in-place, so you can grab it from the same location it's always been at: http://www.microsoft.com/downloads/details.aspx?FamilyId=50A9EC01-267B-4521-B7D7-C0DBA8866434. Tim Heuer's got more information on Visual Studio 2008 SP1 and Silverlight Tools.

Great - So What Did I Just Install?

I think some of the most interesting features are ASP.NET Dynamic Data, Entity Framework, ADO.NET Data Services (REST based), XBAP and ClickOnce support for Firefox, the Client Profile (24MB lightweight .NET framework which is makes it easier to distribute .NET applications to users who don't have the .NET framework installed).

There's a lot more, though. Rather than writing up "yet another SP1 feature list" I'll point you to a few which I've found helpful:

First off, you didn't install ASP.NET MVC, although you got a building block (System.Web.Routing - similar to URL Rewriting, but it's bi-directional). Phil Haack explains it all in a post titled (oddly enough) ASP.NET MVC Is Not Part of ASP.NET 3.5 SP1.

ScottGu's out of the office right now; fortunately Scott Hanselman stepped up with good overview of what's in SP1.

Here's what changed from a performance point of view.

Dr. Tim Sneath wrote a great post on the WPF enhancements in SP1 from when the Beta was released.

Here's the overview at MSDN: Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1

If you want the point by point list, take a look at the following KB articles:

• 950263 List of changes and fixed issues in Visual Studio 2008 Service Pack 1
• 951845 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for Team Editions
• 950264 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for Express Editions
• 951847 List of changes and fixed issues in Visual Studio 2008 Service Pack 1 for the .NET Framework 3.5

And if you really want the low level details, Patrick Smacchia used NDepend to show exactly which classes changed in SP1.

ASP.NET Themes Don’t Like IE8’s X-UA-Compatible header; Neither Do I

Summary

I ran into an interesting issue a few months ago with IE8 support on sites which use ASP.NET Themes. I’ll talk about the issue and how to fix it. More important, though, I’ll talk about how this small example fits into the whole IE8 / X-UA-Compatible thing, and why I think the way that turned out was bad for everyone.

The Problem: That First Meta Tag

If you’ve got a page that doesn’t render correctly in IE8’s new standards mode, you can add a meta tag to the page which requests that IE8 render it in IE7 mode. The problem I ran into would have been comical if the timing had been better:

• IE8 only recognizes the X-UA-Compatible header if it’s the first META tag, appearing immediately after the <HEAD> tag
• The ASP.NET Theme system writes out the theme CSS reference immediately after the <HEAD> tag

Of course, the reason I know that is that I needed to emulate IE7 on a page which was using ASP.NET themes. Video.Show was released in November 2007 and was tested on Firefox 2, Safari 3, and Internet Explorer 7. We built a demo for the MIX 08 conference which ran on the a Pre-Beta 1 release of IE8. Back then, you had to opt-in to super-standards mode, so our IE7 capable markup did just fine. Here’s how that page looked:

A little while after that, IE8 Beta 1 came out. One of the significant changes in Beta 1 was that IE8 would render your page in standards mode unless you specifically opted out. That was important to us because our client on that project wanted to be able to use the Video.Show demo we’d built for him, and it didn’t work well in IE8 Beta 1. Here’s how it looked:

The most obvious problem here is that the page background was messed up. The page structure is a bit complex due to the expanding banner at the top, and IE8 calculated that the page header extended to the bottom of the expanding  banner area. Also, the navigation links below the header were showing in a vertical line rather than floating left in a horizontal row. We had a very short turn around time for this project, and the IE8 display quirks weren’t well documented at that time, so tried just adding that fancy new X-UA-Compatible header:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head  id="Head1" runat="server">
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="shortcut icon" href="favicon.ico" />
    <script type="text/javascript" src="Javascript/silverlight.js"></script>
    <title>Video.Show</title>
</head>
<body>[...]</body></html>

However, here's what was actually rendered:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head id="Head1">
    <link href="App_Themes/Default/DefaultStyle.css" type="text/css" rel="stylesheet" />
    <meta http-equiv="X-UA-Compatible" content="IE=7" />

 content="IE=7" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="shortcut icon" href="favicon.ico" /><link rel="stylesheet" href="css/lookDefault4.css" type="text/css" />
    <script type="text/javascript" src="Javascript/silverlight.js"></script>
    <title>Video.Show</title>
</head>
<body>[...]</body></html>

IE8 didn’t recognize the X-UA-Compatible header because the ASP.NET Themes engine always writes out the CSS link as the element in the head section.

How I Fixed It: A Custom Response Header in IIS7

Since I was setting this up in a virtual machine for demo purposes, I could easily make server changes. Here’s how I added that header in IIS7:

The IE blog has links to instructions on setting those headers various servers:  IIS7.0, IIS6.0, Apache 2.2, Apache 2.0, Apache 1.3. So, yeah, it works, but it’s not perfect. For one, it sets that header for all pages in the site. But, more concerning – what would I have done if I wasn’t able to make changes to the server configuration? If you’re running under IIS7, you can tweak headers with a change to your web.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name="X-UA-Compatible" value="IE=EmulateIE7">
      </customHeaders>
    </httpProtocol>
  <system.webServer>
</configuration> 

Otherwise, you can code your way around it with an HTTP Module or something, but the point is that the solution’s so simple anymore. All that brought me back to the X-UA-Compatible conversation from several months ago.

X-UA-Compatible: One Developer’s History

One of the big changes in IE8 is a major shift in the method of selecting the rendering mode for a particular file. The DOCTYPE switch was born a decade ago, and made sense at the time – it used an opt-in model which assumed that a page with a valid DOCTYPE knew what it was doing, so browsers would render the page according to the latest browser standards. It seemed to make sense, but there was trouble in DOCTYPE paradise:

Unfortunately, two key factors, working in concert, have made the DOCTYPE unsustainable as a switch for standards mode:

1. Egged on by A List Apart and The Web Standards Project, well-intentioned developers of authoring tools began inserting valid, complete DOCTYPEs into the markup their tools generated; and
2. IE6’s rendering behavior was not updated for five years, leading many developers to assume its rendering was both accurate and unlikely to change.

And so, the IE8 team came up with what most folks would agree is a good idea: opting-in to “standards mode” itself is meaningless unless you specify which standards you’re opting-in to. Targeting “web standards” is great as a platonic ideal, but in reality our pages are rendered by specific browser versions. It’s a lot more practical to opt in to a specific browser version’s rendering mode than a mythical and fluid “standards” mode.

But, then, there was question: since IE8 will be entering a world already populated by billions of web pages written over the past dozen or more years, how should it handle them? Thus began a comedy of errors.

Proving That All Of Us Is Dumber Than Any Of Us

How it’s remembered:

The IE team first announced that it would require pages to opt-in to IE8’s “super-duper standards mode”. The web development community loudly protested, and the IE team changed the default behavior so that pages would be rendered in “super-duper standards mode” by default. We all won!

Here’s what actually happened:

1. The IE team had it right the first time. There are billions of webpages out there which won’t work well in IE8 without changes.
2. The IE team forgot that the web development community, by and large, hates them so much that… I don’t even know how to describe it.
3. The web development community reacted to IE team’s announcement the way they react to just about (except improved CSS support) that the IE team announces. They protested loudly.
4. The IE team decided to switch it up a bit and did what the web development community was telling them they wanted, and quickly to boot.
5. We all lost, but almost no one’s admitting to it.

I know this is all old news – Joel Spolsky wrote about this in March. His post was way too long, but the basic idea was that an idealistic solution isn’t all that useful because people don’t install browsers that can’t display their favorite sites. A lot of people disagreed, using two different arguments:

• “It’s not easy, but we have to try to do the right thing” – I agree with the intentions, but I’m cynical here. Users (and IT shops) are still stalling on the upgrade from IE6 to IE7, even though IE7 was a relatively minor upgrade.
• “IE is irrelevant” – These responses were popular in the web standards community, but were themselves irrelevant. Okay, all your friends are running Firefox 3 on their Macbook Air’s, but the browser stats show that IE is still the dominant browser by a large margin. Unfortunate facts are still facts. If you’re hoping that real people will actually use your sites, you have to care about how IE8 works.

Fix Your Pages! Also, Let Them Eat Cake!

I’ve heard a lot of people say that this is a good time for us all to just get this over with and move on. After all, you’ve got several options:

1. Fix your pages. While I’ve been working with IE8 Beta 1, this is a little easier said than done – there are several IE8 regression bugs which work fine in IE7 and below but fail in IE8. Sure, it’s beta 1, but my point is that this isn’t simply a case of “good HTML / CSS = perfect display in IE8” just yet. I’ve spent several days chasing down several of these bugs, for instance. But, sure, providing that IE8 is really good on CSS 2.1 support, this is the ideal solution. The underlying assumption is annoying, though – the idea is that IE8 is now the authoritative CSS reference. As of now, that’s not at all the case. In some cases my HTML and CSS are correct, work in FF2/3 and IE7 – so why should I have to “fix” them to render in IE8? Arguing that this pain is worthwhile because we’re “doing the right thing for the web” is only valid if we really are improving the HTML/CSS quality of the web, and I’m not convinced this does the trick.
2. Use the X-UA-Compatible header in your pages. This is listed as the standard response when people list cases where it’s not so easy to fix your HTML. The example above shows a case where a pretty new website built on a pretty modern web framework didn’t support that easily. Forget the case where the HTML is bundled in old CDROM’s or help files written out by installers – a web application built on ASP.NET 3.5 less than a year ago had problems with that approach.
3. Write the headers some other way. Sure, it was possible in my case, but depending on the site, the skill level of the developers working on the site and their access to the server configuration, this could add up to an unacceptable amount of time. Unacceptable as in “Sorry, we don’t support or recommend IE8 – please use IE7. Thanks!”

Granted, I’m testing with IE8 Beta 1 and IE8 Beta 2 is due out soon, so this situation could improve the situation for actively developed websites. But the operation of the X-UA-Compatible header seems to be pretty much set, and I don’t think it works well with the majority of the billions of HTML documents we’ve already created.

Upcoming Guests on HerdingCode: Rob Conery, Glenn Block, [your suggestion here]

We’ve done eight episodes of Herding Code in round table format, but we’ve always anticipated bringing on some guests once we had our act together. We’re excited about having Rob Conery as our first guest Tuesday night (7/15). We’ve also had a few folks tell us they’re willing to appear in future shows, including Glenn Block and Scott Bellware.

We’d love to hear you questions for these guest (especially Rob, since he’s confirmed for this week) as well as your recommendations for future guests. While you can always leave comments here or on the Herding Code site, the simplest way to give us feedback is by filling out this quick six question survey.

Speaking at the So Cal Code Camp on 6/29/08: Deep Dive Into Deep Zoom

I'll be speaking at the SoCal Code Camp in San Diego on Jun 29, 2008. My session’s titled Deep Dive into Silverlight Deep Zoom. We'll look at the code that runs the Hard Rock Memorabilia site, then build a site on the fly that takes advantage of Deep Zoom, including all the new features in Silverlight 2 Beta 2.

UPDATE: You can grab the slides from my talk here.

Our Round Table Podcast gets legit - Now we're the Herding Code Podcast (herdingcode.com)

We’ve been experimenting with a weekly technology round table podcast for the past five weeks; now we have our act together to the point where we’re ready to officially launch it. We’re at HerdingCode.com, and you can subscribe to our feed at http://feeds.feedburner.com/HerdingCode on your iPod, Zune, or whatever crazy podcast client you choose.

By we, I mean:

Head on over and give it a listen. On the current episode, we argue discuss whether Silverlight is just another flavor of ActiveX, or if it’s here to stay.

Herding Code 6: Silverlight - Fad Or Fab?

Jon's News Wrapup - June 25, 2008 Edition

Development Tools

Here's the grab bag of tools, development toolkits, etc.