CSS instead of frames (but how)?

Len Philpot · Dec 29, 2005

No code written yet, but I'm trying to figure out how to replace the
functionality of a two-frame (nav/content) layout with CSS. I've heard
the objections to frames and although I've never personally had any
problems with them, I don't dismiss the validity of the arguments
against them. However, I like the idea of a unchanging, non-scrolling
nav bar to one side of the page, with the content free to do it's thing
on the other side (personal preference). I also like the idea of the nav
frame being one piece of code that's not repeated for each content file
that gets loaded.

So, how do I duplicate that with CSS?

Let's say I have two styles :

body
{
margin-left: 220px;
}

..nav
{
position: fixed;
top: 0px;
left: 0px;
width: 200px;
height: auto;
}

I've seen enough to know that in Firefox this will work. The nav-styled
content will stay static to the left while the rest of the <body> goes
on independently about its business to the right of it.

Good deal. Except it doesn't work in IE, which apparently doesn't
recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
desired results. Both parts scroll together, either side by side, or one
renders ahead of the other.

Also, even if I get this to work as desired, how do I populate 'nav' on
multiple pages from a single source, without using SSI (is it possible
with <object>)? The reason I say without SSI is that this is just a
hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
for the defacto ("free") web hosting with standard accounts.

Can it be done?

Thanks.

dorayme · Dec 29, 2005

Len Philpot said:
No code written yet, but I'm trying to figure out how to replace the
functionality of a two-frame (nav/content) layout with CSS.

What you want to know is how can you do without frames but keep
some of the great features of them. You can't satisfactorily as
you have discovered because of lack of browser support.

This is how I changed a framed site, I looked at what I had on
the left and put it on each of my pages and made it go to the
left! (you can use tables, or floats or whatever suits you).

There are more intelligent ways of doing this using "includes",
you will simply have to read up on this and especially follow the
posts on this group which regularly (and even right now) discuss
this. But unless your site is absolutely enormous, it won't kill
you to repeat a navigation column for each page to begin with
till you see how it all looks.

Given that a nav pane now scrolls, this might spur you to design
around it so that not too much is on each page or if there is a
lot, there are other means to get to the nav (you can
periodically include links to the top - in case the user does not
know about the home button on the keyboard).

You need to think about your content, how likely is it that
someone engrossed in something way down deep is wanting to see
the nav? Maybe - the strength of frames! But probably not as much
as you think.

Curtis · Dec 29, 2005

No code written yet, but I'm trying to figure out how to replace the
functionality of a two-frame (nav/content) layout with CSS. I've heard
the objections to frames and although I've never personally had any
problems with them, I don't dismiss the validity of the arguments
against them. However, I like the idea of a unchanging, non-scrolling
nav bar to one side of the page, with the content free to do it's thing
on the other side (personal preference). I also like the idea of the nav
frame being one piece of code that's not repeated for each content file
that gets loaded.

So, how do I duplicate that with CSS?

Let's say I have two styles :

body
{
margin-left: 220px;
}

.nav
{
position: fixed;
top: 0px;
left: 0px;
width: 200px;
height: auto;
}

I've seen enough to know that in Firefox this will work. The nav-styled
content will stay static to the left while the rest of the

on independently about its business to the right of it.

Good deal. Except it doesn't work in IE, which apparently doesn't
recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
desired results. Both parts scroll together, either side by side, or one
renders ahead of the other.

Also, even if I get this to work as desired, how do I populate 'nav' on
multiple pages from a single source, without using SSI (is it possible
with <object>)? The reason I say without SSI is that this is just a
hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
for the defacto ("free") web hosting with standard accounts.

Can it be done?

Thanks.

As I learn about HTML and CSS, including the antiframe
rhetoric one encounters, I am regularly surprised at how
many really solid, well-developed applications use frames.
Two notable recent examples are the admin section of
VBulletin, and the Horde webmail program.

I probably haven't heard all the arguments, but so far I'm
not persuaded that frames are Satan incarnate. I don't use
them, but I wouldn't be afraid to do so.

Not an answer to your question, I know, but there it is.

--

Curtis

Visit We the Thinking
www.wethethinking.com
An online magazine/forum
devoted to philosophical
thought.

Spartanicus · Dec 29, 2005

Len Philpot said:
No code written yet, but I'm trying to figure out how to replace the
functionality of a two-frame (nav/content) layout with CSS. I've heard
the objections to frames and although I've never personally had any
problems with them, I don't dismiss the validity of the arguments
against them. However, I like the idea of a unchanging, non-scrolling
nav bar to one side of the page, with the content free to do it's thing
on the other side (personal preference).

For a www site your personal preferences should be irrelevant, it should
be aimed at users.

Except it doesn't work in IE, which apparently doesn't
recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
desired results. Both parts scroll together, either side by side, or one
renders ahead of the other.

IE6 doesn't support position:fixed, JS hacks exist to emulate similar
functionality, but they are cumbersome to use (high CPU usage when
scrolling), and it's jerky.

Also, even if I get this to work as desired, how do I populate 'nav' on
multiple pages from a single source, without using SSI (is it possible
with <object>)?

No. HTML embedded with an object element opens a new viewport inside an
existing document in which a complete HTML document should be loaded,
not a code fragment. Since it's an independent viewport, for example
clicking a link in that viewport will open inside that viewport, not the
parent viewport.

The reason I say without SSI is that this is just a
hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
for the defacto ("free") web hosting with standard accounts.

Then your options are:

a) Use a preprocessor
b) Use an editor with a good block S&R
c) Build your site locally from a database that generates static files

Len Philpot · Dec 29, 2005

For a www site your personal preferences should be irrelevant, it should
be aimed at users.

Well, that preference was stated from the viewpoint /as/ a user, not an
author.

I look at design decisions based on how I want it to
/operate/, not how I want the building process to go.

To me, a nav pane that out of sight is basically useless, since it
forces me to go to the browser controls anyway instead of using the
supplied page links.

IE6 doesn't support position:fixed, JS hacks exist to emulate similar
functionality, but they are cumbersome to use (high CPU usage when
scrolling), and it's jerky.

You mean "IE 7" ?

No. HTML embedded with an object element opens a new viewport inside an
existing document in which a complete HTML document should be loaded,
not a code fragment. Since it's an independent viewport, for example
clicking a link in that viewport will open inside that viewport, not the
parent viewport.

OK. Thanks.

Then your options are:

a) Use a preprocessor
b) Use an editor with a good block S&R
c) Build your site locally from a database that generates static files

....or to play devil's advocate :

d) Use frames

However, I'm still thinking about that. It's a tradeoff - If this were a
commercial site, the requirements would be a bit more stringent than for
a personal hobby site.

Thanks.

Len Philpot · Dec 29, 2005

I probably haven't heard all the arguments, but so far I'm
not persuaded that frames are Satan incarnate. I don't use
them, but I wouldn't be afraid to do so.

I'm kinda in the same position right now. It reminds me of the 'goto is
evil' arguments you hear. While I certainly don't advocate the careless
use of goto, it's a sharp tool and like all other tools, there is a
place to use it and a place to refrain from using it. You have to use it
without getting cut.

From what I've seen, I'd certainly avoid a site littered with numerous
frames, but there are offsetting factors such as making sure your
<noframes> tag is functional and offers access to the site, etc.

The SE issues are more difficult to avoid, but they're not as much of a
factor in what I'm going here. Still, I've not decided yet and would
like to look at the options. SSI looks like the best direction, if I
want to find a new host just for that.

From a design POV, I like sites in general that look and feel like a
piece of software rather than like a browser-oriented website (my
personal opinion is that while it's OK for web browsing, a web browser
makes for a terrible software interface). That's the direction I'd like
to head.

Thanks for the input.

Spartanicus · Dec 29, 2005

Len Philpot said:
Well, that preference was stated from the viewpoint /as/ a user

It's a mistake to assume that others like what you like, some may,
others will not. Establishing reliable numbers is rarely achievable,
typically you should strive for a situation where your choice causes the
least amount of difficulties for users who dislike your choice.

To me, a nav pane that out of sight is basically useless, since it
forces me to go to the browser controls anyway instead of using the
supplied page links.

A choice for fixed navigation on the basis that you find it difficult to
hit the Home key or some other method to get to the top of a document is
not a good reason.

You mean "IE 7" ?

The Dean Edwards script "IE7" is one JS method (which also includes many
other hacks), there are other dedicated methods.

...or to play devil's advocate :

d) Use frames

However, I'm still thinking about that. It's a tradeoff - If this were a
commercial site, the requirements would be a bit more stringent than for
a personal hobby site.

As long as you are aware of the problems frames often cause, then it's
your choice. A few regulars in this group have pages on how to prevent
many of the problems that frames cause. Note that "doing frames
properly" usually causes a new problem: construction and maintenance
becomes a pig.

dorayme · Dec 29, 2005

Spartanicus said:
It's a mistake to assume that others like what you like, some may,
others will not.

OP has already indicated that he meant that he has tried to look at it
from the users point of view.

A choice for fixed navigation on the basis that you find it difficult to
hit the Home key or some other method to get to the top of a document is
not a good reason.

This is not what the OP is saying or meaning. He is imagining it from
the point of view of the user. I don't know too many folk who know what
the home button is when it is at home. OP is perfectly right that it is
somewhat absurd that a nav pane scrolls away. This is the price one
pays for better overall "non-frames" technology. But this is a
different thing. The lack of a sense of absurdity comes from
familiarity. There is a deep sense in which a scrolling away main nav
is absurd. Face absurdity honestly and squarely. You can do it
Spartanicus!

dorayme

Len Philpot · Dec 29, 2005

It's a mistake to assume that others like what you like, some may,
others will not. Establishing reliable numbers is rarely achievable,

That's true statistically half the time, I guess, unless there are
mitigating factors. It's equally a mistake to assume that others
/dislike/ what you like, but there's no point in debating this tit for
tat.

A choice for fixed navigation on the basis that you find it difficult to
hit the Home key or some other method to get to the top of a document is
not a good reason.

Somewhere elsethread I mentioned that I like web pages that function
more "like software" than like a web page. I guess my idea with a nav
pane is to make it functionally "part of the browser" as much as
possible, instead of part of the site and keep the site contents
conceptually limited to the client area of the browser.

The other thing is the code duplication that comes into play.

As long as you are aware of the problems frames often cause, then it's
your choice. A few regulars in this group have pages on how to prevent
many of the problems that frames cause. Note that "doing frames
properly" usually causes a new problem: construction and maintenance
becomes a pig.

Once again - If this were a commercial venture, I'd probably rule them
out entirely (and I'm not yet sure I won't), but I've yet to figure a
route to get their functionality any other way. I'm doing this as much
for the drill as for any other reason.

Thanks for the feedback.

Len Philpot · Dec 29, 2005

the home button is when it is at home. OP is perfectly right that it is
somewhat absurd that a nav pane scrolls away. This is the price one

I guess it's kind of like having the floor buttons in an elevator
mounted /outside/ of the door on the building's top floor only, with
only a button for the top floor inside the car ...

Spartanicus · Dec 30, 2005

[frames]

but I've yet to figure a route to get their functionality any other way.

You know how to fix parts to the viewport for standard compliant
browsers, you know the options for providing a fall back for the OS
component that tries to fool people into thinking that it's a web
browser, and you know how to include code.

What more do you need to figure out?

Neredbojias · Dec 30, 2005

With neither quill nor qualm, Len Philpot quothed:

Once again - If this were a commercial venture, I'd probably rule them
out entirely (and I'm not yet sure I won't), but I've yet to figure a
route to get their functionality any other way. I'm doing this as much
for the drill as for any other reason.

I like frames for some functions but if the only thing you're looking
for is a static nav menu, you really don't need them at all. The
alternate options have already been much-discussed, if not in this
thread, in recent others.

Len Philpot · Dec 30, 2005

browsers, you know the options for providing a fall back for the OS
component that tries to fool people into thinking that it's a web

Are you referring to IE?

browser, and you know how to include code.

How? (see ** below, though for the conditions)

What more do you need to figure out?

The way I see it, here's how it stands :

Frames CSS

Split view Yes Yes
Static/scrolling Yes Partially *
Single source Yes No **
Degrades OK Yes *** Yes

* IE doesn't support position: fixed, so that's an issue.
** That is, without scripting, SSI, etc.
*** Assuming sufficient info is included in <noframes>, which it is.

If I could fix * and **, then I see no reason to use frames. But,
another argument in favor of frames (which I personally don't care for,
but some users might) is that frames _can_ be made to be resizable.
Whether I'd actually do that is questionable...

I don't want this to look like I'm trying to sell frames over CSS. That
would be absurd; however, given what I want to accomplish within the
restrictions I have to operate, I've not yet been able to do it purely
with CSS. I'll still /use/ CSS though, no doubt.

Spartanicus · Dec 30, 2005

Len Philpot said:
Are you referring to IE?
Obviously.

How? (see ** below, though for the conditions)

** That is, without scripting, SSI, etc.

Again: preprocessor, S&R, building static files locally using a
database.

The way I see it, here's how it stands :

Frames CSS

Split view Yes Yes
Static/scrolling Yes Partially *

You are blaming CSS for not providing fixed positioning, this is
nonsense, blame the OS component or provide a work around for IE using
another technology.

Single source Yes No **

Frames using multiple source files.

But,
another argument in favor of frames (which I personally don't care for,
but some users might) is that frames _can_ be made to be resizable.

If by that you mean that a user can resize a pane by dragging a border,
you can do that with CSS layouts to by using JS. But a CSS pane layout
that needs to be resized in that manner has been poorly constructed,
there should be no need for that. IIRC frames cannot be sized to scale
to the user's font setting which makes the option to drag frame borders
a necessity, fortunately CSS layouts can and should scale to the user's
font setting.

Jonathan N. Little · Dec 30, 2005

Len said:
Are you referring to IE?

How? (see ** below, though for the conditions)

The way I see it, here's how it stands :

Frames CSS

Split view Yes Yes
Static/scrolling Yes Partially *
Single source Yes No **
Degrades OK Yes *** Yes

<snip>

I went with JavaScript (for navbar position only) which most folk still
have enabled. If disable clicking liberally use 'up' buttons put the
menu at hand for gracefully degradation...and anyway isn't that what
JavaScript is for, control behavior for 'extra' but not 'essential'
aspects of the site?

Curtis · Dec 30, 2005

Len Philpot said:
I'm kinda in the same position right now. It reminds me of the 'goto is
evil' arguments you hear. While I certainly don't advocate the careless
use of goto, it's a sharp tool and like all other tools, there is a
place to use it and a place to refrain from using it. You have to use it
without getting cut.

From what I've seen, I'd certainly avoid a site littered with numerous
frames, but there are offsetting factors such as making sure your
<noframes> tag is functional and offers access to the site, etc.

The SE issues are more difficult to avoid, but they're not as much of a
factor in what I'm going here. Still, I've not decided yet and would
like to look at the options. SSI looks like the best direction, if I
want to find a new host just for that.

From a design POV, I like sites in general that look and feel like a
piece of software rather than like a browser-oriented website (my
personal opinion is that while it's OK for web browsing, a web browser
makes for a terrible software interface). That's the direction I'd like
to head.

Thanks for the input.

Click to expand...

Excellent analogy with the goto, Len.

Anotheris the notion that tables are evil, and that one
should stick to "pure" CSS to fashion pages. Admittedly I'm
on the rising side of the learning curve, but in trying to
achieve that I found 1) browser rendering consistency
insanely erratic, 2) overcoming this required patches and
kludges that made for some truly ugly code, and 3) many
really good online applications use tables for the
fundamental header/sidebar/footer structure. Finally I threw
in the towel and went with the simplest--tables--for the
structural backbone, and use CSS for the design elements
within those sections.

Agreed on the large qualitative difference between web pages
and desktop apps. That gap should have been bridged by Java
applets and Javascript, etc., , and has to some degree, but
the performance of both--or at least the usual
implementations of them--is often truly pathetic, entailing
long download times for 56K connections and sluggish or
memory-leaking performance once they're in local computer
memory. Not to mention that they too work on some browsers
and crash on others--some Javascripts fail on IE 5.0, for
example, but run OK on 5.5.

--

Curtis

Visit We the Thinking
www.wethethinking.com
An online magazine/forum
devoted to philosophical
thought.

Len Philpot · Dec 30, 2005

Again: preprocessor, S&R, building static files locally using a
database.

Maybe I can approach it from the other end to clarify my constraints:
How to do it with _only_ (X)HTML and CSS. How's that?

You are blaming CSS for not providing fixed positioning, this is
nonsense, blame the OS component or provide a work around for IE using
another technology.

Not at all - In fact, the part you snipped :

lays the blame, if you want to call it that, on IE and not on CSS. I've
personally stopped using IE, but I realize that most haven't, so I have
to at least consider its influence on things.

Frames using multiple source files.

Let's see - I can have the same nav code repeated x times for x pages
and have to manually update it each change, or I can (functionally)
"import" it once for the nav frame and that's it. Seems simpler to me,
aside from any other issues.

If by that you mean that a user can resize a pane by dragging a border,
you can do that with CSS layouts to by using JS. But a CSS pane layout
that needs to be resized in that manner has been poorly constructed,
there should be no need for that. IIRC frames cannot be sized to scale
to the user's font setting which makes the option to drag frame borders
a necessity, fortunately CSS layouts can and should scale to the user's
font setting.

Doesn't giving the user the ability to resize the frame mesh with the
"what the designer wants isn't important, it what the user wants that's
important" philosophy? ;-) At any rate, I don't personally care for
resizable frames (which I stated).

It seems to me that we're getting into a "toma(y)to / toma(h)to"
discussion here that could end up generating more heat than light.

Len Philpot · Dec 30, 2005

Anotheris the notion that tables are evil, and that one
should stick to "pure" CSS to fashion pages. Admittedly I'm
on the rising side of the learning curve, but in trying to

Same here, hence my questions. I don't see any reason to completely rule
out tables, just use them appropriately. If the data is tabular in
nature, then table it. If not and your design ends can be achieved with
styles, then style it. Typically, it might be both.

Little as I know, I've already reaped some "stylesheet rewards" when I
decided to make revisions after the fact. The biggest shift is simply
learning the interactions and techniques required to best achieve design
goals. Kind of like programming - Learning the grammar and vocabulary is
one thing, learning to program is another.

fundamental header/sidebar/footer structure. Finally I threw
in the towel and went with the simplest--tables--for the
structural backbone, and use CSS for the design elements
within those sections.

I'd surmise you've achieved 90% of what could realistically be done with
pure stylesheets with that approach, as long as you keep the "non-
skeletal" stylings in the CSS. I don't see how content and presentation
can be _completely_ and 100% divorced, anyway. One influences and
directs the other. It's an admirable goal, but I don't see it happening
100%. In my previous career (graphic design), I would have laughed at
anyone who told me to design a brochure (e.g.), but wouldn't provide any
details about what it was or whom it was for, saying rather, "Once
you're done, we'll just plug in the content."

Now, creating an environment that's extensible, flexible and
accomodating to skinning, updating, etc., well that's another matter
entirely. Stylesheets and other more dynamic tools offer LOTS for that.

Agreed on the large qualitative difference between web pages
and desktop apps. That gap should have been bridged by Java

....and I'll admit that some of my approach is strongly influenced by my
"roots" in MS-DOS and administering Unix every day for the past six
years. I've come to appreciate the advantages of "a tool learned" as
opposed to "just click here and _everything_ will be all right...".

Spartanicus · Dec 30, 2005

Len Philpot said:
Maybe I can approach it from the other end to clarify my constraints:
How to do it with _only_ (X)HTML and CSS. How's that?

You say that you cannot figure out how to replicate the function of
frames and when you are told you reject it with an argument that amounts
to "but that's not how frames work". Frames are a fundamentally broken
concept, hence proper solutions should at best aim only to replace some
of the functionality of frames, *not* replicate the failures of the
frames concept.

Let's see - I can have the same nav code repeated x times for x pages
and have to manually update it each change, or I can (functionally)
"import" it once for the nav frame and that's it.

The framed nav code is in a separate file: multiple source files.

Seems simpler to me, aside from any other issues.

For the third time: preprocessor, S&R, building static files locally
using a database, only the last option is potentially more complicated
to use than using frames.

Btw, it's bad form to link to the active (target) page itself, so a
navbar should change from page to page by omitting the link to the
(target) page itself.

Jose · Dec 31, 2005

At any rate, I don't personally care for

resizable frames (which I stated).

Why?

What possible advantage is there in preventing the user from adapting
the display of your data to his needs (such as a narrower or wider
screen area than what you think he ought to have, or needing to keep
other windows open and visible while viewing your site?

Jose

Interfering CSS	1	Feb 9, 2024
How can I get my menu inside of a menu to function properly?	1	Jan 19, 2023
Working on mobile css menu with plenty of frustration!	2	Dec 29, 2022
Javascript scroll to sections and also scroll to section but open relevant nav-tab	4	Feb 25, 2022
Logo and nav disapear/appear on scroll, but on x-axis	0	Nov 24, 2021
Align img inside nav tabs section	5	Dec 29, 2023
Help with Visual Lightbox: Scripts	2	May 3, 2023
Positioning CSS components	1	Nov 16, 2023

CSS instead of frames (but how)?

Len Philpot

dorayme

Curtis

Spartanicus

Len Philpot

Len Philpot

Spartanicus

dorayme

Len Philpot

Len Philpot

Spartanicus

Neredbojias

Len Philpot

Spartanicus

Jonathan N. Little

Curtis

Len Philpot

Len Philpot

Spartanicus

Jose

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads