Back to the land of browser inconsistencies :¬(

I had such high hopes for the silverlight plug-in.  Cross-browser incompatablities can be the most time consuming areas of web development, so a browser plug-in overcomes these by sandboxing the application so it handles all of it's rendering internally

Or so I thought.  Having developed all my silverlight under Internet Explorer, everything renders fine with the default 100% heights and widths.  Rendering the controls is important for templated controls and the loaded event only fires when the control is rendered and the loaded event is important in order for the control to pipe up and accept some data from the dartabinding process. 

To my amazement, and slight relief, Firefox actually requires a fixed height in order for it to render.  By default, you are given a silverlight plugin, set to 100% height and width, wrapped in a div with a height : 100% style attribute.  Just change the containing div to a fixed height and your controls now render fine in Firefox :¬)

so from this

to this

<asp:Silverlight ID="Xaml1" runat="server" Source="~/ClientBin/NavTeqBannerMain.xap" MinimumVersion="2.0.31005.0" Width="100%" Height="100%" InitParameters="ctlid=SilverLightBanner" />

</div>

It's fair to says IIS7 has some differences when compared to IIS6 (Well, Duh!)

The one I found most difficult to get my head around was the Wildcard Handler Mappings.  Traditionally, we wrote the handler in .net, or used the global.asax file to map the requested re-written URL to a pgae in the application.  IIS6 had the option to specify whether or not the file exists.

For example, you request http://www.creative-jar.com/News.  There is not physical file called News in the root, and even if there was, there's no extension on the file in the URL so IIS wouldn't know which dll to map it to, generating a 404 beacuse the file isn't found.  So, you set the WildCard handler to NOT verify that the file exists, before passing it to the handler to do it's magic

It's this Verify File Exists option that's missing in IIS7, causing the 404 to fire before your handler even get's a bite of the apple.

I found a good post on the subject here.  It explains the extra steps you need to get IIS7 not verifying files in your web application, instead just passing the whole request to your app and let it carry on as normal.  The post links through to an open-source UrlRewriting HttpHander called UrlRewriter.NET which has such a simple setup, it's untrue.  It currently uses a section of the web-config to work out it's mappings but, being that it's open-source, you can change it to collect from wherever you like

enjoy :¬)

It is assumed that when we apply a background image to an input field that it is fixed. This is the case when short amounts of text is inputed, but once you type more than the length of the field in Internet Explorer, the background starts to move along with the text. Unfortunately, a simple background-attachment: fixed does not fix this problem.

Here is an example of what happens:

A work around which I stumbled upon is to wrap the input field in a DIV and apply the background to this, whilst making the input field’s background transparent. Your code should look like this:

#input_wrapper {
    width: 180px;
    height: 26px;
    background: url('input_bg.png') no-repeat top left;
}

input.search {
    width: 156px;
    height: 16px;
    background: transparent;
    border: 0;
    padding: 5px 12px;
    margin: 0;
}

This is tested in Internet Explorer 6+ and Firefox.

Though it may seem a simple technique to give a website a background image and centering it to the page with background: url('image_url_here') no-repeat center top, it doesn't always work out the way you want it to.

Whilst working on a client's website which required a very wide centered background and the page container to be 1024px wide, I found that once you made the browser window smaller than 1024px wide, the container made the page scroll horizontally like it should, but the background image kept shifting, centering itself to the browser window and therefore not lining up properly with the content.

Strangely, this problem was occurring in every browser except Internet Explorer 6 and 7, and after many attempts with Javascript functions and CSS expressions, a simple solution we found was to add min-width to your html and body CSS. By doing this, once the browser window reaches smaller than 1024px, the page will scroll horizontally, the background image will stop shifting and still line up with the content.

An example of how your CSS should look like is this:

html {
    min-width: 1024px;
}

body {
    min-width: 1024px;
    background: #FFFFFF url('/media/images/background.jpg') no-repeat center top;
}

Came across an interesting bug on one of my client's sites the other day. She was having problems with a link being pushed off her screen. So following the basic diagnosing a problem rules, I found out she was using Firefox. Checked that it was fine no problems. So naturally asked her to provide a screen shot. Snap shot below.

As you can see this was most strange as her browser had added in all this additional formatting around the phone number, causing the email link to be pushed out. Naturally this intrigued me to find out what was causing it, so after looking on several forums found out that it was a Skype Plug-in on Firefox. So basically when you browse a website and see a phone number on the site, the Skype extension automatically converts it into a button that you click to call the person using Skype. Although quite handy for some, very annoying for others, and looks like Skype secretly install it without you knowing.