DR. WEBSITE: Give Your Pages Real-Time Interactivity With Server-Side Includes

Server-side includes-also known as SSIs or just includes, for short-are a capability implemented on many servers that let you embed commands in an HTML file that are carried out when the document is served to a browser. In this way, you can offer dynamically generated data such as the current date or time, information about when a page was last modified, or signature files that you can automatically append to all your Web pages.

One of the benefits of using SSIs is that you can add real-time interactivity to your Web pages without requiring knowledge of JavaScript or CGI scripting. It's possible, however, to use SSIs to execute and include the output of a CGI script in a Web page-for example, to display an access counter showing how many visitors your page has received.

Before you can use SSIs, your Web server must be specially configured to allow them. Check with your server administrator or access provider to make sure this feature is supported. In some cases, you may be given access to some kinds of includes-for example, embedding a signature file in other files-while SSIs that execute scripts may be forbidden for security reasons.

SSIs appear in HTML documents within comment tags, beginning with <!-- and ending with -->. They follow a simple format as shown below:
<!--#command variablex="valuex" --> where #command is the include command that will be executed. Each command can take one or more variables (specific to that command), with values surrounded by quote marks. Here are some real-world examples:
<!--#echo var="LAST_MODIFIED"--> will display when the current document was last modified. (You can modify time/date formats with another SSI command, #config.)
<!--#echo var="DATE_LOCAL" --> will print the current date.

<!--#include file="sig.html"--> will display the contents of a file named sig.html at the place where this #include command appears in your current document.

Files utilizing SSIs may need to use a special file extension that is set up in the server configuration file, which is usually .shtml. But if your server is set up to implement SSIs in files ending with .htm or .html, then you won't need to use a special extension. Your server administrator can tell you if it will be necessary for you to change the file extension in your files that utilize SSIs.

There are a number of straightforward online guides to SSIs, including Matt Kruse's Server-Side Include Tutorial, the NCSA Server-Side Tutorial, and the Webcom Guide to Server-Side Includes.

FALLBACKS FOR JAVASCRIPT Dear Dr. Website®: I have wanted to use JavaScript in my site, but I know that a lot of browsers don't support it. How easy is it to detect whether a browser can handle JavaScript and, if not, to provide them an alternative?

In past columns, we've looked at how you can hide JavaScript scripts from old browsers by enclosing the body of your scripts within an HTML comment [see Dr. Website, Feb. 3]. You have a couple of additional options if you want to detect whether JavaScript is supported and send users to separate versions of your pages as a result.

You could even accomplish this using JavaScript-for example, you could load a page that, by default, relies on no special JavaScript scripting except for a short script that will load a JavaScript-enabled page. If the script runs, then JavaScript is supported and the fancy page is then loaded and displays. Otherwise, the plain, default version is the only one that displays.

Another approach is to use CGI scripting to detect the HTTP_USER_AGENT environmental variable, which indicates what browser is being used. If you've created several versions of your pages, you can use this browser information to then direct users with browsers that do not support JavaScript to pages that do not use JavaScript at all.