Problem with preloading page in hidden div

Chris Tomlinson · Jun 22, 2006

Hi all, hope someone is able to help!...

We have created this page:
http://www.superhighstreet.com/George-Street-Richmond/splash

The purpose of it is:
* To catch visitors' e-mail addresses
* To 'secretly' preload the large page that follows when you click the big
button

1) Is there any way to stop the mouse cursor in IE and other browsers
having a geriatric fit during the loading of the big page in the hidden
div/iframe? This makes it unsightly and difficult for users to click inside
the form field.

2) Although we have added
<script>document.join.q.focus();</script>
under the form, and added name=join to the form tag, the cursor still does
not jump into the form field automatically. Yet this works fine at our
other page www.superhighstreet.com/home where it is used.

Thanks in advance for any tips. If you don't have an answer please don't
feel a need to reply

Chris Tomlinson · Jun 22, 2006

Chris Tomlinson said:
Hi all, hope someone is able to help!...

We have created this page:
http://www.superhighstreet.com/George-Street-Richmond/splash

The purpose of it is:
* To catch visitors' e-mail addresses
* To 'secretly' preload the large page that follows when you click the big
button

1) Is there any way to stop the mouse cursor in IE and other browsers
having a geriatric fit during the loading of the big page in the hidden
div/iframe? This makes it unsightly and difficult for users to click
inside the form field.

2) Although we have added
<script>document.join.q.focus();</script>
under the form, and added name=join to the form tag, the cursor still does
not jump into the form field automatically. Yet this works fine at our
other page www.superhighstreet.com/home where it is used.

Thanks in advance for any tips. If you don't have an answer please don't
feel a need to reply

Ok well I'm kind of getting somewhere. I have now added some
style="cursor:text" code to try to make the cursor behave, but it doesn't
take effect until after the hidden preload div has finished its stuff.

I have also got the <script>document.join.YMLP1.focus();</script> working,
but even though the cursor goes into the box, you can't type until the
preload div finishes

Any other ideas on a better way to preload the next page that will make this
one fully functional during that process?
--
Thanks,
Me

Try Google Quik-e-search™ at www.Superhighstreet.com/home
....Finds anything or they buy it for you!

Neredbojias · Jun 22, 2006

Ok well I'm kind of getting somewhere. I have now added some
style="cursor:text" code to try to make the cursor behave, but it
doesn't take effect until after the hidden preload div has finished
its stuff.

I have also got the <script>document.join.YMLP1.focus();</script>
working, but even though the cursor goes into the box, you can't type
until the preload div finishes

Any other ideas on a better way to preload the next page that will
make this one fully functional during that process?

I see something like <body onload="Preload Images...

Do you "onload" the preloading of the "big page" as well? Also, the j/s
on the page is very, uh, 'unbalanced' and seems overly-complicated. I'm
sure it could be simplified and made more correct. Also, the page has no
doctype. Does it validate? I suspect not.

Randy Webb · Jun 22, 2006

Chris Tomlinson said the following on 6/22/2006 8:28 AM:
How do you think you can do that?

And if I don't click the "big button"?

Chris Tomlinson · Jun 22, 2006

Randy Webb said:
Chris Tomlinson said the following on 6/22/2006 8:28 AM:

How do you think you can do that?

By them typing them in. It's a splash page to optionally request a
visitor's e-mail. I don't mean 'catch' in a sneaky way.

And if I don't click the "big button"?

Then nothing happens - you don't visit the streetscape. It's still in your
cache if you ever do though.

Chris Tomlinson · Jun 22, 2006

I see something like <body onload="Preload Images...

No that is just for the rollover buttons.

Do you "onload" the preloading of the "big page" as well?

Well we would love to, but we are unable to find a way to 'onload' preload
the next page (unless you use WebTV). If you know a way, do let us know!

As mentioned, we currently load the next big page in a hidden div on:
http://www.superhighstreet.com/George-Street-Richmond/splash
and that is where the problem lies. Because it loads in the same page, it
affects the mouse cursor and form entry user experience.

Also, the j/s
on the page is very, uh, 'unbalanced' and seems overly-complicated. I'm
sure it could be simplified and made more correct.

Early days yet... but that is not our problem at the moment. Thanks for
pointing it out though.

Also, the page has no
doctype. Does it validate? I suspect not.

Well based on your comment we have now added <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN" > but can you please briefly mention
the benefit of doing so as all the pages seem to work fine without this, in
all browsers.

To summarise, I think our question should have been, "What is a better way
to preload the big page, as the current way does not work satisfactorily".
--
Thanks,
Me

Try Google Quik-e-search™ at www.Superhighstreet.com/home
....Finds anything or they buy it for you!

Jonathan N. Little · Jun 22, 2006

Chris said:
No that is just for the rollover buttons.

Well we would love to, but we are unable to find a way to 'onload' preload
the next page (unless you use WebTV). If you know a way, do let us know!
As mentioned, we currently load the next big page in a hidden div on:
http://www.superhighstreet.com/George-Street-Richmond/splash
and that is where the problem lies. Because it loads in the same page, it
affects the mouse cursor and form entry user experience.

Actually my browser does that automatically during idle time.
SeaMonkey's advance setting for prefetch links. Of course another option
is to optimize your next page! Your page has taken several minutes(no
exaggeration here)and it *still* hasn't finished loading! I should have
timed this!

What with the 6,953px × 290px image! That's insane.

Dang another one at 7,172px × 290px and 3,548px × 290px and 6,533px ×
290px and 2,605px × 290px. Plus a slew of other smaller images! You need
to find a competent designer.

Documents (56 files) 196 kb
Images (107 files) 2127 kb
Style Sheets (1 file) 2 kb
Scripts (6 files) 124 kb

Chris Tomlinson · Jun 23, 2006

Actually my browser does that automatically during idle time. SeaMonkey's
advance setting for prefetch links. Of course another option is to
optimize your next page! Your page has taken several minutes(no
exaggeration here)and it *still* hasn't finished loading! I should have
timed this!

What speed is your connection? On slow broadband (512) it loads in no more
than 15 seconds, unless you hit a temporary glitch.

What with the 6,953px × 290px image! That's insane.

It's by design. We are aware of many flash web sites which are similar size
downloads.

Dang another one at 7,172px × 290px and 3,548px × 290px and 6,533px ×
290px and 2,605px × 290px. Plus a slew of other smaller images! You need
to find a competent designer.

Documents (56 files) 196 kb
Images (107 files) 2127 kb
Style Sheets (1 file) 2 kb
Scripts (6 files) 124 kb

You're stating the obvious here. That is the only way to achieve the beauty
of what this site does. The solution is to preload the page, which is the
entire reason for our question.

All you have done is tell us what size the "big page" is, but we already
knew that. What would help is if you were able to tell us how to preload it
from the splash page.

Thanks if so.

Jonathan N. Little · Jun 23, 2006

Chris said:
What speed is your connection? On slow broadband (512) it loads in no more
than 15 seconds, unless you hit a temporary glitch.

I am on dialup, no broadband available. May folks are still stuck with it.

It's by design. We are aware of many flash web sites which are similar size
downloads.

No, not 2.5MB That is way over the top of a webpage.

dorayme · Jun 23, 2006

Jonathan N. Little said:
I am on dialup, no broadband available. May folks are still stuck with it.

No, not 2.5MB That is way over the top of a webpage.

I agree, it is far too big as a general page offered to the
public. If you link to such a page with an explanation of what
they are in for, fine. But then you need not preload or postload
or anyload anything. They either go and wait as warned or don't
wait because they are on a fast connection and they know it and
are proud of it...

Neredbojias · Jun 23, 2006

No that is just for the rollover buttons.

Well we would love to, but we are unable to find a way to 'onload'
preload the next page (unless you use WebTV). If you know a way, do
let us know!

Of course I do. But...

As mentioned, we currently load the next big page in a hidden div
n:
http://www.superhighstreet.com/George-Street-Richmond/splash
and that is where the problem lies. Because it loads in the same
page, it affects the mouse cursor and form entry user experience.

....What I don't know is how you load (or preload) a page into a div.
Pages just aren't loaded into divs; it isn't possible, barring something
wierd and non-html. On the other hand, perhaps you are loading the
_content_ of the (next) page into a div?? The what-looks-like FrontPage
javascript routines might possibly suck like the rest of Microsoft
software.

Well based on your comment we have now added <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN" > but can you please briefly
mention the benefit of doing so as all the pages seem to work fine
without this, in all browsers.

Unfortunately, I lack the eloquence, but if you don't know why you should
use a doctype and what the doctype should really be, briefness wouldn't
suffice, anyway.

To summarise, I think our question should have been, "What is a better
way to preload the big page, as the current way does not work
satisfactorily".

As I intimated before: put whatever you want preloaded in the body's
onload event.

Chris Tomlinson · Jun 23, 2006

Hi, thanks for the reply...

...What I don't know is how you load (or preload) a page into a div.
Pages just aren't loaded into divs; it isn't possible, barring something
wierd and non-html. On the other hand, perhaps you are loading the
_content_ of the (next) page into a div?? The what-looks-like FrontPage

Sorry we should have recapped but in the original post we talked about the
"loading of the big page in the hidden div/iframe". The hidden div contains
an iframe which calls the 'big page'. It was a nice idea.

As I intimated before: put whatever you want preloaded in the body's
onload event.

Great, would you kindly show us the correct format to use onload to preload
an .htm page in its entirety.

Much appreciated.

Chris Tomlinson · Jun 23, 2006

dorayme said:
I agree, it is far too big as a general page offered to the
public. If you link to such a page with an explanation of what
they are in for, fine. But then you need not preload or postload
or anyload anything. They either go and wait as warned or don't
wait because they are on a fast connection and they know it and
are proud of it...

We take your points on board. It is a big dilemma, as once the page is
loaded the user experience is impressive. If we loaded the slices of the
image only when the user called them, it wouldn't provide for a seamless
scroll down the street.

What we are hoping to do based on your feedback is combine two effects:

1) Use the splash page which asks for their e-mail, to start preloading the
page (they need not know about this)

2) When they enter the big page, have some sort of 'floating flash progress
bar' which will tell them how close the page is to loading.

Are you guys able to point us in the right direction of a nice swf device
like this? It needs to sit near the bottom of the page over the
streetscape, so that it doesn't obscure the street introduction which they
can be reading whilst the page loads.

Neredbojias · Jun 23, 2006

Sorry we should have recapped but in the original post we talked about
the "loading of the big page in the hidden div/iframe". The hidden
div contains an iframe which calls the 'big page'. It was a nice
idea.

Ah, I should have guessed.

Great, would you kindly show us the correct format to use onload to
preload an .htm page in its entirety.

Much appreciated.

There are several ways. (I assume you are familiar with the javascript
onload event: onload=somefunction.) The best and correct way is to (pre)
load just the _contents_ of the page, usually meaning images. The text
of an even fairly-lengthy page loads fast and is normally considered
negligable. Another way is to have the function called by the onload
event insert the future page url into the source of your iframe. Another
way is to have the same function insert the future url into an object.
Another way is to open an invisible window with the future page as its
source. Another way is to use frames, but that is generally frowned
upon.

That's all I can think of right now.

Chris Tomlinson · Jun 23, 2006

There are several ways. (I assume you are familiar with the javascript
onload event: onload=somefunction.) The best and correct way is to (pre)
load just the _contents_ of the page, usually meaning images. The text
of an even fairly-lengthy page loads fast and is normally considered
negligable.

Our big page is a bit of a unqiue entity in that it loads a few big images,
and many more small ones. (This was the best way to achieve the ePosters in
the shop windows, and have them automatically updatable.) There are also
swf sounds, iframes, google map, etc.

Therefore it is preferable to just preload the entire page, rather than
specify all the seperate elements *of* that same page, so...

Another way is to have the function called by the onload
event insert the future page url into the source of your iframe.

Would you be kind enough to show us the correct code for this? Remember
first though, it needs to solve the original problem of this thread, namely
that our hidden div with the iframe containing the big page messes around
with the cursor and form entry whilst it is preloading into the cache.

Another
way is to have the same function insert the future url into an object.

Again, would you be able to show us the correct code for this? Remember...

Another way is to open an invisible window with the future page as its
source.

I suspect this may be the best and least interfering option. I assume
pop-up blockers don't mind this. Would you be able to show us the correct
code for this? Remember first though...

Joel Shepherd · Jun 23, 2006

Chris Tomlinson said:
Well based on your comment we have now added <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN" > but can you please briefly mention
the benefit of doing so as all the pages seem to work fine without this, in
all browsers.

The benefit (assuming the doctype is correct: it looks plausible) is
that you can now pass the page source through a validator, which in turn
will tell you whether your HTML is valid (i.e., well-formed). Without
getting into the panty-bunching aspects of validation, it can be very
helpful for pointing out gross errors such as missing and improperly
nested tags.

Sorting that out, in turn, can resolve some page rendering problems, and
help ensure that the page continues to render reasonable well on
browsers not yet in the wild: i.e., future-proof the page.

Neredbojias · Jun 23, 2006

Our big page is a bit of a unqiue entity in that it loads a few big
images, and many more small ones. (This was the best way to achieve
the ePosters in the shop windows, and have them automatically
updatable.) There are also swf sounds, iframes, google map, etc.

Therefore it is preferable to just preload the entire page, rather
than specify all the seperate elements *of* that same page, so...

'Though you might say that.

Would you be kind enough to show us the correct code for this?
Remember first though, it needs to solve the original problem of this
thread, namely that our hidden div with the iframe containing the big
page messes around with the cursor and form entry whilst it is
preloading into the cache.

Hopefully, onloading will do that but it's something you'll have to try.

OTTOMH...

<iframe id="iffy"...

function petunia() {
document.getElementById('iffy').src="newpage.html";
}

onload=petunia;

....in the said:
Again, would you be able to show us the correct code for this?
Remember...

Same as iframe but using said:
I suspect this may be the best and least interfering option. I assume
pop-up blockers don't mind this. Would you be able to show us the
correct code for this? Remember first though...

Use the window.open function with the page to-be-loaded as url. Like...

var dupa=window.open('newpage.html,'gnupage','');

The j/s code within newpage.html should blur the page and make it
invisible if loaded via preload. This last can be done something like...

if (opener) document.body.style.visibility='hidden';

Chris Tomlinson · Jun 26, 2006

Hi Neredbojias, thanks for that. Just a couple of Qs before we try this:

<iframe id="iffy"...

function petunia() {
document.getElementById('iffy').src="newpage.html";
}

onload=petunia;

...in the <body> section.

How would this differ to our current method of loading the iframe in a
hidden div?

Use the window.open function with the page to-be-loaded as url. Like...

var dupa=window.open('newpage.html,'gnupage','');

The j/s code within newpage.html should blur the page and make it
invisible if loaded via preload. This last can be done something like...

if (opener) document.body.style.visibility='hidden';

What is the advantage of bluring and hiding the page, if the popup window is
invisible anyway?
Is that the exact j/s we need to enter in the target big page?

--
Thanks,
Me

Try Google Quik-e-search™ at www.Superhighstreet.com/home
....Finds anything or they buy it for you!

Andy Dingley · Jun 26, 2006

Joel said:
The benefit (assuming the doctype is correct: it looks plausible) is
that you can now pass the page source through a validator, which in turn
will tell you whether your HTML is valid (i.e., well-formed).

Please don't confuse validity and well-formedness.

Joel Shepherd · Jun 27, 2006

Please don't confuse validity and well-formedness.

Uh ... Yeah, that's a good point. I don't have a strict definition in
front of me, but I believe it's reasonable to say that well-formedness
includes points such as elements that require end tags, having end tags,
proper nesting of elements, and proper key-value-separator syntax for
attributes. It wouldn't include points such as specific element and
attribute names, logical nesting rules (e.g., p can include span but not
vice-versa), order and frequency of certain elements such as html, head
and body, and so on. The latter go beyond well-formedness and are the
province of the validator.

Clearer?

Help with my responsive home page	2	Dec 14, 2022
Image shifts to the right when export the page to pdf	4	May 5, 2023
Help with code	0	Jun 12, 2022
I Need Help with making a function that draws in a canvas using location data.	1	Dec 17, 2021
HCaptcha - How to stop page from refreshing on submit if captcha is not checked/validated	1	Aug 29, 2023
Help with Visual Lightbox: Scripts	2	May 3, 2023
Gallery - mosiac/grid layout with filtering and information page popup	1	Apr 13, 2020
Another Password Confirmation	2	Sep 22, 2023

Problem with preloading page in hidden div

Chris Tomlinson

Chris Tomlinson

Neredbojias

Randy Webb

Chris Tomlinson

Chris Tomlinson

Jonathan N. Little

Chris Tomlinson

Jonathan N. Little

dorayme

Neredbojias

Chris Tomlinson

Chris Tomlinson

Neredbojias

Chris Tomlinson

Joel Shepherd

Neredbojias

Chris Tomlinson

Andy Dingley

Joel Shepherd

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads