Link to another website, in an iframe, to a spot on page

[Beauregard T. Shagnasty]

You are mistaken here. I've been using HomeSite for years. It's a
very good plain text editor and web authoring tool. Some versions do
have some WYSIWYG-like features, but they are best ignored.

I may be confusing it with GoLive... but are you saying mjones typed
all that code manually? <phew!> It looks so .. generated!

 

[mjones]

I may be confusing it with GoLive... but are you saying mjones typed
all that code manually? <phew!> It looks so .. generated!

Ya, I typed most of it, unless I copied/pasted or used the pick from
the list method. HomeSite isn't WYSIWYMG. What do the experts use if
not HomeSite or Dreamweaver?

Thanks for the menu example Bergamot. I'm not a fan of the expanding/
contracting type of menu, however. It makes me motion sick, but I
know many like it. I call it mystery meat - you don't know what's
there until you mouse over or click.

I guess that's a no then on my original request.

I appreciate all your comments and ideas.

Thanks all and good night,

Michele

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Tue, 07 Aug 2007 06:20:29 GMT
mjones scribed:

Thanks for the menu example Bergamot. I'm not a fan of the expanding/
contracting type of menu, however. It makes me motion sick, but I
know many like it. I call it mystery meat - you don't know what's
there until you mouse over or click.

I guess that's a no then on my original request.

I appreciate all your comments and ideas.

Thanks all and good night,

I see the sign of the cause of the original problem. The content is being
delayed in loading (-include? -iframe? -javascript manipulation?) so
there is nothing "there yet" when the hash, #demarco, tries to operate.
When the content finally does appear, it's too late.

 

[Tim Streater]

Well bust mah britches and call me cheeky, on Tue, 07 Aug 2007 06:20:29 GMT
mjones scribed:


I see the sign of the cause of the original problem. The content is being
delayed in loading (-include? -iframe? -javascript manipulation?) so
there is nothing "there yet" when the hash, #demarco, tries to operate.
When the content finally does appear, it's too late.

Loading stuff in frames or iframes does take time, a problem especially
if other frames rely on the loaded information. I got round this sort of
problem by having the onLoad event of the slow-loading frame set a flag.
You can use a timer event elsewhere to pick this up. Unfortunately you
need to do this in a loop as JS doesn't give you the proper tools, but
at least you can avoid running the CPU at 100% by not simply spinning on
the flag.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Tue, 07 Aug 2007 09:23:41
GMT Tim Streater scribed:

Loading stuff in frames or iframes does take time, a problem
especially if other frames rely on the loaded information. I got round
this sort of problem by having the onLoad event of the slow-loading
frame set a flag. You can use a timer event elsewhere to pick this up.
Unfortunately you need to do this in a loop as JS doesn't give you the
proper tools, but at least you can avoid running the CPU at 100% by
not simply spinning on the flag.

That could work for the OP's problem by capturing any hash immediately and
processing it later. Might be a moderate PIA, though.

 

[Bergamot]

I may be confusing it with GoLive...

No comparison, really. HomeSite was created by a company called
Allaire (who also created Cold Fusion), which was bought by Macromedia
in 2001 and is now of course owned by Adobe. That ownership the only
thing HomeSite has in common with GoLive.

but are you saying mjones typed
all that code manually? <phew!> It looks so .. generated!

If it's that ugly, he more likely copy and pasted manually.

 

[Bergamot]

Thanks for the menu example Bergamot.

Are you confusing me with someone else? I don't know what you are
referring to.

 

[Adrienne Boswell]

Gazing into my crystal ball I observed mjones <michele@quality-
computing.com> writing in @r34g2000hsd.googlegroups.com:

How do I go about fixing it? Are you suggesting that I don't use
Javascript?

Javascript should be used as an enhancement. When vital elements do not
work, then yes, it's time to get rid of the javascript. Do something
server side.

We're getting 47% returning visitors. For the client's industry, I'm
happy with that.

You could be getting better.

 

[Tim Streater]

Gazing into my crystal ball I observed mjones <michele@quality-
computing.com> writing in @r34g2000hsd.googlegroups.com:


Javascript should be used as an enhancement. When vital elements do not
work, then yes, it's time to get rid of the javascript. Do something
server side.

Is this a general rule, then?

 

[Beauregard T. Shagnasty]

Is this a general rule, then?

A real rule? Probably not, but would you want to risk losing ~10% of
your annual business because visitors couldn't navigate your web site?
It's not an actual rule, but it certainly is good common sense, eh?

 

[Tim Streater]

A real rule? Probably not, but would you want to risk losing ~10% of
your annual business because visitors couldn't navigate your web site?
It's not an actual rule, but it certainly is good common sense, eh?

Well, it depends, doesn't it? The wesbite I manage at work is a front
end to our assets database. It's used by our engineers, finance,
development, and operations teams, and by selected engineers of some of
our customers. It wouldn't work worth beans with extensive use of
Javascript, PHP, and iframes.

 

[Beauregard T. Shagnasty]

Well, it depends, doesn't it? The wesbite I manage at work is a front
end to our assets database. It's used by our engineers, finance,
development, and operations teams, and by selected engineers of some
of our customers.

Your description implies that you have access control to this web site,
and that it is not a public site. If so, you can demand that your
engineers et al, have JavaScript enabled. You can even demand that they

It wouldn't work worth beans with [without?] extensive use of
Javascript, PHP, and iframes.

That would be your choice. PHP of course is server-side, and not
dependent upon the visitors' browser. Some people, though not as many as
with JavaScript, may block iframes as well.

Opera: Tools > Preferences > Advanced tab > Content
[ Style Options ] > Display tab
[X] Enable frames
[ ] Enable inline frames

Firefox: URL: about:config
Filter: frame
Change value for: browser.frames.enabled to false

We are saying that an author should not use a technology on a public
site that will render the site useless for a fair chunk of visitors.

 

[Tim Streater]

Your description implies that you have access control to this web site,
and that it is not a public site.
Correct.

If so, you can demand that your
engineers et al, have JavaScript enabled. You can even demand that they
all use "Internet Explorer 6 and above" if you wish. <g>

Well, I don't go that far

In fact it's unlikely they will be using IE, in my experience, although
I test against several browsers including IE.

It wouldn't work worth beans with [without?] extensive use of
Javascript, PHP, and iframes.

Typo, sorry.

That would be your choice. PHP of course is server-side, and not
dependent upon the visitors' browser. Some people, though not as many as
with JavaScript, may block iframes as well.

Opera: Tools > Preferences > Advanced tab > Content
[ Style Options ] > Display tab
[X] Enable frames
[ ] Enable inline frames

Firefox: URL: about:config
Filter: frame
Change value for: browser.frames.enabled to false

We are saying that an author should not use a technology on a public
site that will render the site useless for a fair chunk of visitors.

Depends if the author cares (or needs to care), I suppose. They can
always put some caveats on the page somewhere. That said, I can
obviously imagine that if the site is aimed at getting more and more
visitors it's important that it work for a wider set.

I've had no formal training in the area, so it could easily be that I do
a number of things the hard way without being aware of that. E.g I use
cascading popups where the content of popup n is set when the user
chooses from popup n-1. This avoids the popups containing several
hundred items, 90% of which are not relevant. My solution is to use the
results of the choice for popup n-1, to drive what is then loaded into
the iframe containing popup n. This also reduces the load on the
database server, and the size of the downloaded page.

So I'm quite proud of myself.

But then I lurk here, and I see it said that:

1) Javascript evil
2) Frames evil
3) iframes evil

and I'm never quite sure whether that's because:

1) the statements made pertain to a particular set of circumstances
2) these things really *are* evil and I am a bozo for being ignorant of
some other technique which solves all my problems pronto.

Hence my question.

 

[Jonathan N. Little]

Tim Streater wrote:

But then I lurk here, and I see it said that:

1) Javascript evil

Very useful but because of past abuse and security flaws I would say not
dependable.

2) Frames evil

Was an ad hoc way of modularizing web page content (or steal it) before
server-side solutions were readily available or affordable. Server-side
is far superior without the well discussed problems frames cause. Why
would you use an ax to cut down a tree after the advent of the chainsaw?

3) iframes evil

Ditto! Just an MS's take on the frame. As I recall frame was Netscape's
baby...

and I'm never quite sure whether that's because:

1) the statements made pertain to a particular set of circumstances
2) these things really *are* evil and I am a bozo for being ignorant of
some other technique which solves all my problems pronto.

Hence my question.

I'd say a little from #1 and a little from #2 ;-)

 

[Beauregard T. Shagnasty]

:

Depends if the author cares (or needs to care), I suppose. They can
always put some caveats on the page somewhere. That said, I can
obviously imagine that if the site is aimed at getting more and more
visitors it's important that it work for a wider set.

Caveats might work, in some circumstances. There was a poster in one of
these groups the other day, asking for some assistance on a site that
relied on JavaScript to display everything but the header logo and the
footer. To a visitor with JavaScript unavailable, the page was no more
than that logo, and a long, wide, empty blue box about three viewports
long. No navigation either.

But then I lurk here, and I see it said that:

1) Javascript evil
2) Frames evil
3) iframes evil

and I'm never quite sure whether that's because:

1) the statements made pertain to a particular set of circumstances
2) these things really *are* evil and I am a bozo for being ignorant of
some other technique which solves all my problems pronto.

1. Ok for fluff but not important stuff.
2. Google for "frames are evil" <g>
3. May be ok if for your own stuff (not capturing someone else's page)
and not too important.

Hence my question.

Understood.

 

[Ben C]

But then I lurk here, and I see it said that:

1) Javascript evil

JavaScript isn't evil at all and there are lots of things you can't do
any other way (at least not with just HTML and CSS).

So use it for those things, but not for things you can do perfectly well
or better with HTML and CSS.

2) Frames evil
3) iframes evil

But you don't very often need either of these.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Thu, 09 Aug 2007 20:32:27 GMT
Jonathan N. Little scribed:

Was an ad hoc way of modularizing web page content (or steal it) before
server-side solutions were readily available or affordable. Server-side
is far superior without the well discussed problems frames cause. Why
would you use an ax to cut down a tree after the advent of the chainsaw?

1. Perhaps he saw "The Texas Chainsaw Massacre" and was traumatized.
2. Perhaps he thinks he's George Washington.
3. Perhap he just wants to build-up some muscles to impress the girls.
4. Perhaps the buzz saw is outta gas.

Remember, just because something's old doesn't mean it's useless, and I'm
sure Duende has some equally-worthwhile saving graces, too.

 

[Blinky the Shark]

Your description implies that you have access control to this web site,
and that it is not a public site. If so, you can demand that your
engineers et al, have JavaScript enabled. You can even demand that they
all use "Internet Explorer 6 and above" if you wish. <g>

Or Netscape 4! He has The Power!