Frames and a navigation bar & CSS

S

Spacen Jasset

One of the reasons that frames were inveted is to enable a navigation bar -
that is - the main page content changes whereas naviagtion information
remains static and is not dupicated into every html file.

So why it is apparently not possible to do the same using CSS?

It doesn't seem possible to use div tags for the static natigation content
with object or iframe tags becase one gets scroll bars if the content it to
big for the object / iframe.

If there is a way please do tell. All the "professional" websites I have
seen have duplicated navigation in each and every page - instered by server
side scripting ( or includes ), but this isn't a good solution now is it. -
Especially if support for this isnt available.
 
S

SpaceGirl

Spacen said:
One of the reasons that frames were inveted is to enable a navigation bar -
that is - the main page content changes whereas naviagtion information
remains static and is not dupicated into every html file.

So why it is apparently not possible to do the same using CSS?

It doesn't seem possible to use div tags for the static natigation content
with object or iframe tags becase one gets scroll bars if the content it to
big for the object / iframe.

If there is a way please do tell. All the "professional" websites I have
seen have duplicated navigation in each and every page - instered by server
side scripting ( or includes ), but this isn't a good solution now is it. -
Especially if support for this isnt available.

Why isn't it a good solution? Why rely on the client doing it when we
already know that all clients seem to render pages in different way.
Also, what about search engines? They cannot cope with framed sites very
well. Also, what happens when a user bookmarks your website? They only
get to bookmark the frameset, rather than a page within the frame set.

Server Side Includes work 100% of the time in ALL browsers, even the
very oldest, because the browser itself doesn't even REALISE that it is
getting a page that has been put together from smaller modules - all the
browser ever sees is the completed HTML. Same goes for server side
scripting... the client browser never sees any of this script as it is
run at the server and stripped out before it even goes near the browser...

The only excuse I can think of for a designer not doing it this way is
that they haven't taken on board a server side language, and dont know
how to use SSIs...

--


x theSpaceGirl (miranda)

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

Mark Parnell

One of the reasons that frames were inveted is to enable a navigation bar -
that is - the main page content changes whereas naviagtion information
remains static and is not dupicated into every html file.

Don't know about the reasons they were created, but that's certainly why
a lot of authors use them these days.
So why it is apparently not possible to do the same using CSS?

The fact that it is not duplicated on every page has nothing to do with
CSS. As for the not scrolling, it _is_ possible with CSS. In fact, it is
very easy. Unfortunately most of the web uses an ancient browser that
doesn't support position: fixed;
It doesn't seem possible to use div tags for the static natigation content
with object or iframe tags becase one gets scroll bars if the content it to
big for the object / iframe.

So don't use said:
If there is a way please do tell. All the "professional" websites I have
seen have duplicated navigation in each and every page - instered by server
side scripting ( or includes ), but this isn't a good solution now is it. -

Why not? It's an ideal solution. You only have one file which contains
your menu (or whatever) and the server automatically includes it in
every file. You only have to update one file if you want to change it.
Especially if support for this isnt available.

Any half-decent host supports SSI these days. Even if they don't, you
can always use pre-processing (which reduces the load on the server
slightly, too).
http://www.allmyfaqs.com/faq.pl?Include_one_file_in_another
 
S

Spacen Jasset

....
The only excuse I can think of for a designer not doing it this way is
that they haven't taken on board a server side language, and dont know
how to use SSIs...

....

No, it's becuase I don want to use SSI for something that should be simple.
And why exactly don't the HTML / CSS specs incorporate such features, it's
mind bogling. So instead a web server spits out the same contents page over
and over.

Why can't <object> or <iframe> elements resize to thier content? like main
frameset tags do?

Anyway - I take it there isn't a client side way around this?
 
K

Kris

The only excuse I can think of for a designer not doing it this way is
that they haven't taken on board a server side language, and dont know
how to use SSIs...

...

No, it's becuase I don want to use SSI for something that should be simple.[/QUOTE]

SSI is simple. Your fear of webservers is making it difficult.
And why exactly don't the HTML / CSS specs incorporate such features, it's
mind bogling.

Because there is not point in trying to surpass the qualities of SSI.
Client side inclusion can never be so good.
So instead a web server spits out the same contents page over
and over.

That is it's purpose.
Why can't <object> or <iframe> elements resize to thier content? like main
frameset tags do?

Because markup has nothing to do with presentation.
Anyway - I take it there isn't a client side way around this?

No. Battle your fear.
 
S

Spartanicus

Kris said:
Because there is not point in trying to surpass the qualities of SSI.
Client side inclusion can never be so good.

Client side include would actually have some benefits, a big plus would
be the cacheability of included code.

The real reason why there currently isn't such a thing is that it would
break backward compatibility with existing UAs. Inclusion of such a
feature can therefore only be considered in a language that in itself is
designed to be not backward compatible.
 
S

Spacen Jasset

Kris said:
...

No, it's becuase I don want to use SSI for something that should be
simple.

SSI is simple. Your fear of webservers is making it difficult.
And why exactly don't the HTML / CSS specs incorporate such features, it's
mind bogling.

Because there is not point in trying to surpass the qualities of SSI.
Client side inclusion can never be so good.
So instead a web server spits out the same contents page over
and over.

That is it's purpose.
Why can't <object> or <iframe> elements resize to thier content? like main
frameset tags do?

Because markup has nothing to do with presentation.
Anyway - I take it there isn't a client side way around this?

No. Battle your fear.
[/QUOTE]
Fear? Erm. No I don't know what plannet your on, but the ability to properly
include web pages in other web pages on the client can only be a be
plus...what we have now is a hack.
 
S

Spacen Jasset

Spartanicus said:
Client side include would actually have some benefits, a big plus would
be the cacheability of included code.

The real reason why there currently isn't such a thing is that it would
break backward compatibility with existing UAs. Inclusion of such a
feature can therefore only be considered in a language that in itself is
designed to be not backward compatible.

We're at HTML 4.01 now. The whole point of issuing a new draft and standard
is to add new features. Frames have been around for ages, and it surprises
me that there does not appear to be any new functionality to help with fil e
inclusion.

Using SSI's to include navigation content is -- I assume noone's ideal
method, rarther, one of the only methods. It has it's own drawbacks. People
still use modems to browse the net, and more commonly xhtml moblie enabled
phones, which don't benefit from having the same content resent each time a
content page is changed.

Anyway...there we are.
 
S

SpaceGirl

Spacen said:
We're at HTML 4.01 now. The whole point of issuing a new draft and standard
is to add new features. Frames have been around for ages, and it surprises
me that there does not appear to be any new functionality to help with fil e
inclusion.

Using SSI's to include navigation content is -- I assume noone's ideal
method, rarther, one of the only methods. It has it's own drawbacks. People
still use modems to browse the net, and more commonly xhtml moblie enabled
phones, which don't benefit from having the same content resent each time a
content page is changed.

Anyway...there we are.

SSI is often smaller than using frames... so... explain your reasoning.

--


x theSpaceGirl (miranda)

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

Spartanicus

Spacen Jasset said:
Client side include would actually have some benefits, a big plus would
be the cacheability of included code.

The real reason why there currently isn't such a thing is that it would
break backward compatibility with existing UAs. Inclusion of such a
feature can therefore only be considered in a language that in itself is
designed to be not backward compatible.

We're at HTML 4.01 now. The whole point of issuing a new draft and standard
is to add new features.
[...]

Frames have been around for ages

And a mild example of what happens when stuff is introduced without
considering the drawbacks. Frames are fundamentally flawed, and we are
still suffering the ill effects of this mistake. Had HTML 4 introduced
CSI things would have been much worse. A fundamental feature of HTML is
that when an older UA encounters an element it doesn't understand it
will ignore the element and *render the content*, that last bit is
essential. CSI would cause mayhem as it would make content unavailable,
every parser would have to be updated, SEs, the lot.
 
K

Kris

No. Battle your fear.
Fear?[/QUOTE]

Because you appear to me one of the kind that expects HTML is all one
needs to author web pages.
Erm. No I don't know what plannet your on, but the ability to properly
include web pages in other web pages on the client can only be a be
plus...what we have now is a hack.

SSI is not a hack
 
S

Spacen Jasset

SpaceGirl said:
SSI is often smaller than using frames... so... explain your reasoning.

SSI causes more traffic on the server and cilent by a factor of N * X Where
N is the size of your included content and X are the number of pages that
are requested that include the content.

I am not saying frames are better, we know the problems; what I was hoping
for was a good replacement. For instance <object data="page"
sizetocontent="true" /> Where sizetocontent would size the object to it's
content.

The other problem is that different web servers handle SSI's in different
ways, for example it might be configured to only process SSI's from pages
endinging .shtml, where as some don't. So you have fiddle about to get
things working.
 
S

Spacen Jasset

Spartanicus said:
Spacen Jasset said:
Client side include would actually have some benefits, a big plus would
be the cacheability of included code.

The real reason why there currently isn't such a thing is that it would
break backward compatibility with existing UAs. Inclusion of such a
feature can therefore only be considered in a language that in itself is
designed to be not backward compatible.

We're at HTML 4.01 now. The whole point of issuing a new draft and standard
is to add new features.
[...]

Frames have been around for ages

And a mild example of what happens when stuff is introduced without
considering the drawbacks. Frames are fundamentally flawed, and we are
still suffering the ill effects of this mistake. Had HTML 4 introduced
CSI things would have been much worse. A fundamental feature of HTML is
that when an older UA encounters an element it doesn't understand it
will ignore the element and *render the content*, that last bit is
essential. CSI would cause mayhem as it would make content unavailable,
every parser would have to be updated, SEs, the lot.

Well I don't see that as a good argument. Any thing that is added to HTML
means that older clients may not be able to use it. <object data= > is just
one example. By adding another "resizetocontent" attribute to the object
element it woud't prevent browsers rendering content.

Besides many browsers still fail to render CSS properly and yet still new
features have been added. So HTML/CSS doesn't stand very still anyway does
it?
 
S

Spacen Jasset

Kris said:

Because you appear to me one of the kind that expects HTML is all one
needs to author web pages.[/QUOTE]

Well yes, why not.
SSI is not a hack

It I think it is for this type of thing because it's used to get around the
problem of having multiple duplicate fragments of html in many html files.
It's not efficient either. The content has already been sent to the client
when the first page loads.

I am surprised that noone really agrees with me on this because it would
make web designers lives easier ( you could then test pages from a local
file system aswell - instead of having to go through a web server. - plus
the other advantages already mentioned ) The only single drawback is support
for it. But why wasn't it added after problems with frames came to light?

I think I've imposed my logic on everyone enough now so I'll desist.
 
R

rf

Spacen Jasset wrote
SpaceGirl wrote

SSI causes more traffic on the server and cilent by a factor of N * X Where
N is the size of your included content and X are the number of pages that
are requested that include the content.

Do you have any idea at all how the internet works internally? Sorry to be
blunt but you are missing quite a few vital facts.

Traffic:

A page with SSI on it (lets forget about images for the moment) requires one
hit on the server. That is, two set of HTTP headers and TPC/IP packet
overhead, one up, one down.

A typical frame page requires four hits on the server, one for the frameset
and one for each frame (assuming header, nav, content). This uses eight sets
of headers etc. These are not small, haven't looked closely but I'd imagine
a couple or three hundred bytes at least. Yes, the returns appreciate after
the frameset is loaded but the first hits on the server are a bastard.

Server:

A page with SSI on it requires one transaction schedule. That is,
marshalling the incoming request, queing it if the server is busy, actioning
it and getting the results out the door. The time spent by the server to
actually assemble the SSId page is a small proportion of this whole. The
execution path length in the TCP/IP stack alone would be greater.

Of course the server has to read the page from its local storage BUT, after
the first hit the included bit is in the servers file system cache.

A hit on a framed page requires 4 of these. 4 times the processing. Once
again appreciating returns but that first hit is a bastard.

Network.

A page with SSI on it requires one round trip to the server. From where I am
a trip to a server in the U S of A costs me 400 milliseconds. So, my UA
sends off a request and waits... For 400ms... This is *not* a small amount
of time when one is looking at a screen waiting for something to happen.

A framed requires 4 trips to the server. 1600ms. 1.6 seconds overhead, over
and above the usual transport times.

Content.

SSI delivers one page, with one set of <!doctype, <head> etc. Frames deliver
four of this overhead.

The bottom line.

It is *quite* expensive to set up a transaction with the server. The actual
processing of that transaction is minimal, compared to the turn around time
over the net.

We went through this a while ago with regard to slicing up images, under the
misapprehension that a sliced image downloads quicker. An experiment
revealed that slicing an image into 9 bits resulted in an end user loss of
performance by a factor of 10.

Frames, while not quite so bad, are still bad from a network point of view.
Any savings made by sending out a slightly smaller package (once the
frameset has been set up on the browser) are far far outweighed by the vast
overhead of setting up that frameset to start with.

Any savings made by not sending the "included" stuff, usually a text menu
bar, are usually far outweighed by the size of the content in the "content"
frame. Why bother saving a couple of hundred bytes of menu when a single
click on that menu spews down tens of thousands of bytes of <img>?
I am not saying frames are better, we know the problems; what I was hoping
for was a good replacement. For instance <object data="page"
sizetocontent="true" /> Where sizetocontent would size the object to it's
content.

Don't worry about it. Just use SSI and be done with it. If you are really
worried about performance issues simply up the compression on your logo
jpeg. You'll be better off.
The other problem is that different web servers handle SSI's in different
ways, for example it might be configured to only process SSI's from pages
endinging .shtml, where as some don't. So you have fiddle about to get
things working.

So? Once you have worked out how your server works you are done with that
bit. You simply do it that way from now on.
 
S

Spartanicus

Spacen Jasset said:
Well I don't see that as a good argument. Any thing that is added to HTML
means that older clients may not be able to use it. <object data= > is just
one example.

Used correctly it's no problem at all:

<object data="http://example.com/example.htm" type="text/html">
<a href="example.htm">Example</a>
</object>

Remember that embedded HTML is displayed in a separate viewport inside
the existing document and that the embedded code is a completely
independent document in it's own right.

Now let's assume that HTML 4 would have introduced something like this:

<include data="http://example.com/example.txt" type="text/plain">
<a href="example.txt">Example</a>
</include>

whereby example.txt contains a code *fragment*, this code makes no sense
whatsoever outside of the context of the original document, resulting in
a broken www for older clients. This is simply unacceptable in a
language designed to be backward compatible as HTML 4 was.
Besides many browsers still fail to render CSS properly and yet still new
features have been added. So HTML/CSS doesn't stand very still anyway does
it?

CSS is presentational, entirely optional and new CSS features have no
effect on the availability of content. Google Bot doesn't do CSS and it
seems to be doing ok without it.
 
P

Philip Ronan

A typical frame page requires four hits on the server, one for the frameset
and one for each frame (assuming header, nav, content). This uses eight sets
of headers etc. These are not small, haven't looked closely but I'd imagine
a couple or three hundred bytes at least. Yes, the returns appreciate after
the frameset is loaded but the first hits on the server are a bastard.

If the frameset contains static files without SSIs, then they can actually
be retrieved in one go with a persistent connection. So the frameset could
be delivered in just two round trips to the server.
 
R

rf

Philip Ronan wrote
If the frameset contains static files without SSIs,

How does the presence or absence of SSIs affect this particular scenario?
The SSI is done at the server. The UA knows nothing about what happens at
the server.
then they can actually
be retrieved in one go with a persistent connection. So the frameset could
be delivered in just two round trips to the server.

Could. But do the UAs do this? No. Do the servers support retrieving
multiple HTML pages in one (your second) transaction? No. HTTP is designed
to serve up one "page" per connection. It is stateless by definition and by
specification. One connection to the server, one page served.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top