Response title
This is preview!
- Screen name: alistair.potts
alistair.potts's Profile
18 Posts
26 Responses
0
Followers
Activity Trend
Last 30 days
Loading Chart...
Show:
- Expanded view
- List view
- The first is only a getter, the second both a getter and a setter - it looks like redundancy but maybe I'm missing something?(see lines 6244 and 6436).
- First - there's a lot of testing whether
- typeof selector !== "string"
Second - there's quite a lot of comparison to null and not-null - but usually == instead of ===. Either it's meant to be coerced (in which case just do !(whatever)) but I reckon would be better to do a proper comparison to undefined or false or empty or zero or whatever.
A- The nice shiny green 'forum' button on the jquery mobile site sends you to a non-existent forum, and 404s.AJP
- Using a live-tracking system (which in turn uses ajax to retrieve and execute remote scripts using the jQuery library) I noticed today a visitor from Mountain View (unknown browser type). A quick check of the logs and it was, of course, the Googlebot, version 2.1, coming from 66.249.65.183.
Maybe it's been noted before, but I was quite surprised to see it executing such complex scripts, especially since the ajax isn't even triggered until half a second after page load.
Anyway, I thought it would be worth noting.- Is there any difference between the two following things - assume we have lots of divs -
- $('DIV').each(function() {
- /* some long and complex logic here */
- });
- $.fn.myMethod = function() { /* some long and complex logic here */ }
- $('DIV').myMethod();
I'm thinking that maybe the javascript parser has to reparse the long-and-difficult bit each time in the first instance, but not in the second. But maybe they're actually just the same?
Thanks.
I didn't expect this to work (with my 'compiler' hat on) but it does:
var clickFunction = function() { $inner.doSomething() };
$("div")
.append("<div id=inner>bla</div>")
.click(clickFunction);
var $inner = $div.find("#inner");
I was expecting an error for $inner to be undefined when the
javascript parsed the first line, but the browser script engines seems
quite happy with this sort of super-late declaration.
Trying to do manipulate an element from within it can cause an error
in IE6. So this WONT work in IE6
<!DOCTYPE html>
<script src="jquery.js"></script>
<div>
foo
<script>
$('div').append('bar');
</script>
</div>
... but will in IE7 and 8. So 7 and 8 look more forgiving, but unlike
other major browsers if you try to manipulate the body before it's
closed, that won't work either. So this won't work in any version of
IE:
<!DOCTYPE html>
<script src="jquery.js"></script>
<body>
foo
<script>
$(document.body).append('bar');
</script>
</body>
I'm inclined to think 'fair enough' - the error message is quite
descriptive ("Unable to modify the parent container before the child
element is closed"), and the fix is quite easy: either move the script
or do it properly with a $(document).ready call.
However (and this is the problem): in either scenario IE6 has a
complete tizz, tells you it's aborting, blanks the page and then
claims you have 'network connectivity problems'.
It's not so much a jquery issue, but a fix might be to check that the
script is not a child of the element that's being modified. It's
probably not worth solving, but I leave it here as reference because
IE6 gives no clue as to why it has gone a bit mad.
AJP
I know there's been a few discussions centred around the image load
event. This (previously suggested) workaround works fine for catching
both new loads and cached images in the testing I have done:
$('img').bind('load readystatechange', function(e) {
if (this.complete || (this.readyState == 'complete' && e.type ==
'readystatechange')) {
... do stuff ...
}
})
The problem is that binding a load event to the images isn't
guaranteed to happen before the image itself has loaded. So we might
not catch the loading at all.
The workaround to this is fairly straightforward - check to see if
(this.complete || this.readyState == 'complete') { ... do stuff ... }
else [bind as above].
Further problems arise when trying to bind an error event to the image
to catch loading broken images. It works fine if the image hasn't
loaded, but is there any way to tell if the image is broken if it's
already loaded? Well here's the catch: in IE there's no way of
differentiating between images that haven't been loaded at all, and
broken images. In both cases the readyState is 'uninitialized' and the
fileSize is -1.
This makes it impossible to guarantee using $('IMG').bind
('error' .... ) will catch broken images.
But I've stumbled across a solution that has greatly simplified my
code. Like this:
$('img').each(function(){
$(this)
.bind('load readystatechange' .... )
.bind('error' .... )
this.src = this.src; // <-----
});
... then the load / readystatechange / error events will be fired (as
appropriate). Using Fiddler and HttpHeaders, it doesn't seem to
generate another request for the image. This is really useful - it
means we can skip all the code we need to check if the image has
already completed before binding - all you have to do is bind the load
and error events, do 'this.src = this.src' and if the image has
already been loaded it will behave as if it's just been loaded. If the
image hasn't been loaded, this.src = this.src doesn't appear to have
any effect. So you can stop worrying about whether your events are
going to miss some images. It also means you can detect broken images
in IE.
I'm quite encouraged by my initial testing on this. I've testing under
IE 7 and FF 3, and a number of different scenarios (early jquery-loop,
posponed jquery-loop, slow loading images, cached images) but it'll
need some more robust tests before I would suggest it as a thorough
solution. I know IE6 has particular issues, so I'll need to look at
that too.
A
PS One unexpected result - detecting broken images is useful for
putting up a slightly more friendly 'broken image' than the default
browser one by changing the src attribute - but if you do this then
your load event will immediately fire! Took me a few minutes to work
out why the load event was firing on broken images because I was doing
this.
I created a local html doc to be pulled in through load(). It has a
style element - FF and IE apply the new styles, but Safari won't if
the style is in the head. So I got rid of the html, body, and head
tags so (this is still valid HTML). Now Safari applies the styles on
load.
Now if I iterate through the children of the containing element of my
newly-loaded doc, FF & Safari return a height for the STYLE element.
Which is odd. It's not like it has any visual representation.
So there are two things here - I don't know whether there is a fix for
Safari to apply styles in the head after an ajax load. Given that all
styles are supposed to be in the HEAD (although not in HTML5) I guess
styling-after-ajax is not a standard thing.
But returning a height for the Style seems definitely wrong.
AJP- 20-Jan-2009 09:48 AM
- Forum: Developing jQuery Core
I really hate not having a thorough test-case, but I really am
mystified by this.
I'm running Firefox 3.0.5 with firebug. This page (test case):
http://www.partyark.co.uk/html/jqtest.html
has a super-minimal, unstyled jQuery + jQuery UI tab.
The page doesn't do anything unsurprising - until you 'suspend'
firebug (right-click the little bug at the bottom and 'suspend').
Reloading the page will cause jQuery to reload parts of the page every
few seconds (check your HTTP headers), cause the CPU to spike and
generally to cause oddness.
I'm sorry I can't be more specific, I have no idea if this is a jQuery
issue, a jQuery UI issue, Firebug or Firefox - although clearly it's
related to Firebug. I have tried it on two machines, so it's
definitely not just me :)
Until I worked out this was related to suspending Firebug I was
tearing my hair out trying to nail this down. I'd be interested first
of all if anyone can reproduce this.
A
I had a bit of a mangled selector on one of my pages which 1.2.6
simply skipped over, but completely kills 1.3.
In fact helped me spot a bit of code that had never worked.
Full test case here: https://www.partyark.co.uk/html/jquery1.3rc2-bug.html
If the BODY is offset from the HTML then offset should report that
number - but it's zero in webkit.
$('body').offset().left
Test case here:
http://www.partyark.co.uk/html/jqueryoffsetbody.html
I couldn't find this in the bug db so I've created a ticket.- 28-Aug-2008 02:02 AM
- Forum: Using jQuery
[apologies, I put this on the dev list but should really have put it
here]
IE8b2 will crash if you try to insert a text node after a float. This
might not seem such a common thing to do, but remember that jquery
parses html into nodes before appending - and if your html starts with
a space then the first inserted node will be a text node and kabooom!
I've put up test page here:
http://partyark.org/html/ie8floattest.html
This completely shafted my site (http://www.partyark.co.uk) where we
use jquery to write a 'basket summary' div at the bottom of the page
if you've got something in your basket. What with this and lack of
opacity I've had to put up the IE=7 http header thingy until they get
this stuff sorted out.
IE8b2 will crash if you try to insert a text node after a float. This
might not seem such a common thing to do, but remember that jquery
parses html into nodes before appending - and if your html starts with
a space then the first inserted node will be a text node and kabooom!
I've put up test page here:
http://partyark.org/html/ie8floattest.html
This completely shafted my site (http://www.partyark.co.uk) where we
use jquery to write a 'basket summary' div at the bottom of the page
if you've got something in your basket. What with this and lack of
opacity I've had to put up the IE=7 http header thingy until they get
this stuff sorted out.
I believe that generally this:
var divs = document.getElementsByTagName('div');
for(var i=0, k=divs.length; i<k; i++){
divs [i].onclick = doThis;
}
function doThis(e){ ... }
is better than:
var divs = document.getElementsByTagName('div');
for(var i=0, k=divs.length; i<k; i++){
divs[i].onclick = function(){ ... }
}
... because you're not creating an anonymous function for each div
event, just a pointer to the function.
Does it therefore follow that this:
$('DIV').click(doThis);
function doThis(){ ... }
is smarter than
$('DIV').click(function(){ ... })
... or does jquery do something clever with the function to make sure
there's just lots of references to it anyway?
A
Last build was 4220 on 18th Dec.
For those of us with limited access to ant or make, jquery-nightly.js
is a really useful way of keeping up.- 13-Aug-2007 12:44 AM
- Forum: Using jQuery
Hello, my site Party Ark for children's party supplies is up and
running with jquery.
We use a modified Thickbox on the product pages, and jquery ajax for
adding to basket. Plus other bits and pieces which have just been much
quicker to write with jquery.
http://www.partyark.co.uk
Cheers, AJP- 31-Aug-2006 12:58 AM
- Forum: Using jQuery
When jquery tries to get the height of a (display:none) element, it
clones the element as (visiblity:hidden display:block), appends it to
the BODY, calculates the dimensions, and removes it.
Which is all very clever.
The problem comes that if you style your element using css selectors,
then you have to ensure that the css is valid when the above 'trick'
takes place.
For instance, say we had a paragraph with padding defined in the css
like this:
div p { padding: 10px; display: none; }
<div>
yadda bla
</div>
jquery will not work as expected if you do animation on it, for instance
to make it slide into view. The calculation of the height won't take
into account the padding, because the cloning method won't 'see' the css.
Solution: always use ids and classes, but don't nest them in the css; e.g.
p.invisible { padding: 10px; display: none; }
<div>
<p class="invisible">yadda bla
</div>
The css will always be valid regardless of where the paragraph is in the
DOM.
Thought this might be useful!
A
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
© 2012 jQuery Foundation
Sponsored by
and others.