The actual limitations and uses of html frames

[David Virgil Hobbs]

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK


I hate to say it, but roughly speaking everyone on the internet has
been missing the important points in the debate as to whether frames
should be used in web pages.

THE ACTUAL REAL LIMITATIONS OF HTML FRAMES

On and on they yap but the overwhelming majority of internet
commentators both pro and anti-frames, have missed the essential
limitation of frames. The essential problem with frames is, that with
both iframes and frames, popout type navigation bars or menus in the
frames (menus in which when a button is moused over a links list
appears), cannot popout into the area of the page that is outside the
frame. Such popout menus in frames and iframes will be obscured by the
contents of the other frame.

Therefore frames cannot be a solution to the problem websters have,
which is the inefficiency of having to update every link in a links
menu, on every page that the links menu occurs in, if you are a
webmaster who wants to put a popout menu (links list appears when
button is moused over) on every page; if you are this kind of
webmaster, you need to move on to methods such as remote external
javascript (js) scripts.

THE ACTUAL REAL WAY IN WHICH HTML FRAMES CAN BE USEFUL

If you are a simpler HTML only type who is interested in putting a
links menu that is not a popout type links menu on every page, who
wisely wants to avoid the inefficiency of having to update the links
menu that appears on most of your pages in every single page the links
menu appears in, frames, specifically iframes, are the best solution.
All of your pages can include an iframe call to a URL that contains
your links list.

Looking at the bigshots, the three most popular websites, a sample
Yahoo News page contained 1 iframe, a sample AOL page contained 3
iframes, and a sample MSN page contained no iframes. The idea that
frames specifically iframes are unhip and out with the cool
programmers is false.

The vast majority of those who object to the use of frames in web
pages, object to problems that are caused when a website employs one
url featuring a frame with a menu and a content frame whose content is
always changing.

The point most of the huge numbers of such vociferous anti-frame
complainants are missing, is, that a website can employ a different
page or URL for each content page online, with each of these URLs
containing a frame or iframe that always accesses the same menu URL.

Even if the scorned webmaster was employing the approach wherein his
site uses one URL that contains a constant menu frame and a content
frame that is always changing, my response to the shrieking anti-frame
complainants is, all the problems that you are shrieking about, are
nothing compared to the advantage of not having to update the links
menu on every single one of your pages when the links menu has to be
updated.

Toil away, crazed anti-frame suckers!!!





@2004 David Virgil Hobbs
http://www.angelfire.com/ma/vincemoon

 

[rf]

David Virgil Hobbs wrote

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK

So can SSI. So can just about any sort of server side scripting.(*)

<snip rant>

(*)
Without this information this just *could* be a serious post.

With this information this post simply looks like a troll.

 

[David Dorward]

The point most of the huge numbers of such vociferous anti-frame
complainants are missing, is, that a website can employ a different
page or URL for each content page online, with each of these URLs
containing a frame or iframe that always accesses the same menu URL.

.... and this approach requires more work then just using includes - so what
benefit does it bring?

 

[David Dorward]

The point most of the huge numbers of such vociferous anti-frame
complainants are missing, is, that a website can employ a different
page or URL for each content page online, with each of these URLs
containing a frame or iframe that always accesses the same menu URL.

.... and this approach requires more work then just using includes but fails
to solve the problem of orphan pages - so what benefit does it bring?

 

[Rob]

THE ACTUAL REAL WAY IN WHICH HTML FRAMES CAN BE USEFUL

If you are a simpler HTML only type who is interested in putting a
links menu that is not a popout type links menu on every page, who
wisely wants to avoid the inefficiency of having to update the links
menu that appears on most of your pages in every single page the links
menu appears in, frames, specifically iframes, are the best solution.
All of your pages can include an iframe call to a URL that contains
your links list.

er... ever heard of include files? (esp when using JSP to create HTML, but
thats just one example)

Toil away, crazed anti-frame suckers!!!

Much less toil without, thanks.
Rob

 

[SpaceGirl]

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK


I hate to say it, but roughly speaking everyone on the internet has
been missing the important points in the debate as to whether frames
should be used in web pages.

THE ACTUAL REAL LIMITATIONS OF HTML FRAMES

On and on they yap but the overwhelming majority of internet
commentators both pro and anti-frames, have missed the essential
limitation of frames. The essential problem with frames is, that with
both iframes and frames, popout type navigation bars or menus in the
frames (menus in which when a button is moused over a links list
appears), cannot popout into the area of the page that is outside the
frame. Such popout menus in frames and iframes will be obscured by the
contents of the other frame.

That's not the reason people tend not to use frames. Do you actually
design pages?

Therefore frames cannot be a solution to the problem websters have,
which is the inefficiency of having to update every link in a links
menu, on every page that the links menu occurs in, if you are a
webmaster who wants to put a popout menu (links list appears when
button is moused over) on every page; if you are this kind of
webmaster, you need to move on to methods such as remote external
javascript (js) scripts.

Seeing as your initial reason for thinking people dont like frames is
utterly flawed, your summation is way off the mark too.

Here's a question - in your above example, if the user has javascript
turned off (that's about 10% of the real world), what happens to your
navigation in your pages? It doesn't work. Using SSI it always works
because the browser doesn't have to do ANYTHING other than display raw
HTML... no scripting, no frames, no headaches.

THE ACTUAL REAL WAY IN WHICH HTML FRAMES CAN BE USEFUL

If you are a simpler HTML only type who is interested in putting a
links menu that is not a popout type links menu on every page, who
wisely wants to avoid the inefficiency of having to update the links
menu that appears on most of your pages in every single page the links
menu appears in, frames, specifically iframes, are the best solution.
All of your pages can include an iframe call to a URL that contains
your links list.

iframes have their uses, but only if implimented carefully (and the
following examples demonstrate this)...

Looking at the bigshots, the three most popular websites, a sample
Yahoo News page contained 1 iframe, a sample AOL page contained 3
iframes, and a sample MSN page contained no iframes. The idea that
frames specifically iframes are unhip and out with the cool
programmers is false.

No, they are inpractical. People haven't turned against frames because
they are untrendy, they have turned against them because they are
incredibly limiting and introduce a whole raft of issues, all of which
are solved by using SSI.

The vast majority of those who object to the use of frames in web
pages, object to problems that are caused when a website employs one
url featuring a frame with a menu and a content frame whose content is
always changing.

The point most of the huge numbers of such vociferous anti-frame
complainants are missing, is, that a website can employ a different
page or URL for each content page online, with each of these URLs
containing a frame or iframe that always accesses the same menu URL.

true, but it kind of fucks up you if you want to bookmark a particular
item that's IN one of those frames... browsers cannot bookmark the
contents of frames, only the containing frameset. So if I have navigated
down through your web site and only the content of one of the iframes
has been changing, how do I bookmark the page I'm on? It can't be done!

Even if the scorned webmaster was employing the approach wherein his
site uses one URL that contains a constant menu frame and a content
frame that is always changing, my response to the shrieking anti-frame
complainants is, all the problems that you are shrieking about, are
nothing compared to the advantage of not having to update the links
menu on every single one of your pages when the links menu has to be
updated.

You mean exactly the same way it works in SSI. I can change the header
on every single page (some 200+) on our current clients site by changing
ONE FILE, thanks to SSI. The pages also generate fewer HTTP requests as
only ONE FILE (assmbled from SSI pages) is sent to the browsers, rather
than several files (each with it's own IP overhead and header data).
It's MUCH more efficient to use SSI.

Toil away, crazed anti-frame suckers!!!

Hmm... so, I build web sites that dont use frames because it saves time
and money. It lets me do things server side you simply cannot do with
frames. Frameless pages load faster. Search engines dont get caught up
in SSI pages, they get index properly...

And we're the suckers?!

--


x theSpaceGirl (miranda)

# lead designer @ http://www.dhnewmedia.com #
# remove NO SPAM to email, or use form on website #

 

[rf]

SpaceGirl wrote

[frames]

true, but it kind of fucks up you if you want to bookmark a particular
item that's IN one of those frames... browsers cannot bookmark the
contents of frames, only the containing frameset. So if I have navigated
down through your web site and only the content of one of the iframes
has been changing, how do I bookmark the page I'm on? It can't be done!

Actualy not so. IE6 at least (I havn't checked the others) will bookmark the
frameset as you see it. It records the frameset and the page within each
frame and correctly repositions. Try it.

The BIG problem is that you can not tell your girlfriend over the phone the
URI or the "page". You have to say "go to example.com and press the "sexy
bras" link.

 

[Webcastmaker]

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK

That line alone tells me this thread is headed nowhere.

 

[Karl Groves]

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK

I thought you were actually going to say something new!
Wait, no I didn't. I've heard them all.

First, methinks that ANYONE who publishes such a wonderful example of HTML
genius DEFINITELY needs to write more articles on how to produce websites.
On http://www.angelfire.com/ma/vincemoon/ we find such wonderful gems as:
" <BR><BR><BR><CENTER></CENTER></I></b>
</I></I></I></I></I></I></I></I></I></I></I></I></I>
</I></I></I></b></I></I></I></I></I></I></FONT>
</I></FONT></FONT></TH>"

YES SIR! You are definitely the KING OF HTML!

How about - Shared Navigation WITHOUT Frames:
http://www.smartwebby.com/web_site_design/server_side_includes.asp
http://www.php.net/manual/en/function.include.php

Whichever one of these the webmaster chooses depends largely upon which of
these is enabled on the server. For this, you'd have to check with your
host, but you can pretty much count on not being able to use either one if
you're on a free host (Like our genius David Hobbs). Feature-rich hosting is
so affordable these days, you're doing yourself a disservice by using a free
host anyway, and this is just another reason why.

The philosophy behind "shared content" is one of convenience - if you have
elements on your website that are used repeatedly among all (or a large
portion) of the pages on your site, you should consider this as a way to
save time when doing updates or changes. The need for this becomes more
apparent as the site grows. For something like a 5 page small business
website, this might not seem as crucial as it might be for a site that is a
few dozen pages that use the same layout. However, as I will show, you may
also be able to do things like rapidly facilitate complete redesigns and
even multiple versions, all with the use of includes.

The Approach
I would like to preface the rest of this article with a statement that my
own experience with SSI is a bit limited. My understanding is that, other
than a few limitations, SSI works similarly to PHP's include() function. The
most important difference, as I understand it, is that the Include itself
must not have any <HTML>, <HEAD> or <BODY> tags, while PHP include() can.
Additional SSI concerns are as follows -

1.. All the pages using Server Side Includes must be .asp or .shtml files.
2.. If you are using ASP code in your include file then make sure the
include file is named .asp so that no one can open the include file and see
your code.
3.. All paths used in the code of an Include file (i.e. images, links,
etc.) must be relative to Site root and not relative to document.
4.. When you use an Include within a file it must be included relative to
Site Root and not relative to Document.
With PHP's include() function, you can place anything in the included file
except another included file that processes data. In other words, you can
nest included files inside of one another, so long as it contains nothing
but HTML markup.For purposes of this discussion, we'll be talking about PHP
includes. The syntax for a PHP include is as follows:

<?php
include("path/file.php");
?>

So the task you're trying to accomplish here is to be able to expand the
site rapidly, preferably by just dumping in new content into a new page and
then placing the code for the include files for the shared content. Here's a
simple web page to start:

<html>
<head>
<title> This is the page title </title>
<head>
<body>
<p> There's a bunch of content here </p>
</body>
<html>

Let's split this up into bits to separate the content from the shared
elements. If you're like most people, your site's pages look the same across
the board and the actual text content is the only thing that is different.
For this discussion, we'll be making three pages -

"header.php" will contain everything down to and including the opening body
tag. Like so:
<html>
<head>
<title> This is the page title </title>
<head>
<body>

Then, we create "footer.php" which contains everything AFTER the text
content:
</body>
<html>

Now, we create the actual page. This page consists of three things - the
call for the header include, the content, and the call for the footer
include:

<?php
include("header.php");
?>

<p>There's a bunch of content here</p>

<?php
include("footer.php");
?>

***Remember, all of this stuff goes together in one page. So, to create a
new page, all you do is change the stuff between the include files.

Assuming you're also using CSS, by making your site's pages this way, you
can more easily facilitate design changes and updates. By having ONLY unique
content in the main page and by using CSS for all typographic control, you
can rapidly add new pages; make layout changes, and update pages or sections
of the site.

I am of the opinion that every single time you see an opportunity to
separate content from presentation, you should do so. There is a long list
of reasons to do this, but our purpose here is for the rapid change and
alteration of the site itself.

So you're saying "How does this answer my question on shared navigation?"

Well, a web page source is organized so that items displayed on screen on
the top are at the beginning of the source code (duh!) as are items that are
displayed on the left of the screen. Like this:

<html>
<head>
<title>This is the page title</title>
<body>
<-- The stuff at the top -->
<-- The stuff at the left -->
<-- all the other stuff -->
</body>
</html>

(Example at:
http://dev.karlcore.com/tutorials/structure/page_structure.php )

***For purposes of this discussion, I'm referring to the common "distributed
top and left" style of page layout. Yes, I know there are some minor
exceptions to this, and people with CSS layouts can put the stuff anywhere
they want. I'm trying to keep this simple.

Still, this may leave one question unanswered by the frames-apologist: How
to ensure that the navigational items are always in clear view of the
visitor? The real answer, the answer that needs to be given, is that this is
simply a myth. Ultimately, you have absolutely no control over how much
screen space you'll be given by the visitor. You have no reliable way of
knowing their monitor size, resolution settings, or even if they have their
browser window maximized to fill the screen. Take a look at this picture:
http://www.karlcore.com/images/framesnastiness.jpg (warning, it is big).
What we see is a frames-site built by someone with a big monitor. That image
is set as 800x576, which is approximately the same available real estate for
an 800x600 maximized browser window. But looking at that page at 1400x1026,
it looks fine (er, fine meaning, none of that icky-scrolly mess). You can
try to work out your layout at 800x600, but what about the people on
640x480? What about the people on WebTV? What about people who surf with
their browser not maximized? In the end, you can make no assumptions that
could be anywhere near reliable about these things, so attempting to make a
fixed navigation that is always visible is a myth.

Some may say they have found ways using DHTML menus to create an
always-visible navigational menu. These methods should be avoided just as
much as the use of frames, as they also violate a number of
website-accessibility conventions and the authors of such DHTML tools often
do not design them with a built-in accessible alternative. In terms of
accessibility, you're more likely to find a means to make a frameset more
accessible than you are to do so with one of those DHTML menus.

Hopefully in the not too distant future, web browsers will begin to support
the CSS2 'position: fixed' specification. The beauty of this is that it is
expected to be backward compatible, meaning older browsers that don't
support it won't just fall apart, but rather simply ignore it. Meanwhile,
those with up to date browsers will get the experience as it was intended.

To reiterate the points made in the previous article, frames are the wrong
solution to many legitimate problems. Of the many issues they were meant to
solve, they do not fulfill any of the concerns without creating more, often
worse problems. They do nothing good, but a lot of things bad. Instead, they
should be avoided in lieu of server-side includes and cascading style
sheets.

-Karl

 

[David Dorward]

I would like to preface the rest of this article with a statement that my
own experience with SSI is a bit limited. My understanding is that, other
than a few limitations, SSI works similarly to PHP's include() function.
The most important difference, as I understand it, is that the Include
itself must not have any <HTML>, <HEAD> or <BODY> tags, while PHP
include() can.

No. A PHP include cannot (unless you want it to output invalid markup).

Additional SSI concerns are as follows -

1.. All the pages using Server Side Includes must be .asp or .shtml

No. You can use whatever file extension you like. Its a case of configuring
the server.

3.. All paths used in the code of an Include file (i.e. images, links,
etc.) must be relative to Site root and not relative to document.

No. Relative to the site root OR relative to the calling page OR absolute.

4.. When you use an Include within a file it must be included relative
to Site Root and not relative to Document.

I can't comment here, I haven't used SSI enough.

With PHP's include() function, you can place anything in the included file
except another included file that processes data.

No. You can include PHP in a PHP include(). (And that PHP can include an
include() statement etc etc).

 

[PeterMcC]

David Virgil Hobbs wrote in
<[email protected]>

my response to the shrieking anti-frame
complainants is, all the problems that you are shrieking about, are
nothing compared to the advantage of not having to update the links
menu on every single one of your pages when the links menu has to be
updated.

SSI?

 

[Arondelle]

First, methinks that ANYONE who publishes such a wonderful example of HTML
genius DEFINITELY needs to write more articles on how to produce websites.
On http://www.angelfire.com/ma/vincemoon/ we find such wonderful gems as:
" <BR><BR><BR><CENTER></CENTER></I></b>
</I></I></I></I></I></I></I></I></I></I></I></I></I>
</I></I></I></b></I></I></I></I></I></I></FONT>
</I></FONT></FONT></TH>"

YES SIR! You are definitely the KING OF HTML!

Prolly used Netscape Composer to generate his page. I've had to clean
up quite a bit of HTML diarrhea after using the latest version to create
pages. :-X

Arondelle

 

[Karl Groves]

No. A PHP include cannot (unless you want it to output invalid markup).

Every single site I have is valid markup
Every single site I have uses includes in the manner I have described

No. You can use whatever file extension you like. Its a case of configuring
the server.

You're correct.
But my intended audience is people who don't know how to do that.
Most hosts that allow SSI require you to use those extensions (unless, as
you say, you modify your configuration)

No. Relative to the site root OR relative to the calling page OR absolute.

Thats not how I understood it, but as I stated, I'm no expert at SSI

I can't comment here, I haven't used SSI enough.


No. You can include PHP in a PHP include(). (And that PHP can include an
include() statement etc etc).

I was referring to an include that included another include that does stuff
So:
parent
calls an include
this 2nd include does stuff

-Karl

 

[David Dorward]

Every single site I have is valid markup
Every single site I have uses includes in the manner I have described

Lets put it to the test then.

We have a PHP script with has an include in it:
<http://dorward.me.uk/tmp/include-test/include-markup.phps>

We have a PHP file to be included which is a complete HTML document in its
own right:
<http://dorward.me.uk/tmp/include-test/included-markup.phps>

We have a combined document:
<http://dorward.me.uk/tmp/include-test/include-markup.php>

Which is invalid:

I was referring to an include that included another include that does
stuff So:
parent
calls an include
this 2nd include does stuff

Your two statements appear contradictory. Previously you said that the
second include can not do stuff, which is wrong:

<http://dorward.me.uk/tmp/include-test/include-level1.php>

which is made up from

<http://dorward.me.uk/tmp/include-test/include-level1.phps>
<http://dorward.me.uk/tmp/include-test/include-level2.phps>
<http://dorward.me.uk/tmp/include-test/include-level3.phps>
<http://dorward.me.uk/tmp/include-test/include-level4.phps>

 

[Adrienne]

Gazing into my crystal ball I observed (e-mail address removed) (David Virgil
Hobbs) writing in

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK

Framed documents do have their uses. The only good thing I can think of
with frames is that you can collapse them. With that being said, I would
only use frames in a local setting.

When I was developing the website for ScriptAssist, which is a frame
based local application, I was faced with recreating frames in CSS.
Here's what I came up with http://www.scriptassist.com/description.asp .
Then we decided to do an online version of the local program, for people
who might not be at their home/office and needed to use the program.
That one was done in frames - go to
http://www.scriptassist.com/online/index.asp. When prompted for a
username and password, use usenet and usenet. Then type in description in
the keyword, and you will see what I mean.

 

[Karl Groves]

Lets put it to the test then.

<Snip>
No shit. You have invalid markup because the parent document and the
included document both have the same shit in them?
Big surprise.

How about this:
Our "header.php" file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Including stuff is fun</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<!--End the header include and start the body-->


Now, our "footer.php" file:
<!--End the body and begin the footer include-->
</body>
</html>


And our parent file calls them both:
<?php
include("header.php");
?>
<h1>Including A Header And A Footer</h1>
<p>Neat, huh?</p>
<?php
include("footer.php");
?>

See it live:
http://dev.karlcore.com/usenet/includestuff/index.php

See it validate:
http://validator.w3.org/check?uri=http://dev.karlcore.com/usenet/includestuff/index.php

-Karl

 

[David Dorward]

No shit. You have invalid markup because the parent document and the
included document both have the same shit in them?
Big surprise.

Then I misunderstood what you meant in your original post... which was still
wrong. If you were talking about markup period, rather then markup which
would conflict when included, then you CAN have it in an SSI include file.

 

[Isofarro]

HTML FRAMES CAN BE USEFUL TO AVOID REPETITIVE MENU UPDATE WORK

There are better, less problematical methods available. Look at those
options first. SSI, HTML preprocessing.

Therefore frames cannot be a solution to the problem websters have,
which is the inefficiency of having to update every link in a links
menu, on every page that the links menu occurs in,

If you are constantly adding new links, moving links, removing links, it
sounds like you've not done a proper information architecture analysis on
the content of the site. Perhaps if more attention was paid upfront at the
design stage, there wouldn't be a need to constantly change menus?

THE ACTUAL REAL WAY IN WHICH HTML FRAMES CAN BE USEFUL

If you are a simpler HTML only type who is interested in putting a
links menu that is not a popout type links menu on every page, who
wisely wants to avoid the inefficiency of having to update the links
menu that appears on most of your pages in every single page the links
menu appears in, frames, specifically iframes, are the best solution.

Iframes are worse than frames in this particular scenario since the menu has
to be reloaded for every page. If you are caching this menu, then when you
do change it, the old one will display until the cache expires. Once again,
an HTML preprocessing or a server-side include mechanism is far superior to
both a frame and iframe solution.

Looking at the bigshots, the three most popular websites, a sample
Yahoo News page contained 1 iframe,

Not used for navigation

a sample AOL page contained 3 iframes,

Not used for navigation

The point most of the huge numbers of such vociferous anti-frame
complainants are missing, is, that a website can employ a different
page or URL for each content page online,

So you've lost the supposed simplicity and low maintenance cost of using
frames by creating a new frameset for each content page.

all the problems that you are shrieking about, are
nothing compared to the advantage of not having to update the links
menu on every single one of your pages when the links menu has to be
updated.

Yet this can all be done without the disadvantages of frames - by using the
right tools for the job. Again, HTML preprocessing or a server-based
include mechanism.

You've introduced nothing new here. Its all been covered before, for
example:
http://www.html-faq.com/htmlframes/?framesareevil -- please read it
carefully.

 

[Daniel R. Tobias]

The BIG problem is that you can not tell your girlfriend over the phone the
URI or the "page". You have to say "go to example.com and press the "sexy
bras" link.

Which isn't much of a problem for the typical computer geek... since
when are
they likely to have a girlfriend?

 

[SpaceGirl]

The Approach
I would like to preface the rest of this article with a statement that my
own experience with SSI is a bit limited. My understanding is that, other
than a few limitations, SSI works similarly to PHP's include() function. The
most important difference, as I understand it, is that the Include itself
must not have any <HTML>, <HEAD> or <BODY> tags, while PHP include() can.
Additional SSI concerns are as follows -

Yes they can. Well sort off. The site I'm working on right now tops' and
tails' my pages, so there is an opening <html> in the first include and

1.. All the pages using Server Side Includes must be .asp or .shtml files.
2.. If you are using ASP code in your include file then make sure the
include file is named .asp so that no one can open the include file and see
your code.

Wrong. They can have any extension you like (at least under IIS). If
they have a .asp extension, they will get preprocessed by IIS just like
any other ASP scripted file, but other than that you can actually
include ANY text file inside any other .asp file. So, IIS will happily
include "myfile.txt" inside index.asp if I asked it to.

3.. All paths used in the code of an Include file (i.e. images, links,
etc.) must be relative to Site root and not relative to document.

No, they are relative to the document.

/images/pic1.gif
/mypages/page1/page.asp
/includes/myinclude.asp


the path to the image inside the include file would be:

.../../images/pic1.gif

the line that gets the include in page.asp is

<!-- #include file="../../myincludes.asp" -->

All relative paths...

4.. When you use an Include within a file it must be included relative to
Site Root and not relative to Document.

Nope.


<snip stuff />

You dont seem to know a lot about includes for such a long post :/

--


x theSpaceGirl (miranda)

# lead designer @ http://www.dhnewmedia.com #
# remove NO SPAM to email, or use form on website #