Help with HTML frames

Hi All,

I'm developing a website which will have a banner and control buttons
at the top of the page, which I want to always be visible. Each
button can be in 4 different states depending on whether it is the
current page, the mouse is hovering over it, it has been pressed, or
none of the above. I have all that done, but the problem I'm having
is with HTML frames. When I click the control button to switch pages,
instead of opening the new page in the lower frame, it opens a new
window, (or new tab in my case as I'm running IE7).

I have included the problematic pages below, and I think the issue has
something to do with which frame name I'm calling from the target> in the AboutFixed and ServicesFixed pages, but I've tried both
the Fixed and Scroll frame names and get the same result. Is it even
possible to have 2 dynamic frames on the same page, because I think
that's where I'm falling down. I need to have 2 due to the changing
nature of the control buttons.

About.htm








resize="no">








AboutFixed.htm

onMouseOut="ServicesOut" onMouseDown="ServicesDown">

This is some text from the About page.

onMouseDown="AboutDown">

This is some text from the Services page.

Re: Help with HTML frames

Well bust mah britches and call me cheeky, on Thu, 18 Oct 2007 03:10:35 GMT
Jayson scribed:

> Hi All,
>
> I'm developing a website which will have a banner and control buttons
> at the top of the page, which I want to always be visible. Each
> button can be in 4 different states depending on whether it is the
> current page, the mouse is hovering over it, it has been pressed, or
> none of the above. I have all that done, but the problem I'm having
> is with HTML frames. When I click the control button to switch pages,
> instead of opening the new page in the lower frame, it opens a new
> window, (or new tab in my case as I'm running IE7).
>
> I have included the problematic pages below,
> ...snip...

Problematic is right. The markup is about 10 years old. Unless you update
your skills, any help you might get will be essentially useless, anyway.

--
Neredbojias
http://www.neredbojias.com/_u/numanumayei.aac

Re: Help with HTML frames

"Neredbojias" wrote in message
news:Xns99CCE704EDB32nanopandaneredbojias@85.214.62.108...
> Well bust mah britches and call me cheeky, on Thu, 18 Oct 2007 03:10:35
> GMT
> Jayson scribed:
>
>> Hi All,
>>
>> I'm developing a website which will have a banner and control buttons

> Problematic is right. The markup is about 10 years old.

and will *only* even possibly work in IE so is unsuitable for the web
anyway.

--
Richard.

Re: Help with HTML frames

Well then can you please suggest an alternative method of achieving
the effect I want?

Re: Help with HTML frames

In article
<1192747041.930823.201240@e9g2000prf.googlegroups.com>,
Jayson wrote:

> Well then can you please suggest an alternative method of achieving
> the effect I want?

Would you care to tell me what effect you want? The dorayme quick
and dirty effects department is open at various times of today.

--
dorayme

Re: Help with HTML frames

On Thu, 18 Oct 2007 15:37:21 -0700, Jayson wrote:

> Well then can you please suggest an alternative method of achieving
> the effect I want?

You might want to learn some PHP, then just include your external
navigation and whatever else into the page.

Frames are dead.

--
http://www.vaxius.net

Re: Help with HTML frames

In article ,
Sean Fritz wrote:

> On Thu, 18 Oct 2007 15:37:21 -0700, Jayson wrote:
>
> > Well then can you please suggest an alternative method of achieving
> > the effect I want?
>
> You might want to learn some PHP, then just include your external
> navigation and whatever else into the page.

This might be true - can't tell as I didn't see the OP's post.

> Frames are dead.

This, on the other hand, is rubbish.

Re: Help with HTML frames

"Jayson" wrote in message
news:1192747041.930823.201240@e9g2000prf.googlegroups.com...
> Well then can you please suggest an alternative method of achieving
> the effect I want?

One of your requirements is that the nav bar (what you call the control
buttons) remains visible at all times.

Remove this requirement and you achieve two things:

1) You free up screen real estate that could be more profitly used
displaying your content, after your viewer has scrolled down a bit.

2) You can drop the frames. Google for "frames are evil".

Have a good look round the internet. How many frame sites to you see,
compared to ordinary ones that scroll up and down?

Of the frames sites you have found, how many are as easy to use/bookmark as
the ordinary ones you have found?

--
Richard.

Re: Help with HTML frames

"Tim Streater" wrote in message
news:timstreater-650DBE.08521219102007@individual.net...
> In article ,
> Sean Fritz wrote:

>> Frames are dead.
>
> This, on the other hand, is rubbish.

Care to cite any modern (that is, this century) source that advocates the
use of frames? And I mean a proper souce, not some web dreziners blog.

--
Richard.

Re: Help with HTML frames

In article ,
"rf" wrote:

> "Tim Streater" wrote in message
> news:timstreater-650DBE.08521219102007@individual.net...
> > In article ,
> > Sean Fritz wrote:
>
> >> Frames are dead.
> >
> > This, on the other hand, is rubbish.
>
> Care to cite any modern (that is, this century) source that advocates the
> use of frames? And I mean a proper source, not some web dreziners blog.

It's the blanket statement that is rubbish. Frames (and iframes) are
working just fine for my application (for a closed community of
engineers).

Re: Help with HTML frames

"Tim Streater" wrote in message
news:tim.streater-C2CCC3.10070419102007@news.individual.net. ..
> In article ,
> "rf" wrote:
>
>> "Tim Streater" wrote in message
>> news:timstreater-650DBE.08521219102007@individual.net...
>> > In article ,
>> > Sean Fritz wrote:
>>
>> >> Frames are dead.
>> >
>> > This, on the other hand, is rubbish.
>>
>> Care to cite any modern (that is, this century) source that advocates the
>> use of frames? And I mean a proper source, not some web dreziners blog.
>
> It's the blanket statement that is rubbish. Frames (and iframes) are
> working just fine for my application (for a closed community of
> engineers).

How many engineers? 20? Out of say 2,000,000,000 internet users?

--
Richard.

Re: Help with HTML frames

In article ,
"rf" wrote:

> "Tim Streater" wrote in message
> news:tim.streater-C2CCC3.10070419102007@news.individual.net. ..
> > In article ,
> > "rf" wrote:
> >
> >> "Tim Streater" wrote in message
> >> news:timstreater-650DBE.08521219102007@individual.net...
> >> > In article ,
> >> > Sean Fritz wrote:
> >>
> >> >> Frames are dead.
> >> >
> >> > This, on the other hand, is rubbish.
> >>
> >> Care to cite any modern (that is, this century) source that advocates the
> >> use of frames? And I mean a proper source, not some web dreziners blog.
> >
> > It's the blanket statement that is rubbish. Frames (and iframes) are
> > working just fine for my application (for a closed community of
> > engineers).
>
> How many engineers? 20? Out of say 2,000,000,000 internet users?

50 to 100, I'd say.

Re: Help with HTML frames

In article ,
"rf" wrote:

>
> "Tim Streater" wrote in message
> news:tim.streater-C2CCC3.10070419102007@news.individual.net. ..
> > In article ,
> > "rf" wrote:
> >
> >> "Tim Streater" wrote in message
> >> news:timstreater-650DBE.08521219102007@individual.net...
> >> > In article ,
> >> > Sean Fritz wrote:
> >>
> >> >> Frames are dead.
> >> >
> >> > This, on the other hand, is rubbish.
> >>
> >> Care to cite any modern (that is, this century) source that advocates the
> >> use of frames? And I mean a proper source, not some web dreziners blog.
> >
> > It's the blanket statement that is rubbish. Frames (and iframes) are
> > working just fine for my application (for a closed community of
> > engineers).
>
> How many engineers? 20? Out of say 2,000,000,000 internet users?

well, I don't think, to be fair, Tim is taking some position that
these facts are all that relevant to. Yeah I know... but frames,
when done well (a rare thing) are not an incompetent thing to
implement, especially with a restricted audience or for CD or
other distributed media.

There is no point reviewing all the evils of frames every time
the poor things rear their heads. They have one huge advantage in
that they perfectly implement the no-scrolling navigation menu.
One of the silliest things ever in the history of mankind is how
we have all gotten so used to useful navigation doing the
disappearing act like the bloody station leaving the station
along with the train! O, we say, that is just standard practice.
Live with it. The alternatives with position: fixed and other
things made Spartanicus (god)'s browser jerky...

I will stop now. Tim, it irritates me too to keep seeing the word
"frames" in the same sentence as "evil" or "dead". I prefer
sunnier associations. I kinda like:

Marilyn Monroe
Henry Fonda
Red
Triumph motorbikes
Angle grinder
Macintosh G4 Quicksilver
Coogee beach

and hell... even...

Thredbo (I have a nce 35mm B & W of me on a Trumpy at Thredbo...)

--
dorayme

Re: Help with HTML frames

In article
,
dorayme wrote:

> In article ,
> "rf" wrote:
>
> >
> > "Tim Streater" wrote in message
> > news:tim.streater-C2CCC3.10070419102007@news.individual.net. ..
> > > In article ,
> > > "rf" wrote:
> > >
> > >> "Tim Streater" wrote in message
> > >> news:timstreater-650DBE.08521219102007@individual.net...
> > >> > In article ,
> > >> > Sean Fritz wrote:
> > >>
> > >> >> Frames are dead.
> > >> >
> > >> > This, on the other hand, is rubbish.
> > >>
> > >> Care to cite any modern (that is, this century) source that advocates the
> > >> use of frames? And I mean a proper source, not some web dreziners blog.
> > >
> > > It's the blanket statement that is rubbish. Frames (and iframes) are
> > > working just fine for my application (for a closed community of
> > > engineers).
> >
> > How many engineers? 20? Out of say 2,000,000,000 internet users?
>
> well, I don't think, to be fair, Tim is taking some position that
> these facts are all that relevant to. Yeah I know... but frames,
> when done well (a rare thing) are not an incompetent thing to
> implement, especially with a restricted audience or for CD or
> other distributed media.
>
> There is no point reviewing all the evils of frames every time
> the poor things rear their heads. They have one huge advantage in
> that they perfectly implement the no-scrolling navigation menu.
> One of the silliest things ever in the history of mankind is how
> we have all gotten so used to useful navigation doing the
> disappearing act like the bloody station leaving the station
> along with the train! O, we say, that is just standard practice.
> Live with it. The alternatives with position: fixed and other
> things made Spartanicus (god)'s browser jerky...
>
> I will stop now. Tim, it irritates me too to keep seeing the word
> "frames" in the same sentence as "evil" or "dead". I prefer
> sunnier associations. I kinda like:

Well, I agree. What I observe is that every time someone (I assume to be
a newbie, but perhaps not) comes here in search of help with frames, the
general reaction is to say "Frames dead" or "Frames evil" etc etc.

I have described here before that I use iframes in a particular way -
the application would simply not scale to the amount of data in our
database without. I use frames to implement a set of tabs that the user
can click to change the content of a frame occupying most of the screen
(below the bar of tabs, other headers, etc), because there is too much
into to put it all on one screen.

I got grudging acknowledgement on a previous occasion that my use of
iframes was appropriate. Perhaps there is a better way to implement this
- but I won't be changing it any time soon, even if there is.

If people said "You should use xyz instead of frames, and here's why,
and here's an example using xyz that functions identically to this
example using frames, and here's why its better" then sceptics like me
might pay more attention.

Re: Help with HTML frames

Well bust mah britches and call me cheeky, on Fri, 19 Oct 2007 13:06:38
GMT Tim Streater scribed:

>> I will stop now. Tim, it irritates me too to keep seeing the word
>> "frames" in the same sentence as "evil" or "dead". I prefer
>> sunnier associations. I kinda like:
....
> If people said "You should use xyz instead of frames, and here's why,
> and here's an example using xyz that functions identically to this
> example using frames, and here's why its better" then sceptics like me
> might pay more attention.

But if people always said what you wanted them to say, you'd have no excuse
to opt out from better methods of engineering your page...

Here's an example of a non-frames page with a stationary header and footer:

http://www.neredbojias.com/_a/whelan1.html

The nav happens to be in the header, but it could be anywhere. This page
works in ie6, ie7, firefox, and opera - all the browsers I am currently
able to test. No, the markup isn't exactly a "piece of cake", but neither
is it so esoteric as to be improbably conformed. The point is don't be so
lazy and you may be surprised by what you can do.

--
Neredbojias

Re: Help with HTML frames

In article ,
Neredbojias wrote:

> Well bust mah britches and call me cheeky, on Fri, 19 Oct 2007 13:06:38
> GMT Tim Streater scribed:
>
> >> I will stop now. Tim, it irritates me too to keep seeing the word
> >> "frames" in the same sentence as "evil" or "dead". I prefer
> >> sunnier associations. I kinda like:
> ...
> > If people said "You should use xyz instead of frames, and here's why,
> > and here's an example using xyz that functions identically to this
> > example using frames, and here's why its better" then sceptics like me
> > might pay more attention.
>
> But if people always said what you wanted them to say, you'd have no excuse
> to opt out from better methods of engineering your page...
>
> Here's an example of a non-frames page with a stationary header and footer:
>
> http://www.neredbojias.com/_a/whelan1.html
>
> The nav happens to be in the header, but it could be anywhere. This page
> works in ie6, ie7, firefox, and opera - all the browsers I am currently
> able to test. No, the markup isn't exactly a "piece of cake", but neither
> is it so esoteric as to be improbably conformed. The point is don't be so
> lazy and you may be surprised by what you can do.

Again, you don't say why it's better, you merely assert that it is.

What I have created works just fine. Changing it to another approach is
way down my list of priorities.

Re: Help with HTML frames

Tim Streater wrote:

> Neredbojias wrote:
>> Here's an example of a non-frames page with a stationary header and
>> footer:
>>
>> http://www.neredbojias.com/_a/whelan1.html
>
> Again, you don't say why it's better, you merely assert that it is.

1. There is only one page to deal with, not three or four (frameset,
heading page, nav page, footer page, and of course, content page).

2. While looking at any of the sub-pages (in this case images), a
visitor can *bookmark* the sub-page, unlike in frames where only the
frameset page can be bookmarked.

3. Assuming pages of text rather than images, Google will index the
content on the sub-page, and when a visitor goes there (direct link sans
frameset), there is *no* header, footer, and more importantly, no
navigation.

That should do it, eh?

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Help with HTML frames

rf wrote:
> "Tim Streater" wrote in message
> news:tim.streater-C2CCC3.10070419102007@news.individual.net. ..
>> In article ,
>> "rf" wrote:
<< snip >>
>> It's the blanket statement that is rubbish. Frames (and iframes) are
>> working just fine for my application (for a closed community of
>> engineers).
>
> How many engineers? 20? Out of say 2,000,000,000 internet users?
>

I think the point is the right tool for the job at hand. When designing
an app for the 20, what do the 2,000,000,000 have to do with it. I have
never used frames (even last century) for all the frequently cited
reasons, and because browser real estate is too precious to waste.
However, now I am now using them for a relational database edit
interface. The user community is even smaller(1) so I have complete
control over all aspects of browser choice, plug-in availability,
feature enabled/disabled, and anything else. Do I need to consider
2,000,000,000 internet users? With the exception of iframes, I can't
see any better way to access, display, and edit data from several
related db tables, and developing a stand alone gui is a pain in the
a**. So, while I don't use frames for commercial sites, I would be
disappointed to see "evil" frames actually "die."

This reminds me of the "no Flash is good Flash" arguments I see here so
frequently. Come to think of it, it reminds me of a lot of "One true
religion" arguments. Call me an html heretic if you like.

Re: Help with HTML frames

dorayme wrote:

> Triumph motorbikes

I never referred to my Bonneville as a motorbike, though I did raise an
eyebrow or two calling it "my scooter." Now I call my ride a Harley,
and no one gets confused.

Re: Help with HTML frames

In article
,
"Beauregard T. Shagnasty" wrote:

> Tim Streater wrote:
>
> > Neredbojias wrote:
> >> Here's an example of a non-frames page with a stationary header and
> >> footer:
> >>
> >> http://www.neredbojias.com/_a/whelan1.html
> >
> > Again, you don't say why it's better, you merely assert that it is.
>
> 1. There is only one page to deal with, not three or four (frameset,
> heading page, nav page, footer page, and of course, content page).

It may ease the implementer's task, but so what.

> 2. While looking at any of the sub-pages (in this case images), a
> visitor can *bookmark* the sub-page, unlike in frames where only the
> frameset page can be bookmarked.

The main page in my app is reached via a table on another page. The
table contents may change (not very often, but it happens) based on
database contents. So they shouldn't be bookmarking even the main page,
as it may not exist at some future point. And they certainly shouldn't
be bookmarking the sub pages, as they are likely to get rubbish (data is
passed back and forth via JS variables in the top frame).

In fact, if I had my way, I'd prevent any of these going into the
history stack.

> 3. Assuming pages of text rather than images, Google will index the
> content on the sub-page, and when a visitor goes there (direct link sans
> frameset), there is *no* header, footer, and more importantly, no
> navigation.

Google doesn't need to know anything about any of my app's pages -
indeed, shouldn't because the users need to login to reach them.

> That should do it, eh?

Yep, sure does.

Re: Help with HTML frames

Tim Streater wrote:

> "Beauregard T. Shagnasty" wrote:
>> Tim Streater wrote:
>>> Again, you don't say why it's better, you merely assert that it is.
>>
>> 1. There is only one page to deal with, not three or four (frameset,
>> heading page, nav page, footer page, and of course, content page).
>
> It may ease the implementer's task, but so what.

Ok, some people like to make things more complicated.

>> 2. While looking at any of the sub-pages (in this case images), a
>> visitor can *bookmark* the sub-page, unlike in frames where only the
>> frameset page can be bookmarked.
>
> The main page in my app is reached via a table on another page. The
> table contents may change (not very often, but it happens) based on
> database contents. So they shouldn't be bookmarking even the main page,
> as it may not exist at some future point. And they certainly shouldn't
> be bookmarking the sub pages, as they are likely to get rubbish (data is
> passed back and forth via JS variables in the top frame).

Do you have full control of your 50 users' browsers? If JavaScript is
disabled, that will certainly fail.

> In fact, if I had my way, I'd prevent any of these going into the
> history stack.

JavaScript should be able do that, for those who have it enabled.

>> 3. Assuming pages of text rather than images, Google will index the
>> content on the sub-page, and when a visitor goes there (direct link
>> sans frameset), there is *no* header, footer, and more importantly,
>> no navigation.
>
> Google doesn't need to know anything about any of my app's pages -
> indeed, shouldn't because the users need to login to reach them.

You didn't say that before...

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Help with HTML frames

Post removed (X-No-Archive: yes)

Re: Help with HTML frames

Post removed (X-No-Archive: yes)

Re: Help with HTML frames

In article ,
"Beauregard T. Shagnasty" wrote:

> Tim Streater wrote:
>
> > "Beauregard T. Shagnasty" wrote:
> >> Tim Streater wrote:
> >>> Again, you don't say why it's better, you merely assert that it is.
> >>
> >> 1. There is only one page to deal with, not three or four (frameset,
> >> heading page, nav page, footer page, and of course, content page).
> >
> > It may ease the implementer's task, but so what.
>
> Ok, some people like to make things more complicated.
>
> >> 2. While looking at any of the sub-pages (in this case images), a
> >> visitor can *bookmark* the sub-page, unlike in frames where only the
> >> frameset page can be bookmarked.
> >
> > The main page in my app is reached via a table on another page. The
> > table contents may change (not very often, but it happens) based on
> > database contents. So they shouldn't be bookmarking even the main page,
> > as it may not exist at some future point. And they certainly shouldn't
> > be bookmarking the sub pages, as they are likely to get rubbish (data is
> > passed back and forth via JS variables in the top frame).
>
> Do you have full control of your 50 users' browsers? If JavaScript is
> disabled, that will certainly fail.

Then they have my phone number, and I will ask them what sort of
Internet engineer are they, running without JS to our database front-end
site. This has not been a problem in the 8 years since I started
developing this.

> > In fact, if I had my way, I'd prevent any of these going into the
> > history stack.
>
> JavaScript should be able do that, for those who have it enabled.

Interesting. When I looked into this, the docs I looked at seemed to be
quite clear that there was no way to prevent a page going into the
history stack, and that this was deliberate.

> >> 3. Assuming pages of text rather than images, Google will index the
> >> content on the sub-page, and when a visitor goes there (direct link
> >> sans frameset), there is *no* header, footer, and more importantly,
> >> no navigation.
> >
> > Google doesn't need to know anything about any of my app's pages -
> > indeed, shouldn't because the users need to login to reach them.
>
> You didn't say that before...

Well, there it is. The dangers of making assumptions ...

Re: Help with HTML frames

Tim Streater wrote:

> Then they have my phone number, and I will ask them what sort of
> Internet engineer are they, running without JS to our database front-end
> site. This has not been a problem in the 8 years since I started
> developing this.

You miss the point entirely. What you do for your "web"site for your 50
engineers has *nothing* to do for *recommended* practice for public
website design. You may *force* your 50 engineers to install an IE
ActiveX control so your page can embed AutoCAD drawings but this should
not be general advice, especially for newbies on web design.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Help with HTML frames

In article <7f5a8$4718d98d$40cba7cb$2595@NAXS.COM>,
"Jonathan N. Little" wrote:

> Tim Streater wrote:
>
> > Then they have my phone number, and I will ask them what sort of
> > Internet engineer are they, running without JS to our database front-end
> > site. This has not been a problem in the 8 years since I started
> > developing this.
>
> You miss the point entirely. What you do for your "web"site for your 50
> engineers has *nothing* to do for *recommended* practice for public
> website design. You may *force* your 50 engineers to install an IE
> ActiveX control so your page can embed AutoCAD drawings but this should
> not be general advice, especially for newbies on web design.

I never said that it did. I "force" them, as you put it, to use JS,
hardly an onerous requirement is this day and age. I know of no browser
that doesn't support it and the several I tested against the app gave,
by and large, no problems.

If I forced them to use IE6 or higher under XP *only*, as many sites
appear to do, then you might have something to complain about.

Re: Help with HTML frames

Tim Streater wrote:

> I never said that it did. I "force" them, as you put it, to use JS,
> hardly an onerous requirement is this day and age. I know of no
> browser that doesn't support it and the several I tested against the
> app gave, by and large, no problems.

http://offbyone.com/ :-)

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Help with HTML frames

Tim Streater wrote:
> In article <7f5a8$4718d98d$40cba7cb$2595@NAXS.COM>,
> "Jonathan N. Little" wrote:
>
>> Tim Streater wrote:
>>
>>> Then they have my phone number, and I will ask them what sort of
>>> Internet engineer are they, running without JS to our database front-end
>>> site. This has not been a problem in the 8 years since I started
>>> developing this.
>> You miss the point entirely. What you do for your "web"site for your 50
>> engineers has *nothing* to do for *recommended* practice for public
>> website design. You may *force* your 50 engineers to install an IE
>> ActiveX control so your page can embed AutoCAD drawings but this should
>> not be general advice, especially for newbies on web design.
>
> I never said that it did. I "force" them, as you put it, to use JS,
> hardly an onerous requirement is this day and age. I know of no browser
> that doesn't support it and the several I tested against the app gave,
> by and large, no problems.
>
> If I forced them to use IE6 or higher under XP *only*, as many sites
> appear to do, then you might have something to complain about.

The point is frames, a hack to begin with, are unnecessary today when a
webserver is involved and with the ubiquitous availability of
server-side scripting. Back at their creation, server-side was rare and
expensive and server-side languages were either in their infancy or yet
to be developed. Other than sheer ignorance I can see no use for them
except the narrow application where a webserver is not available, e.i.,
on local files systems, CD-ROM applications, very-very cheap hosting
with no server-side.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Help with HTML frames

Well bust mah britches and call me cheeky, on Fri, 19 Oct 2007 14:35:07
GMT Tim Streater scribed:

>> > If people said "You should use xyz instead of frames, and here's
>> > why, and here's an example using xyz that functions identically to
>> > this example using frames, and here's why its better" then sceptics
>> > like me might pay more attention.
>>
>> But if people always said what you wanted them to say, you'd have no
>> excuse to opt out from better methods of engineering your page...
>>
>> Here's an example of a non-frames page with a stationary header and
>> footer:
>>
>> http://www.neredbojias.com/_a/whelan1.html
>>
>> The nav happens to be in the header, but it could be anywhere. This
>> page works in ie6, ie7, firefox, and opera - all the browsers I am
>> currently able to test. No, the markup isn't exactly a "piece of
>> cake", but neither is it so esoteric as to be improbably conformed.
>> The point is don't be so lazy and you may be surprised by what you
>> can do.
>
> Again, you don't say why it's better, you merely assert that it is.

Why? -Progress, advancement. Also, it's ultimately simpler. Take
Microsoft out of the equation and it's a lot simpler.

> What I have created works just fine. Changing it to another approach
> is way down my list of priorities.

Don't get me wrong. I'm not one of those people who condemns frame
usage. Frames are fine much of the time and the reasons cited against
them often seem trivial to me. Nevertheless, with today's markup
advancements (-as flawed as they sometimes are) and additional server-
side options, it is usually easier to employ other methods for the older
and more cumbersome practices which frames require to accomplish the same
goals. The "fly in the ointment" is Internet Explorer, but there are
workarounds even for that available to those who endeavor to keep their
skills as current as they should.

--
Neredbojias

Re: Help with HTML frames

Well bust mah britches and call me cheeky, on Fri, 19 Oct 2007 15:50:00
GMT Tim Streater scribed:

>> > In fact, if I had my way, I'd prevent any of these going into the
>> > history stack.
>>
>> JavaScript should be able do that, for those who have it enabled.
>
> Interesting. When I looked into this, the docs I looked at seemed to
> be quite clear that there was no way to prevent a page going into the
> history stack, and that this was deliberate.

This isn't true at all. Location.replace() replaces a page without adding
a slot to the history. Perhaps the docs you mention were once correct but
not updated when updating would have been manifestly prudent...

--
Neredbojias

Re: Help with HTML frames

Well bust mah britches and call me cheeky, on Fri, 19 Oct 2007 15:48:39
GMT still me scribed:

> On Fri, 19 Oct 2007 14:08:52 +0000 (UTC), Neredbojias
> wrote:
>
>>No, the markup isn't exactly a "piece of cake", but neither
>>is it so esoteric as to be improbably conformed. The point is don't
>>be so lazy and you may be surprised by what you can do.
>
> If you don't mind a secondary scroll bar (which can actually be a
> major feature), you can do it a lot simpler with just a scrollable
> div.

Hah, the example I gave is actually just that with a secondary scrollbar
hidden underneath the top (-in ie, of course). [This was done because ie6
miscalculates widths of auto-scrolling divs otherwise.]

--
Neredbojias

Re: Help with HTML frames

In article ,
"Jonathan N. Little" wrote:

> The point is frames, a hack to begin with, are unnecessary today when a
> webserver is involved and with the ubiquitous availability of
> server-side scripting. Back at their creation, server-side was rare and
> expensive and server-side languages were either in their infancy or yet
> to be developed. Other than sheer ignorance I can see no use for them
> except the narrow application where a webserver is not available, e.i.,
> on local files systems, CD-ROM applications, very-very cheap hosting
> with no server-side.

Anyway, I recall moving from frames a while back after getting
fed up of a few things and being gently prodded in this group...
not least by my old pal Mark Parnell. Talking about whom, anyone
feintly tempted by frames might as well do them well, pertinent
to which is:



--
dorayme

Re: Help with HTML frames

dorayme wrote:

> Anyway, I recall moving from frames a while back after getting
> fed up of a few things and being gently prodded in this group...
> not least by my old pal Mark Parnell. Talking about whom, anyone
> feintly tempted by frames might as well do them well, pertinent
> to which is:
>
>
>

Hey yeah, where is old Mark?

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Help with HTML frames

In article ,
"Jonathan N. Little" wrote:

> dorayme wrote:
>
> > Anyway, I recall moving from frames a while back after getting
> > fed up of a few things and being gently prodded in this group...
> > not least by my old pal Mark Parnell. Talking about whom, anyone
> > feintly tempted by frames might as well do them well, pertinent
> > to which is:
> >
> >
> >
>
> Hey yeah, where is old Mark?

He got a big and busy job and abandoned us all...

--
dorayme

Re: Help with HTML frames

dorayme wrote:
> In article ,
> "Jonathan N. Little" wrote:
>
>> dorayme wrote:
>>
>>> Anyway, I recall moving from frames a while back after getting
>>> fed up of a few things and being gently prodded in this group...
>>> not least by my old pal Mark Parnell. Talking about whom, anyone
>>> feintly tempted by frames might as well do them well, pertinent
>>> to which is:
>>>
>>>
>>>
>> Hey yeah, where is old Mark?
>
> He got a big and busy job and abandoned us all...
>
Oh, he got a life eh?

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Help with HTML frames

On 2007-10-21, Jonathan N. Little wrote:
> dorayme wrote:
[...]
>> He got a big and busy job and abandoned us all...
>>
> Oh, he got a life eh?

Since when was a big and busy job a life?

Re: Help with HTML frames

Ben C wrote:
> On 2007-10-21, Jonathan N. Little wrote:
>> dorayme wrote:
> [...]
>>> He got a big and busy job and abandoned us all...
>>>
>> Oh, he got a life eh?
>
> Since when was a big and busy job a life?

Getting monetary compensation for the time makes it a life.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Help with HTML frames

In article ,
Ben C wrote:

> On 2007-10-21, Jonathan N. Little wrote:
> > dorayme wrote:
> [...]
> >> He got a big and busy job and abandoned us all...
> >>
> > Oh, he got a life eh?
>
> Since when was a big and busy job a life?

True, when I am snowed under with work, I feel life has all but
expired... real life for me is time for utter nonsense,
inconsequentiality, trivia, idle speculation, putting some really
cheap parts in my car to keep it going (this is called doing a
lot with a little). I stand appalled at any other attitude.

--
dorayme