pre-loading a script

[dE|_]

Guys,

I resorted to wysiwyg software to write a fancy JS nav bar and I've hidden
an equivalent static HTML set underneath it for disabled browsers.

My problem is; I cant get the appearance of JS and HTML versions to match
pixel-perfect, so as the JS loads a split second late you get a double load
jerk effect.

How can I get the src= linked script to appear before the HTML hidden under
it?

Thanks for any pointers,

---dE|_---

[Peter Michaux]

On Mar 15, 11:54 am, "dE|_" <[e-mail]:

Guys,

I resorted to wysiwyg software to write a fancy JS nav bar and I've hidden
an equivalent static HTML set underneath it for disabled browsers.

My problem is; I cant get the appearance of JS and HTML versions to match
pixel-perfect, so as the JS loads a split second late you get a double load
jerk effect.

How can I get the src= linked script to appear before the HTML hidden under
it?

I recently explored some "jerk" problems and cross-browser loading.

<URL: http://peter.michaux.ca/article/7217>

Peter

[Peter Michaux]

On Mar 16, 9:26 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

I recently explored some "jerk" problems and cross-browser loading.

<URL:http://peter.michaux.ca/article/7217>

One of these "jerk problems" that you miss is that some people keep
advocating to use only the proprietary, inherently unreliable
`window.onload' property

I feature tested for addEventListener and attachEvent on the global
object.

while there are standards-compliant, reliable
alternatives.

What? The body onload attribute?

Peter

[Peter Michaux]

On Mar 16, 12:52 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
I recently explored some "jerk" problems and cross-browser loading.
<URL:http://peter.michaux.ca/article/7217>
One of these "jerk problems" that you miss is that some people keep
advocating to use only the proprietary, inherently unreliable
`window.onload' property
I feature tested for addEventListener and attachEvent on the global
object.
That is only as error-prone.

Why?

Because the Global Object is a native object, not a DOM host object. It
does not need to implement the EventTarget interface of W3C DOM Level 2+
Events or another API.

I'm not so hung up about standardized DOM objects vs non-standard
objects. I use XMLHttpRequest objects based on feature tests. If I
feature test that the global object has addEventListener then it is a
reasonably safe bet the global object will support the onload event.

You should forego attachEvent()

And do what for IE?

Either window.onload or (better) the `onload' attribute of the `body' element.

Well if I was doing that for IE then I would probably just do that for
all browsers.

I've seen in your libray code (http://pointedears.de/scripts/dhtml.js)
that you don't use attachEvent but the reason sited in the comments
did not seem compelling. In the following page which you site

http://www.quirksmode.org/blog/archi...nt_consid.html

PPK seems quite excited about the fact that the "this" keyword doesn't
work the same in the event handlers for IE and W3C. This may have been
an issue when PPK wrote the article but it is no longer considered an
insurmountable challenge for an event library to correct.

[snip]

Peter

[Jeremy J Starcher]

On Sun, 16 Mar 2008 14:42:18 -0700, VK wrote:

Well, if you have a script-generated menu and a static fall-back menu
then the most obvious solution would be to use <script><noscript>
blocks:

Alas, I've found noscript to be fragile.

One of my Javascript stopper plugins under Firefox will keep JS from
running, but won't parse noscript blocks, leaving the user with nothing.

In addition, some firewalls/proxies will strip out Javascript, even
though the browser itself has JS support turned on. Again, the noscript
block will not render.