I've finally gotten to a point in my Silverlight learning where I've been able to build something worthy of running on the actual Internet instead of just letting it incubate indefinitely inside Visual Studio.

Everything I've read about Silverlight deployment has made it seem pretty easy: copy the XAP and its host page; enable its MIME type in IIS. This, compared to creating SharePoint solution deployment packages in my last project, is trivial. And to me, it fits with other advantages of using Silverlight more pervasively in your web applications: no hacky HTML, no cross-browser considerations, no JavaScript / AJAX, etc.

Of course, there are still drawbacks to Silverlight: the anti "plug in" mentality of Internet users, the steep learning curve, and suppressing the urges to over-beautify, over-animate, and basically over-do your web apps simply because you can. These design principles are, however, a topic for another post.

The problem with my app was that the browsers (IE8, FF3, and Chrome) all displayed a 20 pixel-wide padding of whitespace around the content region of the Silverlight control. After everything I just said about Silverlight alleviating the need to worry about such browser issues, this happened!

Here's what it looked like: (The large, outermost square is the browser window itself)

Now being the humble developer that I am, I assumed I was doing something dumb. But after a quick check for any superfluous boarders, extraneous resolution-corrective scaling, or inadvertent whitespace, (and the fact that this behavior was fairly consistent across all browsers) I had to dig a littler deeper than mere bad XAML

My first suspicion was with respect to how my ASPX page was hosting my Silverlight content. In Visual Studio, there was no mysterious padding, and my project has being hosted via an HTML page. This meant that there were div tags, an object tag, and some Javascript controlling how and where the plug in would be rendered on the page.

On my server, however, I was using the ASP.NET Silverlight control to handle all of this in one line of markup. I assumed that this is what was causing the padding. However, copy-and-pasting the HTML from the source of my test page to my prod site didn't change anything.

But the next thing I noticed ensured me that this wasn't Silverlight's fault. When you right click over Silverlight content, you get a context menu with one option that opens the plug in's configuration window. When happened in my situation was right clicking over the erroneous padding gave me the browser's context menu, not Silverlight's!

When the markup hosting your plug in (via either the HTML or ASP.NET methods) has 100% height and width, Silverlight's content region should be allowed to take up the entire page. But the fact that I could see the browser's context menu meant that this wasn't being respected, interestingly enough, in any browser.

So that's a show-stopper; the issue is somewhere inside the Silverlight plug in itself, rather than my XAML or the HTML that hosts it. In other words: nowhere where I could fix it.

So to get it work, I had to get into the HTML of the host page. Here is the markup that was causing the padding:

And here's what I did to fix it:

Adding the div tag on Line #3 allowed me to position the Silverlight control more explicitly. So in the style, I told it to scoot itself up and to the left 20 pixels. I experimented with absolute positioning, but the coordinate systems didn't match up; the control was shoved over to right and was being arbitrarily cut off on it's right and bottom edges. So I went with relative positioning, which moves the control relative to it's native spot on the page.

The only problem is that I now had even more white space on the bottom and right edges of the screen, which normally wouldn't be a problem, but my control has animations the fly in from both places. So looking at Line #4 from the second code blocks shows how I handled this: making the height and width each 110%.

Now, the control renders as expected. But there's still an issue: upping the dimensions over 100% shows scroll bars on both axis of the browser window, allowing the users to scroll, and thus reveling my hack. But you know what? Meh. Although this is not in the least an acceptable comprise for any production system, it doesn't really take anything away from the user experience – something Silverlight (being a RIA technology) is all about. I'm sure I can continue to play around with the positioning and the sizing of these HTML elements, but the gain won't be worth it – especially for just my personal website.

So the lesson here is that although Silverlight takes away the onus of dealing with HTML, it is still ultimately dependant on it. Have fun!