COM271, Week 2

Linking to External Files, Script Libraries, and Style Sheets; Server-side Includes

Syllabus | Table of Pages | Assignments | References and Useful Links

Modular Web Pages

The idea of modularity brings together three principles behind intelligent web design. As designers, we want to be expedient, learning to write and update code as efficiently as possible. We also want our pages to download as quickly as possible. Finally, we want to separate content, layout, and scripts so that they are easy to locate and work on.

We can build better—expedient, updatable, and well-structured—pages by learning to use links and external files. That is, when pages have common parts (usually, a navigation menu, a banner, and a footer) and common styles (identical rules for major elements throughout the site), or common scripts (e.g., for validation of forms), we want to write separate files for these page parts, styles, or scripts, and then have them brought into the page.

Why would we not just copy the same elements into each new page? We could start with a master page that had the common banner, footer, script, and style, and then just save it under a new name with different content and a few changed headers, couldn't we? Many sites do this. But ask yourself, if you build a site with 30 pages, and on each page there is a footer listing the name of the department chair and her telephone number, what do you have to do when there is a new chair with his own phone number? You could spend a couple of hours changing 30 pages. But if you had a means to make the footer a distinct file, and then to bring copies of that file onto each of the 30 pages, you could make all of the desired changes by changing only one page. Or, if you have 200 pages in a site for a corporation that decided to change its background page colors from blue to orange, you could either change style sheets on 200 pages, or change a single style sheet that was linked to each page in the site. So, are you motivated to learn how to include or link to files? You should be: that's the way it's done by professionals.

Links to External Style Sheets

As we'll soon learn, styles can be applied to any page element through the html style attribute or through a list of rules (="style sheet") built within an html style element. Once you have settled on styles, they can be separated from the page and saved by themselves. I usually have a separate directory, within the root directory of my site, called "css" and I put all of my style sheets in this directory, including separate site-wide sheets for screen and print media. I can then take them off of the page, making my page much shorter and faster to download. The styles can be associated with the page, and the file containing them can be sent to the browser, by using a <link> tag. Here is how the screen and print style sheets are brought to this page:
<link rel="stylesheet" href="../css/screen.css" media="screen" type="text/css">
<link rel="stylesheet" href="../css/print.css" media="print" type="text/css">

Notice that the style sheet is accessed through the href attribute. Because link is used for many other things, the attributes type and rel help the browser understand what this file is going to do. The attribute media limits the style to either screen or print, which we'll cover soon.

All I have to do to use the same style sheet on another page (or on 300 pages) is to copy the link line as I create the page. That's pretty expedient, no?

When the page is downloaded to a browser, the browser also calls for a copy of any linked files. It then stores these in the computer's working memory cache. Once a style sheet has been downloaded and stored, any calls for the same style sheet will cause the browser to first check to see whether a copy already exists in the local cache. If so, there is no time wasted in going back to the server or downloading another copy. Again, this is pretty expedient and quick.

Links to Script Libraries

A bit later in the semester, we will also look at JavaScript. We write the code for our scripts in small chunks—functions that we can use by referring to them in our forms or in embedded event handlers that make our page reactive to mouseovers and clicks. If we write our codes correctly, they can be used over and over without being rewritten. We usually make a small library of the scripts we have written, and download a copy to the browser. As with external style sheets, once we have cached a copy of a script library, we can use it without going back to the server for another copy. A typical link to an external javascript library looks like this:
<script type="text/JavaScript" src="../scripts/js_scripts_lib.js" ></script>

Here, the element is a script tag, but the tags contain no lines. Instead, there is an external reference to a file of javascripts stored in a library. The attribute for this is src (source), not href, and the attribute type helps the browser identify what kind of script this is going to be.

Server-side Includes

We have already made our pages pretty compact by moving lengthy style sheets or scripts into files, replacing them with a single line to establish the link. There is one additional efficiency that we might want to exploit.

We can not only break up our page into scripts and styles, but we can also break up the html code as well. One of the characteristics of a site is not only that pages should look similar (a sitewide style), but we are also likely to want several elements of the page to be identical (i.e., common structures and contents). We might, for example, want to identify the department or college on every page in a department or college site. We'd normally do this by using a logo or a label displayed in a consistent place and style across all pages. We might want to include a constant footer giving contact information at the bottom of all pages. We will probably serve the user well if each page contains a common navigation to the other major sections of our site. Banners, footers, and navigation might all be candidates for code modularity, the simple chunking of parts of the page into files.

Let's say that we want a common footer and that for this footer every page has the same content, structure, and style. We'd save this (I'd use a directory called ssi for server-side includes) as a file. Then, as we built a page, when we came to the place for a footer, we'd add a line like this:
<!--#include virtual="/ssi/footer.ssi" -->

Unlike the use of a link or script tag to refer to a file, includes use a unique element structure, preceeding the element name include with !--# (note: no spaces).

The .shtml file extension: The use of includes is a server technology, not specifically part of html. HTML will see the <!-- part of the structure and regard the element as an html comment; it skips over this and looks for the next tag. To have the server recognize the structure as an include, you have to change the file extension to .shtml. The server will see this extension and respond by parsing the document (going through it one character at a time), looking for includes. It will then locate the referenced file and add that file's contents in place of the include element.

You can use either the attribute virtual or the attribute file and refer to the file. Note that the file can be saved with either an .ssi or an .htm or .html file extension. The difference between virtual and file is explained in this wikipedia posting:

Because I keep my server-side includes in a directory just below the root directory for my site, the attributes virtual and file would act the same here.

We have covered most of the pieces needed to build our first web pages. But since we will one day want search engines to find our pages and to describe them, we should take a quick look at a few special tags that we'll want to put in the <head> element of our pages, our next topic.