Advanced HTML

Frames

What do frames do? Frames break up a browser window into peices which load separate pages. For example, you can have a main frame and a smaller index frame. Or a document frame and a glossary.

The Great Frames Debate

Few parts of HTML have created such a furious and heated debate as frames have. (A few others have generated more ire, such as the <blink> tag, but in these cases the anomosity is nearly universal.) So first, the pros and cons of frames!

(Note: many of these are based on points made by Niederst (2001).)

Problems with Frames

With frames you run risks such as:

• They might not be supported. Most current browsers handle frames just fine, but significiantly older browsers might not. Also, alternate clients might have issues with frames.
• They require careful targeting of your links. (You don't always want the link to open in the current frame!)
• Navigation is impeded, espeically if they browser doesn't support frames your navigation uses frames.
• Frames make bookmarking and indexing (like with a search engine) pages much more difficult.
• The can look right ugly.

In Defense of Frames

Frames have several advantages:

• You can independently move through pages that you still want to see side-by-side.
• There is a <noframes> tag that lets you set up alternate content for the readers without frame-capable browsers.
• Including some internal naviagation links inside of each page in addition to the frame naviation tools will allow the pages to work on their own, if somewhat less nicely.

How to Make Frames

The first step in making a framed website is to make the content pages. You'll write these exactly like normal, in pretty much every respect. (You may later want to tweak the appearance some to make them more suited for the in-frame display. But mechanically, it's the same as always.) In fact, a framed site can be displayed without the frames if it is well-designed. This is something to bear in mind.

Now to actually declare the frame setup. You'll need to create a frameset document. The first difference between a frameset document and other HTML documents is that in the DTD where we have "Transitional" originally you'll now have "Frameset". (Also, if you provided the URL to the DTD, you'll need to change it to the one for the Frameset DTD: http://www.w3.org/TR/html4/frameset.dtd.) The head section is the basically same as before, although you'll find that a lot of the stuff that you can put in doesn't make sense to add. (scripts, stylesheets, etc.) Here's were it gets fun: there's no body to this document. Instead, you have <frameset>.

The <frameset> can take several attributes. The most important are rows and cols. These tell the browser how to arrange the frames. For examle, <frameset cols="25%,75%"> will create two frames in columns, one taking up 25% of the width, the other taking 75%. You can specify frame widths with percents (which is what I typically end up using), absolute widths in pixels (denoted as somply cols="200,400"), or with wildcards (*). Wildcards can be used to tell the browser to take up any remaining room. For example, cols ="200, *" says that the first column should be 200 pixels wide, and the second one should be whatever is left. This lets you control the width of any frames where this is important but also allow the remaining frames to adapt to the browser.

Finally, for each frame you need a <frame> tag. This tag should read something like <frame src="source" name="name">. The source tells the browser what page to load into that frame and the name tells the browser what you intend to call the frame when you reference it.

By the way, frames can be nested. To do this, you put another <frameset> tag inside of a <frameset> tag in place of a <frame> tag. This allows you do break up the browser window into a lot of subsections as you would like. However, you probably want to keep it fairly simple.

The last thing I want to mention is that you should always use the <noframes> tag just before you close off the outermost frameset tags. If the user is using a brower that is not frames-capable, then this will cause the material inside the <noframes> and </noframes> tags to be displayed. You can either tell your reader that she will need a frames-capable brower or – better! – give her a way to view the site without frames.

Your frameset document should look something like:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
  <head>
    <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
    <link href="styles.css" type="text/css" rel="stylesheet">
    <title>The Cheshire Cat's Homepages</title>
  </head>
  <frameset cols = "20%, 80%" frameborder=0>
    <frame name = "contents" src= "main_contents.html" frameborder=0>
      
      <frame name="main" src="homepage.html">
	<noframes>
	  <h1>Woops</h1>
	  Your browser does not support frames.  <a
	    href="main_contents.html">Click here</a> to see the no frames
	  version.
	</noframes>
	
	
	
  </frameset>
</html>

    

Targeting Your Links

The topic of frames raises an important issue in links: targeting. The anchor tag has an attribute target that lets you select where the link will (by default, anyway) open. For example, in the example above I could have a set a link in the contents frame to open in the main frame via target="main". By default, links open in the current frame, so this is quite handy! Note that if the main frame doesn't exist in this example, the browser will probably open a whole new window for the new page. Hopefully, you will have set the links to existing frames, though!

There are four interesting special targets that you need to know about. These are defined for all links, no matter the frame environment. They all start with _ (oh, don't start frame names with this charcter, if only on principle):

_blank

Opens link in a entirely new window

_self

Opens link in this frame/window. Useful for targeting links if the default is to not open in this location and you're not sure if the user will be seing this in a frame or not.

_parent

Opens the link in the next higher frameset. If you're already in the highest frameset, this is the same as _self. Not that this only works if the nesting is done in different documents.

_top

Opens the link in the current window, but gets rid of all of the frames so that the link opens up with the whole window to itself.

This is also a good time to mention the <base> tag, which also allows the target attribute. The <base> tag goes in the head section of the document and if a target is specified, this becomes the default target for all links in that page. This can be very handy, as you might expect. The other attribute that <base> takes is href. (Actually, this attribute must be present!) This URL becomes the base for all relative links in the document. The URL can allow you to start relative URLs from a different directory in your site or on an entirely different site. Nice, huh?

Finally, note that the target attribute (in both the <a> and <base> tags) is being deprecated. It is currently valid in HTML 4.01 Transitional, but not in the HTML 4.01 Strict DTD. Of course, without this attribute, frames lose a lot of their power. (Unless you use Javascript, which brings plenty of other problems!)

Javascript

First of all, Federal law requires that I point out that Java and Javascript are unrelated. Second, I'll tell you what Javascript really is. Javascript is a language (invented by Netscape) that lets you control browsers and webpages to do lots of cool and handy things, not to mention even more obnoxious and rude things. Every time you see a webpage change when you "mouse over" a region, that's probably Javascript. Pop-up windows are usually Javascript. And so it goes.

What's Good about Javascript

Javascript does some things very well. It's the only way that I know of to access the elements of the webpage and change them once the page has been rendered by the browser. Javascript actually lets you access indivual elements of the page (paragraphs, images, header, etc.) and modify the contents or their various attributes. As you can imagine, this is amazingly handy at times.

Some good uses for Javascript include "mouseovers": parts of pages (often images) that change when you run your mouse over them. (For example, the APS Homepage uses these with the menu system.) Does intelligently and with good taste, this can be both attractive and useful. Of course, done poorly this becomes annoying.

Another good example of Javascript is resetting the "location" of a link as it appears in the bottom of the browser. On most browsers, when you mouseover a link, the URL appears on the bottom of the browser. Javascript lets you alter to a more helpful message if you so desire. (Of course, if you write your pages carefully, this is seldom necessary.)

Any kind of Dynamic HTML (DHTML) will typically use Javascript and style sheets to make the page adapt to your actions. Examples of this include pull-down menus and links that light up when you mouse over them.

What's Not So Good about Javascript

It's time for a disclosure: I'm not a fan of Javascript. Here are some of my reasons why.

First, I think it's a poorly constructed language. This is true (in my view) from both a mechanical stand-point (ask me off-line for this rant) and from an implimentaton point of view. Regarding the latter matter, while strides are being made to standardize the language and it's outcomes in different browsers, we're still not there yet. So you often have to write your code carefully to detect browsers and give each browser different directions. This is certainly less than optimal.

Second, not everyone has Javascript. In this era, most visual browsers definately come pre-loaded with Javascript. However, users can turn it off. Many do so to avoid pop-up ads, for example, so this is not a point to be sneered at. Also, non-standard browsers probably won't have Javascript at all. So your blind friends might have real problems with a Javascript-heavy site.

Third, I'm not overwelmed with the uses of the language. There are most definately some very helpful applications for it, but most of what it can do is either unnecessary, silly, or downright annoying.

Fourth, for security reasons (most) Javascript cannot interact with your file system. This means that you can't read any data or store any data with Javascript. So a lot of potential applications either won't work or need a lot more effort to make work.

What's the final word on all of this? Should you avoid Javascript like the Black Death? No, not really. You need to ask yourself whether your application of Javascript will be worth the effort, be interesting/helpful/amusing to your readers, and not hamper non-Javascript naviation. If it passes those tests, I'd say that you should at least try it out. (Note that I personally do have some Javascript on my website. It handles the photo albums and the large versions of the images therein.)

Cascading Style Sheets

This is the funnest, most awsome part of today's workshop: cascading styles sheets (CSS). Without fear of exaggeration, I'll say that I think that CSS is probably the most significant breakthrough web-coding in the past 6 years or so. In fact, I'd say that it roughly rivals the developpment of HTML in many ways. This is appropriate since it's suppose to be a sister language to HTML and the two compliment each other.

What are style sheets? You know how all of this time I've been railing about not putting formatting information into your pages? (Even when I've told you how to do it, I've said to avoid it.) Style sheets are what tell (well, suggest to) the browser how to handle the display of the page. So while HTML will tell the browser the document stucture and content, CSS will suggest to it how to display that content. But they're even cooler than that. Besides taking over all of the formatting options that HTML used to have, they've added a lot more. And even beyond that, CSS allows you to give the users options for styles: you can ask them which style they'd prefer or you can even have different default styles for different media. (Going to print the page? Then you can suggest a different style sheet for printing than the one that you suggest for on-screen viewing!) Just how cool is that? And finally, since style sheets need not be in the HTML document (in fact, I encourage them to not be so embedded), you can use the same style sheet for an entire website. This means that when you get sick of the puice headers on your site, you can change the entire site with just one little code change in one file. Sexy.

Style Sheet Basics

Syntax

The first thing that you should know is how a style sheet statment will appear. The basic synatax is selector{attribute:setting;}, where selector refers to an HTML element. For example, I can set my first-level headers to be red via h1{color:#FF0000;}. Note the semi-colon at the end. Technically, for the final attribute:setting pair in the braces, that isn't necessary. However, I'd say that you should just always include it since it's a good habit. The reason that the semi-colon is there is because it delimits attribute:setting pairs. I can set multiple attributers in one line, such as h1 {color:#FF0000; font-size:48pt; text-align:center;}. (Note that we will discuss some the possibilities for the attributes later. If you're confused about what these meant, just hang on. If that line of code made total sense to you, then you'll really love style sheets because it is pretty much that easy.) It is key to remember that semi-colon, since spaces and commas have other, special meanings in style sheets.

Where to Put Styles?

Where do you put these styles? There are three choices:

Inline

Every HTML element has an optional attribute style which you can set for each individual appearance of that element. This can be very handy for one-time appearances, but it's cumbersome for any style you want to apply to many seperate cases of that element. Note that in this case, you can drop the curly-braces and the element name in the above example. (The element will be obvious, after all.) An example of this kind of style is <h1 style="color:#FF0000; font-size:48pt;">

In the Document Head

The second place where you can slip your styles is in the document head. In this case, use the exact general syntax that I outlined above. You enclose all styles in a <style> and a </style>. To be careful, you should set the type attribute in the style tag: <style type="text/css">. This way the browser knows that kinds of styles you are using.

In a Seperate File

This is probably the most exciting of the options. Since you can reference this file throughout your website, you can control the look/feel of the site with just one file. The synatax for entries in the file (which will typically have a .css extension) is just like the general case I outlined above (and the same as in the style tags). To link in a style sheet, use the link tag: <link type="text/css" rel="stylesheet" href="styles.css" />, where styles.css is the style sheet. (This is sort of the traditional name.) The rel attribute sets the relation. For advanced style sheet work, you can tweak this to things like alternate style sheet. But in general, you'll use what I've written.

Referencing Classes and IDs

But there's more! You don't have to stick to simply referring to all elements of a given type! You can set your styles to apply only to specific cases of an element or even whole classes! How? First of all, you'll need to set the class or id attributes (which all tags have) to something. Both are set to string names, for example class="centered" might be used to indicate that all items with this class have some sort of centering applied to them.

To apply a style to all elements with a given class, change the element part of the style to element.class, so you'd have element.class{attribute:setting;}. Not too hard, is it. By the way, you can apply styles to all elements with a given class name (regardless of the type of element) by leaving off the element: .class {attribute:setting;}. Similarly, for a specific element use the syntax element#id or just #id. Remember that only one element may have a given ID in the entire document.

Another useful point are "pseudo-selector". These aren't based on the structural elements of the HTML documet, per se, but they're handy none-the-less. The most important examples a:link, a:visited, and a:active. These set the properties of an unvistited link, a visited link, and a link that is being moused-over. (Remember that stuff we set in the <body> tag in the first session? Guess what you can stop monkeying around with!) There are other pseudo-selects, such as :first-letter, but they're generally not terribly important. (It's worth looking them up some time because you can do some nice little things with them, but it does little more than add a flourish to your documents.)

A Few More Selector Tips

There are a few more things that you can do with selectors. First is that you can have multiple elements with the same styles by placing the elements in a comma-seperated list. For example, h1,h2,h3 {color:#FF0000;} will set headings 1 through 3 to display in red. This is, as you can well imagine, a real shortcut in many case.

Also, there are "contextual" selectors. That is, selectors that only apply to the element in a given context. For example, td p{font-size:90%;} will decrease the font size in all paragraphs located within table cells. Note that the space serves as the indictor that you're looking at "something in the context of something else."

Also, there are two generic tags out there, now. The generic block-level tag is <div> and the generic inline tag is <span>. You can use these to apply styles to parts of your documents that do not otherwise have some natural, structural reason for other tags. They carry no meaning by themselves, so you get to start from scratch with their styles. Note that you probably want to set either id or class whenever you use these. (You could conceivably only use div in one way in a document, but when you suddenly decide you need to use it another way... well, you've made your life more difficult.)

Font Information and CSS

Specifying the font display is probably the most common and important thing to do with CSS. Style sheets can completely and totally replace the old <font> tag and then plenty more.

Font Family

The first attribute you may want to set is the font family. You can suggest the font that the text will use to render. Actually, it's way more fun than that. You can suggest a list of fonts and the browser will work its way down the list until if finds one that it has. (Note that not all browsers/OSs will have every font!)

The syntax for this is font-family: font, font, font, font-family, where font represents a font name and font-family is one of the font families: serif, sans-serif, monospaced, cursive, or fantasy. Most current browsers know what the families are and will have some way for the user to set the default fonts for each family. If no other font matches, the browser can then pick a default font that is loaded, but something that you feel makes some sense for your style.

As far as fonts go, there are many, many of them. Too many to list, of course. I'm partial to Helvetica, Verdana, (both san-serif fonts, oddly) and "Comic Sans MS". But there are also Times, Arial, and Courier (ick) that are popular. By the way, did you notice that I put "Comic Sans MS" in quotes? Since space has a special meaning in style sheets, any name with spaces needs to be quoted.

Font Size

Another popular thing to set is the font size. The attribuate name for this is, oddly, font-size. What you set it to... well, that's involved. There are several kinds of measurements that you're allowed to use:

You know most of those units already. The pica is 12 points (the point is 1/72 of an inch, by the way), the em is the width of a letter m in the current font, and the ex is the height of an x. For specifying the standard font-size, there's no particularlly good way to going where screens are concerned. Pixels vary in size from screen to screen, points are uniformly rendered on-screen, etc. I usally go with points, just because the variation isn't so extreme that I can't pretty much guarantee that the font will be readable if I make a decent selection (such as 12pt). Once you've set a font size and you're doing things like indenting text, ems become the best unit for specifying lengths.

To to specify font size, I'd so something like p{font-size:12pt;}.

Font Color

Font color is set by the color attribute: p{color:#000000} sets the color to black.

Font Extras

I'm lumping these all together because I don't use them very often (but occasionally) so that I think of them as sort of "extras". These attributes are font-style and font-weight. The former is your way of making something italicized (the three options are actually none, italic, and oblique; these make the next normal, italicized, and oblique – which is like italics, but less curvy – respectively).

The latter attribute lets you set things to be bold (or less bold). You've got more options here: normal, bold, bolder, and lighter are the easy ones. They do what you think that they do. You can also set the weight to be an integral multiple of 100 from 100 to 900, where 100 is the lightest font weight and 900 is the heaviest, boldest avaibible. (Why you get multiples of 100 I won't try to explain beyond saying that it's part of the internal arithmetic that the browser does with font weights. Trust me, while it's interesting, it's not that important to understand.)

So, for example, I could set emphasized text to be italicized (explicitly, rather than rely on browser defaults) and bolder by em{font-style:italic; font-weight:bold;}. Nice, eh?

Font

You'll be selecting a lot of these font options frequently. It gets to be a bit of a pain to have to specify each attribute seperately. Luckily, the good folks at the W3C have planned ahead! There is a font attribute that combines these guys. The syntax is font: weight style variant size font-names. (variant we haven't covered. Don't worry about it.) You can skip some of these options, just make sure that the order is correct. For example, I've set the default font in these pages via font: 12pt Verdana, Helvetica, sans-serif;. (Note that I've only set two actual properties this way. Also note the difference between a list of font family options and the different attributes. The former is delimited by commas, the latter by simple spaces.) Color, alas, must be set seperately.

Alignments

A few ways of aligning elements. First, there's text-align which takes styles left, right, justify, and center. I think that it's pretty clear what these mean, except perhaps for justify which means to fully justify, or to make both sides neatly trimmed. (This looks nicest in general, but runs the risk of oddly stretched out lines in some cases. Arguably, that behavior is just bad rendered by the browser, but there you have it.)

There is also vertical-align which does what you think it does. This takes styles: baseline, bottom, middle, top, sub, super, text-bottom, text-top, or top. Note that this is for aligning inline elements, under which should make the meanings pretty clear. The default for this style is "baseline", by the way.

A personal favorite of mine is text-indent. What this does is probably obvious. It takes either a length or a percent for a style and then indents the block-level element's first line. This makes paragraphs look a lot more professional in my view.

Boxes

Every HTML element is surrounded by a box, in the view of CSS. You can set things like the margins and padding on these boxes to adjust how close together neighboring boxes reside. The difference between padding and margins are that the margins are the outer edge of the overall element (used when placing the element relative to its neighbors) while padding sets how much space around the element's content gets the same style as the element. (This is important for backgrounds, for example. Or drawing boxes.)

You can set the top, bottom, right, or left margin or padding with margin-top:, margin-right:... padding-top:, padding-bottom:... Alternately, you can set the whole kit and kaboodle at once with margin: or padding:. In this case, the styles come in the order top right bottom left. If you specify fewer than four styles, there is a way of propogating them to other sides, but in general I'd either set all four or just one. (In the latter case, all sides get the same formatting, of course.) These can be set to a length, a percent, or auto

Borders on Boxes

Somestimes it's fun to set borders around boxes. The border will be drawn around the padding area, but not into the margin of the element. You can do with with border-style which takes styles none, dotted, dashed, ridge, groove, solid, double, inset, and outset. Most of these are pretty clear. The last two make the box appear to into or out of the page. ridge and groove do the same, but just to the border itself. Oh, you can set these for each border seperately by supplying all four values rather than just the one. (Technically, like with margin, there's a way to propogate two or three values, but I can never recall exactly what that is.)

You can also pick the color of your border with border-color. (If you specify more than one color, they propogate down like with margin.)

You can also set the border width with border-width. (What else?) You can chose thin, thick, medium, or a length here. I'd use pixels for the length, incidently. Oh, you can set these for each border with border-top-width... you get the idea.

Finally, you can wrap the whole thing up into one nice little ball with border. The styles come in the order border-width border-style border-color. (Again, no commas!)

A Few More Box-Related Points

You can also set the height of an element. (Not generally a very useful thing, but who knows?) The styles are either lengths, percents, or auto. The latter lets the browser chose based on what seems best. And, of course, there's width, which you'll probably use more often, but is exactly the same. (Well, rotated 90 degrees.)

float lets the element float either left, right or none. In the first two cases, the element will be sent to one side and text will flow around it.

Backgrounds

Now to see how to make the background of an element look a bit niftier. (This could include the background to body, by the way. Guess what HTML attribute that replaces?) The simplest way to do this is background-color. This takes a (you guessed it) color as a style. You can also set background-image. In this case, the style should be a url which is wrapped up in the function url(). For example, background-image:url(stars.gif).

Another nice trick is background-attachment. This gets set to either scroll or fixed. The former makes the background scroll with the page content, the latter makes the background stay put and scrolls the content over the background. scroll is the default, but I think fixed looks wicked-nifty.

There are a lot of little tricks you can pull with the background image, but I'm not going to share them here. (Too involved.) Suffice it to say that you set everything about the background with the background attribute if you want to get fancy. Also, don't forget to have a color set if you set an image, just in case.

List Styles

Lists allow some interesting new style options. The first is list-style-type. There are a lot of options here: disc, circle and square apply to unordered lists. decimal, lower-roman, upper-roman, lower-alpha, and upper-alpha apply to ordered lists. none can apply to either. Oh, in the interest of open disclosure, you can make this property apply to any HTML element, provided you set display:list-item. But in general, why would you want to?

list-style-image sets the image to replace the simple bullets that browsers stock. The style is a URL wrapped up in the url() function: ul{list-style-image:url(red_ball.gif);}.

The Cascade

The last thing that I should mention is the cascade. The cascade sets which styles apply when two more styles seem to conflict. The list of precidence is:

1. Inline styles
2. Embedded styles (in the <style> tags)
3. Imported style sheets (I didn't cover this, actually. It's not a recommended way to use external sheets.)
4. Linked style sheets (via the <link> tag)
5. User settings on the browser
6. Browser defaults

This is actually pretty intuitive.

Now that I've laid out the basics of CSS, I'd invite you to check out the styles sheet for this website for an example. (Or my website or the APS website, for more examples.)

I'll leave off with my one real trick that I've learned. (As opposed to the very obvious, straight-forward applications of CSS.) Namely, how to center a table. If you set table{text-align:center;}, guess what happens? All of the text within the table is centered in its cells. To center the whole table, use table{margin-left:auto; margin-right:auto;}

Oh, the W3C has a CSS Validator that you can use to check your pages. Also, all of the specifications for the language are on their site, as you would expect.

Maintainance

It is pretty well-known that keeping you webpages current is one of the great difficulties with the web. As far as content goes, that's up to you. But you can simplify your life where little things like bookkeeping are concerned. Learning Perl (which we really don't have time to go into here) can greatly aid your efforts, since Perl is very well-suited to going in to one or more text files (like HTML documents) and making changes. For example, I have a couple of scripts that update my menu system and photo albums using Perl and by accessing some simple datafiles. I can create all of the links and the works without having to change every single file when a change is made to the site.

Finally, a short word or several about Server-Side Includes (SSI). First, I should note these are not always supported on every machine, so I'm hesitant to recommend that you rely on them. But if you have them availible, they're quite handy. The one form I will introduce to you is the include SSI. The syntax goes like this: <!--#include file="filename"-->. This causes the file titled filename to be stuck into your page right where that statment occurs. The user will never know that the file is dynamically added, since it's done on the server before the page is sent off. (Hence the name "Server-side include".) This lets you recycle the same bits of code across multiple pages or to break a page up into several files for ease of maintanence. (Parts of the APS homepage are done this way to save headaches. On my own site, the side-bar menues are all seperate files (secretly, of course) as are the CCS and HTML compliant logos common to most of the pages. On this page, the menu at the top is also an include, as it gets used on the main page as well.)

SSI can do much more than this, including grabbing the time and executing scripts. A massive portion of the APS website doesn't exist in any file, but is dynamically generated via SSI. If you're having troubles keeping up a website, you might look in to this. With a little Perl, you can have great fun and make a site a lot more responsive to the users' needs.

That's about it, folks. I hope that this has been helpful!