Visual InterDev

Creating Portable Script

See Also

If you are writing a Web application for use on a corporate intranet or for another known environment, you can usually rely on the features of a specific Web browser.

However, if your application will be accessible by users who can choose their own browser, you must be careful to write an application that works well with as many browsers as possible.

When creating applications that are as browser-independent as possible, you must be able to:

• Identify the browser that the user is using and what capabilities it has.
  
  
• Create scripts that run on different browsers. Alternatively, you can provide a graceful way to accommodate browsers that cannot support all features in your application.

Note   When you create a new Web page in Microsoft^® Visual InterDev™, one of the properties you can set for the page is the DTCScriptingPlatform property. This property does not perform any checking or otherwise prevent you from creating scripts that are incompatible with a specific browser.

The DTCScriptingPlatform property just alerts the editor to whether you are writing scripts for Microsoft^® Internet Explorer 4.0, and if so, it tells the editor to display Internet Explorer 4.0 objects when completing script statements.

Identifying Browsers and Browser Capabilities

You can use various properties and objects to get information about what browser the user is currently using.

To get browser information in client script

• Query properties of the window's navigator object.

  For example, the following client script displays the name of the current browser:

  <SCRIPT LANGUAGE="VBScript">
  Sub Button1_OnClick()
     MsgBox "Current browser is " & window.navigator.appname
  End Sub
  </SCRIPT>
  

In server script, you can get basic information about a browser from the HTTP header and find details by using a bundled component.

To get basic browser information from the HTTP header in server script

• Use the ServerVariables collection of the server's Request object, and query the value of HTTP_USER_AGENT.

The value of the HTTP_USER_AGENT variable is a string that lists the compatibility, name, and version of the browser. For example, this script displays the capability of the browser that requested the page on which it appears:

<% browser = Request.ServerVariables("HTTP_USER_AGENT")%>
<H1>Browser Identification</H1>
<P>Your browser identifies itself as:</P>
<%=browser%>

To get information about specific capabilities of a browser in server script

• Create an instance of the BrowserType object, and then query its properties.

For example, you can determine whether a browser supports frames, or whether it supports VBScript. The following example uses the BrowserType object component to display the current browser's capabilities.

<% Set bc = Server.CreateObject("MSWC.BrowserType") %>
Browser: <%= bc.browser %><BR>
Version: <%= bc.version %><BR>
Supports frames?
   <% If (bc.frames = "true") then %>
      Yes<BR>
   <% Else %>
      No<BR>
   <% End If %>
Supports tables? 
   <% If (bc.tables = "true") then %>
      Yes<BR>
   <% Else %>
      No<BR>
   <% End If %>
Supports background sounds?
<% If (bc.BackgroundSounds = "true") then %>
      Yes<BR>
   <% Else %>
      No<BR>
   <%   End If %>
Supports VBScript?
   <% If (bc.vbscript = "true") then %>
      Yes<BR>
   <% Else %>
      No<BR>
   <%   End If %>
Supports JavaScript?
   <% If (bc.javascript = "true") then %>
      Yes<BR>
   <% Else %>
      No<BR>
   <%   End If %>

Information about specific browser types is maintained on the server in the Browscap.ini file. The content of the Browscap.ini file determines what properties are available to the BrowserType object. For more information, see the Active Server Pages documentation.

Creating Browser-Independent Scripts

Unless you know what types of browsers your users will be using, you should anticipate a wide variety of browsers and create scripts that run on as many browsers as possible.

To make your scripts browser-independent

• Avoid using features, such as specific objects, that are available on only certain browsers.

  –or–

• Allow users to specify what content they want to see.

  –or–

• Test for specific browser capabilities and use branches around sections of script that a specific browser might not support.

Tip   A simple way to target specific browsers is to create two (or more) versions of your Web pages. Based on querying the user's browser (or by asking the user explicitly), you can provide separate pathways through your application, with each pathway containing pages compatible with the user's browser.

Avoiding Browser-Specific Features

Specific browsers make different object models available, although there is often overlap in the object models between browsers. For example, Microsoft^® Internet Explorer 4.0 supports Dynamic HTML (DHTML), which allows you to add animation and text effects to your Web pages. However, DHTML features are not necessarily available in all browsers, so if you use these features, you must ensure that users with different browsers don't try to view pages with DHTML pages.

For details about what objects you can use with specific browsers, see the documentation for your browser. For information about the Microsoft Internet Explorer 4.0 object model, see Dynamic HTML.

Allowing Users to Specify Content

You can ascertain the capabilities of a user's browser in your script, but you cannot determine other factors, such as modem speed, that can affect a user's experience with your Web site. Allowing users to specify the type of content they want to receive has the advantage of putting control in the users' hands.

To allow users to specify content

1. Use a form or dynamic link to query the user's preferences. For details, see Gathering Information Using Forms and Sharing Dynamic Information.
   
   
2. Store the preferences in a server session variable or cookie. For more information, see Sharing Dynamic Information.
   
   
3. Use branches to display or include user-specific information. For more information, see Writing Reusable Script.

For example, the following two links allow a user to specify a display preference.

<A HREF="setpref.asp?type=basic">Basic Display<A>
<A HREF="setpref.asp?type=rich">Rich Display<A>

The script in Setpref.asp sets a Session object variable to the store the user's preference:

<% Session("type") = Request("type")
Response.Redirect "home.asp" %>

Script in your pages can check the setting of the Session object variable to determine how to display your content:

<% If Session("type") = "rich" Then %>
        Display Frames, Tables, and Images.
<% Else %>
        Display text only
<% End If %>

Testing for Browser Capabilities

You can also use logic within a script to make specific features available. For example, the following script tests whether a browser supports JavaScript. If so, it inserts a small script that jumps to the home page. Otherwise, it inserts HTML text that displays a jump for the user to click.

<% Set bc = Server.CreateObject("MSWC.BrowserType") %>
<% If bc.JavaScript = true then %>
   <SCRIPT LANGUAGE="JavaScript">
      top.location.href = "home.asp"
   </SCRIPT>
<%Else%>
   Click <A HREF="home.asp">here</A> to return to the home page.   
<%End If%>

You can combine a test of the browser with a server #INCLUDE directive to display entirely different pages to the user. The following script tests the browser. If the browser is compatible with Microsoft Internet Explorer 3.0 or higher, it includes a page with various color options. Otherwise, it includes a more generic page.

<% browser = Request.ServerVariables("HTTP_USER_AGENT")%>
<%If browser = "Mozilla/2.0 (compatible; MSIE 3.0B; Windows NT)" Then%>
    <!--#INCLUDE FILE="/myapp/ColoredTable.asp"-->
<%Else%>
    <!--#INCLUDE FILE="/myapp/PlainTable.asp"-->
<%End If%>