.
When first designing a Web site, there are a number of key decisions, including what technologies to use. There's often pressure to go with Flash, since you can make a very professional web site with all sorts of cute animations, features, and the like. The good thing about Flash is its total customizability - you can do just about anything and be absolutely sure visitors will see what you want them to see. The bad things about Flash is that many visitors hate it because it slows them down, some don't have Flash installed, and, generally, search engines ignore it. Our advice, then, is to make Flash optional and/or use it for special purposes (games, key animations, etc) but to use standard, open technologies for the rest of the site.
Back when I taught people how to use Microsoft Word, Pagemaker, and the like - so far back that most people still used WordPerfect - I used to have to demonstrate the power of style sheets (which, sadly, most Word users still don't regularly use or understand). The way I'd get people excited was simple - I'd just put the insertion point into a paragraph and then flip through the styles. As the paragraph changed its character, including the font, margins, tabs, background, color, and size, eyes would widen. It would truly impressive to show doctoral students, by the way, how they could format their dissertations perfectly using about ten styles - and nothing else - with page headers automatically defaulting back to body text in the next paragraph. Web editors are still far from the sophistication of, say, Word 5.1 for Mac (1997 or so) in terms of power and ease of use of styles; but they're getting closer (think Word for DOS 5).
These days, it's rare to find webmasters who don't use style sheets (CSS) in one form or another. The idea of style sheets is hardly new - Microsoft Word for DOS 1.0 used them, along with Pagemaker 1.0 and other programs - but they were applied to html and web design fairly late in the game. Essentially, web sites are supposed to be arranged in an hierarchy, with main headings surrounded by <h1> and </h1> tags, secondary headlines by h2, etc., and ordinary body text started with <p>. CSS allows you to redefine these tags so they will have any appearance you want, instead of their default, which makes headings bigger and bolder. In addition, you can define any other element, such as lists (<li>), text area inputs, even the entire web page (<body>). Additions to CSS which make it more flexible are class and ID; you can define a particular type of tag that way. For example, if I want to set up a purple, small type text style, I can put
.sp {font-size: 10px; color: "purple"}
into my style sheet. Then I can make an entire paragraph small and purple by changing the <p> tag to <p class=sp>, or make a bit of text within the paragraph small and purple by surrounding it with <span class=sp>purple text</span>. (This is easy to do in a standard web design program such as Nvu or Dreamweaver. For example, in Nvu, I would go to the Tools menu, select CSS Editor, click on Rule, select the default New Style, and then set it up in a nice visual environment. Once it was set up, I would go to the toolbar, press down on the arrow next to (no class), select sp, and watch my paragraph turn purple; or select some text, select sp, and watch my text turn purple.)
Where many web sites differ is how far they take style sheets. For example, when we design new web sites with a two-column format, we now set up the columns with style sheets; we used to use tables. But for our main home page, we used a table, because we wanted a particular look which involved simple columns, and because we thought we'd be editing it often; also, a single table is not hard for browsers to deal with (unlike tables within tables). But the menu items in the column are set up in css - no Java, just CSS. It's a simple setup designed to highlight the text so it will stand out, and change colors when the mouse is over the text so provide some visual feedback. Moderately snazzy, simple, and very easy for modern browsers to deal with. By the way, the style sheet for this site is kept as an external file - your browser only has to load and interpret it once. That greatly cuts bandwidth and reduces the time it takes your browser to read this page.
By using the standard html formats such as h1, h2, etc., and redefining them to meet your cosmetic needs, you are helping Google to index your site accurately - which means more visitors.
There are four problems with style sheets. One is that older browsers, such as Explorer 3 and Netscape 3, ignore them. That's not much of a problem these days because just about everyone uses Explorer 5 or 6, and those who don't use Safari, Camino, Firefox, Opera 5 or newer, or other modern browsers that can easily deal with style sheets.
The second problem with style sheets is that they can get very complicated in the wrong hands. That actually increases the size of the file. For an example, export a Word file to html from within Word and see what a mess comes out. Style names should be kept short but descriptive, and if you can do the same thing without styles in less space, do it. (For example, why make a style to center a paragraph when you can just say <p align=center>?)
The third problem is that certain things are very hard to do with styles, especially if you want consistency across web browsers. Placement of text is a big one; but so are behaviors. We tried having a css-based menu, and it worked very well (we still use one on some sites) - but when we wanted to have dropdown menus with submenus, we found that the only way to do it was by having a workaround for Internet Explorer using Javascript, and that some browsers, Netscape 4 for example, refused to do horizontal menus at all. In the end, we gave up and went back to Javascript for everyone, which among other things actually reduced load times - because the external scripts only had to be loaded once, and the css-based menus had to be loaded each time the page was brought up.
The fourth problem is that, until recently, there weren't many good web design tools that really worked well with styles. GoLive CS2 claims to have better visual tools than past software; GoLive CS certainly didn't excel in that area. Though it did have a css application menu, it was somewhat hard to use in practice with a large number of styles; was slow; and, being a GoLive tool, was somewhat buggy as well. The internal rendering wasn't consistent with major browsers, either. Nvu, the best open-source graphical web design program, renders styles fairly well, and has a style chooser built into the toolbar, and a css editor built into the tools menu; it works fairly well if you know what you're doing, but doesn' t give a real-time preview. As of April 2005, no package allowed for easy design of, say, side-by-side columns in a WYSIWYG editor; though Golive CS2 does hold that promise, and Dreamweaver must be close behind. (With a roughly 60-40 split in market share, with Dreamweaver holding the lead, we suspect both programs will continue to be developed - though how Adobe will differentiate and market them, we don't know. Perhaps GoLive will be sold back to its original owners, or, worst case, to Microsoft.)
The power of style sheets, by the way, is really only seen when you use an external style sheet - when each page shares the same one. This allows you to easily have a consistent format; to save space by offloading much of the formatting information; and to quickly and easily make site-wide changes. A style sheet can be the smallest page in your site, but it can be the most visually powerful tool you have.
Many people really like "template" features in their web design software - bits that you can redefine at will. I prefer to keep that on the server side, mainly because my use for these is fairly rare, and I like the flexibility of being able to use SSH (terminal) to go into my web site, make a few minor changes to a single file using Pico or Nano (Linux/UNIX word processors), and have every page reflect those changes instantly. The secret is the Server Side Include (SSI), which has to be set up in Apache (or another server), but which doesn't really require much processor power once it's there. The way it works is fairly simple: when it encounters a command in a web file, <!--#include virtual=file.html-->, it inserts the contents of file.html, whatever those might be, into the current file. Most web hosts require that you name any file using SSI to .shtml (that means the file that calls the other file, that is, the master file that includes the other, shared file. The shared file itself can usually be called anything you want).
I use these for:
The nicest thing about server-side includes is freedom from using a particular web editor. If I used Dreamweaver's editable template system, I'd need to always use Dreamweaver to edit my sites. Sometimes I have to do quick edits from a distance; I can do them right from Linux, using Linux editors. Or I can use my cheap PC laptop (as I am right now) running Nvu. Or I can use my main desktop computer, a Mac G4, with GoLive CS2. Or I can use BBEdit, as I often do - it's a great text editor. The server does the work.
By the way, if you run your own server, you can easily let every .html file have SSI - I usually do. It requires a single additional instruction in httpd.conf (apache.conf) -- just add ".html" to the line that reads add-type server-parsed .shtml and it shouldwork. (Don't do this at a peak time, and remember that for it to take effect,.you need to apachectl restart graceful !
We have to admit that we do use Javascript fairly often these days for specialty functions, largely because it's become rather ubiquitous and we're not programmers. We can, however, pay someone - in our case, js-x.com - to do our javascript coding when we need it, and it's usually not very elaborate. Some examples include selectively hiding and showing parts of a page, making sure a field contains numbers and not letters, and the like. In short, we normally use Javascript primarily to support our survey pages, and not for regular pages. Most uses of Javascript appear to be distractions and unnecessary...much like, say, the rotating American flag that seems to be required of most town web sites. But it sure can be helpful at times, too... especially with just about everyone leaving it on in their browser (since so many sites don't work at all without it.)
One of the nicer technologies in the web world is php, which can appear on any file named .php -- as long as your provider makes it available. php can do a lot of clever things, combining easily edited html (standard web) code with programming, and including other files as needed. For example, you can include another file - one which does things like looking up queries in a database - with:
<? include news.php ?>
What's more, php can be used to set cookies, save form information, validate forms, save information into databases, make calculations...all sorts of things. And it can do it in a way which makes it easy for the non-programmer to customize content. There are many, many php scripts available; but before you use them, look through and check out security issues.
One of the more common technologies on the Web has been, for quite a while, databases - having Web pages that interact with a database, often invisibly. There are people who have their entire sites served by a database; and if you've ever seen a forum...chances are it's interacting with a database, and, these days, it's probably php coding with a MySQL database. I've used the combination of php (you can also use Perl) and databases to serve up daily news briefs (the convenience is similar to blog software), forums, search portals for old, non-active forum messages, 200,000 Mile Clubs, and more. The most common database on the Web appears to be MySQL, and there are a huge number of tools, most of them not especially useful, for managing MySQL databases. We suggest a combination of Webmin, phpmyadmin, and eskewl...but serious database people may want Navicat and other tools. Postgre is also gathering steam.
The most complicated issues got the least amount of verbiage in this page, but that makes sense - they can dominate entire sites in themselves. But we hopewe provided some helpful information.
Generally, for ordinary "us to them" pages, we use two non-html technologies: a style sheet to provide a consistent appearance across the site, and server side includes, to show the site header and footer, ads, and menu (the header, ads, and menu are all in a single file to reduce demand on the server CPU). When we need cute little effects, yes, we do use Javascript...if css turns out to be impossible. (Some of our Javascripts rely on css...!).
We hope this page helped. There are many more in-depth treatments of all these issues out there, but basic introductions seem to usually be very shallow; we hope this provide a good balanced introduction to web technologies.