Having problem with frames

[Jonathan N. Little]

I had a framed site for years and it did not break anything, the
world went on fine and people got info from the web site and the
sun still shone. But it's ok I know what you are referring to.
All the ifs and buts and counterfactuals... I must make another
framed site one day for fun. But after I write up the essay on
The Magic of Tables to stir up the church leaders.

Most likely we all made framed sites long ago, because at the time they
were an attempt to modularize to construction and make site maintenance
more efficient. I do remember employing all kind of JavaScript tricks
to allow bookmarking of specific frame content arrangements too! There
are much better ways now, why go back? I use a washing machine now and
have no desire to use a scrub-board and lye soap!

 

[dorayme]

Most likely we all made framed sites long ago, because at the time they
were an attempt to modularize to construction and make site maintenance
more efficient. I do remember employing all kind of JavaScript tricks
to allow bookmarking of specific frame content arrangements too! There
are much better ways now, why go back? I use a washing machine now and
have no desire to use a scrub-board and lye soap!

Why go back? Why go back? I see you are worried by what I said
about me making a framed site and publishing an essay on the
Magic of Tables to stir up the church elders. I knew it! I knew
it! <g>

 

[Joe (GKF)]

You are a farmer right? Robust and all. So I add a little tip
that you and I might suggest to people but I would bet with
generous odds that our PM would not use it:

After the last pee at night, don't flush. Take a look in the
morning. If the bowl looks sparkling clean, the cistern is
leaking and you should fix it (often a worn seal)

If it's yellow ...

Actually, a couple of drops of food dye in the cistern is a good way to
tell - you just wait a few minutes and if you have a leak, the colour
will show up.


Not THAT sort of leak, a cistern leak. Sheesh.

 

[Roy A.]

Many thanks for reply

Those lines (<!DOCTYPE etc.) were in the files - I just didn't clutter
up my message with them Maybe I should have?

I loaded them up to server and, yes, they do work in IE7!!

So the question is, why does IE read them OK from a server but not
from my hard drive whereas Netscape does read Ok from HD? Very strange

It seems like you may have a case problem with long file names. This
could occure if you name your file as e.g. "Mainpage.html" and then
rename it to "mainpage.html". The short filename may still start with
"Main...".

If that's your problem, you could try to rename your file to eg.
"xmainpage.html" and then back to "mainpage.html".

 

[Stubbo_of_Oz]

It seems like you may have a case problem with long file names. This
could occure if you name your file as e.g. "Mainpage.html" and then
rename it to "mainpage.html". The short filename may still start with
"Main...".

If that's your problem, you could try to rename your file to eg.
"xmainpage.html" and then back to "mainpage.html".

Thanks for you post.

Definitely not a case issue. See my post of 26th Jan in which I say
that I now have two IDENTICAL files and one will work and the other
not work!!

 

[Jonathan N. Little]

Stubbo_of_Oz wrote:

I loaded them up to server and, yes, they do work in IE7!!

So the question is, why does IE read them OK from a server but not
from my hard drive whereas Netscape does read Ok from HD? Very strange

I bet it has something to do with M$'s MOTW (Mark Of The Web) bull....

There was someone around here a while trying to explain the rational
behind it. Since IE is also your file management tool Windows Explorer
there has been a long, and successful I might add, history of folks
finding ways to trick IE into thinking its in one mode when in was in
the other allowing the black hats to sneak all kinds of junk onto the
Unsuspecting system. So IE run *more* restrictive with web pages on a
local hard drive!

 

[Stubbo_of_Oz]

Stubbo_of_Oz wrote:



I bet it has something to do with M$'s MOTW (Mark Of The Web) bull....

There was someone around here a while trying to explain the rational
behind it. Since IE is also your file management tool Windows Explorer
there has been a long, and successful I might add, history of folks
finding ways to trick IE into thinking its in one mode when in was in
the other allowing the black hats to sneak all kinds of junk onto the
Unsuspecting system. So IE run *more* restrictive with web pages on a
local hard drive!

Thanks for reply

There are no MOTW lines in the files.

 

[Jonathan N. Little]

There are no MOTW lines in the files.

That may be your problem, without MOTW on your local file system IE can
run the page with even *more* restrictions than on the Internet. See:

http://msdn.microsoft.com/workshop/author/dhtml/overview/motw.asp#The_Local_Machine_Zone_Lockdown
Mark of the Web

 

[Neredbojias]

Saying something never makes it true, but saying something can
reflect that which is true.

Well, suppose I say, "The sky is blue." Now is that true; is it really
blue? It _looks_ blue because of reflection/refraction phenomena, but as
for actually being blue...

 

[Neredbojias]

But there is as well as the "nice little statement" plenty of actual
evidence that frames are a bad solution to a problem and that CSS with
html can do it better. I, alas, have to maintain a frame based
intranet and I curse them nearly every day.

"Evil?" that's an over simplification. "Failed solution that doesn't
work wheras other better solutions are available", that's a pretty
much established fact.

Yes, I like your synposis better than the simplistic "evil", but frames
have good points, too, and some of the bad ones can be avoided with care.
Frames, via javascript, provide an excellent way to carry a persistent
(aka. "session") variable - better even than url-appending or server-side
timing.

 

[Neredbojias]

Frames cause problems. They _always_ cause these problems.

Not always. Take, for example, a single frame frame.

JavaScript doesn't have to cause problems until it's used in an "evil"
way. it is possible to use JavaScript correctly and avoid them.

Most of the generously-termed "problems" can be avoided in frames as well.
I suppose it's true that they are usually not avoided, but that's the
authors' fault.

 

[Blinky the Shark]

Well, suppose I say, "The sky is blue." Now is that true; is it really
blue? It _looks_ blue because of reflection/refraction phenomena, but as
for actually being blue...

Did I not say "can"? Yes, I distinctly said "can".

 

[Stubbo_of_Oz]

That may be your problem, without MOTW on your local file system IE can
run the page with even *more* restrictions than on the Internet. See:
..... snip .....

But that would not explain why I have two identical files one of which
works and one doesn't as per my post of 26th Jan

 

[Jonathan N. Little]

But that would not explain why I have two identical files one of which
works and one doesn't as per my post of 26th Jan

Without the "file" how is any of this be more than just speculation!
Damn tied of playing 20 question game with folk that refuse to post URLs
so we can actually 'see' what they are doing...

 

[Stubbo_of_Oz]

Without the "file" how is any of this be more than just speculation!
Damn tied of playing 20 question game with folk that refuse to post URLs
so we can actually 'see' what they are doing...

The "file" is, as stated in one of my earlier posts, as follows:-

<HTML>
<HEAD>
<TITLE>A simple frameset document</TITLE>
</HEAD>
<FRAMESET cols="20%, 80%">
<FRAMESET rows="100, 200">
<FRAME src="head.html">
<FRAME src="contents.html">
</FRAMESET>
<FRAME src="mainpage.html">
</FRAMESET>
</HTML>

It is not yet part of a fully fledged website and has no URL.

I stated in an earlier post that there was NO problem with it when I
temporarily put it on a server with simple html files for it to load
into the frames so if I did post a URL it would not help as it would
not be reading from my hard drive.

The problem (if you can call it that) is that I have two IDENTICAL
files (as confirmed by a hex editor read of them) with the above
content but with different names, one of which works when loaded into
IE from my hard drive but the other does NOT work - i.e. does not show
any content in the frames. Both work in Netscape.

Being of a curious nature I am trying to understand this anomaly.

 

[Jonathan N. Little]

The "file" is, as stated in one of my earlier posts, as follows:-

<HTML>
<HEAD>
<TITLE>A simple frameset document</TITLE>
</HEAD>
<FRAMESET cols="20%, 80%">
<FRAMESET rows="100, 200">
<FRAME src="head.html">
<FRAME src="contents.html">
</FRAMESET>
<FRAME src="mainpage.html">
</FRAMESET>
</HTML>

This is useless! It is just the frameset, we would need to see
"head.html", "contents.html", & "mainpage.html" and because your
apparently *must* use frames we would have to see it in situ

It is not yet part of a fully fledged website and has no URL.

Then mockup in a temporary folder online!

I stated in an earlier post that there was NO problem with it when I
temporarily put it on a server with simple html files for it to load
into the frames so if I did post a URL it would not help as it would
not be reading from my hard drive.

No but we would see the actually files and maybe see why there could be
a local vs online difference.

The problem (if you can call it that) is that I have two IDENTICAL
files

What file? The frameset page? The head.html page? The contents.html
page? The mainpage.html page?

I have a vehicle in my driveway that does not run, why? Kind of a silly
question isn't it?

(as confirmed by a hex editor read of them) with the above

content but with different names, one of which works when loaded into
IE from my hard drive but the other does NOT work - i.e. does not show
any content in the frames. Both work in Netscape.

Being of a curious nature I am trying to understand this anomaly.

 

[Andy Dingley]

Not always. Take, for example, a single frame frame.

This still decouples (a bad thing) the URL of the container (and
address bar, and bookmarks) from the URL of the content page.

 

[Neredbojias]

Did I not say "can"? Yes, I distinctly said "can".

Actually, you wrote it (-unless you talk to yourself redundantly when you
scribe.)

 

[Neredbojias]

This still decouples (a bad thing) the URL of the container (and
address bar, and bookmarks) from the URL of the content page.

Verily, but I've made frames pages wherein the (sub) frames "pagelets"
where so "slaved" to the rest of the synchronized content that their urls
were meaningless, anyway. Iow, the only significant url was that of the
frameset. This, of course, implies an inability to directly bookmark a
certain phase or "flavour" of the set, but that can actually be desirable
in some cases.

 

[Blinky the Shark]

Actually, you wrote it (-unless you talk to yourself redundantly when you
scribe.)

Red herring. My point stands.