[jQuery] Focus event firing twice in Internet Explorer
I'm building a form in which the specified values (the ones written in
the value attribute) for the inputs (types: text or password) are
saved as default values for that fields and when the user clicks on
them they disappear or appear again if the field has been left blank.
So, basically: the specified values are hints to the fields. With the
focus event, the hint disappears and with blur appears again if the
field is empty.
Each input has the following structure:
div class='txtbox'
div class='i1'/div
div class='input'input class=i2' type='{text or password}'
value=Default value for this field //div
div class='i3'/div
/div
The extra divs are there to make an input with round corners through
CSS. I'm also trying to outline the input when it is selected (with
the same focus and blur events, and preserving the round corners).
The problem comes with password inputs because the 'type' attributes
can't be changed in IE. The solution I came with was appending a text
input to each password input with the value specified for the password
input. Then I cleared the value for the password, hid the password
fields and showed the newly created one. This works like charm.
The thing is that, in IE, when I focus the password field, the focus
event is triggered twice. The outline effect appears and disappears.
There is a nasty workaround for this that I prefer not to use.
This is my code:
var TextBoxOutline=function(){
var a=$(this),b=a.parent();
b.prev().toggleClass(i1b);
a.toggleClass(i2b);
b.next().toggleClass(i3b);
}
/* The iXb classes are specified in the stylesheet and make the
outline effect in the input*/
$(.txtbox input.i2[type=text]).bind(focus blur,TextBoxOutline);
$(.txtbox input.i2[type=text]).each(function(){
var t=$(this),b=jQuery.data(t,defaultValue,t.val());
t.bind(focus blur,function(e){
var x=e.type,q=t.val();
if(x=='focus'q==b){t.val();}
else if(x=='blur'$.trim(q)==){t.val(b);}
})
});
$(.txtbox input.i2[type=password]).bind(focus
blur,TextBoxOutline);
$(.txtbox input.i2[type=password]).each(function(){
var t=$(this),newInput=$(input type='text' class='i2'
readonly).val(t.val()).css({cursor:'text'});
t.val('').after(newInput).css({display:'none'});
var fn=function(){newInput.toggle();t.toggle()}
newInput.focus(function(){
fn();
/*if(!ie)t.focus();else{t.select()}*/
/* This is the nasty workaround for IE */
t.focus();
})
t.blur(function(){
if($.trim(t.val())=='')fn()
});
});
Do you have any ideas?
[jQuery] Re: Performance of jquery
This is possible. We get trolls all the time on our forums. I'd like to point out, however, that all the other links that you guys referred him to have old performance results. We didn't advertise it, but since the release of 1.2b we updated the Slickspeed to reflect 1.2b. All the claims that MooTools was biased against IE have practically been removed :P We're still a bit slower than jQuery in IE, but like Rick Faircloth said it's a small margin now. :D Cheers, -Olmo Maldonado A MooTools Developer On Dec 11, 2:02 pm, Rey Bango [EMAIL PROTECTED] wrote: Hi Rick, Every so often, someone just mysteriously posts a message almost exactly like the one that you saw today and it's usually a brand new user to the list. It's been happening on a frequent basis and is assuredly link bait. So I want you to trust my judgment that when I say it's spam/link bait it truly is. I would never censor any thread and would only request this if I truly felt that it was someone trolling the list. Rey... Rick Faircloth wrote: Sorry, Rey, but I just wanted to understand the issue. It seems like jQuery comes out the winner in the tests that are run, but from everyone's response, I would expect the results to be the opposite. Am I missing something? Rick
[jQuery] Re: Verizon Wireless website using jQuery?
@Michael: just do in the url address bar: javascript:alert(MooTools.version); @Erik: Hahaha. :D We are modular ;). -Olmo Maldonado MooTools Developer http://mootools.net On Sep 20, 4:31 pm, Erik Beeson [EMAIL PROTECTED] wrote: Those MooTools punks stole our filesize! --Erik On 9/20/07, Josh Nathanson [EMAIL PROTECTED] wrote: OK, sorry about that. Weird though that it's also 27K packed. - Original Message - From: Michael Geary [EMAIL PROTECTED] To: jquery-en@googlegroups.com Sent: Thursday, September 20, 2007 4:05 PM Subject: [jQuery] Re: Verizon Wireless website using jQuery? From: Josh Nathanson Spotted in the wild? - Go tohttp://www.verizonwireless.com - Look at your Firebug Script tab, find the script gn_engine.js That packed script looks suspiciously familiar...and it's 27K ? As Erik mentioned, every script run through the old version of Packer (or the new version with base 62 encoding) looks more or less the same. Here's an easy way to tell what is inside a packed script. Open the script file directly in Firefox, in this case: http://cache.vzw.com/scripts/globalnav/gn_engine.js Do a Select All and Copy. Open the Firebug console. Paste the script into the Firebug command line. Go to the beginning of the line and change eval to alert. Hit Enter (or Ctrl+Enter if you have the multiline console command line open). -Mike
[jQuery] Re: from builtwith.com, with love: jquery leads ahead
Cool 0.78%. Now it's 1.21% ... Nice. Weird jQuery is now 1.83%? Must be a mistake? -Olmo Maldonado MooTools Developer http://mootools.net/ schnuck wrote: i know... but still not bad at all: MooTools MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API. 0.78% of all profiled sites use MooTools. JQuery Query is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages. jQuery is designed to change the way that you write JavaScript. 2.33% of all profiled sites use JQuery.
[jQuery] Re: Jquery Vs. Prototype
You're making MooTools sound like it's a fork from Prototype. I'd argue that there's fundamental and code differences between the two. Mitchell, I believe the impressions MooTools leave should be experienced rather than explained :-\. -Olmo Maldonado MooTools Developer http://mootools.net/ On Aug 4, 10:46 pm, Ganeshji Marwaha [EMAIL PROTECTED] wrote: brook, I am not sure if i will add substantially to what others have said above. Still, i wanted to post this mail anyways because you might be more comfortable making a decision if you hear an opinion from a normal user as opposed to a core developer. My background in javascript follows the pattern, javascript - prototype - mootools - jquery, and in that order. I have also played with libraries like YUI, Ext, Rico and GWT just to get a feel for them, but the first 3 libraries are where i have good expertise in... I started using prototype because, that seemed to be the best solution then. It was a well thought out library as opposed to other DHTML gimmicks out there. It was backed by a thorough and beautiful scriptaculous effects library. Although prototype had zero documentation, i still chose them for the quality of the library itself. I sincerely started decoding the source night after night and a week later, i had a comprehensive personal documentation(which ofcourse only i could understand). I used them for a while - Until one day when i found mootools. I was jumping for joy, not because mootools had a radically different approach(coz they don't) and not because they had clear documentation(coz they didn't), but because it was so small in size. This was a welcome gift, and i took it - after all it is free. They had a few bells and whistles as in, new and improved inheritance support etc etc etc., but the best of all, the syntax they offered was almost similar to prototype. I was very happy with them, and will continue to be. I still use both prototype and mootools in different projects and i love them both. But, one fine morning my feed reader was forcing me to read a blog about jquery. I initially resisted, coz, i thought it was related to database. Then for some odd reason, i read it. It was someones blog ( i don't remember who), and i had mixed feelings. Being the experimenter i am, i started playing with it, and trust me, within one day, i felt like an expert. It sure was a radically different approach to modern javascript and the documentation was clean and simple. Then i subscribed to the mailing list and started talking to people here, and man trust me, i haven't been in such a helpful community. Although my initial impressions were that it might not be as extensive as the other 2, those doubts subsided when i realized the simplicity of the plugin architecture. There are plugins for almost everything and every plugin is so darn small and inviting. In the rare case where fellow community members didn't find a plugin for their needs, i have seen plugin authors write a plugin in a matter of hours and throw it in for them to use. With jQuery it is that easy. Everything seems so simple. I now can't remember why i used to hate javascript so much. Now, from time to time, when i go back to prototype or mootools to support my existing projects i really do feel that the code base looks complex. After using jquery every other library looks complex to me. So be warned. If you were to lose one thing by choosing jquery it is that, you might forget plain javascript and other libraries sooner rather than later. Then don't blame, coz i am no different than you then. If you made this far, i am sorry for such a long email, but i just couldn't help telling you my story for your benefit. My best wishes. -GTG On 8/4/07, Dragan Krstic [EMAIL PROTECTED] wrote: BMHO, jquery is easier to learn and doesn't extends native JS objects. jQ people is more enthusiatsic about library they use. Also, jQuery put standards in speed, documentation and support. By introducing jQuery, John forced other folks to improve their libraries. And comunity is very devoted, too. 2007/8/5, John Resig [EMAIL PROTECTED]: I can see the benefit of this being that you only include the methods you need and there is no bloat. That's precisely why. Here's examples of everything that you mentioned: disable: $(input).attr(disabled,disabled); enable: $(input).attr(disabled,); findFirstElement: $(form :input:first) focusFirstElement: $(form :input:first).focus(); getElements: $(form :input) getInputs: $(form :input) request: (via Form plugin) $(form).ajaxSubmit() reset: $(form).reset() serialize: $(form :input).serialize() serializeElements: $(form :input).serialize() Obviously there are philosophical differences at play - but the fact all of these things exist (or are easily accessed via a plugin) just shows how powerful
[jQuery] Re: MooTools $events expando workaround
I'll add a signature from now on it seems. I don't need to waste my time in trying to lecture you. Should have known better. -Olmo M. http://mootools.net/developers On Sep 1, 8:35 am, Rey Bango [EMAIL PROTECTED] wrote: Well, in the interest of full disclosure, for those that don't know, Olmo is part of theMooToolsdevelopment team. Now, back to the topic. If there's nothing to glean and there's no benefit in sending list members to what ended up as a very unproductive discussion, why would it be the right thing to do? Rey... jQuery Project Team Olmo wrote: There's nothing to glean. It's the right thing to do. -Olmo M. On Aug 31, 9:23 pm, Rey Bango [EMAIL PROTECTED] wrote: Actually, I didn't. I left it out intentionally as there was nothing to be gleaned from the thread. Rey... Olmo wrote: You forgot to post the url to theMooToolsforum: http://forum.mootools.net/viewtopic.php?id=5190#post-26592 -Olmo M.
[jQuery] Re: MooTools $events expando workaround
You forgot to post the url to the MooTools forum: http://forum.mootools.net/viewtopic.php?id=5190#post-26592 -Olmo M. On Aug 30, 4:05 pm, Rey Bango [EMAIL PROTECTED] wrote: There was a recent flurry of emails on the list discussing a conflict with the use ofMooToolsin conjunction with jQuery. WhenMooTools released v1.1, they renamed their events expando to $events, thus conflicting instantly with jQuery. Well, Brazilian developer Alexandre Magno (http://blog.alexandremagno.net/) came up with a novel and quite simple solution to get around this issue; rename the $event expando inMootools! I found a solution that works perfectly. Im the live example that we need sometimes to use the both frameworks. Im develop all my projects in jQuery, cause I learn more easily and feel more comfotable with it. Nothing to do withMootools, with is a beatiful framework too... But I need the fancy upload to work and is just possible withMootools, I make everything, but doesnt work because the conflict with the variable $event. I solve this issue by getting themootoolsdownload with no compression, use a software like aptana, dreamweaver, or even notepad to replace all ocurrences of $event to $event2 for example, and compress the libraty after it. This way, the two frameworks works perfectly, since the use of jquery with noConflit its configured. I hope this works and soon I will develop this fancy upload for jquery to dont have to use both. Its a shame for themootoolsteam wait to Jquery solve this problem that noboby its blame... its just convention... why just simple replace $event for $mootoolsEvent or $mooEvent for example??? Somethimes its necessary use both, no doubt.. This was posted in theMooToolsforum in response to a post where John I were trying to resolve an integration problem for aMooToolsuser who wanted to useMooToolsand jQuery together. We realize that its unrealistic to expect that developers are going to use just one library and the team goes to great lengths to ensure some level of interoperability between other libraries via noConflict(). In jQuery v1.2, we take that a step further by allowing the renaming of the events expando to whatever you would like, thus avoiding any conflict. While this was not a bug in jQuery, we feel strongly about allowing developers to leverage the tools that they need to do their work and we never want jQuery to be a bottleneck. Thank you John the jQuery team for continuing to make jQuery such a flexible solution and thank you Alexandre for expanding jQuery's reach to Brazil and offering up this great workaround. Rey...
[jQuery] Re: MooTools $events expando workaround
There's nothing to glean. It's the right thing to do. -Olmo M. On Aug 31, 9:23 pm, Rey Bango [EMAIL PROTECTED] wrote: Actually, I didn't. I left it out intentionally as there was nothing to be gleaned from the thread. Rey... Olmo wrote: You forgot to post the url to theMooToolsforum: http://forum.mootools.net/viewtopic.php?id=5190#post-26592 -Olmo M.
[jQuery] Re: Why jQuery over Mootools
I wanted to clarify.
Mootools is large based off or Moo.fx(and prototype/jQuery)
This is not entirely true. While moo.fx may be prototype based (the
code requires prototype to function), MooTools doesn't have any
ressemblences/connections to jQuery (or at least not apparent to me).
The only function that has strong resemblence might be the $(), but
that comes from working with prototype's $() and our philosophy to say
$ returns one extended element, $$ returns many extended elements.
The history behind MooTools is a little vague. I'll add it to the To
do list and share it with you guys when we compose something more
concrete.
-Olmo M.
On Aug 13, 8:42 am, Eridius [EMAIL PROTECTED] wrote:
Well this is true and not true. Mootoolsis based on Moo.fx which might have
been around much longer than jQuery butMootoolsi believe was released a
few months after jQuery. Mootoolsis largely based off or Moo.fx(and
prototype/jQuery)
Andy Matthews-4 wrote:
Actually, I believe that Moo Tools has been around for quite a bit longer
than jQuery. It was one of the first effects libraries I looked at before
I
ever even heard of jQuery.
-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Eridius
Sent: Saturday, August 11, 2007 5:37 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Why jQuery overMootools
I have been working withmootoolsfor a bit the past few months and
started
to take a look at jQuery too see what the hype is all about from what i
have
heard from a co-worker. From what i see, jQuery does not offer anything
thatmootoolsdoes not. I mean jQuery does have
$().click
and i don't believeMootoolshas anything like that, they just have the:
$().addEvent('click', function(){});
However this is just a shortcut and not a major thing. On thing that
jQuery
has is that there are far more scripts however this is just to the fact
that
jQuery has been around longer thanmootools. However on the other hand
mootoolshas is a very nice way to create new classes. All i have to do
is:
var ajax_request = new Class(
{
options:
{
//class options
};
initialize: function(options)
{
this.setOptions(options);
//other initliaizing code
};
//more methods
});
ajax_request.implement(Options);
var my_ajax_request = new ajax_request({//override default options});
my_ajax_request.process();
Now I have been told that jQuery tries to do things more like the OO
method. Well to me the basically thing about OO is being able to combine
members(variables) and methods(functions) into a common
place(class/object).
I have tried creating a simple class with jQuery and it does not work(this
code if based off what i was told from these forums):
var ajax_request = function(options)
{
ajax_options =
{
test: 'test'
};
test = function()
{
alert(this.test);
}
}
var test = new ajax_request();
test.test();
and this code tells me that test() is not a function of test. It seems
that
jQuery wants you to incorporate everything into the $() selector which
does
not make sense of everything. Being able create separate object is
something that is important to me and jQuery does not seem to support
that.
Another thing that that jQuery says is that is it so small. Well
comparing
the full version ofmootools(all options selected) to the full version of
jQuery is unfair. In order to get allt he features of fullmootoolsyou
would have to add jQuery interface script and comparingmootoolsto
jQueryInterface script,mootoolsis still smaller.
So why should someone choose jQuery overMootoolsor is it really just a
preference thing and and both are basically the same(i see a lot about
jQuery vs prototype but not alot about jQuery vsmootools)
--
View this message in context:
http://www.nabble.com/Why-jQuery-over-Mootools-tf4254982s15494.html#a...
0
Sent from the JQuery mailing list archive at Nabble.com.
--
View this message in
context:http://www.nabble.com/Why-jQuery-over-Mootools-tf4254982s15494.html#a...
Sent from the JQuery mailing list archive at Nabble.com.
[jQuery] Re: jQuery 1.1.4: Faster, More Tests, Ready for 1.2
Hi John, I do believe this leak has been fixed since quite a while ago (understatement): http://dev.mootools.net/ticket/5 -Olmo M. P.S. I had sent this email, but noticed it wasn't added. Ignore duplicates plz. :) On Aug 25, 8:30 pm, John Resig [EMAIL PROTECTED] wrote: I just took a look at prototype.js andmootools.js, neither are depended on a Lets hope if this best guess 13ms always works timer concept. Right, so they leak every single time you use them, both libraries are quite naive about the issue of memory leaks. If you're looking for some form of justification for what we're doing look at Yahoo UI:http://sourceforge.net/project/downloading.php?group_id=165715filena... In build/connection/connection.js look for handleReadyState which does all the polling. Also, Dojo is using this particular method for querying XHR state:http://alex.dojotoolkit.org/?p=528 Yahoo UI is also using a polling interval of 50ms for XHR, which they seemed to just pick arbitrarily. Just to emphasize that point, look in Yahoo UI's build/animation/animation.js where they set their delay on their animation timers to 1ms. I think you're missing a couple points here: - JavaScript engines are not multi-threaded. There's no such thing as a locking or synchronization issue within JavaScript. The XHR request won't return or finish until the current JS is finished executing. - setTimeout and setInterval do not create threads. The push functions onto the JavaScript stack to be executed at a later time (so if a script never stops running a timeout will never be called). - The units passed to setTimeout are arbitrary, it's still at the browsers discretion as to when they're actually executed. They're not sent straight to the processor for handling - all operations are delegated by the browser. So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok, there's no particular reason for not doing so - nor has it made any particular effect upon the system for not having done so. In the case of Ajax, the query rate could probably be slowed down to something like 50ms, and for animations, increased to something like 1ms. The issues at play here are phenomenally more complicated, and nuanced, then they're made out to be. --John
[jQuery] Re: jQuery 1.1.4: Faster, More Tests, Ready for 1.2
John, I've been doing some digging to find that leak and I believe it had been resolved since the 5th ticket in our Trac. http://dev.mootools.net/ticket/5 I also don't encounter any leaks in my own tests. -Olmo M. On Aug 25, 8:30 pm, John Resig [EMAIL PROTECTED] wrote: I just took a look at prototype.js andmootools.js, neither are depended on a Lets hope if this best guess 13ms always works timer concept. Right, so they leak every single time you use them, both libraries are quite naive about the issue of memory leaks. If you're looking for some form of justification for what we're doing look at Yahoo UI:http://sourceforge.net/project/downloading.php?group_id=165715filena... In build/connection/connection.js look for handleReadyState which does all the polling. Also, Dojo is using this particular method for querying XHR state:http://alex.dojotoolkit.org/?p=528 Yahoo UI is also using a polling interval of 50ms for XHR, which they seemed to just pick arbitrarily. Just to emphasize that point, look in Yahoo UI's build/animation/animation.js where they set their delay on their animation timers to 1ms. I think you're missing a couple points here: - JavaScript engines are not multi-threaded. There's no such thing as a locking or synchronization issue within JavaScript. The XHR request won't return or finish until the current JS is finished executing. - setTimeout and setInterval do not create threads. The push functions onto the JavaScript stack to be executed at a later time (so if a script never stops running a timeout will never be called). - The units passed to setTimeout are arbitrary, it's still at the browsers discretion as to when they're actually executed. They're not sent straight to the processor for handling - all operations are delegated by the browser. So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok, there's no particular reason for not doing so - nor has it made any particular effect upon the system for not having done so. In the case of Ajax, the query rate could probably be slowed down to something like 50ms, and for animations, increased to something like 1ms. The issues at play here are phenomenally more complicated, and nuanced, then they're made out to be. --John
[jQuery] Re: Release: Accordion 1.5
The hover bug in the home page is not an actual MooTools bug. It has to do with the layout of the page. There's a demo at: http://demos.mootools.net/Fx.Elements that you won't see the problem. :). -Olmo M. On Aug 26, 5:36 pm, Ganeshji Marwaha [EMAIL PROTECTED] wrote: In my opinion (and only my opinion) i think that it is kinda disturbing if we hover on one item and immediately if we hover on another item, the accordian doesn't open for the second item. If you look at the mootools.net home page, you see the kwick(horizontal acoordian). I am working on something like that. I am facing the same problem there as well. But in the mootools site, if you hover from the left end to the right end fast, you could see that the intermediate items partially animate... As far as i know this can be solved using the stop() method in fx. But the stop() method is available only as part of the interface's animation extension. John has promised that as part of the core in 1.2 though. So, again, in my opinion, i would favor an approach where if we hover over one item and then immediately if we hover over the other item before the animation of first is complete, then the animation of the first item should be stopped in the middle and the second animation should start. That would be ideal. But i am not sure how easy or difficult it is. I am keen and willing to do any help that might be required. -GTG On 8/26/07, Jörn Zaefferer [EMAIL PROTECTED] wrote: Ganeshji Marwaha schrieb: Jörn, this is fantastic... very re-usable as well.. I have a question/suggestion though... When i hover over one of the items, and before the animation completes if i hover over another item, the animation for the second item doesn't occur. Now, i will have to move my mouse out of that item and hover over it again to get the other item to expand. Is it something that can be fixed, or is it a known limitation that we will have to live by... Well, so far that was intended to be a feature, not a bug. The combination of long-running animations with hover is annoying, right. But it is also annoying when the accordion keeps changing on each mouse move, even when you didn't intend to get a different chunk. Fixing it isn't difficult, but it is difficult to decide what the right fix actually is. Your help is appreciated. -- Jörn
[jQuery] Re: jQuery 1.1.4: Faster, More Tests, Ready for 1.2
I've ported the test to: http://ibolmo.no-ip.info/sandbox/ajax-leaks.html (note: it might be offline in a few days-- I'm moving :D). Can't seem to reproduce the leaks. Let us know if you experience any. Like I said, I had believed this had been taken cared of since the 5th ticket. I did find it weird that in the past 8 months no one had mentioned any onreadystatechange leaks. MooTools takes these sort of issues very seriously, and we dont think that we have been naive in our implementations. We have even implemented our own Garbage Collector to deal with unwanted attribute leaks. Never hurts to check, however. Thanks, Olmo M. On Aug 27, 10:31 am, John Resig [EMAIL PROTECTED] wrote: Olmo - That alone is not sufficient - that's what we originally used as well. See this ticket:http://dev.jquery.com/ticket/991 and this blog post:http://alex.dojotoolkit.org/?p=528 YUI, Dojo, and jQuery all use this technique to avoid these leaks. It's unavoidable otherwise. --John On 8/27/07, Olmo [EMAIL PROTECTED] wrote: John, I've been doing some digging to find that leak and I believe it had been resolved since the 5th ticket in our Trac. http://dev.mootools.net/ticket/5 I also don't encounter any leaks in my own tests. -Olmo M. On Aug 25, 8:30 pm, John Resig [EMAIL PROTECTED] wrote: I just took a look at prototype.js andmootools.js, neither are depended on a Lets hope if this best guess 13ms always works timer concept. Right, so they leak every single time you use them, both libraries are quite naive about the issue of memory leaks. If you're looking for some form of justification for what we're doing look at Yahoo UI:http://sourceforge.net/project/downloading.php?group_id=165715filena... In build/connection/connection.js look for handleReadyState which does all the polling. Also, Dojo is using this particular method for querying XHR state:http://alex.dojotoolkit.org/?p=528 Yahoo UI is also using a polling interval of 50ms for XHR, which they seemed to just pick arbitrarily. Just to emphasize that point, look in Yahoo UI's build/animation/animation.js where they set their delay on their animation timers to 1ms. I think you're missing a couple points here: - JavaScript engines are not multi-threaded. There's no such thing as a locking or synchronization issue within JavaScript. The XHR request won't return or finish until the current JS is finished executing. - setTimeout and setInterval do not create threads. The push functions onto the JavaScript stack to be executed at a later time (so if a script never stops running a timeout will never be called). - The units passed to setTimeout are arbitrary, it's still at the browsers discretion as to when they're actually executed. They're not sent straight to the processor for handling - all operations are delegated by the browser. So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok, there's no particular reason for not doing so - nor has it made any particular effect upon the system for not having done so. In the case of Ajax, the query rate could probably be slowed down to something like 50ms, and for animations, increased to something like 1ms. The issues at play here are phenomenally more complicated, and nuanced, then they're made out to be. --John
