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

On Aug 6, 5:02 pm, "Chris F.A. Johnson" <cfajohn....RemoveThis@gmail.com> wrote:
> On 2007-08-06, mjones wrote:
> > On Aug 6, 2:47 pm, John Hosking <J....RemoveThis@DELETE.Hosking.name.INVALID>
> > wrote:
> ...
> >> Beauregard tends to travel unencumbered by JavaScript. With my JS turned
> >> off I see vast tracts of empty space on (the default pages of) both the
> >> sites mentioned. Doesn't matter what browser.
>
> > Our user stats show 0.39% with Java disabled and 0.77% with JavaScript
> > disabled. I guess we're okay then.
>
> No, it means that a lot of people don't bother returning to your
> site.
>
> --
> Chris F.A. Johnson <http://cfaj.freeshell.org>
> ===================================================================
> Author:
> Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

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

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

On 2007-08-06, mjones wrote:
> On Aug 6, 2:47 pm, John Hosking <J....RemoveThis@DELETE.Hosking.name.INVALID>
> wrote:
....
>> Beauregard tends to travel unencumbered by JavaScript. With my JS turned
>> off I see vast tracts of empty space on (the default pages of) both the
>> sites mentioned. Doesn't matter what browser.
>
> Our user stats show 0.39% with Java disabled and 0.77% with JavaScript
> disabled. I guess we're okay then.

No, it means that a lot of people don't bother returning to your
site.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

On 2007-08-06, mjones wrote:
> On Aug 6, 5:02 pm, "Chris F.A. Johnson" <cfajohn... RemoveThis @gmail.com> wrote:
>> On 2007-08-06, mjones wrote:
>> > On Aug 6, 2:47 pm, John Hosking <J... RemoveThis @DELETE.Hosking.name.INVALID>
>> > wrote:
>> ...
>> >> Beauregard tends to travel unencumbered by JavaScript. With my JS turned
>> >> off I see vast tracts of empty space on (the default pages of) both the
>> >> sites mentioned. Doesn't matter what browser.
>>
>> > Our user stats show 0.39% with Java disabled and 0.77% with JavaScript
>> > disabled. I guess we're okay then.
>>
>> No, it means that a lot of people don't bother returning to your
>> site.
>
> How do I go about fixing it? Are you suggesting that I don't use
> Javascript?

Exactly!

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

Think how much more it would be without JS.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

mjones wrote:
> On Aug 6, 1:56 pm, "Beauregard T. Shagnasty" wrote:

>> The resulting page, though, is still a large empty blue box "for the
>> month of August"...
>>
>> Are you: http://www.quality-computing.com/?
>> ..a large empty *dark* blue box. That site has the same problems.

>
> I'm not sure what you mean by a 'large empty *dark* blue box". This
> website works in IE6, IE7 and pretty much in FireFox, has been for
> several years, i.e. www.devitawellness.com works. Similarly, so does
> www.energywellnessstudies.com. And the 'month of August'? Whatever
> do you mean? It sounds like you're into the Tetigi software (the
> webstats stuff) from the bottom of the pages. What browser do you
> use?

Beauregard tends to travel unencumbered by JavaScript. With my JS turned
off I see vast tracts of empty space on (the default pages of) both the
sites mentioned. Doesn't matter what browser.


--
John
Pondering the value of the UIP: http://blinkynet.net/comp/uip5.html

Beauregard T. Shagnasty wrote:
> mjones wrote:
>
>> Yes, hand coded if I understand what you mean. I use HomeSite,
>
> Your sites are not hand-coded. Hand-coding is when you type everything
> in the "source" with your keyboard, not using a WYSIWYMG product such as
> HoseSite.

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.

--
Berg

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.

--
Neredbojias
Half lies are worth twice as much as whole lies.

In article <Xns998513C37187Dnanopandaneredbojias.TakeThisOut@198.186.190.161>,
Neredbojias <monstersquasher.TakeThisOut@yahoo.com> wrote:

> 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.

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.

Beauregard T. Shagnasty wrote:
> Bergamot wrote:
>
>> I've been using HomeSite for years. It's a
>> very good plain text editor and web authoring tool.
>
> 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.

--
Berg

mjones wrote:
>
> Thanks for the menu example Bergamot.

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

--
Berg

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

>> > 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.
>
> 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.

--
Neredbojias
Half lies are worth twice as much as whole lies.

In article <Xns998756C66AB9Darbpenyahoocom.DeleteThis@69.28.186.121>,
Adrienne Boswell <arbpen.DeleteThis@yahoo.com> wrote:

> Gazing into my crystal ball I observed mjones <michele@quality-
> computing.com> writing in news:1186434912.350208.135740
> @r34g2000hsd.googlegroups.com:
>
> >> > Our user stats show 0.39% with Java disabled and 0.77% with
> JavaScript
> >> > disabled. I guess we're okay then.
> >>
> >> No, it means that a lot of people don't bother returning to your
> >> site.
> >>
> >
> > 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.

Is this a general rule, then?

In article <fkIui.26692$ax1.198@bgtnsc05-news.ops.worldnet.att.net>,
"Beauregard T. Shagnasty" <a.nony.mous RemoveThis @example.invalid> wrote:

> Tim Streater wrote:
>
> > Adrienne Boswell <arbpen RemoveThis @yahoo.com> wrote:
> >> 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?
>
> 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.

In article <o1Jui.26746$ax1.22335@bgtnsc05-news.ops.worldnet.att.net>,
"Beauregard T. Shagnasty" <a.nony.mous.TakeThisOut@example.invalid> wrote:

> Tim Streater wrote:
>
> > "Beauregard T. Shagnasty" <a.nony.mous.TakeThisOut@example.invalid> wrote:
> >> Tim Streater wrote:
> >>> Adrienne Boswell <arbpen.TakeThisOut@yahoo.com> wrote:
> >>>> 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?
> >>
> >> 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.
>
> 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.