You are here

Creating A Website: Part 5

Creating A Website: Part 5

Mike Simmons ties up some loose ends with some words on browser compatibility, a look at other Internet music formats than Real Audio, and a brief guide to using frames on your site. This is the fifth article in a six‑part series.

Last month you might have felt that I'd dropped a small (but perfectly formed) bombshell when I explained that though the tag <BGSOUND> would trigger background music for those people using Internet Explorer, Navigator would ignore the command completely, requiring <EMBED> instead. Conversely, at least some versions of Internet Explorer do understand the <EMBED> tag. Surely, you may have thought, HTML is HTML — how can one browser recognise something , and the other totally ignore it? Perhaps this is the time for a brief explanation.

MP3 files can also be made to stream — but don't get confused here. The MP3 file that offers near‑CD quality is not the same MP3 file that can be streamed.

HTML is, essentially, a live language, and like any language it has been subject to change and development. A few years ago, simply getting pictures onto a web site was considered to be pretty impressive, but now we have the potential for sound, video, animations and so on. Inevitably, a great deal of the impetus for these innovations has come from the major players in the browser market, each of whom is striving to produce the dominant product. There is a body called the World Wide Web Consortium which attempts to standardise HTML, and from time to time 'suggests' what version of HTML we should be using, but inevitably this is something of an uphill struggle in the context of the scramble between Netscape and Microsoft to produce the industry standard browser. Thus, the Consortium 'suggests' that HTML 4 should be the adopted standard, but neither of the big two support all the features described in that version — and both of them have introduced innovations of their own which are not part of the specification, and which are not supported by their rival.

Thus, Internet Explorer supports the <MARQUEE> tag, a kind of scrolling animation for text messages, which is ignored by Navigator, which supports the infamous <BLINK> tag which is (quite rightly) ignored by Internet Explorer, and so it goes on. It's always seemed to me hugely impressive that all those synth manufacturers could have sat down together at NAMM in 1982 to agree the MIDI standard. When you consider the difficulty involved in getting two manufacturers to agree over HTML, it's little short of miraculous!

What all this means in practice is that you have to bear in mind that not every feature you include in your web site will necessarily be supported by both the major browsers. Nor will every visitor to your site be using the most up‑to‑date version of that browser, be it Navigator, Internet Explorer or something completely different! This is not an insurmountable problem, and can largely be overcome by simply being aware of the limitations within which you are working. Unless you are working with a captive audience, all of whom are using the same version of the same browser, you must be aware that what you see on your screen may well not be what other people see on theirs!

The Real Deal?

Three of the available Mac audio file players (from top): the Quicktime 4 player, MacAmp, and the MVP player.Three of the available Mac audio file players (from top): the Quicktime 4 player, MacAmp, and the MVP player.

So back to the music. Last month we looked at Real Audio and the way in which it could be integrated into your web site. Real Audio is something of a cheap and cheerful choice, in that it offers pretty much instant (or 'streamed') music at the click of a button, and gives anyone who listens to it a 'good enough' impression of what you sound like. Because the encoder compresses your files so dramatically, however, it's inevitable that there will be some loss of quality involved in the process. If you want to offer high‑quality sound to your site visitors you're going to have to think in terms of some sort of download‑and‑play system, and the flavour of the month here is clearly MP3.

MP3 has featured in this magazine on a fairly regular basis over the last few months, and I don't want to go over old ground again. The process is, in fact, quite similar to the Real Audio system we've already discussed, in that an ordinary sound file is heavily compressed and converted into a different file type which may then be played back on a dedicated player. The difference here is that there is not one company offering the required software but very many of them — and the quality of reproduction is generally very good.

Creating A Website: Part 5MP3 files can also be made to stream. In the light of what I've already said, this must seem as if I'm contradicting myself — but don't get confused here. The MP3 file that offers near‑CD quality is not the same MP3 file that can be streamed. Like Real Audio, MP3 is available in different levels of compression, and the sort of MP3 file that can be streamed will be much more compressed than the CD‑quality version — and, therefore, of much lower quality. An MP3 encoder generally offers a whole range of compression ratios and it's up to you to decide which one is best for your purposes.

Something you might like to consider, and something that I'm thinking about doing on my own site, is providing both Real Audio streaming and downloadable MP3 versions of your tracks [that's what SOS do on this web site so that readers can hear Demo Doctor submissions, too — Ed]. In this way, visitors can get a sense of your music very quickly from the Real Audio system, and could then download the MP3 files for more serious appraisal later. They'd have to really want to download them, though: MP3 may offer relatively dramatic compression ratios, but it still results in pretty substantial file sizes.

It's important to remember, however, that MP3 is only one of the download‑and‑play options currently available. Quicktime 4 is now making aggressive inroads into the market and, with the QDesign Music Codec 2 coming as part of the Quicktime Pro package, may well be worth serious consideration in the next few months. Quicktime comes ready installed as part of every Mac's operating system, and with increasing numbers of PC users installing it onto their machines, it's inevitably going to become an attractive proposition — particularly considering that the Quicktime 4 player will also play MP3 files.

In the end it all comes down to what players your site visitors are likely to have installed on their machines. The only thing stopping you from putting Real Audio, MP3, Quicktime and any other versions of the same track onto your site is the time you have available to do the encoding, and the amount of space you have on your ISP's server. If you've got enough of both, go for it!


Creating A Website: Part 5

One system that we haven't not looked at yet, and one which obviates all the difficulties involved in compressing vast sound files, is the one that is likely to be most familiar to readers of this magazine — MIDI. As I'm sure you know, MIDI files are very small, since they contain a set of instructions about a piece of music, rather than the sound itself. It's perfectly possible to call up a MIDI file on your site with nothing more complicated than a tag like:

<A HREF="filename.mid">here's a MIDI file for you to play</A>

The difficulty here, however, is that you have no way of knowing what the end user will be playing that MIDI file with. Almost certainly, Mac users will hear it on the built‑in Quicktime Musical Instrument Set, while PC users will play it back on whatever soundcard they have installed, if any.

Paradoxically, therefore, it is those who are most able to introduce MIDI onto their web sites who are likely to be most reluctant to do so. When I'm writing music I spend a lot of time — as I'm sure you do — auditioning synths and samplers to determine exactly the right sound for the piece I'm working on. To then have the music reduced down to a General MIDI set of unpredictable quality is not an attractive proposition. I'm not denying that MIDI has its place — but that place could be on pretty much any site other than one showcasing a musician's work!

While I would be reluctant to use MIDI to reproduce any of my recorded music over the web, however, I can imagine using it to provide a simple background to one or two pages. Both Navigator and Internet Explorer will play back MIDI files as background music, using the <EMBED> tag (for Internet Explorer, as I've explained, you could also use the <BGSOUND> tag: safest of all would be to combine the two, as demonstrated last month). However, you might like to consider the finer feelings of your visitor here. You will have noticed that a soundclip presented like this:

<A HREF="filename.wav">you can hear some music here</A>

...offers the visitor to your site some degree of authority over what happpens after they click the link, in that a set of control buttons will appear floating over the browser window (usually — again it can depend on the version and configuration of your browser). If you embed the music, however, this control is gone, and they're stuck with the music for as long as they stay at the page. Given that you don't want to drive anybody away from your site you might find the following code useful:

<EMBED SRC="piano.mid" AUTOSTART=TRUE loop=TRUE HEIGHT="60" WIDTH="144">

This inserts a control console into the page. The controller that the default Navigator player provides is not particularly attractive, however, so you might want to think about placing the code within a table so that you at least have some say over where it appears. Alternatively, something like:


...will simply present the visitor with a pause/play button, which is a good deal less obtrusive.


The MVP site uses frames — the navigation panel to the left is in a separate frame from the title page on the right — but suppresses the borders so they are invisible.The MVP site uses frames — the navigation panel to the left is in a separate frame from the title page on the right — but suppresses the borders so they are invisible.

At the beginning of this series I explained how my own site was made up of 'frames', a system which makes it possible to display two (or more) web pages in the same browser window at the same time. In my case, one page holds little more than a set of graphic and text links to each of my albums, while the other displays the details of whichever link is clicked on. The reason for doing this is quite simple: it aids navigation. Visitors to a site get tired of clicking backwards and forwards from the same menu page, and by keeping the entire menu on screen all the time I'm likely to hold on to my visitors for longer.

The pages in this setup are written in exactly the same way as we've already discussed — in fact, they can be pages that you've already written. The one extra component you need to write is something called a frame holder, which is simply an extra page carrying a chunk of HTML which determines exactly how the browser is going to be divided up. Have a look at this:

<FRAMESET COLS="260,260">

<FRAME SRC="page_a.html">

<FRAME SRC="page_b.html">


This simple piece of HTML, written immediately below the <head> tags, will divide up your browser window into two columns, each 260 pixels wide. Into those columns it will insert two other pre‑written pages — in this case, page_a and page_b. Using <FRAMESET ROWS="25%,75%"> as the first line instead will create two rows running across your browser, the first occupying 25 percent of the space, the other 75 percent.

You don't have to stop there, though; you can create frames within frames within frames if you want to, though the more you add, the messier things are likely to become — if you look at the bottom screen on the right you'll see what I mean!

What you may already have noticed is that it's possible to determine the size of the frame either in absolute terms, in pixels, or in relative terms, by percentages. When it comes to making menus, as I've done, the most useful arrangement is probably to use something like <FRAMESET COLS="20,*">. This determines the width of the first column absolutely, at 20 pixels, while the * symbol indicates that the rest of the available space, be it 80 or 800 pixels, is all allocated to the other column. Clearly, if your menu page is only 20 pixels wide, that's how wide the frame will need to be, regardless of how large the entire browser window is.

Once you've sorted out the relative sizes of your frames there's very little else to do. You don't enter any text, sound or graphics into this page because what you've created is simply a page which will hold other pages, and it's those pages which your visitors will see when they visit your site. To take a small detour here, most ISPs expect you to name your home page, the page that all other pages link from, with something like 'index.html'. If you're going to use frames on your site then it's the page that holds the other pages that gets given the designated name.

The real power of a frame set, as I've indicated earlier, is that it enables you to produce a much more friendly navigation system than would otherwise be possible. In order to complete this process we need to name our frames, and then consider the use of the TARGET tag. Naming the frames is a simple enough process. An example from my site reads something like this:

<FRAME SRC="Albmfr.html" NAME="albums">

<FRAME SRC="intro.html" NAME="intro">

Here, I've named one frame 'albums' and the other frame 'intro'. I could equally well have named them Bill and Ben, by the way: it doesn't matter what name you pick, as long as you pick one. Having done this, we can then start establishing links between the frames. Here's an example of a link that's on my 'Albmfr.html' page:

<A HREF="stone.html" TARGET="intro">Compositions of Stone</A>

What we see here is a straightforward link from the words "Compositions of Stone" which is targeted to the frame named 'intro'. This means that when these words are clicked, the page 'stone.html' will appear in the frame named 'intro'. As I've said earlier, you can have as many frames as you need and, as long as you name each one of them, your links can make any page appear wherever you want it to. How do you make a page appear in the same page as the link? Simply exclude any target data, since the HTML default is simply to replace the link page with the new one.

Just because you can see all the text in a frame on your machine doesn't mean that everybody else will. Remember, HTML is not desktop publishing, it's a mark‑up language...

One of the less attractive features of a frames system is that you can end up with an awful lot of scroll bars on your site. If an individual page's content is small enough not to need them then your visitor's browser won't provide them. However, once there is any data outside a frame then they will appear. You can stop this happening by using the SCROLLING tag, as shown in the following piece of code:

<FRAME SRC="Albmfr.html" name="albums" SCROLLING="no">

This will suppress scroll bars on an individual frame, while putting the same command within the <FRAMESET> tags suppresses all the scroll bars on all the frames on a page.

You need to be very careful here, however, since not everybody's monitor is going to be the same size as yours. Just because you can see all the text in a frame on your machine doesn't mean that everybody else will. Remember, HTML is not desktop publishing, it's a mark‑up language, and if a visitor to your site has configured their browser to display body text at a larger point size, or in a smaller window, then they're inevitably going to wind up feeling pretty frustrated.

If you have a frame that is entirely made up of a graphic, like the 'module' navigation bar on the SOS web site, for example, then you're on safer ground. You can, in fact disguise the fact that there's a frame there entirely by using the folowing piece of code within the FRAMESET tag:


As always, it's down to some judicious experimentation, coupled with careful analysis of the source code on other people's web sites. Though frames have become extremely common over the last year or two there are still people out there who, for one reason or another, are using browsers which do not support them. The most basic way of dealing with this is to include something like the following below the </FRAMESET> tag on your frameholder page:



Sorry, your browser doesn't support frames so you're not going to be able to visit this site!


To make it a little more friendly you could include a link to the browser upgrade page of your choice or, if you really want to make sure that you reach as many as people as possible, you could include a link to an unframed version of your site. This doesn't involve you in half as much work as you might think, and generally comes down to creating a new home page (which will not be called index.html) and then sorting out an unframed navigation system which will allow your visitor to reach all the other pages you have created. One of the features of HTML that it's important to be aware of is that if a browser doesn't recognise something it will simply ignore it. So, if you spell a tag incorrectly it will be disregarded, and if your framed site is visited by a 'no frames' browser it will simply display a plain grey page — so at least get a <NOFRAMES> message up there so your potential visitor knows what's happening!

We're getting to the end of this series now, and you should have pretty much all the information you need to get a site up and running. Next month I'll try to mop up the queries that people have been sending me, so if there's something you're not sure of, this is the time to let me know. You can contact me at

MP3 Issues

On my site, many of the pages are larger than an average browser window, so the browser displays scroll bars on both frames.On my site, many of the pages are larger than an average browser window, so the browser displays scroll bars on both frames.

One of the attractions of the Real Audio system is that the player is free, and so is the encoder. More sophisticated versions of both systems are available at a price, but you don't actually need them to get sound onto your site. Earlier this summer a quick search of the Internet would have revealed a whole range of MP3 players and encoders, some freeware, some shareware, and some commercial. Over the last few months, however, the situation has changed dramatically. Fraunhofer/Thomson Multimedia, who own the rights to the MP3 technology, appear to be enforcing those rights, and are demanding licence fees from anyone using an MP3 encoder. As a result, pretty much all of the freeware encoders seem to have vanished from sight.

At the time of writing the situation here still seems unclear. There's no problem if you're prepared to pay for your encoder — you probably couldn't do much better than Xing's Audio Catalyst, reviewed in the September issue of SOS — but if you want to get your feet wet without spending any money things are rather more tricky. Until recently I could have steered you to the Mpecker site at, but at the moment this site is only able to supply its player, not its encoder. Xing offer their encoder on a trial basis for PC users but not Macs. There is some light at the end of the tunnel, however, in the form of QDesign's MVP player and encoder which is available at This is a splendid piece of software which is currently available at beta 3 and converts files to either the MP3 or MOV format with high levels of compression and equally high levels of fidelity. I'm not sure whether or not this is going to remain as a free product once it comes out of beta testing, but it's certainly worth visiting the site to see what the situation is.

You've Been Framed...

Now I've really gone too far! Don't use more frames than you really need...Now I've really gone too far! Don't use more frames than you really need...A word of warning about frames. I recently received an email from someone who had visited my site and found the menu bar missing. I checked it on my machine, I checked it on several others, and the menu bar was always there. Further exploration revealed that my visitor had forgotten the name of my site and simply done a search for 'Music from the Mountains' in one of the search engines. Search engines index the contents of all the pages of a site, not just the home page, and the first page that this engine came up with happened to be the introduction, which was what came up on my visitor's browser — and which had no links on it, since the idea is that visitors use the navigation panel to get around the site. The introduction and the navigation panel are different pages, which are supposed to be held in different frames — but going direct to the introduction bypassed the index page which set up the frames. Without that setup, it was impossible to navigate anywhere else in the site. The workaround? I've just installed a small 'home page' button at the very bottom of every page, linking it to 'index.html'. Most people will never use it, most people will probably never see it, but the next person who wanders 'sideways' into my site via a search engine will be able to use that button to get into the rest of my site.