> there is one thing - these are not placed *after* jquery.js is called.
This is likely your entire problem. The jquery.js *must* be before
*any* jQuery code -- the browser will choke when it sees $ or jQuery
before $ and jQuery are defined.
Charles
On Nov 7, 12:01 pm, mike503 <[EMAIL PROTECTED]> wrote:
> thanks for the reply.
>
> On Nov 7, 10:19 am, polyrhythmic <[EMAIL PROTECTED]> wrote:
>
> > You are mixing your Model-View-Controller together with such 'links'.
> > href="javascript: ..." is bad jQuery practice, and never recommended.
> > It does not degrade in any way for users who are not running
> > JavaScript. Any events that have any jQuery related code should be
> > unobtrusively bound in $( function() { }); [jQuery's doc.ready fn]
> > with $(element).click( function() {}), etc. That means no inline
> > onClick, onMouseover, etc in your HTML.
>
> that's what i am trying to do. before the other developer had <a
> href="javascript:foo()" where foo referenced jquery code. i changed it
> to be <a href="javascript:;" id="foo"> (if you put href="#" it makes
> the page skip around and changes the URL, a dead javascript link seems
> to work great) and tied it to a jquery onclick event. however, it
> still takes time for it to load and process that piece it seems.
>
> > Also, make sure your jQuery ready function is placed *after* your
> > jQuery script, whether it's at the bottom of the page or top. Note
> > that while you're doing dev, and constantly reloading, you may
> > experience weird issues with page refreshes and caching that will give
> > you "$ is not defined" errors, due to the browser loading the page in
> > the incorrect order. However, under normal use I and my clients have
> > not experienced that problem.
>
> when i do this i am using shift-reload in firefox - which is a total
> 100% reload off the server, no caching. i can confirm this by looking
> at firebug's Net tab...
>
> > jQuery can always be put safely at the bottom of the page, if the page
> > is designed with proper jQuery practices. However, the reason to load
> > jQuery last is to show your users content as fast as possible -- if
> > your page is completely jQuery-dependent, you may want jQuery in the
> > head instead so jQuery can work on the content before the users sees
> > and interacts with it, at the expense of longer load times.
>
> yes, that is my confusion. i bind these actions inside of
> document.ready which requires jquery. inside of the action, which is $
> ("#foo").mouseover(function() { something }); is when it throws a "$
> is not defined" - but why is it binding to the mouseover event of the
> "$" and able to bind to $(document).ready() then if "$" is not
> defined? it's confusing.
>
> > Also, I can't get your test page to throw an error. I too am using FF
> > 2.0.0.9 with Firebug. I don't use YSlow, but I'm not seeing errors no
> > matter what I click or hover.
>
> it's very odd, i can do it consistently.
>
> there is one thing - these are not placed *after* jquery.js is called.
> they are in document.ready() blocks though. however due to how the
> page is designed, reorganizing it to put jquery at the top winds up
> changing the point of the "experiment" ... i will try to group all of
> the stuff on this example to the bottom of the page even after the
> jquery.js and all the javascripts are referenced, and see if that
> helps.
>
> the problem is users have a tendency of hovering/mouseover or clicking
> on links before the page fully loads... and if the events are being
> bound at the very last part of the page load that's a lot of bad user
> experiences and dead links. probably a better rule of thumb is generic
> page elements should work without jquery/advanced code needed, but
> sometimes that's the whole point of certain links.
