Problem with preloading page in hidden div
Chris Tomlinson
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 ;)
--
Thanks,
Me
Chris Tomlinson
news:6zlmg.89874$wl.2...@text.news.blueyonder.co.uk...
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
vouchsafed:
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.
--
Neredbojias
Infinity has its limits.
Randy Webb
> "Chris Tomlinson" <an...@anon.com> wrote in message
> news:6zlmg.89874$wl.2...@text.news.blueyonder.co.uk...
>> 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
How do you think you can do that?
>> * To 'secretly' preload the large page that follows when you click the big
>> button
And if I don't click the "big button"?
--
Randy
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Chris Tomlinson
"Randy Webb" <HikksNo...@aol.com> wrote in message
news:_rSdnRS7dLWVagfZ...@comcast.com...
> Chris Tomlinson said the following on 6/22/2006 8:28 AM:
>> "Chris Tomlinson" <an...@anon.com> wrote in message
>> news:6zlmg.89874$wl.2...@text.news.blueyonder.co.uk...
>>> 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
>
> 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.
>>> * To 'secretly' preload the large page that follows when you click the
>>> big button
>
> 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
message
> 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".
Jonathan N. Little
> "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote in
> message
>
>> 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.
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
--------------------------------
Total 2449 kb!!!!!
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Chris Tomlinson
news:1926b$449b1a8d$40cba7bb$13...@NAXS.COM...
> 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
> --------------------------------
> Total 2449 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
> "Jonathan N. Little" <lws...@centralva.net> wrote in message
> news:1926b$449b1a8d$40cba7bb$13...@NAXS.COM...
>
>> 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.
I am on dialup, no broadband available. May folks are still stuck with it.
>
>> 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.
No, not 2.5MB That is way over the top of a webpage.
dorayme
"Jonathan N. Little" <lws...@centralva.net> wrote:
> Chris Tomlinson wrote:
> > "Jonathan N. Little" <lws...@centralva.net> wrote in message
> > news:1926b$449b1a8d$40cba7bb$13...@NAXS.COM...
> >
> >> 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.
>
> I am on dialup, no broadband available. May folks are still stuck with it.
> >
> >> 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.
>
> 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...
--
dorayme
Neredbojias
vouchsafed:
>> 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!
> :)
Of course I do. But...
> 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.
...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.
>> 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.
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
"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote in
message
>> 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.
>
> ...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.
>> 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.
Great, would you kindly show us the correct format to use onload to preload
an .htm page in its entirety.
Much appreciated.
--
Thanks,
Me
Chris Tomlinson
news:doraymeRidThis-318...@news-vip.optusnet.com.au...
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.
--
Thanks,
Me
Neredbojias
vouchsafed:
>>> 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.
>>
>> ...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.
Ah, I should have guessed.
>>> 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.
>
> 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
message
>> 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.
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... :D
--
Thanks,
Me
Joel Shepherd
> "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html>
>
> > 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.
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.
--
Joel.
Neredbojias
vouchsafed:
>>> 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.
>
> 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.
>> 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.
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 <body> section.
>> 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...
>:)
Same as iframe but using <object>.
>> 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... :D
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
>>> 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?
> <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?
>>> Another
>>> way is to have the same function insert the future url into an
>>> object.
>
> Same as iframe but using <object>.
>
>>> 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... :D
>
> 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?
Andy Dingley <dingbat@codesmiths.com>
> 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
wrote:
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?
--
Joel.
Andy Dingley <dingbat@codesmiths.com>
Joel Shepherd wrote:
> 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,
Close, but still no cigar.
Is the intaweb so short of half-baked partially correct answers that
people have to keep posting more of them? There's a whole pile of
reference material out there - if you don't know, or you aren't damned
sure you're right, or even if you just _aren't_ right, then either look
it up first or put a sock in it.
Alan J. Flavell
> "Andy Dingley <din...@codesmiths.com>" <din...@codesmiths.com>
> wrote:
>
> > 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,
Then you should make it your business to do so, before putting digits
to keyboard again.
> but I believe it's reasonable to say
The definitions of validity and well-formedness are not a matter of
"belief".
Neredbojias
<joel...@ix.netcom.com> vouchsafed:
Let me analogize. Well-formedness is a quality of body-shape and validity
is if she's married or not. However, when the former is more obviated than
the latter, some people just don't care.
Joel Shepherd
> On Tue, 27 Jun 2006, Joel Shepherd wrote:
>
> > "Andy Dingley <din...@codesmiths.com>" <din...@codesmiths.com>
> > wrote:
> >
> > > Please don't confuse validity and well-formedness.
Okay, and thank you, Andy, for not taking advantage of several
opportunities to help clear up that confusion.
> > but I believe it's reasonable to say
>
> The definitions of validity and well-formedness are not a matter of
> "belief".
If you were to parse that phrase carefully, you would see that there is
no such implication.
Now that you've corrected me, how about putting some digits back on the
keyboard, and clearing up the OP's confusion as well. You are more
qualified to do so, and it's a shame to withhold knowledge and
understanding that you are fortunate enough to have acquired.
--
Joel.
Andy Dingley <dingbat@codesmiths.com>
> Okay, and thank you, Andy, for not taking advantage of several
> opportunities to help clear up that confusion.
If you can't Google it, I can't teach it.