 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
 |
|
|
|
 |
 |
||
|
Go MAD for ASP.NET with Graymad!
By G. Andrew
Duthie
Author, Microsoft ASP.NET Step By Step
and founder of Graymad Enterprises, Inc.
Dynamic Style Sheets with Request.Browser and User Controls
Does your site use Cascading Style Sheets (CSS) to format text and/or provide a consistent look and feel for your Web site? If not, why not? Probably because you need to support multiple browser types, each of which has differing levels of support for CSS. This means that it's very difficult to create a .css file (used for creating linked style sheets...for more on CSS, see http://www.w3.org/Style/CSS/) that will provide a consistent look and feel across multiple browsers such as IE 5.5+, Navigator 6.x and especially Navigator 4.x or earlier, where support for CSS is limited.
In a Web developer's ideal world, all users would always use the latest browsers, and they'd all upgrade simultaneously, allowing us to develop for a single browser. And while Microsoft has made strides in getting folks to upgrade to the latest version of Internet Explorer, there are still enough folks out there using other browsers that it's important to make sites look good with as many as you can. In this article we'll look at how you can use the Browser class, which is built into ASP.NET and exposed as the Browser property of the Request object, to dynamically link to one of multiple .css files, to best support the browser of the current user. Even better, we'll see how you can encapsulate the browser detection and dynamic selection code into a User Control, to make it easier to reuse across your entire site.
The Problem
Because not all CSS styles work equally well in all browsers, it is often difficult, if not impossible, to create a single style sheet that both gives you the look you want, and also renders properly in all of the browsers you choose to support. WebReview.com has a chart showing the various CSS1 features, and which browsers support them (and how well). As the chart shows, if you have clients running Netscape Navigator 4.x, or IE 3.x, the chances are very good that you'll run into some CSS feature that is either not supported or buggy. For example, the drop cap style used in the first paragraph of this article works great in IE 5+ or Navigator 6.x (see figure 1), but does not render well in Navigator 4.x (figure 2).
Figure 1: BrowseCapUC.aspx rendered in IE 6.x
Figure 2: BrowseCapUC.aspx rendered in NN 4.x
As you can see from the figures, the drop cap renders nicely in IE, but is riding over the text in Navigator 4.x. So what to do?
The Solution
Thanks to ASP.NET's built in support for easily querying browser capabilities (and version information, of course), you can simply query the version of the browser making the request, and return a style sheet that is appropriate for the browser or browser level. Of course, this is something that's also possible with classic ASP, albeit with a separate component. What's special about doing it in ASP.NET is that ASP.NET's support for User Controls makes it especially easy to reuse this solution in all your pages. By managing the selection of style sheets in a user control, it is much easier to maintain this logic. For example, if you need to add support for a new browser (or enhance support for an older one), you can make your changes in a single location, rather than in every page.
The Code
First, let's look at the original CSS code used to create the drop cap style, which is created as a .class-type style:
Styles.css
|
.dropcap |
The style sheet is linked into the page using a <link> tag, which is placed in the <head> section of the page, as shown below:
|
<head> <link href="StylesNS.css" type="text/css" rel="stylesheet"></link> </head> |
Then we use a <span> tag with the class attribute set to the name of the defined CSS class to apply the style:
| <span class="dropcap">D</span> |
The problem in this case is that Navigator 4.x is buggy when it comes to the margin-right style, and doesn't implement the margin-bottom style at all. Fortunately, all we need to do to correct this problem is remove these two styles, as shown below:
StylesNS.css
|
.dropcap |
Once we've removed those styles, Navigator will render the drop cap without riding over the paragraph text. But now we need a way to substitute the StylesNS.css style sheet for Styles.css when a visitor is using Navigator 4.x, while still providing the original style sheet for uplevel browsers. This is where the Browser object comes in.
Using the Browser Object
The Browser object is exposed as a property of the Request object, which in turn is exposed as a property of the Page and Control classes, which means we can easily access it from both ASP.NET pages and user controls by using the syntax Request.Browser. The Browser object is actually an instance of the HttpBrowserCapabilities class, which exposes properties that indicate which features the requesting browser supports. The properties exposed include:
- ActiveXControls
- AOL
- Beta
- Browser (gets the browser string)
- CLR Version
- Cookies
- Frames
- JavaScript
- MajorVersion
- MinorVersion
- Tables
- VBScript
- Win32
Most of the properties return boolean values indicating support for a particular feature, while a few (such as the Browser, MajorVersion, and MinorVersion properties) return string or integer values.
To make our solution as reusable as possible, we'll create a user control that chooses the correct style sheet based on the browser type and major version number. If the browser is IE and the version is 4.x or greater or if the browser is not IE and the version is 5.x or greater (we're assuming this means Navigator 6.x. While this is not necessarily a valid assumption, for purposes of this example it simplifies the code), we'll use the original style sheet. If the browser is IE and the version is less than 4.x or if the browser is not IE and the version is less than 5.x, we'll use the modified style sheet. The user control code is shown below:
BrowserCheck.ascx
|
<%@Control %> |
To use the BrowserCheck.ascx user control, we need to add two things to our page...an @ Register directive to set up the tag we'll use, and the actual user control tag itself. The @ Register directive, which should be placed at the top of the page (just below the @ Page directive, if there is one), is shown below:
|
<%@Page Language="VB"
%> <%@Register TagPrefix="graymad" TagName="BC" Src="BrowserCheck.ascx" %> |
The TagPrefix and TagName attributes can be anything you want them to be, as long as they combine to create a tag that is unique on the page. Practically speaking, you should probably use a consistent TagPrefix for all user controls (and custom server controls, for that matter) in your application, and use the same TagName for a given user control across all pages in the application. This will make your code more maintainable in the long run.
The actual tag will replace the <link> tag in our earlier example, as shown below:
|
<head> <graymad:BC runat="server"></graymad:BC> </head> |
Note that if you have a user control that you want to manipulate programmatically at runtime (for example, if your user control has properties), you should also add an id attribute to the tag declaration, with the value set to a unique name by which you can refer to the control at runtime in code.
The Result
Once the user control is in place, requesting the page from a Navigator 4.x browser will result in the modified StylesNS.css style sheet being linked to, and the drop cap will render without riding over the paragraph text, as shown in figure 3.
Figure 3: Corrected Rendering of CSS in Navigator 4.x
Conclusion
In this article, we've seen how the Browser object and ASP.NET User Controls make it simple and straightforward to dynamically link style sheets or perform other actions based on the browser being used by the client requesting a page. I use this technique in all of my CSS-enabled sites, including http://www.graymad.com/, to make the sites render as consistently as possible across the major browsers and versions. But the technique is not limited to style sheets. If your site uses client-side script, ActiveX controls, or client-side .NET controls, the Browser object can be invaluable in determining whether the client browser supports the desired feature. Once you've determined the support level, you can then decide what to do if the desired support isn't there, such as display a message recommending an uplevel browser, or rendering alternate content.
Our sponsors support AspAlliance, so please support them!
Take a moment to visit and see what they have to offer.