I posted yesterday about setting ASP.NET Browser control properties differently for different browsers by using device filtering syntax for setting the properties. I've received some questions via e-mail about that post so I wanted to follow up on some additional things I've found on this topic.


1) This can only be done declaratively. If you need to do this in the code-behind you'll need to use Request.Browser. Example:

switch (Request.Browser.Browser.ToLower())
{
    case "ie":
        if (Request.Browser.MajorVersion == 7)
            labelText.Text = "Hello IE7!";
        else 
            labelText.Text = "Hello IE (time to upgrade!)";
        break;
    case "firefox":
        labelText.Text = "Hello Firefox";
        break;
    default:
        labelText.Text = "Hello other browser";
        break;
}

2) There is no designer support. Don't expect to see this stuff in the intellisense. It won't be there, but it will work.

3) Not just for simple properties. This device filtering technique worked with every property I tried it with. In fact, it even worked in other unexpected ways as well, such as with templated controls. Take a look at the following example:

<asp:Menu runat="server" id="myMenu">
    <ie:Items>
       <asp:MenuItem Text="IE Item" />
    </ie:Items>
    
    <mozilla:Items>
       <asp:MenuItem Text="Firefox Item" />
    </mozilla:Items>

    <Items>
        <asp:MenuItem Text="Other Item" />
    </Items>
</asp:Menu>

Now that is pretty cool.

4) How it works. This didn't take too long to work out. A little bit of digging quickly showed how this all comes together because it works just how you would probably guess. The biggest question is "how do you know what device values you can use for filtering?". In the .NET Framework directory you'll find some config files showing how to behave and render controls for different types of browsers.

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

In that folder you'll see several config files named things like "ie.browser", "mozilla.browser", "safari.browser", "palm.browser", etc. In each of these files there are several "browser" elements, each with an ID. These ID values are what can be used to declaratively filter server control properties for the specific devices. Mind you, it's not just the names of the files, but the browser ID values contained inside. This means that you can get very specific about the targeted browser for a property value. Instead of just specifying "ie", you could use any of the following "ie", "ie5", "ie5to9", "ieaol", "ie4" and many many more. Also, you can edit these, or add an App_Browsers folder to your propject and place a new file named "something.browser" in it to define your specific browser capabilities.

5) It works with directives too! This was the one that blew me away. You can use it on directives as well! That means, control directives (to modify properties, attributes, templates, etc), page directives (to modify CodePage, MasterPageFile, Culture, Theme, etc), and master page directives (to modify CodeFile, Viewstate, etc). W-w-what? The following will set a separate master page for IE and Firefox and a third for all other browsers:

<%@ Page Language="C#" 
    ie:MasterPageFile="~/MasterPageIE.master" 
    mozilla:MasterPageFile="~/MasterPageFirefox.master" 
    MasterPageFile="~/MasterPageGeneric.master" 
%>

Freaky, I know.

6) Why use this? There are a lot of uses for device filtering with server control properties. Consider this. You have a simple page with a welcome label. It's a simple page so you don't really need a separate mobile version of the page. You could shorten that text easily for anyone on a PocketPC IE or Palm browser to account for the limited screen real estate.

7) You can disallow the use of device filtering in your custom controls if you want. If you build your own control and you don't want the consuming developer to be able to use device filtering with it's properties, you can mark the class with the Filterable(false) attribute and it will ignore the device specific properties that are set for the control.


Well, that is about all I know. I'm still just trying to cope with the fact that this has been there since ASP.NET 2.0 and I am just finding out about it now. Apparently, I'm not the only one since it was difficult to track down details on this.