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]

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

 

[Thomas 'PointedEars' Lahn]

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 while there are standards-compliant, reliable
alternatives.


PointedEars

 

[Peter Michaux]

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

 

[Thomas 'PointedEars' Lahn]

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

That is only as error-prone. You should forego attachEvent() and apply
addEventListener() on the `document' property if it refers to a DOM object.

What? The body onload attribute?

That or see above. Unfortunately, I have just found out that the latter
requires the current DOM Level 3 Events working draft to be implemented.
That does not appear to be the case in Gecko 1.8.x or MSHTML, which would
leave the `onload' attribute as the only available option to fulfill these
requirements.


PointedEars

 

[Peter Michaux]

That is only as error-prone.
Why?

You should forego attachEvent()

And do what for IE?

and apply
addEventListener() on the `document' property if it refers to a DOM object.



That or see above. Unfortunately, I have just found out that the latter

Which one is "the latter"?

requires the current DOM Level 3 Events working draft to be implemented.
That does not appear to be the case in Gecko 1.8.x or MSHTML, which would
leave the `onload' attribute as the only available option to fulfill these
requirements.

Peter

 

[Thomas 'PointedEars' Lahn]

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

And do what for IE?

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

Which one is "the latter"?

document.addEventListener("load", ...);


PointedEars

 

[Peter Michaux]

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.

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/archives/2005/08/addevent_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

 

[Thomas 'PointedEars' Lahn]

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

However, it is less likely that a native object would implement a method
designed for DOM objects. And if the feature test failed you would be left
with window.onload or nothing.

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

Yes, the logical conclusion of these observations is that you should use the
`onload' attribute of the `body' element for all user agents, including Web
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/archives/2005/08/addevent_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.

It becomes compelling when you consider that all event listeners have to be
called as methods of window.event.srcElement just to accomodate their being
usable with MSHTML's attachEvent().

But the `this' keyword is rather the less important reason why not to use
attachEvent(). You have missed that PPK's document also points out what the
MSDN Library says: Event listeners that are attached this way are executed
in arbitrary order.


PointedEars

 

[Peter Michaux]

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.

However, it is less likely

Sure "less likely" but as we have noted over the months, all of this
feature testing doesn't make any guarantees but only makes us
relatively confident that the user agent to execute the code
correctly. Once the developer is far enough into the "safe zone" then
it will be personal preference how much more to test. This extra
testing could be considered paranoia and over testing by others.

[snip]

It becomes compelling when you consider that all event listeners have to be
called as methods of window.event.srcElement just to accomodate their being
usable with MSHTML's attachEvent().

I call the event handler with Function.prototype.apply so I can choose
the "this" object freely and reliably.

But the `this' keyword is rather the less important reason why not to use
attachEvent(). You have missed that PPK's document also points out what the
MSDN Library says: Event listeners that are attached this way are executed
in arbitrary order.

If I use attachEvent (or addEventListener) multiple times on a single
element, I hope the spec says they will execute in an arbitrary order.
Even if the spec says otherwise, I don't think depending on the order
that observers are added is good practice.

Peter

 

[VK]

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?

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:

<your page>
<script src="menu.js">
// document.write your menu
// using menu.js
</script>
<noscript>
<!-- static HTML menu
for users with script disabilities
-->
</noscript>

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] 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.

However, it is less likely

Sure "less likely" but as we have noted over the months, all of this
feature testing doesn't make any guarantees but only makes us
relatively confident that the user agent to execute the code
correctly. Once the developer is far enough into the "safe zone" then
it will be personal preference how much more to test. This extra
testing could be considered paranoia and over testing by others.

[snip]

You have snipped the important part.

I call the event handler with Function.prototype.apply so I can choose
the "this" object freely and reliably.

Only where Function.prototype.apply() is available.

If I use attachEvent (or addEventListener) multiple times on a single
element, I hope the spec says they will execute in an arbitrary order.

There is no specification for attachEvent(), there is something that could
be considered reference material: the MSDN Library. However, the W3C DOM
Level 2 Events Specification that defines EventTarget::addEventListener()
(implicitly) says that event listeners are to be executed in the order that
they are added with this method; it is implemented so, and that is good so.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget

Even if the spec says otherwise, I don't think depending on the order
that observers are added is good practice.

One may not have the choice, given that the elements may have an intrinsic
event handler attribute value set for that event already.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-registration-html40


PointedEars

 

[dE|_]

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:

<your page>
<script src="menu.js">
// document.write your menu
// using menu.js
</script>
<noscript>
<!-- static HTML menu
for users with script disabilities
-->
</noscript>

My in-site search engine was not following the links in the scripted menu.
The question with your scenario is whether spiders of my own and google's
will pay attention to and follow the links sitting in <noscript>.

I've not tested my own, not a quick job, but should be worth it unless you
know the google result- ?

---dE|_---

 

[Jeremy J Starcher]

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.

 

[dE|_]

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.

A friend came up with a good alternative to noscript;

<body onLoad="document.getElementById('navpanel').style.display='none';">

If there is no script available you get the navpanel HTML that should be
there in the first place. Makes sense.

---dE|_---

 

[Jeremy J Starcher]

A friend came up with a good alternative to noscript;

<body
onLoad="document.getElementById('navpanel').style.display='none';">

I did something similar, but I'm sure even that will cause me grief down
the road. I'm becoming more and more convinced that I'm better off
giving up on Javascript -and- HTML -and- computers in general and going
back to carving things on bits of stone.

My search engine becomes old geezers with excellent memories.

 

[dE|_]

"Jeremy J Starcher" say...

I did something similar, but I'm sure even that will cause me grief down
the road. I'm becoming more and more convinced that I'm better off
giving up on Javascript -and- HTML -and- computers in general and going
back to carving things on bits of stone.

My search engine becomes old geezers with excellent memories.

Just draw it on a big jpeg