I think you're not "fixing" the event when calling fix. You're just
cloning it, aren't you ?
The code to copy the $.event.props is quite short, I'd say you can
redo that yourself.
Just copy the props from the mousemove (fixed) event to a new $.Event
('drag').
--
Ariel Flesler
http://flesler.blog
Can we use a different property to track fixed events or make the expando
public? It would be really useful to be able to detect if an event is fixed
outside of core, or be able to remove the flag to allow the event to be
fixed again.
The problem I'm running into is I have an event that has alrea
This is a long thread with lots of information.
Would you mind filing an enhancement ticket for jQuery to implement a
similar solution to help overcome the "submit()" issue you mentioned?
--
Brandon Aaron
On Tue, Jan 27, 2009 at 1:25 PM, Diego Perini wrote:
>
> Correct John, I also do that on m
Diego -
Thanks for the clarification, I'll land this as soon as possible.
--John
On Tue, Jan 27, 2009 at 2:47 PM, Diego Perini wrote:
>
> 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.j
On Jan 27, 6:19 pm, Diego Perini wrote:
> 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 ne
for picasa, if enter a wrong userid in the link, the page will print a
string "Unable to find user with email x...@gmail.com" instead of a
json object.
Is there anyway to detect the return string is in wrong format?
I tried ajaxComplete,ajaxError,ajaxStop,ajaxSuccess, none of them
triggered if th
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
On Jan 27, 4:46 pm, Diego Perini 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
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
alert, setInterval and setTimeout via silly tricks can be reassigned.
Apparently, IE does not allow the reassignment of the window.window, at
least static in other browsers.
try{window.window=null}catch(e){$.isIE=true};
On Tue, Jan 27, 2009 at 9:46 PM, Diego Perini wrote:
>
> Juriy,
> we agr
Could someone confirm this is a bug?
On Mon, Jan 26, 2009 at 02:45, Nicolas Grilly wrote:
> My web site uses a so-called "sticky footer" layout. It worked perfectly
> until I had replaced jQuery 1.2.1 by jQuery 1.3.1. The simple fact to load
> jQuery 1.3.1, without any other script in my page, i
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
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:2
On Tue, Jan 27, 2009 at 4:36 PM, KidsKilla .grin! wuz here <
kidski...@gmail.com> wrote:
>
> 2009/1/28 John Resig :
> >
> > A whole mess of problems:
> > - Caches queries with reckless abandon - this is incredibly bad on
> > any sort of dynamic document (aka - all of jQuery)
> it is, but maybe th
2009/1/28 John Resig :
>
> A whole mess of problems:
> - Caches queries with reckless abandon - this is incredibly bad on
> any sort of dynamic document (aka - all of jQuery)
it is, but maybe there is some way to recognize when we can use a
cache and when we can't. kinda
if(lastInnerHTML != docum
On Jan 27, 1:37 pm, Diego Perini 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
A whole mess of problems:
- Caches queries with reckless abandon - this is incredibly bad on
any sort of dynamic document (aka - all of jQuery)
- Offers no extensibility beyond simple :foo or [foo__bar] selectors
- Uses browser sniffing
- Have you looked at the source code?
--John
On Tue,
He's talking about YASS. The code is here:
http://code.google.com/p/yeasss/source/browse/trunk/src/yass.js
The speed claims are interesting if true, though it looks like it's
still using browser sniffing.
-- dz
On Tue, Jan 27, 2009 at 4:06 PM, Elijah Insua wrote:
> link is broken.
>
> On T
link is broken.
On Tue, Jan 27, 2009 at 4:01 PM, KidsKilla wrote:
>
> Hi everyone!
>
> Did you seen this tests? It's just amazing! espesially in IE.
> Maybe it's a good idea to cooperate Sizzle and YACC developers?
>
>
> http://yass.webo.in/en/slickspeed/?Dojo_Toolkit_1-2-0/Peppy_0-1-2/DOMAssist
Hi everyone!
Did you seen this tests? It's just amazing! espesially in IE.
Maybe it's a good idea to cooperate Sizzle and YACC developers?
http://yass.webo.in/en/slickspeed/?Dojo_Toolkit_1-2-0/Peppy_0-1-2/DOMAssistant_2-7-4/YUI_2-6-0/MochiKit_1-4/MooTools_1-2-1/Sizzle_11-12-08/Sizzle_21-10-08/ya
John,
On 27 Gen, 20:23, John Resig 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
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 wil
Correct John, I also do that on my NWMatcher selector engine I should
have said "most" instead of "every".
I was aware jQuery does not suffer this problem, but the solution I
used is somehow different:
- save the element offending id="length"
- remove the offending id from element
- do the DOM c
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.
Previously the check was: !window.frameElement
Which was not enough - it completely breaks use of jQuery. There needs
to be a
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,
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 e
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
sin
Tried that, same result...
On 1月28日, 上午3時07分, David Zhou wrote:
> What happens if you use the full un-minified version?
> -- dz
>
> On Tue, Jan 27, 2009 at 1:54 PM, helianthus
>
>
>
> wrote:
>
> > I hope I know why this happens...
> > Just tried again, no error is shown at the error console, bu
What happens if you use the full un-minified version?
-- dz
On Tue, Jan 27, 2009 at 1:54 PM, helianthus
wrote:
>
> I hope I know why this happens...
> Just tried again, no error is shown at the error console, but the
> problem still exists.
>
> On 1月28日, 上午2時46分, John Resig wrote:
>> I really
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.doScrol
I really don't know enough about Opera's UserJS - more information
about why it's not working (error messages?) would be useful.
--John
On Tue, Jan 27, 2009 at 10:41 AM, helianthus
wrote:
>
> Got no replies at the General Discussion so I'm posting here:
>
> I have been writing a user-script(u
I hope I know why this happens...
Just tried again, no error is shown at the error console, but the
problem still exists.
On 1月28日, 上午2時46分, John Resig wrote:
> I really don't know enough about Opera's UserJS - more information
> about why it's not working (error messages?) would be useful.
>
>
Hi all,
Someone posted this problem at the jquery-en group:
http://groups.google.com/group/jquery-en/browse_thread/thread/ecc1dc86bc46b528
In jQuery 1.2.6, appending to multiple elements deep clones the
appended element, copying it's event handlers. In 1.3.1 this only
happens on IE, in other bro
why don't you just use the window onload event?
On 1月28日, 上午1時52分, Fabio Buffoni wrote:
> This is a think I've been thinking about since jQuery 1.2.
>
> I had a similar problem working on cloned nodes for layout, (1.2.6, didn't
> try using jquery 1.3+), when the node has images with no size spec
> One "span" element with an id="length" will do much more damages to
> every existing framework/library
Except jQuery, where we take this into account.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuer
Got no replies at the General Discussion so I'm posting here:
I have been writing a user-script(userjs) with jQuery recently, the
way I integrate jQuery is to copy the minified code into the user-
script.
It had been working fine until I updated jQuery to 1.3, while on
other
browsers(FF3, Chrome,
Juriy,
you know my code and you have links showing I moved everything to
proper feature testing because I believe it is a superior methodology.
This doesn't mean we have to throw away well tested object inference
we have learned up to here.
There is no need to jump away from working solutions, w
Ops, of course I misunderstood the problem, sorry :)
--Fabio
On Tue, Jan 27, 2009 at 6:52 PM, Fabio Buffoni wrote:
> This is a think I've been thinking about since jQuery 1.2.
>
> I had a similar problem working on cloned nodes for layout, (1.2.6, didn't
> try using jquery 1.3+), when the node
This is a think I've been thinking about since jQuery 1.2.
I had a similar problem working on cloned nodes for layout, (1.2.6, didn't
try using jquery 1.3+), when the node has images with no size specified, the
offset / width calculations are sometimes wrong because they're done too
early, expecia
On Jan 27, 11:34 am, Matt wrote:
> On Jan 27, 7:12 am, Diego Perini wrote:
>
> > I just wrote in another thread that there are cases where I prefer to
> > use the following:
> > var IE = typeof document.fileSize !== 'undefined', // IE6, IE7 or IE8
> > as a general boolean to detect any IE versio
Hey Matt,
I really appreciate your knowledge and your passion regarding feature
detection. You've definitely given me a lot to think about in this
thread. I'm wondering about this paragraph, though:
> jQuery and many plugins purposely limit the "supported browser" list
> because of the techn
Here you go:
http://dev.jquery.com/ticket/4004
Jed
On Jan 27, 6:27 am, Brandon Aaron wrote:
> This sounds reasonable. Can you make an enhancement ticket so it doesn't get
> lost on the list?
> --
> Brandon Aaron
>
> On Tue, Jan 27, 2009 at 2:02 AM, Jed Schmidt wrote:
>
> > John,
>
> > Thinkin
This is already in the bug tracker as #3988:
http://dev.jquery.com/ticket/3988
-- dz
On Tue, Jan 27, 2009 at 11:24 AM, John Resig wrote:
>
> Do you have a demo page that we can look at?
>
> --John
>
>
>
> On Fri, Jan 23, 2009 at 11:01 AM, helianthus
> wrote:
>>
>> 1.2.6:
>> No problems on
On Jan 27, 7:12 am, Diego Perini wrote:
> I just wrote in another thread that there are cases where I prefer to
> use the following:
> var IE = typeof document.fileSize !== 'undefined', // IE6, IE7 or IE8
> as a general boolean to detect any IE version
Is that really a good test? Do you know for
I'll try not to beat a dead horse, since I've stated my views. But it
does often take some repeated pushing to get js developers to change
their thinking and see the benefits of true feature detection. I'm
happy to continue this discussion and really get into the dirty
details of finding the best
Do you have a demo page that we can look at?
--John
On Fri, Jan 23, 2009 at 11:01 AM, helianthus
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.
>
>
can anyone confirm??
On 1月24日, 上午3時01分, helianthus 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.
--~--~-~--~~~---~--~~
Y
Thanks for the pointer-- it would be worthwhile to have the jQuery
tree and your original env.js blog post point to the new effort.
The same issue I reported above appears in the file at
http://github.com/jeresig/env-js/blob/70ed3800d7abaaff54af67e39842f4fc3e5fac61/src/env.js
My suggested fix wou
This sounds reasonable. Can you make an enhancement ticket so it doesn't get
lost on the list?
--
Brandon Aaron
On Tue, Jan 27, 2009 at 2:02 AM, Jed Schmidt wrote:
>
> John,
>
> Thinking about it again, would it make sense to decouple DOM removal
> from element death? This could help you speed u
Kevin,
if that counts...I fully agree with you on the fact that browser
sniffing will never be replaced completely.
I just wrote in another thread that there are cases where I prefer to
use the following:
var IE = typeof document.fileSize !== 'undefined', // IE6, IE7 or IE8
as a general boolean
I was able to find the error, i was using try/catch blocks to switch checks
between activex and navigator.plugins, when i changed the code to use
conditionals blocks(if/else) instead of catching exceptions it worked fine
2009/1/27 John Resig
>
> I just loaded it in Firefox 3 on OS X and it seems
Hi John.
I know there is a fallback solution, but as the ID is auto-generated
in my app and it does adhere to
the standard w3c (except for a single character) wouldnt it be nice to
atleast include the minimum
characters allowed in the spec. I read the w3c spec:
ID and NAME tokens must begin with
John,
Thinking about it again, would it make sense to decouple DOM removal
from element death? This could help you speed up not only
$.fn.replaceWith, but also $.fn.empty and everything that uses it
(including $.fn.html and $.fn.text), with something like this:
function kill() {
jQuery.event.r
53 matches
Mail list logo
