[jquery-dev] Re: jQueryLINT
Dave,
I completely agree with Andrea Raimondi above and everything he said
make sense to me.
Why should we inflict these no sense conditionals onto everybody.
Should we then check every parameter of every method too, just to be
helpful to one people not remembering signatures or lazy to lookup a
documentation page ?
Not useful, none of those checks should be in core, if necessary, for
DBJ and people needing that, an external checker will be ok, I would
not like to be the one writing that though :-) Those writing $('*')
should be returned what they asked, it is incorrect to assume
everybody is a beginner and time wasting trying to guess what they
would do with those selectors.
Diego
On 15 Gen, 18:31, Dave Methvin dave.meth...@gmail.com wrote:
Not technically demanding uh?
I beg to differ on this one.
Conceptually it's a simple idea: Inspect the parameters being passed
to jQuery and its methods, then see if they match the API signature
and follow good practice. I started on it years ago but punted (hides
head in shame) because it was a lot of work, especially at that time
when the jQuery API was changing
quickly:http://markmail.org/message/wzkosk2s5jklpkv4
First of all, what would the criteria be?
Whatever the author thought was bad practice or a possible mistake. If
you've ever used the original jslint (http://www.jslint.com/) or the
(imo) better javascriptlint (http://www.javascriptlint.com/), you know
that lint occasionally complains about things that are not outright
errors but sometimes indicate problems or are just bad style. The $
(*) case that dbj mentioned is a good one. It's not an error but it
is generally not good to do something to every element on the page. I
also would flag the case of $(myid) versus the intended $(#myid)
on non-xml docs if the selector didn't return any elements--that's a
mistake I make a few times a month.
pretty much all of the JQuery classes and functions can use
server side tags and code.
I think dbj was proposing runtime analysis, not static analysis as
used with tools like jslint. By the time the jQuery code is called,
any server-side tags and code is irrelevant for the kind of checks
you'd want to do.
The library has *no* knowledge(and rightfully so, imho) of what tags
and/or selectors will be used.
True, so the messages it gives aren't going to be 100% correct in all
cases. That's okay, the developer needs to look at the messages and
decide whether it's found a problem or not. The volume of messages
could be controllable via options. See the lints above for examples of
how to do it.
This would slow things down *A LOT* with many checks.
Performance could definitely be an issue; if the page gets 10 times
slower with jquery-lint, people aren't likely to use it regularly for
day-to-day development. But even if it *was* 10 times slower, it could
still be useful because when people come to a forum complaining their
code doesn't work we could point them to jquery-lint.js and tell them
to look for problems using that first.
Fourth: plug-ins would have to do the same checks.
A plugin author could certainly write a linted version of their own
code, but if they include jquery-lint.js in the page the plugin will
automatically get the lint features for any jQuery methods it calls.
Fifth: *ANYONE* using improper selectors or using JQuery improperly
deserves his/her fate. Reading the docs is the first thing you should do.
It's easy to make mistakes, even if the docs are good and you read
them well. As I said in that old thread, I would be embarrassed to
tell you how many times I've said $(myid) when I meant $(#myid)
and spent 10 minutes trying to figure out what was broken. A lint
tool helps find those mistakes, and people can learn things by reading
its advice which is always a good thing. It's like a code review in a
Javascript file.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: jQueryLINT
Jason,
maybe I have attributed to Dave something that was actually said by
DBJ ... sorry in that case.
I am just against inclusion in core and against the inclusion of any
mechanism for that scope in general.
As said, if the tool is an external and independent Lint-like
solution I don't see any problem. I already use tools like those
myself (jsl).
Two different versions of jQuery will just create more confusion and
more maintenance problems.
Diego
On 15 Gen, 20:11, Jason Persampieri papp...@gmail.com wrote:
Diego,
I think you're still not quite understanding what Dave is suggesting.
He is *not* saying everyone running jQuery would be subjected to these
checks.
He *is* saying there is a completely new build of jQuery (let's call
it jQuery-1.4.lint.js) that a developer could *choose* to run against
just to test out their code. And in the documentation, it could be
strongly urged that new developers try this at least once.
Heck, let's take it a step farther... how about jquery-1.4.newb.js
that has some sort of 'tutorial' built in when it sees bad practices?
At least that's how I've interpreted it :)
_jason
On Jan 15, 11:02 am, Diego Perini diego.per...@gmail.com wrote:
Dave,
I completely agree with Andrea Raimondi above and everything he said
make sense to me.
Why should we inflict these no sense conditionals onto everybody.
Should we then check every parameter of every method too, just to be
helpful to one people not remembering signatures or lazy to lookup a
documentation page ?
Not useful, none of those checks should be in core, if necessary, for
DBJ and people needing that, an external checker will be ok, I would
not like to be the one writing that though :-) Those writing $('*')
should be returned what they asked, it is incorrect to assume
everybody is a beginner and time wasting trying to guess what they
would do with those selectors.
Diego
On 15 Gen, 18:31, Dave Methvin dave.meth...@gmail.com wrote:
Not technically demanding uh?
I beg to differ on this one.
Conceptually it's a simple idea: Inspect the parameters being passed
to jQuery and its methods, then see if they match the API signature
and follow good practice. I started on it years ago but punted (hides
head in shame) because it was a lot of work, especially at that time
when the jQuery API was changing
quickly:http://markmail.org/message/wzkosk2s5jklpkv4
First of all, what would the criteria be?
Whatever the author thought was bad practice or a possible mistake. If
you've ever used the original jslint (http://www.jslint.com/) or the
(imo) better javascriptlint (http://www.javascriptlint.com/), you know
that lint occasionally complains about things that are not outright
errors but sometimes indicate problems or are just bad style. The $
(*) case that dbj mentioned is a good one. It's not an error but it
is generally not good to do something to every element on the page. I
also would flag the case of $(myid) versus the intended $(#myid)
on non-xml docs if the selector didn't return any elements--that's a
mistake I make a few times a month.
pretty much all of the JQuery classes and functions can use
server side tags and code.
I think dbj was proposing runtime analysis, not static analysis as
used with tools like jslint. By the time the jQuery code is called,
any server-side tags and code is irrelevant for the kind of checks
you'd want to do.
The library has *no* knowledge(and rightfully so, imho) of what tags
and/or selectors will be used.
True, so the messages it gives aren't going to be 100% correct in all
cases. That's okay, the developer needs to look at the messages and
decide whether it's found a problem or not. The volume of messages
could be controllable via options. See the lints above for examples of
how to do it.
This would slow things down *A LOT* with many checks.
Performance could definitely be an issue; if the page gets 10 times
slower with jquery-lint, people aren't likely to use it regularly for
day-to-day development. But even if it *was* 10 times slower, it could
still be useful because when people come to a forum complaining their
code doesn't work we could point them to jquery-lint.js and tell them
to look for problems using that first.
Fourth: plug-ins would have to do the same checks.
A plugin author could certainly write a linted version of their own
code, but if they include jquery-lint.js in the page the plugin will
automatically get the lint features for any jQuery methods it calls.
Fifth: *ANYONE* using improper selectors or using JQuery improperly
deserves his/her fate. Reading the docs is the first thing you should
do.
It's easy to make mistakes, even if the docs are good and you read
them well. As I said in that old thread, I would be embarrassed to
tell you how many times I've said
[jquery-dev] Re: jQueryLINT
Yes a temporary wrapper is better... and useful for other things too.
Diego
On 16 Gen, 01:16, DBJDBJ dbj...@gmail.com wrote:
How about a proxy (aka mediator, aka facade ) pattern ?
Let us call that facade : jQLint. An facade to the real jQuery
behind . Let's call its instance: $$
// inside jQlint
(function ( window, undefined ) {
// Define a local copy of jQLint
var jQLint = function( selector, context ) {
//
// A lot of sanity testing of the selector+ context
// A lot of warning, messages to the console
// At last pass the action to the jQuery
return jQuery ( selector, context );
},
_jQLint = window.jQLint,
// Map over the $ in case of overwrite
_$$ = window.$$,
// implementation proceeds here ...
Usage :
script src=jquery.1.4.min.js /script
script src=jquery.1.4.lint.js /script
script
$$(*) ; // using jQueryLINT ... leaves a lot of messages in the
console or wherever , etc ...
// $(*) // back to jQuery silence
/script
One can switch back and forth obviously ... jQuery stays unharmed ...
And two developments go happily in parallel.
PS: this is an sketch, not a real and ideal code ...
--DBJ
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Activate event
Daniel, click events can be triggered in various ways, more generally, events should be allowed to be triggered by any means of device, a keyboard, a mouse, a sensitive tablet/surface, a touch screen and so on and even by voice and manyother means. I am scary to even say that seems Microsoft has the best implementation for what is regarding Activation (I just mean the event hooks exists, nothing else OK?). What you are touching/looking@ is the Activation Model, it is the way to be really device independent by using a different set of events (on IE). @Dave, I wouldn't make my assumptions a statement, but yes everything you know/said above could/should be replaced by using activation events, tabbing to a link for example (just for IE) could be intercepted by just using onactivate event to be sure to catch any means of activating that link and on any device, be it by keyboard, mouse, touch or whatever other input aided device. I will point out that (on IE) both onactivate and ondeactivate exists and have related pairs onbeforeactivate and onbeforedeactivate which fire even earlier in the same chain. If you think to it you can also intercept programmatically fired events (for example the ones you can invoke from javascript code .submit() .click () .foucs() .blur()). I would really like you have a look at my: http://github.com/NWEvents project there you will find some example to understand what these events are for (again on IE) and what I used them for. ;-) For other browsers, the ones following the W3C Event Model, the capture phase is a good replacement to obtain a cross-browser helper. However it seems there are already tracks of this Activation model both in DOM Level 3 Events and in most browsers (DOMActivate/ DOmFocusIn/DOMFocusOut events has been working for some time now). Let me know if I can be of help. Cheers, Diego On 9 Gen, 20:11, Daniel Friesen nadir.seen.f...@gmail.com wrote: Ugh... I was under the impression that click events only fire when you click on something. Aye, activate is supposed to fire in all those cases as well. Click's current behavior now seams to really be activate in a confusingly named guise. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Dave Methvin wrote: Activate basically behaves the exact same as a href on an a does. Sorry I'm still not understanding the difference. The href is an attribute of the link, not an event. It sounded like activate was an event. AFAIK click is fired by the browser in three cases: when the user clicks the link, when the link has focus and the user presses Enter, or when the link has an accessKey attribute and the user types that accessKey. Does activate fire in all those cases as well? Do you have some reference urls that explain it all? -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: attr() is still very broken in 1.4a1
Karl,
it is not only href that has problems, seems all attributes having
an URI string as value have to be read in the way you described.
Some of them are: action, cite, codebase, data, href, longdesc,
lowsrc, src, usemap.
In IE6/7 elements have a predefined number of attributes (minimum 80,
varies depending on the element).
Further complication comes from the fact that IE6/7 getAttribute does
not always return string when a value is present.
document.body.getAttribute(onload); // function
document.body.getAttribute(style); // object (not null)
As an example go to http://www.google.com; with IE6 and other
browsers and type this in the URL:
javascript:alert(document.getElementsByTagName('textarea')
[0].getAttribute('style'));
You will have to add .cssText in IE6/7 to read a slightly similar
value:
javascript:alert(document.getElementsByTagName('textarea')
[0].getAttribute('style').cssText);
I don't think all these cases/differences are currently handled and I
don't think they can be handled in a reasonable way.
Diego
On 14 Dic, 16:49, Karl Swedberg k...@englishrules.com wrote:
I use .attr() to get the href attribute value, too. If you
use .getAttribute(), IE6 and IE7 require a second argument to really,
truly get the attribute: somelink.getAttribute('href', 2)
--Karl
Karl Swedbergwww.englishrules.comwww.learningjquery.com
On Dec 14, 2009, at 10:05 AM, Scott Sauyet wrote:
On Dec 13, 11:27 pm, Matt m...@thekrusefamily.com wrote:
I'm not going to jump into these murky waters, but I want to follow up
on this bit:
As it is now, I always recommend that attr() be avoided in code, and
if someone uses it in code I am looking at, I tell them to remove it.
It's too fragile and the logic that it is intending to code is not
well documented, so we can't depend on it. Luckily, it's easily coded
around.
The only place I use attr extensively is when I want the href value of
a link for further manipulation to unobtrusively convert non-JS
functionality to JS functionality, most commonly when the href is for
a document fragment. Do you think it's bad practice to call
var myDiv=$(item.attr('href'));
Obviously I could go down to getAttribute, but I've never had a
problem using it like this.
-- Scott
--
You received this message because you are subscribed to the Google
Groups jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en
.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: typo in ready event since null !== undefined
I don't understand why you are writing code like this in a developer
group... some ongoing competition.
It is not clear if you have trade secrets or just don't want others to
see the errors in it. ;-)
Do you want to talk about them and discuss them or is this a way of
just posting a snippet, for this we have javascript.com and at list
they are well commented.
Diego
On 20 Nov, 12:50, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
@Shade, just to inform you I have removed the named function expression
reusing a variable:
(function(s,o,l,v,e,d){if(s[o]==nulls[l+e]){s[o]=loading;s[l+e](d,l=function(){s[o]=complete;s[v+e](d,l,!1)},!1)}})(document,readyState,add,remove,EventListener,DOMContentLoaded)
Regards
On Thu, Nov 19, 2009 at 12:10 AM, Shade get...@gmail.com wrote:
Here's my minified version... it's *slightly* larger at 209 characters
(vs 195), but it works, and bonus, it doesn't use a memory-leaky named-
function-expression:
(function(a,b,c,d){if(a[b]==nulla[c]){a[c](d,function()
{a.removeEventListener(d,arguments.callee,false);a[b]
=complete},false);a[b]=loading}})
(document,readyState,addEventListener,DOMContentLoaded);
Thanks for the inspiration, though, Andrea!
--Kyle
On Nov 18, 5:55 pm, Shade get...@gmail.com wrote:
Ummm... ammendment: The complete snippet works:
if(document.readyState == null document.addEventListener){
// on DOMContentLoaded event, supported since ages
document.addEventListener(DOMContentLoaded, function
DOMContentLoaded(){
// remove the listener itself
document.removeEventListener(DOMContentLoaded,
DOMContentLoaded, false);
// assign readyState as complete
document.readyState = complete;
}, false);
// set readyState = loading or interactive
// it does not really matter for this purpose
document.readyState = loading;
}
But, the minified/re-arranged snippet (the 195 chars) Andrea provided
does not work. Do you own minification and you'll be fine, just don't
use what he posted.
--Kyle
On Nov 18, 5:44 pm, Shade get...@gmail.com wrote:
I have confirmed in this test:
http://test.getify.com/archive/dynloadjquery/index6.html
...that Andrea's proposed snippet does in fact patch a page to have
a proper readyState, assuming of course the snippet itself is
guaranteed to run before domready. The test includes it in a manual
script tag at the bottom of the page, and then you can click a button
to dynamically load jquery into the page, then click the other button
to see if jquery's internal ready flag is set properly or not.
I used a patched version of jQuery 1.3.2 (1.3.2.1 I called it) which
only has the changes to the bindReady() function as they appear in
GitHub right now (namely, the additional check for the
document.readyState which John landed as a result of that previous bug
I linked to earlier in this thread).
I tested this just now in both FF3 and 3.5 (both windows), and it
works fine.
That means, that at least for now, even though patching jquery itself
doesn't do much or help anything with the problem of being able to
lazy-load jquery core, which my biggest concern/use-case, you can
still patch a page to be able to lazy-load jquery. That's definitely
an improvement.
It also means that any code that relies on jquery's test (such as code
that uses document.ready) is now also safe to lazy load right along
with jquery core itself, as long as doing so in a patched page.
I'm satisfied that this being included in LABjs will allow users to
adequately load jquery.js on-demand without fear of the isReady checks
failing later. The only caveat then will be that LABjs has to make
sure it's there before dom-ready, but for all the use cases I care
about, it's quite unlikely that people will use some other loading
technique to lazy-load the Loader itself.
--Kyle
On Nov 18, 5:03 pm, Már Örlygsson mar.orlygs...@gmail.com wrote:
Am I right to think that there's a similar problem with the
window.onload event?
i.e. if you're too late in binding a handler to window.onload, it
will
never fire?
--
Már- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from
[jquery-dev] Re: typo in ready event since null !== undefined
Here is a snippet much longer, and hope a bit clearer, than the one
Andrea wrote:
(function(global) {
if (typeof document.readyState == 'undefined') {
HTMLDocument.prototype.
__defineGetter__(readyState, function () { return
domReady; });
HTMLDocument.prototype.
__defineSetter__(readyState, function (state) { domReady =
state; });
function interactive(e) {
domReady = 'interactive';
top.status += ' * ' + document.readyState;
domImage.removeEventListener('error', interactive, false);
domImage = null;
}
function loading() {
domReady = 'loading';
top.status += ' * ' + document.readyState;
global.document.addEventListener('DOMContentLoaded', complete,
false);
}
function complete() {
domReady = 'complete';
top.status += ' * ' + document.readyState;
global.document.removeEventListener('DOMContentLoaded',
complete, false);
}
function initialize(document) {
domReady = 'uninitialized';
top.status += ' * ' + document.readyState;
domImage.addEventListener('error', interactive, false);
domImage.src = mozilla://;
loading(document);
}
var
domImage = new Image(),
domReady = 'uninitialized';
initialize(global.document);
}
})(this);
It adds an extra interactive state where the BODY is available, also
possibly not completely parsed and rendered.
For the rest it is just similar to what Andrea does in his code, add a
readyState property to document the W3C way.
Still not a solution for what jQuery needs.
-
Diego
On 25 Nov, 02:15, Diego Perini diego.per...@gmail.com wrote:
I don't understand why you are writing code like this in a developer
group... some ongoing competition.
It is not clear if you have trade secrets or just don't want others to
see the errors in it. ;-)
Do you want to talk about them and discuss them or is this a way of
just posting a snippet, for this we have javascript.com and at list
they are well commented.
Diego
On 20 Nov, 12:50, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
@Shade, just to inform you I have removed the named function expression
reusing a variable:
(function(s,o,l,v,e,d){if(s[o]==nulls[l+e]){s[o]=loading;s[l+e](d,l=function(){s[o]=complete;s[v+e](d,l,!1)},!1)}})(document,readyState,add,remove,EventListener,DOMContentLoaded)
Regards
On Thu, Nov 19, 2009 at 12:10 AM, Shade get...@gmail.com wrote:
Here's my minified version... it's *slightly* larger at 209 characters
(vs 195), but it works, and bonus, it doesn't use a memory-leaky named-
function-expression:
(function(a,b,c,d){if(a[b]==nulla[c]){a[c](d,function()
{a.removeEventListener(d,arguments.callee,false);a[b]
=complete},false);a[b]=loading}})
(document,readyState,addEventListener,DOMContentLoaded);
Thanks for the inspiration, though, Andrea!
--Kyle
On Nov 18, 5:55 pm, Shade get...@gmail.com wrote:
Ummm... ammendment: The complete snippet works:
if(document.readyState == null document.addEventListener){
// on DOMContentLoaded event, supported since ages
document.addEventListener(DOMContentLoaded, function
DOMContentLoaded(){
// remove the listener itself
document.removeEventListener(DOMContentLoaded,
DOMContentLoaded, false);
// assign readyState as complete
document.readyState = complete;
}, false);
// set readyState = loading or interactive
// it does not really matter for this purpose
document.readyState = loading;
}
But, the minified/re-arranged snippet (the 195 chars) Andrea provided
does not work. Do you own minification and you'll be fine, just don't
use what he posted.
--Kyle
On Nov 18, 5:44 pm, Shade get...@gmail.com wrote:
I have confirmed in this test:
http://test.getify.com/archive/dynloadjquery/index6.html
...that Andrea's proposed snippet does in fact patch a page to have
a proper readyState, assuming of course the snippet itself is
guaranteed to run before domready. The test includes it in a manual
script tag at the bottom of the page, and then you can click a button
to dynamically load jquery into the page, then click the other button
to see if jquery's internal ready flag is set properly or not.
I used a patched version of jQuery 1.3.2 (1.3.2.1 I called it) which
only has the changes to the bindReady() function as they appear in
GitHub right now (namely, the additional check for the
document.readyState which John landed as a result of that previous bug
I linked to earlier in this thread).
I tested this just now in both FF3 and 3.5 (both windows), and it
works fine.
That means, that at least for now, even though patching jquery itself
doesn't do much or help anything with the problem of being able to
lazy-load jquery core, which my biggest
[jquery-dev] Re: window === window.top false in IE8, thus late ready...
Klaus, your statements are correct, I can confirm that...that change is wrong. I don't understand why for each new version of jQuery the non-strict == check in the ready method is changed into the strict === (non working). There was a comment on those lines I seem to remember, stating not to change it and explaining the strangeness in IE. In my IEContentLoaded snippet that's correctly checked, and only IE goes true that code. I actually rewrote that trick a bit better, avoiding the need to use window.top since there could also be an Acces denied in case of frames from different domains. On top of that I also added support for detecting the correct moment on IFRAMES, for all versions of IE. John already know and have the new code, hope he can switch to that one soon. -- Diego On 6 Ott, 12:50, Klaus Hartl klaus.ha...@googlemail.com wrote: Hi all, in IE8 window === window.top is false, whereas window == window.top evaluates to true. Because of this the ready event will always rely on document's onreadystatechange event instead of using Diego Perini's doScroll trick, see line 833 in event.js. I assume his trick is better in terms if earliness. Can somebody please confirm this? Or is it that we want to rely on the event in IE8? --Klaus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: window === window.top false in IE8, thus late ready...
David, the explanation you give of this fact make sense and is the more plausible one. I have had others giving me that same bit of information. Unfortunately that's only our guess up to now, I haven't disassembled their DLL (not yet) ! ;-) -- Diego On 6 Ott, 19:01, David Flanagan da...@davidflanagan.com wrote: Klaus Hartl wrote: Hi all, in IE8 window === window.top is false, whereas window == window.top This may already be common knowledge, but it is new to me HTML5 mandates that window.top, window.parent, etc. all be WindowProxy objects rather than true Window objects. A WindowProxy acts just like a Window object because all of its properties are proxied directly to a Window. A Window and a WindowProxy are not the same object, however, and so they are not === to each other. I'm a little surprised that they are actually == to each other in IE8, but maybe that's the way all the browser vendors will do it. One fix to the code would be to use == instead of ===. Another, I suppose might be to test something like: window.top.document === window.document (The DOM isn't ready when this code is executed, but the document object exists, doesn't it?) I haven't seen an explanation of why the WindowProxy is necessary, though I suppose that something must exist in the HTML 5 mailing lists. I'd love to understand this, if anyone has pointers. David evaluates to true. Because of this the ready event will always rely on document's onreadystatechange event instead of using Diego Perini's doScroll trick, see line 833 in event.js. I assume his trick is better in terms if earliness. Can somebody please confirm this? Or is it that we want to rely on the event in IE8? --Klaus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: window === window.top false in IE8, thus late ready...
I don't really have any other big issue then this and the few more other features only found in IE browsers ever since. Do not loose the site of that. I will kindly skip that for now, many thanks for your insights anyway. -- Diego On 8 Ott, 17:57, DBJDBJ dbj...@gmail.com wrote: IHTMLWindow6 Interface and its implemenation is inside MSHTML.DLL. Which we call Trident html rendering engine. Which is used in IE8. Where we have this top vs window feature in action. And a few more other features ... unfortunately. MSFT is dropping Trident in favour of new HTML rendering engine which is already in use in The Expression Web. This is not a secret and interestingly MSFT is not hiding (ie : they are open about it) that it is better than Trident. Ditto it is not very hard to deduce which html rendering engine will be used in IE9. Even if it keeps the name Trident. I am affraid we are in for a lot of compatibility issues when IE9 comes out. So, nothing new in the IE-Land ... Wait, there is more! There is a big dark cloud on the horizon heading this way : XAML. How is HTML rendered , is CSS processed perfectly and how is JScript behaving between the two is only interesting for MSFT in the context of producing a perfect XAML rendering engine and perfect WPF host. Do not loose the site of that. We will have much bigger issues to talk about than top vs window ;o) --DBJ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: ready event fires only after images are loaded on IE?
Hi John, sorry for the delay in answering but I am currently on vacation until 13 of July. I have read the bug report and tryed something with IE8 (I only have access to it now). It seems IE8 does not let users change the document.domain property so not too much to try in IE8. I will do tests on IE6 and IE7 as soon as I am back in Verona. Rich and Paul probably found another weird behavior of IE6/IE7. I will see if these edge cases can be covered in some way. The temporary solution (not using window.top) requires another way to detect IFRAMES, I will think about it. Thank you all for the heads-up, Diego Perini On Mon, Jun 22, 2009 at 8:16 PM, John Resig jere...@gmail.com wrote: Interesting fix, Rich. I've CC'd in Diego who's been doing a lot of work with the ready code lately. --John On Mon, Jun 22, 2009 at 5:53 PM, Rich Doughertyr...@rd.gen.nz wrote: On Feb 7, 11:55 am, Paul Irish paul.ir...@gmail.com wrote: I can report that the jquery-2009-01-28.js nightly, with this fix, caused IE (6 and 7) to sporadically hang and become unresponsive in my and ajpiano's applications. At this time i'm too busy (and unhelpful, sadly) to actually create a testcase of this. But I'm hypothesizing that the window.top check is the culprit. I'm reverting back to 1.3.1 for the moment, but I experienced the same delay in doc ready() firing as others here. :/ (I'm reviving an old thread here...) I'm also seeing a delay in IE6, but only when document.domain is set. I've created a small test case that I think demonstrates this problem. In the test case accessing window.top causes a large delay. If I comment out window.top then everything works straight away. Note that problems may not show up when accessing the page in a fresh browser - you may need to refresh to see the hang. More details here: http://dev.jquery.com/ticket/4787 Patching the code in ready() to avoid using window.top fixes the problem for me in JQuery 1.3.2. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: handling 'Content-Encoding: chunked' in a lazy iterative manner
Andrew, this is a neat idea but from my knowledge it is not currently applicable to HTML fragments to be inserted in the DOM. Transfer-encoding: chunked means that output_buffering is enabled on the server. Each chunk size is predefined (configurable), normally the default in PHP is set to 4Kbytes but could be made smaller or larger, the configuration in PHP may be changed by means of the output_buffering directive. Here are the relevant commented lines from my php.ini: ; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. If you wish to limit the size of the buffer ; to a certain size - you can use a maximum number of bytes instead of 'On', as ; a value for this directive (e.g., output_buffering=4096). output_buffering = On The problem is that for HTML we have to insert the fragment in the DOM and to do that we need to know where the HTML tags starts and where they end, we could not insert a chunk like this one: divTest example strongReults (no closing tag has arrived in the last chunk, so broken HTML) Yes that's what can happen, since the chunks have a predefined length we have no way to know the size in advance from the client-side, maybe something could be done server-side to mitigate this problem with HTML data (some wrapper/parser). If the data has no structure, and can be rendered or used byte by byte then maybe this idea has a bright future. I confirm that Transfer-encoding: chunked is not MXHR (Multi-part XHR) like in DUI.Stream, it is just a mean of transferring long streams of data in chunks as the answer to a single HTTP request. And yes if feasible it will perform better than MXHR since the multi-part headers and related TCP overhead will be avoided both sides and Cookies will be sent only once in the first and only XHR. +1 for the idea, keep us informed on the development. Diego PS: Transfer-encoding: chunked and browser local caching is what makes our life difficult in detecting the DOMContentLoaded event in IE. In fact in this mode the client has no way of knowing in advance the length of the answer, if transfer is chunked there will not be a Content-Length: header in the answer. On 30 Mag, 22:26, Andrew Ingram a...@andrewingram.net wrote: I'm talking about content-encoding: chunked, it's a single connection. The server can periodically 'flush' the response stream to send all content that has been generated up to that point. The idea being that if each chunk is self-contained, ie a single entity on a response that would return a list of entities, the AJAX library can handle the first entities before the complete response has even finished being generated by the server. Technically this could require even less connection overhead than Comet because you could keep the connection open after delivering each 'update' - rather than requiring the client to create a new connection each time. http://en.wikipedia.org/wiki/Chunked_transfer_encoding Now I could be completely mistaken and actually chunked encoding requires multiple connections, but I don't believe this to be the case. On May 30, 3:31 pm, Ricardo ricardob...@gmail.com wrote: Creating lots of connections would probably have a large overhead making it slower than if you waited for the whole processing to end, for each connection you have to factor the 2-way latency + server response time. A better approach and already usable is HTTP Streaming/ Comet: http://ajaxpatterns.org/HTTP_Streaming On May 29, 7:36 pm, Andrew Ingram a...@andrewingram.net wrote: Hi all, I'm not even sure if this is possible with JavaScript at the moment, but it would make a powerful feature if it were. If returning a list of resources as the response to a request, it's relatively trivial to configure the app (in Django at least) to flush the stream after each resource and provide a semi real-time feed of results, ie you don't have to wait for the last item to be calculated before the first one is returned. This uses Content-Encoding chunked. I was thinking that if jQuery could somehow recognise these types of response, it could iterate over these individual resources as they come over the wire, then the callback would be given individual items rather than the full response. This would make AJAXy functionality even more responsive because you can start handling parts of the response before the server has even finished generating the later parts. Maybe this is already possible, but I couldn't have any documentation or mention of it. Any thoughts on this idea? Regards, Andrew Ingram --~--~-~--~~~---~--~~ You received this message
[jquery-dev] Re: $( window.parent.document ).height() throws error from child iframe
Jed,
forgot to say that you probably have to wrap those alert inside a
readystatechange for IE or similar for other browsers.
You have to wait for all the elements to be loaded in the parent
window before getting dimensions.
Here is the code I used to test:
html
head
script type=text/javascript src=jquery-1.3.2.js/script
script type=text/javascript
window.parent.document.onreadystatechange = function() {
if (window.parent.document.readyState == 'complete') {
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
}
};
/script
/head
/html
And it seems to me something is wrong with the numbers I get. As said
above a full review of that code part is needed.
Diego
On 8 Mag, 06:34, Jed Schmidt t...@nslator.jp wrote:
Hello all.
I have two html documents.
(1) parent.html
html
body
iframe src=child.html/
/body
/html
(2) child.html
html
head
script type=text/javascript src=http://ajax.googleapis.com/
ajax/libs/jquery/1.3.2/jquery.min.js/script
script type=text/javascript
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
/script
/head
/html
As is visible from the code, I'm having trouble getting the height of
the document in the parent window. I can access the window, document,
and body of the parent without issue, but can only access the height
of the parent's body. An error is thrown when I try to access the
height of the parent window or document.
Is there something I'm missing here, or does this need a ticket?
Jed Schmidt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( window.parent.document ).height() throws error from child iframe
Jed,
glad it helped show you were the problem is...and yes I suggest you
file a ticket out of the bug you found so it doesn't get lost.
Just a couple of extra thoughts on this fix...the two lines I changed
above are not enough...you will have realized by looking at it !
All those document.body and document.documentElement pointing to
fixed objects should be changed to using the this[0] object to have
meaningful values when working cross-frames.
If it is necessary to have checks on the body in that part of the
code, it should be stated clearly in the DOCS that dimensions should
not be read/tried before they contain some useful value, eg: waiting
for a ready or onload event (on the host object we are going to get
dimensions from).
The IE readystatchange event was the only one I could make to work
to listen for when the parent is ready. That's the reason I included
it, alert should block processing anyway but I know some browser not
being synchronous in that. So to be safe on the IE test.
Diego
On 8 Mag, 23:45, Jed Schmidt t...@nslator.jp wrote:
Thanks for checking on this, Diego. It seems there are still a lot of
current window/document assumptions in the jQuery code base.
(Thanks also for the readystatechange information, though I can't
really put it to use because I'm using this in a bookmarklet.)
Anyway, I'm very grateful for your working fixes, so let me know if
you think I should file a ticket, okay?
Jed Schmidt
On May 8, 11:13 am, Diego Perini diego.per...@gmail.com wrote:
Jed,
forgot to say that you probably have to wrap those alert inside a
readystatechange for IE or similar for other browsers.
You have to wait for all the elements to be loaded in the parent
window before getting dimensions.
Here is the code I used to test:
html
head
script type=text/javascript src=jquery-1.3.2.js/script
script type=text/javascript
window.parent.document.onreadystatechange = function() {
if (window.parent.document.readyState == 'complete') {
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
}
};
/script
/head
/html
And it seems to me something is wrong with the numbers I get. As said
above a full review of that code part is needed.
Diego
On 8 Mag, 06:34, Jed Schmidt t...@nslator.jp wrote:
Hello all.
I have two html documents.
(1) parent.html
html
body
iframe src=child.html/
/body
/html
(2) child.html
html
head
script type=text/javascript src=http://ajax.googleapis.com/
ajax/libs/jquery/1.3.2/jquery.min.js/script
script type=text/javascript
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
/script
/head
/html
As is visible from the code, I'm having trouble getting the height of
the document in the parent window. I can access the window, document,
and body of the parent without issue, but can only access the height
of the parent's body. An error is thrown when I try to access the
height of the parent window or document.
Is there something I'm missing here, or does this need a ticket?
Jed Schmidt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( window.parent.document ).height() throws error from child iframe
Brandon,
thanks so much for the addition.
I will leave part of the code I tried to fix here, maybe you can see
something different from your impl.
jQuery.fn[ type ] = function( size ) {
var doc, root, value;
doc = this[0].ownerDocument || this[0].document || this
[0];
root = doc.compatMode == CSS1Compat ?
doc.documentElement : doc.body;
value =
// Get window width or height
'frameElement' in this[0] ?
root[client + name] ||
root[offset + name] :
// Get document width or height
'documentElement' in this[0] ? Math.max(
root[client + name],
root[scroll + name],
root[offset + name]) :
// Get or set width or height on the element
size === undefined ?
// Get width or height on the element
(this.length ? jQuery.css( this[0],
type ) : null) :
// Set the width or height on the
element (default to pixels if value is unitless)
this.css( type, typeof size ===
string ? size : size + px );
doc = root = null;
return value;
};
Have the best.
Diego
On 9 Mag, 01:37, Jed Schmidt t...@nslator.jp wrote:
That's great news, Brandon, thanks for your hard work! This will
surely make doing iframe development much more reliable.
Jed Schmidt
On May 8, 4:28 pm, Brandon Aaron brandon.aa...@gmail.com wrote:
Sorry for the late reply. No need to file a ticket for this as it has
already been fixed in SVN and will be in 1.3.3. The .css(), .width(), and
.height() methods now work for other windows and documents.
--
Brandon Aaron
On Fri, May 8, 2009 at 4:45 PM, Jed Schmidt t...@nslator.jp wrote:
Thanks for checking on this, Diego. It seems there are still a lot of
current window/document assumptions in the jQuery code base.
(Thanks also for the readystatechange information, though I can't
really put it to use because I'm using this in a bookmarklet.)
Anyway, I'm very grateful for your working fixes, so let me know if
you think I should file a ticket, okay?
Jed Schmidt
On May 8, 11:13 am, Diego Perini diego.per...@gmail.com wrote:
Jed,
forgot to say that you probably have to wrap those alert inside a
readystatechange for IE or similar for other browsers.
You have to wait for all the elements to be loaded in the parent
window before getting dimensions.
Here is the code I used to test:
html
head
script type=text/javascript src=jquery-1.3.2.js/script
script type=text/javascript
window.parent.document.onreadystatechange = function() {
if (window.parent.document.readyState == 'complete') {
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
}
};
/script
/head
/html
And it seems to me something is wrong with the numbers I get. As said
above a full review of that code part is needed.
Diego
On 8 Mag, 06:34, Jed Schmidt t...@nslator.jp wrote:
Hello all.
I have two html documents.
(1) parent.html
html
body
iframe src=child.html/
/body
/html
(2) child.html
html
head
script type=text/javascript src=http://ajax.googleapis.com/
ajax/libs/jquery/1.3.2/jquery.min.js/script
script type=text/javascript
alert( $( window.parent.document ) );
// CORRECT: alerts [object Object]
alert( $( window.parent.document.body ).height() );
// CORRECT: alerts 154
alert( $( window.parent.document ).height() );
// ERROR: Could not convert JavaScript argument arg 0
alert( $( window.parent ).height() );
// ERROR: Could not convert JavaScript argument arg 0
/script
/head
/html
As is visible from the code, I'm having trouble getting the height of
the document in the parent window. I can access the window, document,
and body of the parent without issue, but can only access the height
of the parent's body. An error is thrown when I try to access the
height of the parent window or document.
Is there something I'm missing here, or does this need a ticket
[jquery-dev] NEW! jQuery Multiple File Upload Plugin v1.40
NEW! jQuery Multiple File Upload Plugin v1.40
http://www.fyneworks.com/jquery/multiple-file-upload/
New features:
1. API method to reset control (remove all file selections) like
this:
$('input:file').MultiFile('reset')
Improvements:
1. Now entirely based in the $.fn.MultiFile namespace
2. Now uses $.fn.data to store control settings
3. The plugin will automatically disable the dummy additional input
element when the form is submitted conventionally or by using the
form
plugin - this removes the extra empty file from the end of the array.
IMPORTANT:
Be notified of future updates via this Twitter account:
http://twitter.com/fyneworks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: NEW! jQuery Multiple File Upload Plugin v1.40
Hi Rey,
Sure no problem. Actually, I don't want to clutter any of the jQuery lists
with announcements anymore so I've created a twitter account where I'll post
updates regarding my plugins.
I've also made this pretty obvious for new plugin users so they start
following the twitter account as soon as they first download the plugin.
I'll probably announce the next major update on the main jQuery mailing list
for one last time, then I'll just leave it down to twitter...
Cheers,
Diego A.
2009/4/2 Rey Bango r...@iambright.com
Hey Diego,
Thanks for the heads up. I'm definitely going to test this out!
If you can though, please keep these types of announcements focused on
the main jQuery mailing list. The Dev list is geared towards topics
involving the internals of the jQuery core lib and not general topics.
Rey...
Diego A. wrote:
NEW! jQuery Multiple File Upload Plugin v1.40
http://www.fyneworks.com/jquery/multiple-file-upload/
New features:
1. API method to reset control (remove all file selections) like
this:
$('input:file').MultiFile('reset')
Improvements:
1. Now entirely based in the $.fn.MultiFile namespace
2. Now uses $.fn.data to store control settings
3. The plugin will automatically disable the dummy additional input
element when the form is submitted conventionally or by using the
form
plugin - this removes the extra empty file from the end of the array.
IMPORTANT:
Be notified of future updates via this Twitter account:
http://twitter.com/fyneworks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] NEW! Star Rating Plugin v3.00
NEW! jQuery Star Rating Plugin v3.00 http://www.fyneworks.com/jquery/star-rating/ New features: - Now entirely based in the $.fn.rating namespace - Now uses $.fn.data t9o store control settings - API to set control value / state via javascript - API to change readOnly option dynamically - API to enable / disable control (interrupts form submission) Fixed bugs: - The plugin no longer assumes (requires) that each group of elements has a separate parent ALSO: Be notified of future updates via this Twitter account: http://twitter.com/fyneworks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Ticket #4087 (1.3 regression due to documentFragment)
Dave, I didn't meant changing anything there...maybe I optimized too much. What I wanted to do was just adding a .cloneNode(false) in the second fragment instance in that line so instead of: callback.call( root(this[i], first), this.length 1 || i 0 ? fragment.cloneNode(true) : fragment ); change it to: callback.call( root(this[i], first), this.length 1 || i 0 ? fragment.cloneNode(true) : fragment.cloneNode(false) ); I thought nothing will have changed about node ordering and the original concept... :-) As said above have no sense yet for me...it just removed the error and the li's in the ticket test were reordered correctly. Both concerns you explained above make sense to me ( this.length 1 || i 0 + returned fragment instead of original ). Maybe John can tell us more about the inners... Diego On 2 Mar, 05:19, Dave Methvin dave.meth...@gmail.com wrote: Diego, that patch makes the error go away because the selected node now has a parentNode, but it's the wrong parentNode--it's the document fragment instead of the original document. So, the element gets left behind in the document fragment instead of being inserted back into the document. It looks like the original code has some problems as well. for ( var i = 0, l = this.length; i l; i++ ) callback.call( root(this[i], first), this.length 1 || i 0 ? fragment.cloneNode(true) : fragment ); The expression this.length 1 || i 0 will always be true whenever this.length1 so what is the purpose of the i0? I *think* the intent was this.length 1 i 0 with the idea that the first insert would be the original nodes and the subsequent ones would be clones of that. Even with that change it still causes the problem reported in #4087 though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Ricardo,
I am highly supporting this idea even at the cost of code size (to
some extent).
Also, more independent, normally means more maintainable and less
execution calls so should be faster too.
Diego Perini
On 2 Mar, 13:18, ricardobeat ricardob...@gmail.com wrote:
I'm not really aware of the code practices in the core, but I thought
keeping one method independent from the other was a good thing.
On Mar 1, 6:31 pm, Robert Katić robert.ka...@gmail.com wrote:
Making inline calling would be avoided if not really necessary.
Is the speed difference of two solutions relevant at this point?
However, I am sure that John will consider this optimization too if
needed.
On Mar 1, 8:01 pm, ricardobeat ricardob...@gmail.com wrote:
We can preserve the index without resorting to get (and without
affecting performance) by using a ternary:
jQuery.fn.eq = function( i ) {
return this.pushStack( this[i0 ? i+this.length : i], 'eq', i )
}
cheers,
- ricardo
On Feb 28, 8:42 pm, Robert Katić robert.ka...@gmail.com wrote:
An slightly slower but more robust solution would be:
eq: function( i ) {
return this.pushStack( this.get(i), 'eq', i )
}
The main difference is that the ret.selector would preserve the
initial index (relative if negative).
On Feb 28, 9:44 pm, Robert Katić robert.ka...@gmail.com wrote:
If this solution seems ok, I would update the
tickethttp://dev.jquery.com/ticket/4188.
On Feb 28, 8:50 pm, ricardobeat ricardob...@gmail.com wrote:
Nice catch, that makes sense. Added it to the test page, it has no
significant impact on performance.
cheers,
- ricardo
On Feb 27, 7:27 pm, Robert Katić robert.ka...@gmail.com wrote:
Since .get(-1) will be supported, eq(-1) would be supported too
(?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one
onhttp://dev.jquery.com/ticket/4188, I suppose.
On Feb 26, 11:02 pm, ricardobeat ricardob...@gmail.com wrote:
Right, thanks!
Using pushStack seems ok, it's still chainable and keeps the
selector
state, while still being at least twice faster.
http://dev.jquery.com/ticket/4262http://jquery.nodnod.net/cases/177/run
cheers,
- ricardo
On Feb 26, 11:28 am, John Resig jere...@gmail.com wrote:
Well, first I would argue that the two are not equivalent.
$($(...)[x]) doesn't maintain the stack. You can no longer do:
$(...).eq(1).addClass(test).end().appendTo(#foo);
$($(...)[x]) doesn't maintain the internal selector state for
plugins.
For example if you checked $(...).eq(1).selector you'd see:
.slice(1,
2)
So, with that in mind, if there were ways to maintain that
functionality and still get a performance speed-up, I'd
definitely be
open to it.
--John
On Wed, Feb 25, 2009 at 11:41 PM, Ricardo Tomasi
ricardob...@gmail.com wrote:
Creating two jQuery objects + a lookup $( $(...)[x] ) is
faster than a
simple $(...).eq(x). That doesn't make much sense.
Currently the eq function looks like this:
eq: function( i ) {
return this.slice( i, +i + 1 );
},
Are there any downsides to changing it to this (object
unique IDs,
chaining)?
eq: function( i ) {
return jQuery(this[i]);
},
That offers a 25% to 40% speed improvement across all
browsers.
http://jquery.nodnod.net/cases/177
cheers,
- ricardo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Binding to events in child iframe windows
Jed,
now your test is accessible, I can load it.
One problem I noticed:
frameWindow.onresize = function( e ) {
$(div/)
.text( DOM + e.type + event on the + this.name + at +
+new Date )
.prependTo( frameWindow.document.body );
}
when using DOM0 events IE will not pass the e event argument to the
handler.
So the above will error on IE when trying to access the type
property of an undefined object (e).
I don't recommend using the simple e || (e = window.event) since you
are handling iframes, use the this keyword instead, find the
ownerDocument, then find the parentWindow or
defaultView (depending on browser) and get the event from that
object.
After correcting the above in your test I still get errors in
jquery-1.3.2.js because seemingly at some point ret[i] value is null
before trying to append it in this piece of code around line 958:
if ( ret[i].nodeType === 1 )
ret.splice.apply( ret, [i + 1, 0].concat
(jQuery.makeArray(ret[
fragment.appendChild( ret[i] );
I should momentarily interrupt the testing to follow up some work but
will have a look back.
Diego
On 27 Feb, 04:20, Jed Schmidt t...@nslator.jp wrote:
Diego,
My apologies, I misunderstood you.
(Also, the test case is working now: resize the window to test it, and
see that jQuery is binding one of the resize events incorrectly.)
Jed Schmidt
On Feb 26, 6:01 pm, Diego Perini diego.per...@gmail.com wrote:
Jed,
your test case is not accessible for me. I get Access denied.
Diego
On 27 Feb, 02:21, Jed Schmidt t...@nslator.jp wrote:
The above code is just to skip processing for text nodes (nodeType ==
3) and comments (nodeType == 8), which do not have events.
Windows are the only elements which lack a nodeType, but for which
events (resize, focus) are possible.
Here's a better test
case:http://s3.amazonaws.com/iframeWindowTest/index.html
Jed Schmidt
On Feb 26, 4:51 pm, Diego Perini diego.per...@gmail.com wrote:
Jed,
I would like to add that a few lines above the ones you pointed out we
also have:
if ( elem.nodeType == 3 || elem.nodeType == 8 )
return;
Can elem really be a window/frame reference ?
Shouldn't this give an error since windows/frames do not have a
nodeType property or am I missing the obvious ?
Diego
On 27 Feb, 00:39, Jed Schmidt t...@nslator.jp wrote:
Hello all,
I'm having trouble binding events to the window of a child iframe:
$(iframe/)
.bind( load, function() {
$( this.contentWindow ).bind( function() {
console.log( this == window ) // true, should be false
})
.appendTo( document.body )
Basically, events bound to the window of a child frame end up being
bound to the window in which jQuery is running. I think this might be
because of the following section in jQuery.event.add:
// For whatever reason, IE has trouble passing the window object
// around, causing it to be cloned in the process
if ( elem.setInterval elem != window )
elem = window;
This condition mistakenly triggers for child windows, because they
have the setInterval method but are not the main window.
I think this can be fixed by changing line 2587 to:
if ( elem.setInterval ( elem != window || !elem.frameElement ) )
elem = window;
Jed Schmidt
PS: Also, after doing some iframe-related work, I have a few ideas
about making jQuery more intuitive:
(1) $.fn.html should have a case for iframes that calls open/write/
close for the frame's document, enabling $(iframe/).html
(htmlbodyHello world/body/html)
(2) $.fn.parent and $.fn.children should work for windows, returning
their child/parent windows where possible.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Is it possible to get mouse position when the page has loaded without moving the mouse?
Gavin,
FYI in Firefox 3.0.6 on my Mac it seems I can get at those values
using the Java plugin with following bookmarklet:
javascript:alert(java.awt.MouseInfo.getPointerInfo().getLocation
().getX());
by typing that in the URL bar I can get current mouse X coordinates.
I cannot make it work on Firefox 3.0.6 WIndows, I get Access Denied
in the console log.
I feel dirty just by saying that...
I know this hackery is not going to solve your problem cross-
browser, for that reason I would prefer to revisit the problem and
think to a different solution.
Diego
On 27 Feb, 17:48, d3r1v3d (Gavin Mulligan) vtga...@gmail.com
wrote:
You're right, it does seem to work in IE 7. However, it still fails to
work in Firefox and Chrome...
- Gavin
On Feb 27, 11:42 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I tested in IE :D
On Fri, Feb 27, 2009 at 2:20 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com
wrote:
Yep, I tried your code in a demo page and it confirmed my initial
suspicions. It works great when the DOM of the test page is
initialized with the mouse coordinates. However, this only happens
when the mouse is initially moved after the page is refreshed.
Put your mouse in the middle of the test page, and hit F5 without
moving your mouse. No alerts will pop up until your mouse moves at
least a pixel. If you continue slamming refresh, no alerts at all will
display. The 'mouseover' event doesn't trigger until the mouse is
moved over the body of the web page. Additionally, the same is true if
you use your mouse to manually hit the refresh button, since it exists
outside the confines of the page.
Note: I tested in Chrome and Firefox 3 on Windows.
- Gavin
On Feb 27, 8:47 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I do not need to move the mouse to fire that event ... have you tried?
write this wherever and press F5 without move the mouse ...
document.documentElement.onmouseover = function(){
alert(Who moved?);
};
Regards
On Fri, Feb 27, 2009 at 12:54 PM, d3r1v3d (Gavin Mulligan)
vtga...@gmail.com wrote:
Yes, but that requires the 'mouseover' event to be executed; which, in
turn, requires that a user move their mouse over the page at least a
pixel for it to trigger.
I believe Marcus was asking if it was possible to retrieve a user's
current mouse position without moving the cursor at all.
- Gavin
On Feb 27, 4:17 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
$(document.documentElement).bind(mouseover, function(eventObj){
alert([eventObj.clientX, eventObj.clientY]);
});
On Thu, Feb 26, 2009 at 2:49 PM, d3r1v3d (Gavin Mulligan)
vtga...@gmail.com
wrote:
Hi Marcus,
The function I've always used for obtaining the current mouse
position
is:
function getMousePosition(eventObj){
if (eventObj.pageX eventObj.pageY)
{
return {x: eventObj.pageX, y: eventObj.pageY};
}
return {x: (eventObj.clientX + document.body.scrollLeft -
document.body.clientLeft),
y: (eventObj.clientY + document.body.scrollTop -
document.body.clientTop)};
}
However, the major caveat here is that you need to bind this
function
to some event. A given browser will keep track of mouse movements
within itself, but I do not believe it tracks movements outside
its
window. Additionally, unless a user has moved their mouse within a
given web page, I don't believe the DOM for that page is updated
with
the appropriate coordinates. So, long story short, I don't think
what
you're asking is possible.
- Gavin
On Feb 26, 9:41 am, smurkas marcus.dalg...@gmail.com wrote:
Hello. I ran into this problem today. I would like to know the
mouse
position when the page has loaded without the user having to
move
the mouse. I have tried just getting the xy-values but it
returned
undefined if I triggered on document load and 0 0 if I just
trigger
different mouse events when the page has loaded via firebug.
Is it possible to get the values without moving the mouse and
if
so,
how do I do it?
Yours kindly, Marcus.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Is it possible to get mouse position when the page has loaded without moving the mouse?
Andrea, On 28 Feb, 00:42, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I bet is the classic banner, spot, or JS effect to attach to the mouse and somebody asked him why it is not attached since the beginning ... well, Marcus, if it is the case tell them that the browser is inside a window and if the user is not interacting with that window there's nothing you can do via web except create a plugin to download, even more disturbing ;-) This is correct...however you can still createEvent() / dispatchEvent () whatever type you like but the coordinates must be specified in the event initialization method so the scope of the OP is lost again. The difference in IE and probably a possible reason for this is that IE has a global window event for each document so whenever you can get at the event object those XY properties have already been populated by the underlying layers. In IE you can .click() any element in a programmatic way since all have a .click() method. The generated event will have current cursor position properties up to date and so will other events like onmouseover you told. This will not happen in other browsers. And even if it is possible to add a .click() prototype to elements using browsers native event constructor/dispatcher the screenX/screenY should always be passed as parameters to the initMoseEvent/initEvent methods. Take this with a bit of salt... In every other case, I am curios as well but thanks to this issue I discovered that onmouseover in internet explorer isfired ONLY if the document.body is already present in the DOM, somwthing that could be useful for the doScroll interception as well (since Diego is reading this post) Yes, this is a nice bit of info you got into. You are welcome to set something up and explore that approach in your spare time. That will just say the body was present and the time somebody mouseovered it. Far from a ready notification but still usable to some extent. I would like to spare you this, but I know/understand how strong the temptation may be and I don't know if a simple sentence like you are talking about Activation events will convince you desist. There are some accidental similarities with the ready moment, nothing else. I went that way with the onfocus once trying to achieve cross- browser when no DOMContentLoaded existed yet...then I was attracted by the onactivate/onbeforeactivate trying to solve the exact same problem, but I was wrong again that stuff was very useful for another task with events... while doScroll() survived to all of IE6/7/8...(to date). All those Activation events should be definitely be taken in consideration to widen support on IE emulating other browser established behaviors (W3C). Hey...I am speaking about IE8 here not just about IE6 and IE7. Diego On Fri, Feb 27, 2009 at 11:13 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com wrote: Just out of curiosity, Marcus, I would be interested to know why you want to know the user's mouse position before they move it. Maybe there's a better solution that'll fit snugly within the scope of your requirements. - Gavin On Feb 27, 12:02 pm, unwiredbrain unwiredbr...@gmail.com wrote: 2009/2/27 d3r1v3d (Gavin Mulligan) vtga...@gmail.com: You're right, it does seem to work in IE 7. However, it still fails to work in Firefox and Chrome... Both methods suggested by Andrea Giammarchi are working properly on my box -- Firefox 3.0.6, Linux. I wonder if it's just a Windows' window focus management issue... Mac OS X testing anyone? Hope that helps -- unwiredbrain Linux user #437712 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Binding to events in child iframe windows
Jed,
it seems the first error you mentioned is now OK in all browser I
could test.
In Internet Explorer 6 I still see the second error I said above in
line 958 char 6 error: Invalid argument.
But this is a different issue, your patch seems to have corrected the
logic error, hope somebody from the team notice this other problem
with IE6. Only IE6 have show to be affected up to now, is there a soul
that can try Jed tests with IE7 ?
Diego
On 27 Feb, 20:19, Jed Schmidt t...@nslator.jp wrote:
Diego,
Thanks for taking a look. I've distilled the test case down to make it
simpler:
http://s3.amazonaws.com/iframeWindowTest/before.htmlhttp://s3.amazonaws.com/iframeWindowTest/after.html
And submitted a bug here:
http://dev.jquery.com/ticket/4268
Jed Schmidt
On Feb 27, 7:26 am, Diego Perini diego.per...@gmail.com wrote:
Jed,
now your test is accessible, I can load it.
One problem I noticed:
frameWindow.onresize = function( e ) {
$(div/)
.text( DOM + e.type + event on the + this.name + at +
+new Date )
.prependTo( frameWindow.document.body );
}
when using DOM0 events IE will not pass the e event argument to the
handler.
So the above will error on IE when trying to access the type
property of an undefined object (e).
I don't recommend using the simple e || (e = window.event) since you
are handling iframes, use the this keyword instead, find the
ownerDocument, then find the parentWindow or
defaultView (depending on browser) and get the event from that
object.
After correcting the above in your test I still get errors in
jquery-1.3.2.js because seemingly at some point ret[i] value is null
before trying to append it in this piece of code around line 958:
if ( ret[i].nodeType === 1 )
ret.splice.apply( ret, [i + 1, 0].concat
(jQuery.makeArray(ret[
fragment.appendChild( ret[i] );
I should momentarily interrupt the testing to follow up some work but
will have a look back.
Diego
On 27 Feb, 04:20, Jed Schmidt t...@nslator.jp wrote:
Diego,
My apologies, I misunderstood you.
(Also, the test case is working now: resize the window to test it, and
see that jQuery is binding one of the resize events incorrectly.)
Jed Schmidt
On Feb 26, 6:01 pm, Diego Perini diego.per...@gmail.com wrote:
Jed,
your test case is not accessible for me. I get Access denied.
Diego
On 27 Feb, 02:21, Jed Schmidt t...@nslator.jp wrote:
The above code is just to skip processing for text nodes (nodeType ==
3) and comments (nodeType == 8), which do not have events.
Windows are the only elements which lack a nodeType, but for which
events (resize, focus) are possible.
Here's a better test
case:http://s3.amazonaws.com/iframeWindowTest/index.html
Jed Schmidt
On Feb 26, 4:51 pm, Diego Perini diego.per...@gmail.com wrote:
Jed,
I would like to add that a few lines above the ones you pointed out
we
also have:
if ( elem.nodeType == 3 || elem.nodeType == 8 )
return;
Can elem really be a window/frame reference ?
Shouldn't this give an error since windows/frames do not have a
nodeType property or am I missing the obvious ?
Diego
On 27 Feb, 00:39, Jed Schmidt t...@nslator.jp wrote:
Hello all,
I'm having trouble binding events to the window of a child iframe:
$(iframe/)
.bind( load, function() {
$( this.contentWindow ).bind( function() {
console.log( this == window ) // true, should be false
})
.appendTo( document.body )
Basically, events bound to the window of a child frame end up
being
bound to the window in which jQuery is running. I think this
might be
because of the following section in jQuery.event.add:
// For whatever reason, IE has trouble passing the window object
// around, causing it to be cloned in the process
if ( elem.setInterval elem != window )
elem = window;
This condition mistakenly triggers for child windows, because they
have the setInterval method but are not the main window.
I think this can be fixed by changing line 2587 to:
if ( elem.setInterval ( elem != window || !elem.frameElement )
)
elem = window;
Jed Schmidt
PS: Also, after doing some iframe-related work, I have a few ideas
about making jQuery more intuitive:
(1) $.fn.html should have a case for iframes that calls
open/write/
close for the frame's document, enabling $(iframe/).html
(htmlbodyHello world/body/html)
(2) $.fn.parent and $.fn.children should work for windows,
returning
their child/parent windows where possible
[jquery-dev] Re: jQuery 1.3.2 Released
John, some great updates you are releasing, everything has been improved, new functionalities and increased speed for the core methods. Events management covers most of what I would expect. The bits about return false and .stopPropagation() on .live() will be very useful. My compliments to the team. Diego On 21 Feb, 02:05, John Resig jere...@gmail.com wrote: Hi Everyone - Full details here:http://docs.jquery.com/Release:jQuery_1.3.2 Enjoy! --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3.2 Alpha Ready
John,
thank you for the nice additions and fixes, the document order is
really welcome :-)
Just a minor thing I noticed in the new code source is about older
Opera (probably 9.27 and older). Opera have implemented the
sourceIndex property too but it starts at index 0 for the
documentElement.
So your check (starting at at line 2096):
if ( Array.prototype.indexOf ) {
...
} else if ( document.documentElement.sourceIndex === 1 ) {
...
}
will fail for that specific browser (since it doesn't have an indexOf
() either) and probably others versions/browsers too.
Don't know if that is still supported or if there is an interest into
solving this more generically with proper tests.
Diego
On 16 Feb, 19:31, John Resig jere...@gmail.com wrote:
Hey Everyone -
Just finished up the last ticket for 1.3.2 and wanted to throw a copy
out for people to try:http://code.jquery.com/nightlies/jquery-2009-02-16.js
Please let me know if anything is breaking from 1.3.1 - 1.3.2.
There were some logic changes - specifically with cloning in IE (lots
of bug fixes), how the selector engine, how :visible/:hidden work,
.height()/.width(), and .ready() in IE - so watch those areas in
particular.
The current full ticket list can be found here:http://dev.jquery.com/report/33
Thanks!
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Forcing an event handler to be the first handler
Scott,
I tried to post this a couple of time on this thread, but seems there
where problem with Groups...
What I said above is incorrect, in that way it is obviously impossible
to stop a click event to happen from a mouseup handler on the same
element.
However I looked back at how I did it and realize I removed the
click event handler before it happen:
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script type=text/javascript
window.onload = function() {
var element = document.getElementById('tester');
function logandstop(event) {
if (event.type == 'mouseup') {
if (element.removeEventListener) {
element.removeEventListener('click', logandstop, false);
} else {
element.detachEvent('onclick', logandstop);
}
}
top.status += ' * ' + event.type;
}
if (element.addEventListener) {
element.addEventListener('mousedown', logandstop, false);
element.addEventListener('mouseup', logandstop, false);
element.addEventListener('click', logandstop, false);
} else {
element.attachEvent('onmousedown', logandstop);
element.attachEvent('onmouseup', logandstop);
element.attachEvent('onclick', logandstop);
}
};
/script
/head
bodydiv id=testerdivClick me !/div/div/body
/html
For the same order reason I gave in my previous post (mousedown
mouseup click) this will work cross-browser (tested FF3, IE6, Opera
9.6 Safari 3.2). The click event is not fired and the order in
which the three handler are registered does not change the results.
I should add that in some cases I have also used an element overlay
technique similar to the one you described, to separate events on
different elements.
Diego
On 14 Feb, 15:30, Scott González scott.gonza...@gmail.com wrote:
Thanks Diego, I'll try this out. However, for this specific case
this may not be a good solution for us because we want to allow the
mousedown event to bubble up.
On Feb 13, 9:10 pm, Diego Perini diego.per...@gmail.com wrote:
Scott,
if I recall correctly, the solution to this maybe in the way the click
event works.
click = mousedown + mouseup
if you setup three handlers, one for each of the above events you
should see them fire in this order:
mousedown - mouseup - click
Don't use the alert() to show them they may appear in the wrong order,
use top.status...
Now (to cover different browsers) insert these lines in the mouseup
handler:
event.stopPropagation();
event.preventDefault();
event.cancelBubble = true;
event.returnValue = false;
return false;
The click event shouldn't happen then.
One or more of the above lines shouldn't be necessary but while
testing you can leave them all, I really can't remember very well in
this moment...I suggest you try this first with native methods on FF
and see the result compared with those you can get with jQuery.
Let me know if I did understand your problem correctly. The above
seemed weird to me at first but there are reasons to it, so a quick
test will hopefully take you out of doubts...or put more on me... :-)
Diego
On 13 Feb, 22:14, Scott González scott.gonza...@gmail.com wrote:
Not being able to guarantee the order does make this tricky. At least
for now, I'm just looking for something to improve our reliability in
UI, even if we don't provide this as a guaranteed method for putting
your handler at the top of the stack.
As for why we want to do this, we're modifying the defined behavior
that browsers provide. The draggable plugin provides non-native
functionality and creates non-native events. In addition to creating
new events, we believe that modifying the existing event system is
beneficial. So if you mousedown and mouseup on a draggable element
without dragging, then you should get a click event and no drag
events. However, if you do drag, you should get all of the drag
events (dragstart, drag, dragstop) and not get the click event, since
you performed a drag not a click.
Since we can't actually prevent the click event from being triggered,
the best we can do is cancel the click event as soon as it's
triggered. While writing this last sentence I had an idea that we
could throw a transparent div over the draggable as soon as dragging
starts. This would cause the mouseup to occur on a different element
than the mousedown and should prevent the click event altogether.
On Feb 13, 10:07 am, Brandon Aaron brandon.aa...@gmail.com wrote:
Before we can answer that, we need to answer this question:
Are we, as a library, guaranteeing the order of events as part of our
API?
The spec and browsers do not guarantee the order of events and our
ordering
is more a side-affect of how we currently handle the events.
Even with your bindFirst method you cannot guarantee that your event
will be
the first when finally triggered. Why
[jquery-dev] Re: Forcing an event handler to be the first handler
Scott,
what I said above is incorrect, in that way it is obviously impossible
to stop a click event to happen from a mouseup handler on the same
element.
However I looked back at how I did it and realize I removed the
click event handler before it happen:
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
script type=text/javascript
window.onload = function() {
var element = document.getElementById('tester');
function logandstop(event) {
if (event.type == 'mouseup') {
if (element.removeEventListener) {
element.removeEventListener('click', logandstop, false);
} else {
element.detachEvent('onclick', logandstop);
}
}
top.status += ' * ' + event.type;
}
if (element.addEventListener) {
element.addEventListener('mousedown', logandstop, false);
element.addEventListener('mouseup', logandstop, false);
element.addEventListener('click', logandstop, false);
} else {
element.attachEvent('onmousedown', logandstop);
element.attachEvent('onmouseup', logandstop);
element.attachEvent('onclick', logandstop);
}
};
/script
/head
bodydiv id=testerdivClick me !/div/div/body
/html
For the same order reason I gave in my previous post (mousedown
mouseup click) this will work cross-browser (tested FF3, IE6, Opera
9.6 Safari 3.2). The click event is not fired and the order in
which the three handler are registered does not change the results.
I should add that in some cases I have also used an element overlay
technique similar to the one you described, to separate events on
different elements.
Diego
On 14 Feb, 03:10, Diego Perini diego.per...@gmail.com wrote:
Scott,
if I recall correctly, the solution to this maybe in the way the click
event works.
click = mousedown + mouseup
if you setup three handlers, one for each of the above events you
should see them fire in this order:
mousedown - mouseup - click
Don't use the alert() to show them they may appear in the wrong order,
use top.status...
Now (to cover different browsers) insert these lines in the mouseup
handler:
event.stopPropagation();
event.preventDefault();
event.cancelBubble = true;
event.returnValue = false;
return false;
The click event shouldn't happen then.
One or more of the above lines shouldn't be necessary but while
testing you can leave them all, I really can't remember very well in
this moment...I suggest you try this first with native methods on FF
and see the result compared with those you can get with jQuery.
Let me know if I did understand your problem correctly. The above
seemed weird to me at first but there are reasons to it, so a quick
test will hopefully take you out of doubts...or put more on me... :-)
Diego
On 13 Feb, 22:14, Scott González scott.gonza...@gmail.com wrote:
Not being able to guarantee the order does make this tricky. At least
for now, I'm just looking for something to improve our reliability in
UI, even if we don't provide this as a guaranteed method for putting
your handler at the top of the stack.
As for why we want to do this, we're modifying the defined behavior
that browsers provide. The draggable plugin provides non-native
functionality and creates non-native events. In addition to creating
new events, we believe that modifying the existing event system is
beneficial. So if you mousedown and mouseup on a draggable element
without dragging, then you should get a click event and no drag
events. However, if you do drag, you should get all of the drag
events (dragstart, drag, dragstop) and not get the click event, since
you performed a drag not a click.
Since we can't actually prevent the click event from being triggered,
the best we can do is cancel the click event as soon as it's
triggered. While writing this last sentence I had an idea that we
could throw a transparent div over the draggable as soon as dragging
starts. This would cause the mouseup to occur on a different element
than the mousedown and should prevent the click event altogether.
On Feb 13, 10:07 am, Brandon Aaron brandon.aa...@gmail.com wrote:
Before we can answer that, we need to answer this question:
Are we, as a library, guaranteeing the order of events as part of our API?
The spec and browsers do not guarantee the order of events and our
ordering
is more a side-affect of how we currently handle the events.
Even with your bindFirst method you cannot guarantee that your event will
be
the first when finally triggered. Why is the bindFirst method necessary?
Why
don't you want other subscribers to know the event was triggered?
Shouldn't
those subscribers be prepared to check if a particular change actually
happened or not for some events?
--
Brandon Aaron
On Fri, Feb 13, 2009 at 8:41 AM, Scott González
scott.gonza...@gmail.comwrote:
We have a few places in jQuery UI where we need
[jquery-dev] Re: $(a, b, c) and Elements in document order
Robert,
I have also needed this bit of help from jQuery...for extracting texts
from HTML code.
I proposed this similar solution on the Sizzle group some time ago:
http://groups.google.com/group/sizzlejs/browse_thread/thread/44d2b3fd5d532b5b
which probably solves with a simpler sort() on the result set, maybe
only done when a comma (group separator) is found in the selector.
Maybe your code adds some way to do it faster or are there other
reasons to not use .sort() ?
Diego
On 14 Feb, 01:47, Robert Katić robert.ka...@gmail.com wrote:
I corrected the joinResultsHelper:
function joinResultsHelper( res, a, i, b, j ) {
if ( b b[j] ) {
for ( var l = a.length; i l; ++i ) {
if ( a[i] === b[j] !b[++j] )
return joinResultsHelper( res, a, i )
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
joinResultsHelper( res, b, j, a, i );
break;
}
}
} else {
for ( var l = a.length; i l; ++i )
res.push( a[i] );
}
return res;
}
On Feb 14, 12:26 am, Robert Katić robert.ka...@gmail.com wrote:
The querySelectorAll returns elements in documents order, but Sizzle
(for now?) treat each selector separately.
Maybe this can be easily resolved joining each result array in one
with nodes in documents order?
If so, maybe something like this would help (not tested). Or you are
thinking to sort results all together?
var precedes = ( document.documentElement.sourceIndex == 0 )
function( a, b ) {
return a.sourceIndex b.sourceIndex;
}
|| ( document.documentElement.compareDocumentPosition )
function( a, b ) {
return !!( a.compareDocumentPosition(b) 4 );
}
|| function( a, b ) {
if ( a === b || b.contains(a) )
return false
if ( a.contains(b) )
return true;
var c = a.parentNode;
while ( !c.contains(b) ) {
a = c;
c = c.parentNode;
}
var p = b.parentNode;
while ( p !== c ) {
b = p;
p = p.parentNode;
}
var nodes = c.childNodes;
for ( var i = 0, node = nodes[0]; node; node = nodes[+
+i] ) {
if ( node === a )
return true;
if ( node === b )
return false;
}
return false;
};
function joinResultsHelper( res, a, i, b, j ) {
if ( b[j] ) {
for ( var l = a.length; i l; ++i ) {
if ( a[i] === b[j] )
++j;
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
joinResultsHelper( res, b, j, a, i );
break;
}
}
} else {
for ( var l = a.length; i l; ++i )
res.push( a[i] );
}
return res;
}
function joinResults( a, b ) {
if ( a.length === 0 )
return b;
if ( b.length === 0 )
return a;
return joinResultsHelper( [], a, 0, b, 0 );
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Forcing an event handler to be the first handler
Scott, if I recall correctly, the solution to this maybe in the way the click event works. click = mousedown + mouseup if you setup three handlers, one for each of the above events you should see them fire in this order: mousedown - mouseup - click Don't use the alert() to show them they may appear in the wrong order, use top.status... Now (to cover different browsers) insert these lines in the mouseup handler: event.stopPropagation(); event.preventDefault(); event.cancelBubble = true; event.returnValue = false; return false; The click event shouldn't happen then. One or more of the above lines shouldn't be necessary but while testing you can leave them all, I really can't remember very well in this moment...I suggest you try this first with native methods on FF and see the result compared with those you can get with jQuery. Let me know if I did understand your problem correctly. The above seemed weird to me at first but there are reasons to it, so a quick test will hopefully take you out of doubts...or put more on me... :-) Diego On 13 Feb, 22:14, Scott González scott.gonza...@gmail.com wrote: Not being able to guarantee the order does make this tricky. At least for now, I'm just looking for something to improve our reliability in UI, even if we don't provide this as a guaranteed method for putting your handler at the top of the stack. As for why we want to do this, we're modifying the defined behavior that browsers provide. The draggable plugin provides non-native functionality and creates non-native events. In addition to creating new events, we believe that modifying the existing event system is beneficial. So if you mousedown and mouseup on a draggable element without dragging, then you should get a click event and no drag events. However, if you do drag, you should get all of the drag events (dragstart, drag, dragstop) and not get the click event, since you performed a drag not a click. Since we can't actually prevent the click event from being triggered, the best we can do is cancel the click event as soon as it's triggered. While writing this last sentence I had an idea that we could throw a transparent div over the draggable as soon as dragging starts. This would cause the mouseup to occur on a different element than the mousedown and should prevent the click event altogether. On Feb 13, 10:07 am, Brandon Aaron brandon.aa...@gmail.com wrote: Before we can answer that, we need to answer this question: Are we, as a library, guaranteeing the order of events as part of our API? The spec and browsers do not guarantee the order of events and our ordering is more a side-affect of how we currently handle the events. Even with your bindFirst method you cannot guarantee that your event will be the first when finally triggered. Why is the bindFirst method necessary? Why don't you want other subscribers to know the event was triggered? Shouldn't those subscribers be prepared to check if a particular change actually happened or not for some events? -- Brandon Aaron On Fri, Feb 13, 2009 at 8:41 AM, Scott González scott.gonza...@gmail.comwrote: We have a few places in jQuery UI where we need to prevent events from occurring, e.g., preventing the click event after a drag. We've been partially successful by just binding a handler and the click event and returning false. This can be improved by calling event.stopImmediatePropagation(), but that won't prevent handlers bound before ours from running. The only solution I can come up with is to force our handler to be the first handler. With some help from Ariel, I've put togheter some code (http://codedumper.com/oxewu) and I'm looking for some feedback. Is there some other way we can prevent event handlers from running? Are there still caveats like native onclick events? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: general RegExp optimizations
I believe the point made by Ariel about non-local access is to be taken in high consideration. As he said, the gain obtained by caching very small expressions may be lost due to non-local variable access. So changes should be done only where a speed improvement can be achieved and verified. The trim() case was solved and the problem was not about caching of the regular expression but maybe a too complicated RegExp for the task. A simpler one was enough. As I said, I was following the trim() thread, spotting some ideas on what could be wrong. So speed is not a concern, readability maybe, if it doesn't slow down code execution. Diego On 2 Feb, 17:19, John Resig jere...@gmail.com wrote: It depends - if there's a considerable amount of duplicate code it would be good to cut down on that (using the same regex over and over, for example). --John On Mon, Feb 2, 2009 at 8:40 AM, Ariel Flesler afles...@gmail.com wrote: Why patch it, John ? there's no speed gain and I actually think it'd make things slower. If you save the regex in a var within the upper scope, each access will take longer than if it were 100% local. -- Ariel Flesler http://flesler.blogspot.com On Feb 1, 10:09 pm, John Resig jere...@gmail.com wrote: Ah, ok. I suspect that some of that may be in Sizzle. Patches are welcome! --John On Sun, Feb 1, 2009 at 2:14 PM, Diego Perini diego.per...@gmail.com wrote: John, well I did some small test with: /\s+/ /\\/g and it seems there is no appreciable speed gain that I could measure. I spotted those shorter RegExp because I saw they are re-used at least 4 or 5 times in current jQuery. Thanks to jdalton for the link and explanation. Diego On 1 Feb, 15:53, John Resig jere...@gmail.com wrote: Is there any appreciable speed-up to caching RegExp that are that small? I wasn't able to find any when I looked. --John On Sun, Feb 1, 2009 at 7:58 AM, Diego Perini diego.per...@gmail.com wrote: I did have a quick look through the code and see that most of the (small) regular expressions are not cached and referenced but defined in-line in the conditionals/replacements. For example these are repeatedly used in various place: /\s+/ /\\/g /\?/ I believe there are improvements in both speed and readability of code by caching them compiled. Is there some reason I don't know in not defining some constants like TRIM, SQUEEZE, ESCAPE etc... ? Diego- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: the ready not working properly in Opera, safari and chrome
Karl,
these are other tips if loading jQuery using Google AJAX Library API.
I know it is possible to only load jQuery from Google without needing
their API but I also know that sometime there are good reasons and
features in using them.
Google JSAPI implements the same technique implemented in jQuery ready
(). Their google.setOnLoadCallback() method accepts two parameters,
the first is a function to be executed, the second is a boolean that
indicates if the function is executed at onload time (false or
absent) or when the DOM is ready (true).
So here is one way on how to use the ready() method (both Google and
jQuery ones) in case one load jQuery through Google JSAPI (known and
easy):
script type=text/javascript src=http://www.google.com/jsapi;/
script
script type=text/javascript
// Load jQuery
google.load(jquery, 1.3.1);
// fire when page load complete
google.setOnLoadCallback(function() {
alert(Google onload());
}, false);
// fire when DOM is complete
google.setOnLoadCallback(function() {
alert(Google ready());
}, true);
/script
script type=text/javascript
$(document).ready(function() {
alert(jQuery ready());
});
/script
In the above example the jQuery ready() call is in a script block
different from the one were it is loaded.
The other way, this avoids using an extra script tag (and is less
known/obvious):
script type=text/javascript src=http://www.google.com/jsapi;/
script
script type=text/javascript
// Load jQuery
google.load(jquery, 1.3.1);
// fire when page load complete
google.setOnLoadCallback(function() {
alert(Google onload());
}, false);
// fire when DOM is complete
google.setOnLoadCallback(function() {
$(document).ready(function() {
alert(jQuery ready());
});
alert(Google ready());
}, true);
/script
Both in the first and second method I have left in the
google.setOnLoadCallback( fn, false ) just to show the small syntax
difference (true/false).
Using the Google JSAPI is possible to load older jQuery versions (
1.2.3) and still use a more recent and stable ready() method from
Google JSAPI.
Evaluate and see if this has it's place somewhere in the docs,
Diego
On 2 Feb, 21:26, Karl Swedberg k...@englishrules.com wrote:
Hi Diego,
Thanks. Yes, it is in the documentation for ready(). I should have
linked to it here, as I did on jquery-en where the OP was cross-posted.
http://docs.jquery.com/Events/ready:
Note: Please make sure that all stylesheets are included before your
scripts (especially those that call the ready function). Doing so
will make sure that all element properties are correctly defined
before jQuery code begins executing. Failure to do this will cause
sporadic problems, especially on WebKit-based browsers such as Safari.
--Karl
Karl Swedbergwww.englishrules.comwww.learningjquery.com
On Feb 2, 2009, at 3:01 PM, Diego Perini wrote:
Karl,
nice tip, is there a link to this in the documentation for ready() ?
It will not force users to read the documentation but you can answer
back with a link to the docs.
I see this may pop up frequently for Webkit/Opera users so a small
description will hopefully cut on the number of hits.
Diego
On 2 Feb, 14:20, Karl Swedberg k...@englishrules.com wrote:
If the problem you're having is with stylesheet info not being
available on ready, the solution is to change the source order in the
html: make sure that you reference them in the head before you
reference your scripts.
--Karl
Karl Swedbergwww.englishrules.comwww.learningjquery.com
On Feb 2, 2009, at 6:53 AM, Tom Tom wrote:
Hello.
I discovered some time ago that in browsers based on WebKit, the
ready not working properly. Looking into the code of jQuery 1.3.1 in
binready I noticed it was missing the code. Because it tests only
for IE and mozilla. It does not test for Opera, Safari and Chrome.
I analyzed the version 1.2.6 and the bindready code has changed,
result, in opera, safari and chrome, the ready does not work
properly (stylesheets are loaded after the page content)
Could you give me an alternative to not put the code of 1.2.6 in
1.3.1?
Here is the code I changed. The ready work correctly with these
changes :
// Figure out what browser is being used
jQuery.browser = {
version: (userAgent.match( /.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/ )
|| [0,'0'])[1],
safari: /webkit/.test( userAgent ),
opera: /opera/.test( userAgent ),
msie: /msie/.test( userAgent ) !/opera/.test( userAgent ),
mozilla: /mozilla/.test( userAgent ) !/(compatible|
webkit)/.test( userAgent ),
language: navigator.language? navigator.language :
navigator.userLanguage,
chrome : /chrome/.test(navigator.userAgent.toLowerCase())
};
function bindReady(){
if ( readyBound ) return;
readyBound = true;
// Mozilla, Opera (see further below
[jquery-dev] general RegExp optimizations
I did have a quick look through the code and see that most of the (small) regular expressions are not cached and referenced but defined in-line in the conditionals/replacements. For example these are repeatedly used in various place: /\s+/ /\\/g /\?/ I believe there are improvements in both speed and readability of code by caching them compiled. Is there some reason I don't know in not defining some constants like TRIM, SQUEEZE, ESCAPE etc... ? Diego --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: general RegExp optimizations
John, well I did some small test with: /\s+/ /\\/g and it seems there is no appreciable speed gain that I could measure. I spotted those shorter RegExp because I saw they are re-used at least 4 or 5 times in current jQuery. Thanks to jdalton for the link and explanation. Diego On 1 Feb, 15:53, John Resig jere...@gmail.com wrote: Is there any appreciable speed-up to caching RegExp that are that small? I wasn't able to find any when I looked. --John On Sun, Feb 1, 2009 at 7:58 AM, Diego Perini diego.per...@gmail.com wrote: I did have a quick look through the code and see that most of the (small) regular expressions are not cached and referenced but defined in-line in the conditionals/replacements. For example these are repeatedly used in various place: /\s+/ /\\/g /\?/ I believe there are improvements in both speed and readability of code by caching them compiled. Is there some reason I don't know in not defining some constants like TRIM, SQUEEZE, ESCAPE etc... ? Diego --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Very slow performance in 1.3.1 when inserting large HTML fragment
Dimi Paun, It could be the slowdown is due to the in-line RegExp in the trim(). I always keep these pre-compiled in an external variable for speed (cached). Since you are going to try, I would suggest that as the first try. Next try would be also to avoid a call to trim() and just do it in- line there (in the clean() method) and see if this improve the speed...and how much...I bet there is quite an improvement, don't know if it is enough for the OP...wow 660Kb... First declare externally the used RegExp some place (another tip, is the /g global flag necessary ? if not it will also be part of the slow down): var trim = /^\s+|\s+$/g, then in clean() line 868 (in 1.3.1): // Trim whitespace, otherwise indexOf won't work as expected var tags = elem.replace(trim, '').toLowerCase(); I would then try to only do the left part as you suggested, believe that's enough too. I haven't tested any of the above just trying to help spot the problem, I know some is already doing the tests Diego On 31 Gen, 16:16, Dimi Paun d...@lattica.com wrote: Thanks. But we can do better still: 1. it seems that the slow part for trimming is trimming spaces at the *end* which is rather irrelevant here. 2. in fact, we don't need _any_ trimming here, we could just have a reg exp that matches the begging and ignores leading spaces. Of course, (2) is more work/code than (1). I'll give them a try and report back. On Sat, 2009-01-31 at 04:08 -0800, Ariel Flesler wrote: http://dev.jquery.com/ticket/2279#comment:7 -- Ariel Flesler http://flesler.blogspot.com On 30 ene, 22:02, dimi d...@lattica.com wrote: Hi folks, I have a large HTML fragment that I load via AJAX. The fragment is big (~660KB), and it takes over 2s (more like 2.7s) to insert it. I've profiled the code, and it turns out that most of the time is spent in the .trim() function. It is being called from .clean() (around line 835): // Trim whitespace, otherwise indexOf won't work as expected var tags = jQuery.trim( elem ).toLowerCase(); Is this something that can be fixed? Dimi. -- Dimi Paun d...@lattica.com Lattica, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] live() slowing down DOM access after each firing
I have just gone through a problem in code that seems related to live
().
A coworker has just shifted from bind() to live() in a page where many
UL / LI / A (probably a hundred of them).
The anchors are just internal page jumps, there are counters for each
click on them. The user have to follow a specific path through them
and get a score.
The event types for which he did the change are only mouseover and
mouseout, also he will need to do the same for clicks, he just
stopped when he saw that a few seconds interaction with that page will
slow down his processing.
I looked at the code and suggested to put the minimum necessary in the
live() callbacks, we finished up testing with this bare minimum:
$('ul li a').live('mouseover', function (e) {
e.target.style.backgroundColor = 'red';
});
$('ul li a').live('mouseout', function (e) {
e.target.style.backgroundColor = '';
});
the hover effect still works as expected on all the links but the
problem still happen in the main code, it is not visible initially
since the slow down is increasing few hundreds milliseconds for each
triggering of the events,
after a minute interacting the browser spit the warning The script is
taking to much time.
He does not have the same trouble with bind() at least the problem
does not show up.
Are there quirks or suggestion in how to better isolate and debug the
problem in live() ?
Diego
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: live() slowing down DOM access after each firing
John,
I have no access to all the code, at least not yet, some part of it is
also packed and minified and not part of jQuery. So there may be
something wrong there. They don't make great use of jQuery that's for
sure, they where trying to spice up a bit the ugly interface they had.
The problem is they did it before with 1.2.6 with no problem using the
bind() method. Now, somebody suggested them delegation was far
superior for their task so they tried with live() in jQuery 1.3.1 and
they fall in the problem I described.
I checked the page they showed with FF Tidy validator and it showed no
problems in the HTML. There is basically nothing except hundreds of
UL / LI / A, more or less like this:
ul
lia href=#mainFirst Level A/a
ul
lia href=#mainSecond Level A/a
ul
lia href=#mainThird Level A1/a
lia href=#mainThird Level A2/a
lia href=#mainThird Level A3/a
lia href=#mainThird Level A4/a
/ul
/li
/ul
... about a hundred of the same UL blocksthen
li
/ul
I mean this is something I set up on my machine to do some test
locally and I have no slow down problems and the hover works perfectly
even if I exaggerate with the UL / LI / A and their nesting.
The problem you cited, about probable bad markup, was it referred to
the complexity of the page or to errors like unclosed tags or the
likes ?
Don't think the complexity of the markup nesting affect live() so
much...am I missing something about it ?
Diego
On 29 Gen, 17:06, John Resig jere...@gmail.com wrote:
Could you put an example up? That would certainly help to debug the
problem (I suspect that this problem is largely markup dependent).
--John
On Thu, Jan 29, 2009 at 8:02 AM, Diego Perini diego.per...@gmail.com wrote:
I have just gone through a problem in code that seems related to live
().
A coworker has just shifted from bind() to live() in a page where many
UL / LI / A (probably a hundred of them).
The anchors are just internal page jumps, there are counters for each
click on them. The user have to follow a specific path through them
and get a score.
The event types for which he did the change are only mouseover and
mouseout, also he will need to do the same for clicks, he just
stopped when he saw that a few seconds interaction with that page will
slow down his processing.
I looked at the code and suggested to put the minimum necessary in the
live() callbacks, we finished up testing with this bare minimum:
$('ul li a').live('mouseover', function (e) {
e.target.style.backgroundColor = 'red';
});
$('ul li a').live('mouseout', function (e) {
e.target.style.backgroundColor = '';
});
the hover effect still works as expected on all the links but the
problem still happen in the main code, it is not visible initially
since the slow down is increasing few hundreds milliseconds for each
triggering of the events,
after a minute interacting the browser spit the warning The script is
taking to much time.
He does not have the same trouble with bind() at least the problem
does not show up.
Are there quirks or suggestion in how to better isolate and debug the
problem in live() ?
Diego
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: live() slowing down DOM access after each firing
John, while debugging those two .live() on few elements on my machine I have come across another problem. It seems that every element touched by the selector is adding a doneXXX property to each parent on each iteration of the selector. So with mouseover/mouseout I finished up with something about 5800 properties added up in different places in my DOM in just few seconds mouse-hovering on a list of just 8 UL nested at 3 levels. Inspecting each element in Firebug shows tents of doneXXX properties on each element. Also this may have nothing to do with the original problem above I believe it is quite a big issue that must be addressed ! Going to look into the selectors and see why this happens. Diego On 29 Gen, 18:33, John Resig jere...@gmail.com wrote: I mean this is something I set up on my machine to do some test locally and I have no slow down problems and the hover works perfectly even if I exaggerate with the UL / LI / A and their nesting. It sounds like it's likely a problem with some other piece of code on their site, then. It would definitely be good to localize the problem. While .live() can replace a number of uses of .bind() - it can't replace all of them (nor does it make sense to). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Handling forms with overwritten methods (submit/reset)
Brandon,
here is a sample of the trick used to overcome these form
annoyances, I will gladly open an enhancement ticket if deemed
interesting to have in jQuery. I will first let it here for comment
reviews.
Some point:
- I used DOM0 event onmouseup to avoid including cross-browser code
adaption, and because they fire first
- nothing useful in this snippet alone, it is a tentative fix for some
bug due to badly chosen element names in forms
- the interesting objective is just be able to restore the needed
methods before invoking them, to avoid errors
- the fix here is used through an event just to show how a general
form fix could look but it is not strictly necessary this is wired to
an event, it could be simply done programmatically in your own code
html lang=en
head
titleHandling forms with overwritten methods/title
script type=text/javascript
document.onmouseup = function(event) {
var e;
event || (event = window.event);
e = event.target || event.srcElement;
// only do this for clicks on submit/reset
if ('|reset|submit|'.indexOf(e.type) 0) {
// this is how we detect offending names (on forms)
if (e.form e.form[e.type].nodeName) {
// save current attribute
var oId = e.id, oName = e.name;
// remove offending attribute
oId e.removeAttribute('id');
oName e.removeAttribute('name');
// steal the method of a newly created form element
e.form[e.type] = document.createElement('form')[e.type];
// invoke method
e.form[e.type]();
// restore offending attribute
oId e.setAttribute('id', oId);
oName e.setAttribute('name', oName);
}
}
}
/script
/head
body
h1Handling forms with overwritten methods/h1
div id=container
form id=aform onsubmit=alert('Submit'); return false;
onreset=alert('Reset');
input value=default /
input type=submit id=submit name=submit /
input type=reset id=reset name=reset /
input type=text id=elements name=elements value=12345 /
/form
/div
/body
/html
the solution seems easy but there may be quirks I am not considering.
So comment please.
Diego
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
John,
you have clearly depicted detection objectives and categorized the
type of detections, cleverly written...
couldn't do that in plain English as you did...probably even not in my
own language :-)
Diego
On 28 Gen, 16:30, John Resig jere...@gmail.com wrote:
Feature Detection is all about checking how a feature behaves, and if
it behaves in a known faulty way, then apply the known fix. Instead of
checking whether browsers support each of the standard way of doing
things, the detection should be checking for known failures that need
fixing. Knowing that a browser does not support a standard way of
doing something does _not_ logically tell you the correct way to fix
it. You need to test to see how the feature behaves to know which fix,
if any, is most appropriate.
You're still assuming that there's more than one possible fix. If we
need more than one fix then we would certainly test for the
applicability of each and work our way down - but as it stands there
is no point in progressing that far (we already use many more browser
features which would immediate exclude, or break, old browsers - such
as document fragments, advanced regular expressions, etc.)
There are two ways a one-fix situation can be done:
if (standards_supported)
use_standards_method()
else
apply_ie_fix()
// non-ie, non-compliant, browsers are broken
if (standards_supported)
use_standards_method()
else if ( can_do_ie_fix() )
apply_ie_fix()
else
// non-ie, non-compliant, browsers are broken
It doesn't matter - one way or the other the broken browser is still
going to be broken - the only difference is that IE is going to be
slower.
Feature detection is about providing fixes to bugs in a manner that
will gracefully continue to work when those bugs are fixed in new
browsers (or if duplicate bugs are introduced elsewhere, in an other
new browser).
Feature detection is all about new and unknown browsers - hoping that
your code will continue to persist. You conflate it with supporting
old browsers that are lacking features - which is a completely
separate set of discussions.
For example, right now different parts of jQuery may break in older
browsers - but the library, as a whole, will continue to try and
operate. It's not clear if that's desirable - if we can't guarantee
that all of the library should work, should we just quietly fail
instead? One idea that I've been thinking of is to make it so that the
callback passed to $(document).ready(function(){}) will just not
execute if we can't guarantee that all of jQuery will work.
This does a couple things:
1) Users of old browsers will simply have no JavaScript run (which is
fine, since users of jQuery should be doing graceful degradation
anyway).
2) This limits the set of possible browsers that will ever even hit
the jQuery.support code to those that we actually have solutions
for.
I'll need to collect an assortment of older browsers, first, to
determine what can and should be checked for a failure state (probably
check Firefox 1.5, IE 5.5, Opera 8, Safari 1, etc.). This will be good
since if we can't make a check to properly exclude an older browser
(since it would be missing some critical feature) then we should
probably work to support it fully.
But - again - this is not feature detection as it's typically defined
and should not be confused with feature detection. You're worried
about old browsers failing gracefully - and that's a completely
different set of issues from what normal bug fix feature detection
should be handling.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: ready event fires only after images are loaded on IE?
John,
the report is OK and says the truth...Mexicans would say ay ay
ay !!!.
This is something that should have been avoided...a too critical place
to play with.
The problem I see is that my patch and test for iframes got changed:
Line 2952 is currently:
if ( document.documentElement.doScroll typeof window.frameElement
=== undefined ) (function(){
This will always exclude the doScroll() magic.
When does the type of that property assumes an undefined type ? I
would bet for never ?
That property can be null which is an object not an undefined
value. Please fix that a.s.a.p. to avoid further problems and wrong
reports.
I would take my part of responsibility for not having checked that,
but releases are so fast I didn't even know a 1.3.1 was already
available.
Diego
On 27 Gen, 17:24, John Resig jere...@gmail.com wrote:
Do you have a demo page that we can look at?
--John
On Fri, Jan 23, 2009 at 11:01 AM, helianthus
project.heliant...@gmail.com wrote:
1.2.6:
No problems on all browsers tested.
1.3.1:
IE7 IE8 beta2: Fires only after all images are completely loaded.
FF3, Opera 9, Chrome: Fires right after DOM is loaded.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: ready event fires only after images are loaded on IE?
John,
well the reasons are ok, but the method is wrong in fact the doScroll
() trick is actually short-circuited and will never be usable neither
in iframes nor on the main document. So in IE everything will be
started by the onreadystatechange event...a bit too late.
Diego
On 27 Gen, 20:09, John Resig jere...@gmail.com wrote:
That check, alone, is not sufficient, though. We were hitting a number
of ugly exceptions with IE - when dealing with cross-domain frames.
http://dev.jquery.com/ticket/3880
In this commit:http://dev.jquery.com/changeset/6120
So some alternative solution will need to be derived - especially
since getting the exceptions was far worse (the page didn't load, at
all).
--John
On Tue, Jan 27, 2009 at 11:00 AM, Diego Perini diego.per...@gmail.com wrote:
John,
the report is OK and says the truth...Mexicans would say ay ay
ay !!!.
This is something that should have been avoided...a too critical place
to play with.
The problem I see is that my patch and test for iframes got changed:
Line 2952 is currently:
if ( document.documentElement.doScroll typeof window.frameElement
=== undefined ) (function(){
This will always exclude the doScroll() magic.
When does the type of that property assumes an undefined type ? I
would bet for never ?
That property can be null which is an object not an undefined
value. Please fix that a.s.a.p. to avoid further problems and wrong
reports.
I would take my part of responsibility for not having checked that,
but releases are so fast I didn't even know a 1.3.1 was already
available.
Diego
On 27 Gen, 17:24, John Resig jere...@gmail.com wrote:
Do you have a demo page that we can look at?
--John
On Fri, Jan 23, 2009 at 11:01 AM, helianthus
project.heliant...@gmail.com wrote:
1.2.6:
No problems on all browsers tested.
1.3.1:
IE7 IE8 beta2: Fires only after all images are completely loaded.
FF3, Opera 9, Chrome: Fires right after DOM is loaded.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
Daniel, I am not advocating against conditional comments, as I am not against any of the techniques described here, I said I use them all were I see appropriate. The argument of other browser implementing CC was just an example, since somebody asked what is going to happen when other browsers will implement the document.fileSize property to fold my test, every check in a browser can be folded but I am not trying to protect my code from that, I am just trying to recognize a browser, if the makers of those browse do not want to be recognized they have a ton of way to be successful. I bet they are looking at other features than breaking my scripts. Diego On 27 Gen, 20:09, Daniel Friesen nadir.seen.f...@gmail.com wrote: That sounds like a very weak argument against use of conditional comments. More like a misunderstanding of them. By definition of conditional comments, even if every other browser decided to implement them the existing tests still wouldn't change. Conditional comments work using conditions. So even if Firefox decided to add conditional comment support, only conditional comments targeted at Firefox would be run, all those still targeted at IE will still be strictly for that same set. Unlike the useragent which is known for browsers to purposefully lie about what they are, after all just about every browser has been pretending to be Netscape Navigator nearly forever. Opera disguises itself as IE by default, and even Konqueror lets you completely customize the entire user agent string. Despite whatever the user agent says, conditional comments will not lie. If a browser tried to do that it would likely go and break itself on a large number of websites already using conditional comments to apply IE fixes. And that's the opposite of any reason browsers have decided to spoof things. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point (http://nadir-point.com) -Wiki-Tools (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.nadir-point.com) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com) Diego Perini wrote: Juriy, ... One span element with an id=length will do much more damages to every existing framework/library, and there are tons of properties that can be overwritten. Should we also hope no other browser implements conditional comments ? Are you interested in how much a test is foldable or how good it is into recognize if the browser is IE ? First case you win, second case I win. ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
Juriy,
we agreed that if we can write something in the DOM everybody else can
delete/overwrite it and fold our testing.
Your feature test on the alert() method will probably have failed
with this old piece of code of mine :-)
http://javascript.nwbox.com/asyncAlert/
Diego
On 27 Gen, 22:20, kangax kan...@gmail.com wrote:
On Jan 27, 1:37 pm, Diego Perini diego.per...@gmail.com wrote:
[...]
One span element with an id=length will do much more damages to
every existing framework/library, and there are tons of properties
that can be overwritten. Should we also hope no other browser
implements conditional comments ?
Are you interested in how much a test is foldable or how good it is
into recognize if the browser is IE ?
First case you win, second case I win.
I'm not sure I understand your argument. Second case actually
somewhat depends on the former one - how good it is would surely
depend on how hard it is to *accidentally* break it. I also have no
idea why you would want go with the weaker test when other - more
robust ways - are available. Is it because `fileSize` saves few lines
of code? It's up to you of course, but if something is known to
produce false positives (in a not so contrived case scenario), why not
try alternative approach? Chances of `document.fileSize` being truthy
are too big (as for my taste); Its value is easily changeable by any
3rd party script. Why such risk? Why not use test that operates on a
lower level?
I would probably try testing for behavior that can not be easily
overwritten. Something that is at the core of the object/host model.
Something like:
var IS_MSHTML_DOM = (function() {
var global = this;
return (
global.alert
// some host methods return object for `typeof`
typeof global.alert == 'object'
// some host methods do not inherit from `Function.prototype`
typeof global.alert.call == 'undefined'
// some host methods throw errors on setters
(function(){
try {
global.alert.x = true;
return false;
} catch(e) {
return true;
}
})()
)
})();
While it's still possible to fool this test, chances of that are, imo,
much lower.
--
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: ready event fires only after images are loaded on IE?
John,
it result that it was my fault then...
Here are the relevant commit infos:
http://dev.jquery.com/changeset/5941/trunk/jquery/src/event.js
this was the ticket:
http://dev.jquery.com/ticket/2614
I don't know/remember what made me suggest the use of
window.frameElement, but window == window.top works.
Diego
On 27 Gen, 23:06, Diego Perini diego.per...@gmail.com wrote:
John,
I could finally replicate the problem with the help of john dalton on
IE7 (I only had IE6 to test).
The problem is the use of window.frameElement, shouldn't error since
the property is in our global space but who knows...
Revert back the change to what is used in the original
ContentLoaded.js here:
http://javascript.nwbox.com/ContentLoaded/contentloaded.js
window == top
or better as john dalton suggest:
window == window.top
it seems that testing in this way the Access denied error is
circumvented, I probably never fall in this case since I wasn't using
jQuery window.frameElement in my own code.
Diego
On 27 Gen, 21:34, Diego Perini diego.per...@gmail.com wrote:
John,
On 27 Gen, 20:23, John Resig jere...@gmail.com wrote:
I think you misunderstood me. Simply accessing the frameElement
property from a frame that isn't on the same domain as the parent
frame causes an exception to be thrown.
I probably did. However I don't see any cross-frame access in that
part of the code we are just peeking a property on the same window
where jQuery is loaded, we always own that window.frameElement
property. Am I missing something ?
Previously the check was: !window.frameElement
Well the other way to do it is:
window.frameElement === null
which we already talked about when writing that patch, hope you recall
that.
Which was not enough - it completely breaks use of jQuery. There needs
It seemed to work well in 1.2.6 from what the OP says, I am sure there
are other edge cases but even trying what is pointed out in ticket
#3898 I cannot reproduce this bug.
It will help having a link to an example showing the misbehavior of
ready().
to be a new check. Granted, the typeof one appears to be too extreme
but the previous one was broken, as well (and in a much worse way).
Could you further elaborate on the exact problems you detected with
the iframe check ?
Diego
--John
On Tue, Jan 27, 2009 at 11:18 AM, Diego Perini diego.per...@gmail.com
wrote:
John,
well the reasons are ok, but the method is wrong in fact the doScroll
() trick is actually short-circuited and will never be usable neither
in iframes nor on the main document. So in IE everything will be
started by the onreadystatechange event...a bit too late.
Diego
On 27 Gen, 20:09, John Resig jere...@gmail.com wrote:
That check, alone, is not sufficient, though. We were hitting a number
of ugly exceptions with IE - when dealing with cross-domain frames.
http://dev.jquery.com/ticket/3880
In this commit:http://dev.jquery.com/changeset/6120
So some alternative solution will need to be derived - especially
since getting the exceptions was far worse (the page didn't load, at
all).
--John
On Tue, Jan 27, 2009 at 11:00 AM, Diego Perini
diego.per...@gmail.com wrote:
John,
the report is OK and says the truth...Mexicans would say ay ay
ay !!!.
This is something that should have been avoided...a too critical
place
to play with.
The problem I see is that my patch and test for iframes got changed:
Line 2952 is currently:
if ( document.documentElement.doScroll typeof window.frameElement
=== undefined ) (function(){
This will always exclude the doScroll() magic.
When does the type of that property assumes an undefined type ? I
would bet for never ?
That property can be null which is an object not an undefined
value. Please fix that a.s.a.p. to avoid further problems and wrong
reports.
I would take my part of responsibility for not having checked that,
but releases are so fast I didn't even know a 1.3.1 was already
available.
Diego
On 27 Gen, 17:24, John Resig jere...@gmail.com wrote:
Do you have a demo page that we can look at?
--John
On Fri, Jan 23, 2009 at 11:01 AM, helianthus
project.heliant...@gmail.com wrote:
1.2.6:
No problems on all browsers tested.
1.3.1:
IE7 IE8 beta2: Fires only after all images are completely
loaded.
FF3, Opera 9, Chrome: Fires right after DOM is loaded.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http
[jquery-dev] Re: IE6 feature detection - possible solution
Juriy,
I really hope you had a look at feature testing in my new NWMatcher
code, so I hope you don't think of me as unmovable stone...
I removed the document.fileSize the second time we talked about
it...to avoid being blamed...
Still I needed a place to complain about my code size growing too much
after switching to FT and was trying to give a place to these old
tricks.
The more complex is the library / framework the more is worth
switching to FT, my project is too small generally to add 1Kb extra
just for that, but I did it anyway.
I am overall happy with the switch because now I do support more
browsers and faster too. The size...well we have compressors (5Kb).
Diego
On 27 Gen, 23:51, kangax kan...@gmail.com wrote:
On Jan 27, 4:46 pm, Diego Perini diego.per...@gmail.com wrote:
Juriy,
we agreed that if we can write something in the DOM everybody else can
delete/overwrite it and fold our testing.
This is not a context of code folding (as you put it). We can do
many bad things in many environments - the following assignment, for
example, will certainly fool my previous test:
window.alert = {
call: undefined,
set x(){ throw new Error() }
}
but not only does it require support for setters, it also takes an
actual effort on someone's part to just go ahead and break it on
purpose. `document.fileSize`, on the other hand, requires little
effort to overwrite, and, as I showed earlier, only takes one careless
form naming.
--
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: jquery 1.3 .val() and form plugin's .value()
For the record, and benefit of anyone who finds this thread in the future, I got the latest version from Base2's project on Google Code: http://code.google.com/p/base2/source/checkout On Jan 22, 12:32 pm, Diego diego.a...@gmail.com wrote: You're right. I was using v3 beta 8. I've updated to the final version and the packed code works now. Thanks! (and sorry for starting a pointless discussion, I should have checked I had the latest version of packer to start with). On Jan 21, 3:47 pm, Leeoniya leeon...@gmail.com wrote: when i ran into this issue, i repacked it using the current version of Packer for shits and giggles before sending Dean Edwards a bug report, and it worked just fine. what Packer version are you guys using, John? On Jan 21, 7:57 am, Diego diego.a...@gmail.com wrote: Hi John, I've having a little trouble working out what has broken in the pakced (with base64) version, but I've isolated both chunks of code and put them here:http://pastebin.com/m3f9a3db6 Cheers, Diego A. On Jan 21, 1:22 pm, John Resig jere...@gmail.com wrote: Are you using the packed version of jQuery? It appears as if the packer is somehow corrupting jQuery and causing some things to break - try switching to the minified version. If that's not the case, do you have an example? --John On Wed, Jan 21, 2009 at 8:13 AM, Diego diego.a...@gmail.com wrote: Hi there, I'm funding some inconsistencies between jQuery's .val() method and form plugin's .value() method. The form plugin method is always correct, but in jquery 1.3, the .val() method isn't working (at least for me) on select boxes loaded via ajax. I'm considering overwriting $.fn.val and forcing it to use the form plugin's own implementation. Is there any differences I should be aware of? Cheers, Diego A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] jquery 1.3 .val() and form plugin's .value()
Hi there, I'm funding some inconsistencies between jQuery's .val() method and form plugin's .value() method. The form plugin method is always correct, but in jquery 1.3, the .val() method isn't working (at least for me) on select boxes loaded via ajax. I'm considering overwriting $.fn.val and forcing it to use the form plugin's own implementation. Is there any differences I should be aware of? Cheers, Diego A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jquery 1.3 .val() and form plugin's .value()
Hi John, Thanks for the prompt reply! You're absolutely right. It works fine when I use the source, rather than the packed version. Thing is, I use Dean's packer to group jQuery and all my plugins into one file for several reasons (ease of distribution and faster download times). I used to have a similar problem with jQuery 1.24 (when it was first released), so I'll take a look and try to fix it. I'll post results back here... Cheers, Diego A. On Jan 21, 1:22 pm, John Resig jere...@gmail.com wrote: Are you using the packed version of jQuery? It appears as if the packer is somehow corrupting jQuery and causing some things to break - try switching to the minified version. If that's not the case, do you have an example? --John On Wed, Jan 21, 2009 at 8:13 AM, Diego diego.a...@gmail.com wrote: Hi there, I'm funding some inconsistencies between jQuery's .val() method and form plugin's .value() method. The form plugin method is always correct, but in jquery 1.3, the .val() method isn't working (at least for me) on select boxes loaded via ajax. I'm considering overwriting $.fn.val and forcing it to use the form plugin's own implementation. Is there any differences I should be aware of? Cheers, Diego A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jquery 1.3 .val() and form plugin's .value()
Hi John, I've having a little trouble working out what has broken in the pakced (with base64) version, but I've isolated both chunks of code and put them here: http://pastebin.com/m3f9a3db6 Cheers, Diego A. On Jan 21, 1:22 pm, John Resig jere...@gmail.com wrote: Are you using the packed version of jQuery? It appears as if the packer is somehow corrupting jQuery and causing some things to break - try switching to the minified version. If that's not the case, do you have an example? --John On Wed, Jan 21, 2009 at 8:13 AM, Diego diego.a...@gmail.com wrote: Hi there, I'm funding some inconsistencies between jQuery's .val() method and form plugin's .value() method. The form plugin method is always correct, but in jquery 1.3, the .val() method isn't working (at least for me) on select boxes loaded via ajax. I'm considering overwriting $.fn.val and forcing it to use the form plugin's own implementation. Is there any differences I should be aware of? Cheers, Diego A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
Kangax, you have convinced me about the goodness of feature testing. Now convince yourself about the goodness of: // detect IE any version from IE to IE8 IE = typeof document.fileSize != 'undefined', I don't understand how conditional comments or userAgent parsing can be better than the above for IE. Look at bug #3169 as an example... In fact the above will have worked from IE4 and up to todays IE7 / IE8, while we have seen the userAgent parsing changing quite a lot of time in the course of the past years. You see with userAgent parsing/sniffing libraries must be updated (or at least checked/ tweaked) for each new version of the browser and that is a very bad practice. I repeat, this is useful when feature testing is requiring to much code, realize that the above test will cover more than 50% of your current CFT tests. Nearly all bugs are IE related, few are Opera or Konqueror as you already noticed. Kangax, I really like your CFT and believe it is the way to go, but I don't need to open an iframe each time I need to know if a method will work on IE, that's too much for my taste and probably for others too. Diego On 13 Gen, 07:07, kangax kan...@gmail.com wrote: On Jan 12, 10:01 pm, Diego Perini diego.per...@gmail.com wrote: [...] My suggestion is to start including these two constants in the process of removing the others, they will never go away: IE = typeof document.fileSize != 'undefined', // IE6 / IE7 / IE8 S2 = top !== top.document.defaultView, // Safari 2 This object inference doesn't seem like a much better solution than `userAgent` parsing. I can imagine 3rd party code having `document.fileSize` and accidentally messing things up. It's also not clear why anyone would want to detect IE in such way, when more robust ways are known - i.e. IE's conditional comments. On the other hand, if you were to introduce IE and S2 - why skip Opera and/or Konqueror, etc.? Please don't laugh...I know they are not feature testing. But these never changed and will never change, IE7 / IE8 are still using that property (uniquely), S2 is still on 10.4.3 Mac, only two short lines, can be shortened if document is aliased to correct context, can execute before onload on both Webkit and all versions of IE. Exactly which version of Safari are you talking about? I know that =2.0.2 are missing `Object.prototype.hasOwnProperty`. Maybe we're talking about the same version. [...] -- kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
Kangax, I could extend a bit the testing to ensure type is unknown but I believe it is unfeasible since at some point that property will be number in IE. That property can be tested for unknown only in rare and specific occasions, in that case it should be done before anything else, after DOM has finished loading that property will be a number, in case of static pages, in case of dynamic pages that will depend on the headers sent by the server...(no-cache, pragma et all). This is the reason I kept testing for just !== undefined. If we are presuming that somebody with some bad code can fold our checks, yes that will always be true, both if we use sniffing, inference or feature testing. Really, people could also overwrite the createElement, or prototype the HTMLIFrameElement to open a window instead but we should draw a line about what is necessary and consistent. Why would somebody use the fileSize property if the 3/4 of the browsers have this property nativelyand why would they want to add that to FF / Opera / Webkit only and not to Internet Explorer, I believe we are crossing the border of usefulness here... As I said, I reiterate that feature testing is the best method, nearly in all cases, both inference and sniffing have their places in the game. Diego On 13 Gen, 18:00, kangax kan...@gmail.com wrote: On Jan 13, 10:17 am, Diego Perini diego.per...@gmail.com wrote: Kanagax, agree with you about using (or not) frames being irrelevant if the is objective is met. I was talking about reducing a bit the code size were possible, feature testing is more costly in byte size. Please tell me how a 3d party is going to create problem with those testing I am really interested into improve them if possible. You see, the document.fileSize property in IE is read-only, and it is of a type the user cannot create himself that I know, but would be very interested in how the user could create a variable of type unknown, especially how to I create an unknown variable in FF / Opera / Webkit / Konqueror or mobile web browsers ??? Your snippet didn't test for typeof unknown, but rather for != 'undefined'. Sorry if I missed something. If a 3rd party script defines `document.fileSize` in non-IE browser, your proposed `IE` boolean will have a false positive: // run this in Firefox document.fileSize = 1024; IE = typeof document.fileSize != 'undefined'; IE; // true [...] -- kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
Ariel, if you need to bifurcate in the event system I suggest to test for: document.createEventObject() in this way you prevent the problem John is telling since Opera never implemented that event method. Diego On 13 Gen, 19:06, Ariel Flesler afles...@gmail.com wrote: Isn't this good enough ? IE = !!document.attachEvent; On Tue, Jan 13, 2009 at 3:00 PM, kangax kan...@gmail.com wrote: On Jan 13, 10:17 am, Diego Perini diego.per...@gmail.com wrote: Kanagax, agree with you about using (or not) frames being irrelevant if the is objective is met. I was talking about reducing a bit the code size were possible, feature testing is more costly in byte size. Please tell me how a 3d party is going to create problem with those testing I am really interested into improve them if possible. You see, the document.fileSize property in IE is read-only, and it is of a type the user cannot create himself that I know, but would be very interested in how the user could create a variable of type unknown, especially how to I create an unknown variable in FF / Opera / Webkit / Konqueror or mobile web browsers ??? Your snippet didn't test for typeof unknown, but rather for != 'undefined'. Sorry if I missed something. If a 3rd party script defines `document.fileSize` in non-IE browser, your proposed `IE` boolean will have a false positive: // run this in Firefox document.fileSize = 1024; IE = typeof document.fileSize != 'undefined'; IE; // true [...] -- kangax -- Ariel Fleslerhttp://flesler.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
John, even if you didn't completely removed $.browser it is great to see most of them are gone. Next move is to go for feature testing, plugin writers should already start using it to speed-up the complete removal. At least they should have a direction to follow from the team in the process of removing/ changing $.browser... I believe it can be made painless enough for the developers. My suggestion is to start including these two constants in the process of removing the others, they will never go away: IE = typeof document.fileSize != 'undefined', // IE6 / IE7 / IE8 S2 = top !== top.document.defaultView, // Safari 2 Please don't laugh...I know they are not feature testing. But these never changed and will never change, IE7 / IE8 are still using that property (uniquely), S2 is still on 10.4.3 Mac, only two short lines, can be shortened if document is aliased to correct context, can execute before onload on both Webkit and all versions of IE. I purposely picked the two that are not feature testing...but these will avoid a great amount of code in 95% of the cases, probably more if we look at use cases. Let me know what you think about it. Diego On 12 Gen, 21:09, John Resig jere...@gmail.com wrote: Just to clarify: $.browser is not being removed in 1.3 - and not for the foreseeable future - but it is deprecated. --John On Mon, Jan 12, 2009 at 3:04 PM, Dan G. Switzer, II dswit...@pengoworks.com wrote: Boy, I'm not looking forward to $.browser.msie being removed. I use that all the time to add class definitions to fix CSS issues in IE. On Mon, Jan 12, 2009 at 9:03 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Nevermind, got it all fixed. Jörn On Mon, Jan 12, 2009 at 1:14 PM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Forgot to mention: version.txt has RC2 already, I did a local build to get the latest fixes. Anyway, that wasn't my problem anyway. $.browser is deprecated just now, so I can worry about removing that later. Jörn On Mon, Jan 12, 2009 at 12:32 PM, Ariel Flesler afles...@gmail.com wrote: Isn't it RC1 yet ? The $.browser removal is a hard one. I fixed it on one plugin already as if( document.attachEvent ) of course that doesn't move to feature detection, but sometimes you just want to know if it's IE, no feature related. -- Ariel Flesler http://flesler.blogspot.com On Jan 12, 8:29 am, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: I'm currently adapting the validation plugin to 1.3 RC2, aiming for a new release before 1.3 is out. The obvious problem, usage of deprecated [...@attr=val] selectors was easy to fix. Another issue I couldn't fix yet is selecting options. I'm using these lines to validate if enough options have been selected: var options = $(option:selected, element); return options.length 0 ( element.type == select-multiple || ($.browser.msie !(options[0].attributes['value'].specified) ? options[0].text : options[0].value).length 0); It seems like $(option) in 1.3 RC2 returns only a single option on my testpage, causing all tests related to selects to fail. Is there an alternative that I can use that also works with 1.2.6? There are more which I haven't yet pinned down... Jörn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
A correction in the above two lines: // detect IE any version IE = typeof context.fileSize !== 'undefined', // Safari 2 doesn't implement View on window S2 = top.defaultView top !== top.document.defaultView, I left out part of the Safari check... Diego On 13 Gen, 04:01, Diego Perini diego.per...@gmail.com wrote: John, even if you didn't completely removed $.browser it is great to see most of them are gone. Next move is to go for feature testing, plugin writers should already start using it to speed-up the complete removal. At least they should have a direction to follow from the team in the process of removing/ changing $.browser... I believe it can be made painless enough for the developers. My suggestion is to start including these two constants in the process of removing the others, they will never go away: IE = typeof document.fileSize != 'undefined', // IE6 / IE7 / IE8 S2 = top !== top.document.defaultView, // Safari 2 Please don't laugh...I know they are not feature testing. But these never changed and will never change, IE7 / IE8 are still using that property (uniquely), S2 is still on 10.4.3 Mac, only two short lines, can be shortened if document is aliased to correct context, can execute before onload on both Webkit and all versions of IE. I purposely picked the two that are not feature testing...but these will avoid a great amount of code in 95% of the cases, probably more if we look at use cases. Let me know what you think about it. Diego On 12 Gen, 21:09, John Resig jere...@gmail.com wrote: Just to clarify: $.browser is not being removed in 1.3 - and not for the foreseeable future - but it is deprecated. --John On Mon, Jan 12, 2009 at 3:04 PM, Dan G. Switzer, II dswit...@pengoworks.com wrote: Boy, I'm not looking forward to $.browser.msie being removed. I use that all the time to add class definitions to fix CSS issues in IE. On Mon, Jan 12, 2009 at 9:03 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Nevermind, got it all fixed. Jörn On Mon, Jan 12, 2009 at 1:14 PM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Forgot to mention: version.txt has RC2 already, I did a local build to get the latest fixes. Anyway, that wasn't my problem anyway. $.browser is deprecated just now, so I can worry about removing that later. Jörn On Mon, Jan 12, 2009 at 12:32 PM, Ariel Flesler afles...@gmail.com wrote: Isn't it RC1 yet ? The $.browser removal is a hard one. I fixed it on one plugin already as if( document.attachEvent ) of course that doesn't move to feature detection, but sometimes you just want to know if it's IE, no feature related. -- Ariel Flesler http://flesler.blogspot.com On Jan 12, 8:29 am, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: I'm currently adapting the validation plugin to 1.3 RC2, aiming for a new release before 1.3 is out. The obvious problem, usage of deprecated [...@attr=val] selectors was easy to fix. Another issue I couldn't fix yet is selecting options. I'm using these lines to validate if enough options have been selected: var options = $(option:selected, element); return options.length 0 ( element.type == select-multiple || ($.browser.msie !(options[0].attributes['value'].specified) ? options[0].text : options[0].value).length 0); It seems like $(option) in 1.3 RC2 returns only a single option on my testpage, causing all tests related to selects to fail. Is there an alternative that I can use that also works with 1.2.6? There are more which I haven't yet pinned down... Jörn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1.3 RC2, selecting options
Wrong again, that's what happen in the late nights with no sleep // Safari 2 doesn't implement View on window S2 = top.document.defaultView top !== top.document.defaultView, sorry for the spam, wrong info is worst... :-) Diego On 13 Gen, 04:52, Diego Perini diego.per...@gmail.com wrote: A correction in the above two lines: // detect IE any version IE = typeof context.fileSize !== 'undefined', // Safari 2 doesn't implement View on window S2 = top.defaultView top !== top.document.defaultView, I left out part of the Safari check... Diego On 13 Gen, 04:01, Diego Perini diego.per...@gmail.com wrote: John, even if you didn't completely removed $.browser it is great to see most of them are gone. Next move is to go for feature testing, plugin writers should already start using it to speed-up the complete removal. At least they should have a direction to follow from the team in the process of removing/ changing $.browser... I believe it can be made painless enough for the developers. My suggestion is to start including these two constants in the process of removing the others, they will never go away: IE = typeof document.fileSize != 'undefined', // IE6 / IE7 / IE8 S2 = top !== top.document.defaultView, // Safari 2 Please don't laugh...I know they are not feature testing. But these never changed and will never change, IE7 / IE8 are still using that property (uniquely), S2 is still on 10.4.3 Mac, only two short lines, can be shortened if document is aliased to correct context, can execute before onload on both Webkit and all versions of IE. I purposely picked the two that are not feature testing...but these will avoid a great amount of code in 95% of the cases, probably more if we look at use cases. Let me know what you think about it. Diego On 12 Gen, 21:09, John Resig jere...@gmail.com wrote: Just to clarify: $.browser is not being removed in 1.3 - and not for the foreseeable future - but it is deprecated. --John On Mon, Jan 12, 2009 at 3:04 PM, Dan G. Switzer, II dswit...@pengoworks.com wrote: Boy, I'm not looking forward to $.browser.msie being removed. I use that all the time to add class definitions to fix CSS issues in IE. On Mon, Jan 12, 2009 at 9:03 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Nevermind, got it all fixed. Jörn On Mon, Jan 12, 2009 at 1:14 PM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Forgot to mention: version.txt has RC2 already, I did a local build to get the latest fixes. Anyway, that wasn't my problem anyway. $.browser is deprecated just now, so I can worry about removing that later. Jörn On Mon, Jan 12, 2009 at 12:32 PM, Ariel Flesler afles...@gmail.com wrote: Isn't it RC1 yet ? The $.browser removal is a hard one. I fixed it on one plugin already as if( document.attachEvent ) of course that doesn't move to feature detection, but sometimes you just want to know if it's IE, no feature related. -- Ariel Flesler http://flesler.blogspot.com On Jan 12, 8:29 am, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: I'm currently adapting the validation plugin to 1.3 RC2, aiming for a new release before 1.3 is out. The obvious problem, usage of deprecated [...@attr=val] selectors was easy to fix. Another issue I couldn't fix yet is selecting options. I'm using these lines to validate if enough options have been selected: var options = $(option:selected, element); return options.length 0 ( element.type == select-multiple || ($.browser.msie !(options[0].attributes['value'].specified) ? options[0].text : options[0].value).length 0); It seems like $(option) in 1.3 RC2 returns only a single option on my testpage, causing all tests related to selects to fail. Is there an alternative that I can use that also works with 1.2.6? There are more which I haven't yet pinned down... Jörn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: inDOM method proposal
ricardo,
On 30 Nov, 19:35, ricardobeat [EMAIL PROTECTED] wrote:
Hi,
It seems the ownerDocument is set for the created element even if it's
not in the DOM, it's the document where jQuery was loaded in. A simple
Correct, the ownerDocument will always be available, but it will
reference the document you used to create the element
(document.createElement), which may be a different one than the one
jQuery was loaded in.
check for parentNode or offsetParent would do:
$.fn.inDOM = function(){
return !!this.parentNode; //boolean
});
It is not enough to check the first parent node, you will have to
traverse up until the last parent is found, if the last parent is not
nodeType == 9 (a document node) it means the element is detached
from a DOM tree.
parentNode returns faster for elements in the DOM, while offsetParent
returns faster for elements not in the DOM (in FF3 at least).
I believe that native compareDocumentPosition/contains are much
faster.
--
Diego
Hope I'm not missing anything. It surely would need a better name :]
cheers,
- ricardo
On 29 nov, 14:46, Ariel Flesler [EMAIL PROTECTED] wrote:
'body' should be replaced by 'html'.
Maybe we can make it faster by consulting expandos like
ownerDocument ?
--
Ariel Fleslerhttp://flesler.blogspot.com
On Nov 27, 12:52 am, diogobaeder [EMAIL PROTECTED] wrote:
Hi there,
I'm new here (and in jQuery), but even though I'd like to propose some
simple but usefull method to the jQuery object (at core.js) to tell
the API user if an element exists in the document. I've tried to build
one as follows:
[CODE]
(function($) {
$.fn.inDOM = function() {
return !!this.parents('body').length;
};
})(jQuery);
jQuery(document).ready(function(){
var jEl = $('.someExistingClass');
// Should be in DOM
console.debug(jEl.inDOM());
// Removing the element
jEl.remove();
// Should NOT be in DOM
console.debug(jEl.inDOM());});
[/CODE]
So, if the client sets a variable as a jQuery object, and at some
point of the code the DOM element within it can be removed, he/she can
test if it really was. OK, I know it sounds unsignificant, but I think
it would still be usefull.
Thanks!
Diogo Baeder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Event class for jQuery
Ariel, jQuery is already doing very well in many fields, the suggestions were to cover expressed needs not to leave out working code. I will follow on your answers... On 29 Nov, 16:22, Ariel Flesler [EMAIL PROTECTED] wrote: @Scott Ok, that's an easy change (leave it or remove it). The question is, what's the formal application of this extra function ? @Diego We don't have the needed hacks to implement event capturing in IE (I know your NWEvents does). We don't plan to add that I think, that requires a lot of hacking and not many would benefit from it. So why add that parameter to our method ? Hey, I didn't invent that capture flag, nor the need for it...the fact is well documented in W3C specifications, it has been there for long, ignored by jQuery though. There are several techniques and methods that were not available in IE and were fixed or emulated by jQuery, or a workaround was found for it. The question should be turned to: why did jQuery ditched that standard and very useful parameter ? Or, why should users load a framework to learn a different and mangled way of setting up javascript events ? We probably disagree about what W3C specifications are for, I for myself believe they did it for the benefit of many. There are many useful things that can be done with the capture flag, you have code parts both in core and in various plugins that would benefit from this. After loading a 50Kb framework I wouldn't expect being forced to write standard javascript to achieve events working as described by 4 vendors over 5, this makes code size bigger and duplicated in each plugin needing this extra event functionality. We are still not talking about delegation...and benefits there. I've been thinking about trying native event triggering instead of what we have now. I showed that old experiment where I achieved native event bubbling on all browsers, even for custom events. But that required quite a large amount of code, maybe we can leave that as a plugin. Programmatically dispatching events using native methods seems to me much shorter (and faster) than constructing an emulated event object and looping through the handlers. All browsers can handle that natively. In reality both methods of dispatching/triggering events should be available, this is also the standard W3C way of doing it (for DOM elements only, not for custom or object events). About the event properties from the originalEvent... jQuery claims it normalizes event objects in a cross browser way (some properties). Telling the user look for them on the original object doesn't seem too nice for me. The needed properties should already be there as needed, my suggestion was about maintaining the information and passing it down the chain, making it possible to reference the original event and properties should they be needed. For example, if I am not wrong the iPhone keep information about several events in the main event object to handle touch events and be multi-touch aware. This is similar to what I propose. Thanks both for replying. Thanks you for the hard work, -- Diego Cheers On Sat, Nov 29, 2008 at 1:08 PM, Scott González [EMAIL PROTECTED] wrote: jQuery UI uses the return value of triggerHandler, but we only care about false, so this change shouldn't affect us. What's the logic behind removing the event from the extra function? If I remember correctly, I talked to John about this a while ago and he couldn't think of any reason why that was done. I created a ticket to remove this behavior and it has just been sitting in Trac for 5 months (http://dev.jquery.com/ticket/3096). On Nov 28, 7:14 pm, Ariel Flesler [EMAIL PROTECTED] wrote: Feedback please! :) I really like (and support) this feature. http://dev.jquery.com/ticket/3662 Also... I know that the returned value from jQuery.fn.trigger is used here and there (jQuery UI?). But that behavior is really odd and fragile in my opinion (false overrides any previous value). I think it'd be nice to return true/false depending on whether e.preventDefault() was called. This would be very useful for custom events, to allow event handlers to stop a scheduled (custom) behavior. As an alternative, we could add e.isDefaultPrevented() that retrieves this value from the event object. Note that none of this last 2 behaviors (or the one in the ticket) is my invention. I'm just imitating AS3's event system. I suppose that belongs to some EcmaScript specification as well. http://docs.brajeshwar.com/as3/flash/events/Event.html Thanks -- Ariel Fleslerhttp://flesler.blogspot.com -- Ariel Fleslerhttp://flesler.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more
[jquery-dev] Re: jQuery selection methods compared to XPath axes.
Mark, maybe I am just misunderstanding you, however my tip using CSS selector groups (comma separated) is: for the direct descendants descendant-or-self = self *, self for all the descendants descendants-or-self = self *, self Both will get you a collection of descendant including the element itself. For ancestors there isn't an equivalent CSS syntax that I am aware of. Hope you are missing one less now -- Diego On 28 Nov, 15:34, Mark Gibson [EMAIL PROTECTED] wrote: For people who are familiar with XPath, I think it would be useful to list the similarities between XPath axes and jQuery selection/traversal methods, and also add any useful discrepancies into jQuery, or describe how to emulate them. This is my interpretation, additions would be most welcome, ideally I'd like to cover all the appropriate axes (not marked n/a). XPath Axis jQuery ancestor context.parents(...) ancestor-or-self ? attribute n/a child context.children(...) or context ... or $ ( ..., context) descendant context.find(...) or context ... or $(..., context) descendant-or-self ? following ? following-sibling context.nextAll(...) or context ~ ...? namespace n/a parent context.parent(...) preceding ? preceding-sibling context.prevAll(...) or ... + context? self context.filter(...) ??? I've found a few situations where I've needed 'ancestor-or-self', 'following', and 'preceding' style selection, but not found any easy way to do it. For example, keyboard navigation of a tree (key up down) would benefit greatly from the following and preceding axes. Finding descendants and including all the elements specified in an aria-owns attribute in the search would benefit from the descendant-or-self axis. (ie. find in the context element, and find-inc-self for all elements specified by the attribute) I know there is a .andSelf(), but I don't think it really cover these situations. Previously I've suggested a .selfOrParents() method, but I think a general 'include self' switch before a traversal method would be better: context.incSelf().find(...) context.incSelf().parents(...) Can the jQuery team see this as being generally useful, and accepted into the core? Or any alternative suggestions? Also, any suggestions on how to do following or preceding style selection? Cheers -Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: ticket #2614 unclosed...please
John, thank you for applying the patch. I have a couple of test cases laying around to test for the correct functionality of the ready() method. Let me know if you need them to include/rework them into jQuery test unit. -- Diego On 12 Nov, 14:33, John Resig [EMAIL PROTECTED] wrote: Just landed the patch, sorry for the delay. --John On Wed, Nov 12, 2008 at 2:54 AM, David Serduke [EMAIL PROTECTED] wrote: Looking at the ticket it is marked as fix for 1.3 which may or may not be the next release which may be why it hasn't landed yet. That said does anyone have any objections to this patch? I have to admit I haven't followed the latest content ready sagas. David On Nov 11, 6:37 am, Diego Perini [EMAIL PROTECTED] wrote: Anybody ? -- Diego On 8 Nov, 14:43, Diego Perini [EMAIL PROTECTED] wrote: Hi team, are there issues with closing that old ticket. IE is in extreme need of that patch, we get issues with iframes and the Back/Forward browsers button in some circumstance and I would like to see this fixed a.s.a.p. The problem is often visible especially when pages only have texts in it or when opening in iframes. The main problem being that onload is fired too early in those situations and a real event fall back is needed to be able to catch those situations in a more precise and timed method. That patch has sit there for 4 months now, I talked with John at that time and I followed his suggestions on removing browser sniffing. It seems to me he was aware of the problem and acknowledge the need for this. The patch has currently been included in both ExtJS and Google own JS API. It is pending for Prototype too. Let me know if there is still something to change in it. -- Diego- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: ticket #2614 unclosed...please
Anybody ? -- Diego On 8 Nov, 14:43, Diego Perini [EMAIL PROTECTED] wrote: Hi team, are there issues with closing that old ticket. IE is in extreme need of that patch, we get issues with iframes and the Back/Forward browsers button in some circumstance and I would like to see this fixed a.s.a.p. The problem is often visible especially when pages only have texts in it or when opening in iframes. The main problem being that onload is fired too early in those situations and a real event fall back is needed to be able to catch those situations in a more precise and timed method. That patch has sit there for 4 months now, I talked with John at that time and I followed his suggestions on removing browser sniffing. It seems to me he was aware of the problem and acknowledge the need for this. The patch has currently been included in both ExtJS and Google own JS API. It is pending for Prototype too. Let me know if there is still something to change in it. -- Diego --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] ticket #2614 unclosed...please
Hi team, are there issues with closing that old ticket. IE is in extreme need of that patch, we get issues with iframes and the Back/Forward browsers button in some circumstance and I would like to see this fixed a.s.a.p. The problem is often visible especially when pages only have texts in it or when opening in iframes. The main problem being that onload is fired too early in those situations and a real event fall back is needed to be able to catch those situations in a more precise and timed method. That patch has sit there for 4 months now, I talked with John at that time and I followed his suggestions on removing browser sniffing. It seems to me he was aware of the problem and acknowledge the need for this. The patch has currently been included in both ExtJS and Google own JS API. It is pending for Prototype too. Let me know if there is still something to change in it. -- Diego --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: event delegation
Mike, the points I tried to make above are not specific to your code (haven't tested it yet). For the ordering problem I was talking about the find() method, I understand you use a modified is() method that does some more powerful things in a more spec compliant way. NWMatcher has always done the match() in that way (bottom-up), and yes it is much faster. Sizzle will do that too I hope. I don't really have anything contrary to what you have done, I instead think is a good job and I will have a peak at it with some of my own test as soon as I have some time. I was just pointing out the problems that I have seen before while writing my own code and in some other implementation of events delegation. Thank you for sharing your ideas, will report any finding when I have tested it -- Diego Perini On 15 Ott, 16:49, mike.helgeson [EMAIL PROTECTED] wrote: Diego, I do not understand what you are getting at, or what the issue is... The plugin I have provided does not have any dependency on document ordered or unordered nodes. When John's new selector engine (sizzle) is included in the core, perhaps the order of nodes may be different, but I don't see how that would effect anything I have coded. The patch I provided for the is method works in a similar way to what I understand of sizzle: Start with the end of the selector, then walk up the ancestor chain while working though the selector backwards, filtering out elements with each declaration. This needs to be tested, but I was surprised at the performance I have seen with this new patch. The only selectors that query the DOM at the time of binding, are those passed into the main jquery function, all other selectors passed into the delegate method are stored and only executed when the events are fired. So added and modified elements will automatically be found if they are within the event scope. Binding a document or html delegation event is completely possible before the DOM has finished rendering, the listen plugin just happens to make the document the default listener for you. Please explain what it is that I am missing, and I apologize if I am misunderstanding your points. -mike On Oct 14, 7:30 pm, Diego Perini [EMAIL PROTECTED] wrote: Mike, no, it is not about me or Matt or the others, that's how the CSS specs are already implemented in the browsers, or will soon be (Webkit leading the way). My selector engine is just a temporary path to enhance browsers still not having those capabilities (all but Safari currently !) and is optional. You can use NWEvents alone if you don't need pseudos. To make it clear, I hardly believe my NWEvents code (as is) can replace anything in jQuery. At the same time I find current jQuery selectors are inadequate to delegation, I know John is working on it for 1.3. This is why I wrote the NWMatcher companion. Every implementation has its good things, one of Ariel's plugins, for example, DOES NOT need an onload event to start listening on element in advance. This small feature (that I also implement) will help drop many bugs and inconsistencies between browser events at startup. The order is important, elements can generate events only when they are already rendered. So, setting up events through delegation to higher parents (or up to document or documentElement), allow for pre-declared behaviors. Like CSS does, or like XUL and IE HTC's are able to do. And since order is important, several W3C specs states that the results of a selector query should return a document ordered static node list. Currently only XPath, and the Selector API do that (and my NWMatcher). Have you taken in consideration the fact that when the new Selectors API will be introduced elements will be returned in a different order than current ? Does your new implementation also take this in account ? I highly appreciate your efforts and comments, -- Diego On 14 Ott, 21:49, mike.helgeson [EMAIL PROTECTED] wrote: Ariel, Perhaps I am just polluting the plugin universe with duplicate features, but part of the reason I created another plugin is because I learn by coding. When you have an idea, do you prefer to write it out yourself, or tell someone else to write it for you? I guess it depends on the idea, but I wanted to try this one myself. Matt, I did not see that thread from the other list before. The ways that this is different from other plugins centers around attempting to make this more closely match the features available with bind... - the ability to bind data with a delegate handler - the ability to bind multiple handlers to the same selector - the ability to bind multiple events and multiple selectors to the same handler - the ability to stop the artificial propagation of delegates - the ability to selectively remove selectors, events, or everything Diego, I have not had a chance to look at your code
[jquery-dev] Re: Xml parsing and Firefox 2 3
I think data2.children(file) is the equivalent of data2.find( file). It will only match direct descendants of the root node. Try using .find instead, like this: [code] var tmp = data2.find(file); alert(files : + tmp.length); [/code] PS.: forgive me if I'm wrong, I haven't checked this, I'm just guessing! 2008/10/13 Lideln [EMAIL PROTECTED] Hi all, I fell on what seems to be a big issue (for me at least !). I have that ajax call that returns an xml tree. For example : dir --- dir --- --- file --- --- file --- dir --- --- file --- file --- file file file When I do that code : [code] var tmp = data2.children(file); alert(files : + tmp.length); [/code] It tells me files : 2 in firefox 3 (the proper answer), and it tells me files : 0 in firefox 2 (bad answer) (where data2 is a dir xml node) If someone knows something about that issue, I would be very pleased to hear it, since this is the first time I get a different behavior for parsing XML with jquery in firefox 2 and firefox 3. Thanks a lot ! -- Cheers, Diego A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: JQuery can't find imported nodes via innerHTML
Why are you using $('#id').attr('innerHTML',...); instead
of $('#id').html(...);???
2008/10/12 Sina Salek [EMAIL PROTECTED]
Hi everyone,
When i use innerHtml, either with $('#id').attr('innerHTML'... or
getElementById('id').innerHTML , jquery can no longer
find the elements imported via innerHTML.
First i search the web, but couldn't any thing related to this issue.
The first things came into my mind was, jquery needs to traverse new
elements again.
I checked the source code and found this f.apply( document ); and
tried using it in serveral ways
but couldn't get it to work.
I'm totaly out of idea(s) :( and really apperciate any help. tx
I'm using 1.2.6
--
Cheers,
Diego A.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] MultiFile Plugin Updated (v1.3)
* Announcement to anyone using the Multiple File Upload plugin * A new version is available which fixes a major bug in IE6/7. Download it here: http://www.fyneworks.com/jquery/multiple-file-upload/ Official project page: (for download/support) http://code.google.com/p/jquery-multifile-plugin/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
