Re: [jquery-dev] Re: jQuery.event.special['type'].add modifies handler of other types
Hey John, Feel free to submit a patch. Anything that can help move us forward is great. I'm going to see if I can't carve out some time to take a look at this issue in detail this evening. -- Brandon Aaron On Thu, Jan 14, 2010 at 12:18 AM, John Arrowwood wrote: > I could write a patch, if someone wants me to. It shouldn't be hard, I > described the fix in the defect. But I wanted someone more intimate with > the code to look at it, first. > > On Wed, Jan 13, 2010 at 5:25 PM, Dave Methvin > wrote: >> >> http://dev.jquery.com/ticket/5779 >> >> Patch, anyone? Is there a test case we can add to make sure it stays >> fixed? >> >> -- >> 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. >> >> >> > > > > -- > John Arrowwood > John (at) Irie (dash) Inc (dot) com > John (at) Arrowwood Photography (dot) com > John (at) Hanlons Razor (dot) com > -- > http://www.irie-inc.com/ > http://arrowwood.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-...@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. > > -- 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.
Re: [jquery-dev] Re: Change "this" when binding element
I'm on board with this.
--
Brandon Aaron
On Thu, Dec 31, 2009 at 2:19 PM, John Resig wrote:
> I added in jQuery.proxy( obj, name ) support as well (I like this - I
> also showed how to do it in Secrets of the JavaScript Ninja:
> http://github.com/jquery/jquery/commit/1d2b1a57dae0b73b3d99197f73f4edb623b5574a
>
> Any major concerns before I push this through? Will this meet the
> needs of everyone in the thread?
>
> --John
>
>
>
> On Thu, Dec 31, 2009 at 12:39 AM, John Resig wrote:
>> So I definitely agree that having a single, one-off, API addition (to
>> bind and live) is kind of lame - especially when it conflicts with the
>> jQuery way of defining the methods (having a non-callback argument
>> being last).
>>
>> I sat down and wrote up a quick jQuery.bind() but found one critical
>> issue that was not resolved by the hitch/bind/fn.prototype.bind
>> technique: You can't (easily) unbind a function that has a different
>> scope defined.
>>
>> For example:
>>
>> function foo(){}
>> .bind( "click", foo.bind(someObject) );
>> .unbind( "click", foo /* errr we actually need to save the fn
>> somewhere */ );
>>
>> jQuery has already solved this problem internally using our
>> jQuery.event.proxy method - and, in fact, if I were to land a
>> jQuery.bind() it would end up using jQuery.event.proxy(). But if you
>> look at jQuery.event.proxy() you can see that, in reality, we could
>> just be using that method and skip this whole dance entirely. For
>> example (and this works today, in jQuery 1.3.2):
>>
>> function foo(){}
>> .bind( "click", jQuery.event.proxy( foo, someObject ) );
>> .unbind( "click", foo );
>>
>> Save for the sugar that hitch provides I can't see any reason to not
>> just promote jQuery.event.proxy() to jQuery.proxy() and make it an
>> officially supported part of the jQuery API.
>>
>> Filed: http://dev.jquery.com/ticket/5736
>> Landed (in a branch, for review and further discussion):
>> http://github.com/jquery/jquery/commit/66975de2d249643779e2b3daad0457f7f5f92508
>>
>> --John
>>
>> For fun, here is the jQuery.bind() that I quickly wrote (that DOESN'T
>> use jQuery.proxy):
>>
>> diff --git a/src/core.js b/src/core.js
>> index 944e8a9..1908123 100644
>> --- a/src/core.js
>> +++ b/src/core.js
>> @@ -614,6 +614,20 @@ jQuery.extend({
>> return ret.concat.apply( [], ret );
>> },
>>
>> + bind: function( scope, fn ) {
>> + if ( scope ) {
>> + if ( typeof fn === "string" ) {
>> + fn = scope[ fn ];
>> + }
>> +
>> + if ( fn ) {
>> + return function() {
>> + return fn.apply( scope, arguments );
>> + };
>> + }
>> + }
>> + },
>> +
>> // Use of jQuery.browser is frowned upon.
>> // More details: http://docs.jquery.com/Utilities/jQuery.browser
>> browser: {
>>
>>
>>
>>
>> On Tue, Dec 29, 2009 at 4:58 PM, Rick Waldron wrote:
>>> This is exactly what I was getting at... With regard to event handler
>>> .bind() and fn.bind()
>>>
>>> So far with my $.hitch tests, the one thing I dislike is the argument
>>> structure. It does what it should but I'd much prefer
>>> a function.prototype.bind() if given the choice.
>>>
>>>
>>>
>>> -- Sent from my Palm Prē
>>>
>>> ajpiano wrote:
>>>
>>> I love the idea of extending scope manipulation to any function,
>>> rather than only event handlers. Callbacks to ajax requests often
>>> need a better scope than the XHR, and while I look forward to 1.4's
>>> functionality for event handlers, it would really be a shame to
>>> continue to force people to use non-jQuery solutions for full scope
>>> manipulation.
>>>
>>> That said, and while I do love (and frequently recommend) $.hitch, I
>>> prefer an approach more like Prototype or Underscore's that doesn't
>>> involve passing so many strings.
>>>
>>> --adam
>>>
>>> On Dec 29, 3:45 pm, Peter Higgins wrote:
>>>> It is a short-port of Dojo's dojo.hitch(). The only thing it doesn't do
>&
Re: [jquery-dev] Re: Array.prototype.indexOf not fully utilized in jQuery.inArray
http://github.com/jquery/jquery/blob/master/src/core.js#L49 http://github.com/jquery/jquery/blob/master/src/core.js#L571 -- Brandon Aaron On Mon, Dec 14, 2009 at 4:16 AM, caii wrote: > Array.prototype.indexOf? > where it in JQUERY? > > On Dec 14, 6:13 pm, Robert Katić wrote: >> Already fixed. If Array.prototype.indexOf exists, then it is always >> used. >> >> On Dec 14, 10:38 am, helianthus wrote: >> >> > This occurs when using jQuery.fn.index, which utilizes jQuery.inArray. >> > Since the jQuery object does not have an indexOf method, it falls back >> > to the for loop approach, while Array.prototype.indexOf could have >> > been used. > > -- > > 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. > > > -- 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.
Re: [jquery-dev] position() in Firefox
Each browser will usually give a different result based on how it is
rendering the font, spacing, etc. Try positioning a div at the
reported top/left to see if the results are accurate or not.
--
Brandon Aaron
On Wed, Nov 18, 2009 at 11:01 AM, mkeppler wrote:
> Hello,
> when i want to get the height of some element, i get different values
> in Firefox and IE.
>
> The values in IE are the correct values, the Firefox returns greater
> values.
>
> I have written a minimal sample:
> http://joomla.paradi.de/test.php
>
> $("#div").position().top returns also wrong values in FF.
>
> Is this a known bug, do i a mistake or on most important, do someone
> knows a bugfix or a other way?
>
>
> Marius
>
> --
>
> 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=.
>
>
>
--
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.
Re: [jquery-dev] Build Process
I think the question might be more about general combination of scripts (such as jQuery plugins and custom code)... -- Brandon Aaron On Thu, Nov 12, 2009 at 7:12 PM, John Resig wrote: >> Is there any work being done to create a jQuery build process that >> helps automate the concatenation and minifying of javascript files. > > Different from what we already have? If you wish to create a version > of jQuery that has a different set of functionality (or reduced set) > you just twiddle the file list in the Makefile and get a fully > minified result. > > --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-...@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=. > > > -- 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=.
[jquery-dev] Re: jQuery Special Events: Firing event the instant it has been setup... do we need another hook?
Cool, nice usage of the special events hooks. :)
--
Brandon Aaron
On Tue, Sep 29, 2009 at 4:37 PM, stephb...@googlemail.com
wrote:
>
>> setTimeout(function(){ .../*your code to fire the event*/... },0);
>
> Hey, that works! Thanks for this tip.
>
> Since the event I made concerns itself with minimising the number of
> timers on a page, I appreciate the irony of having to add one to make
> it work as intended. You can see the result here:
>
> http://webdev.stephband.info/events/frame/
>
> I still reckon this is a good use case for wanting a postSetup hook...
>
> Cheers
> Stephen.
> >
>
--~--~-~--~~~---~--~~
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: Severe memory leak with clone()
DBJ, This is an acceptable thread for the dev list. Memory leaks are very important and the development community is probably best to help figure them out. Lets get back on topic now... Ricardo, I don't believe I've seen anyone else reporting clone leaking... but that doesn't mean it isn't leaking. Would you also please file a ticket ( http://dev.jquery.com/newticket/ ) for this once you are able to create a test-case. This way it doesn't get lost on the mailing list. -- Brandon Aaron On Mon, Sep 28, 2009 at 3:54 AM, DBJDBJ wrote: > > Hi Ricardo, > > Please present the url where the page with your problem/solution is, > and then please repost this in the "jQuery (English )" Google > group ... > > Regards: --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: Are jQuery nightlies intentionally pinned to r6529
Sometimes the nightly script can be flaky and fall behind. -- Brandon Aaron On Tue, Sep 15, 2009 at 8:07 AM, mharen wrote: > > The current nightly from http://code.jquery.com/jquery-nightly.js is > old. Is it intentionally pinned to r6529/2008-08-10? > > /*! > * jQuery JavaScript Library v1.3.3pre > * http://jquery.com/ > * > * Copyright (c) 2009 John Resig > * Dual licensed under the MIT and GPL licenses. > * http://docs.jquery.com/License > * > * Date: 2009-08-10 17:22:31 -0400 (Mon, 10 Aug 2009) > * Revision: 6529 > */ > > > > --~--~-~--~~~---~--~~ 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: position() issue/bug
So I've been thinking about this and it is actually somewhat of an ambiguous use-case. Most things in HTML/CSS are usually considered from their left most and top most sides (bounding box) when thinking of position/dimensions. However, I see the reasoning and desire to handle this inline element differently. Unfortunately the solution isn't very simple and doesn't translate well to the offset and position methods. In other words, offset and position are strictly for calculating the bounding pox position. For this particular use-case of knowing where the text begins within the bounding box you'll need to use the workaround you suggested. -- Brandon Aaron On Fri, Aug 28, 2009 at 10:51 AM, Nikola wrote: > > Hello, > > I believe I may have found an issue with the position() method. > > When getting an element.position().left property using jQuery, if a > link is long enough that it wraps down to another line, the property > will be thrown off. Instead of getting the left of where the link > itself starts, it will instead get the left of the position where the > bounding rectangle of the entire link would end up. > > example here: > http://gavinlynch.name/algorithms/javascript/link_position.html > > > > --~--~-~--~~~---~--~~ 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: Possible bug binding events to iframes window (document works fine)
I believe this is fixed in SVN/jQuery nightlies. However, there is
still an issue with popups... but should work just fine for iframes.
Try the nightly and see if that fixes the issue you are having:
http://code.jquery.com/jquery-nightly.js
--
Brandon Aaron
On Tue, Sep 1, 2009 at 8:22 AM, Henrik T wrote:
>
> Hi!
> Tried this question in jQuery(English) without any response so I am
> hoping for more luck here.
>
> I am using jQuery 1.3.2 and for some reason I am trying to add event
> listeners to windows/documents in iframes (yeah I know...) from the
> parent window and I have run into some problems...
>
> Does anyone know why it's possible to bind a listener to the click
> event of the document in an iframe but not bind a listener to the
> unload event of the window object (contentWindow) in the same iframe?
> At least the unload isn't triggered when the iframe.src is changed.
>
> Since it is possible to bind to the click event of the document in the
> iframe an unload handler will automatically be registered in IE (to
> prevent memory leaks) but this unload handler will not be triggered
> when the iframe.src is changed, which in turn will cause an annoying
> javascript error (permission denied) when you first alter the
> iframe.src and then reload the top window. I have tested with
> "beforeunload" with the same result.
>
> Using win.attachEvent/addEventListener works fine...
>
> $(document).ready(function() {
> $("#clickable").click(function() {
> $("#frame1").attr("src", "frame2.html");
> });
>
> addEvents(window);
>
> });
>
> function addEvents(win) {
> if (win.contentWindow) {
> win = win.contentWindow;
> }
>
> $(win.document).bind("click", function() {alert("click");});
> $(win).bind("unload", function() {alert("unload");});
>
> var frames = win.document.getElementsByTagName("iframe");
> for (var i=0; i < frames.length; i++) {
> addEvents(frames[i]);
> }
>
> }
>
> Click me
>
>
> /Thank you for showing interest
> Henrik
>
> >
>
--~--~-~--~~~---~--~~
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: $()[0] == document // strange !?
This is fixed in jQuery SVN. The only one that still returns the
document is by not passing anything to jQuery: $() => [document] but
all the others you posted return and empty collection.
This is due to backwards compatibility so that $().ready(fn) continues
to work properly.
--
Brandon Aaron
On Fri, Aug 21, 2009 at 1:37 PM, Már Örlygsson wrote:
>
> I just got bitten by an unexpected (for me at least) behaviour of the
> jQuery() function:
>
> $(), $(''), $(0), $(null) and $(undefined), all return a collection
> equal to $(document).
>
> ...this causes weird things to happen when one converts a String to a
> dom, when the string happens to be empty.
>
> Somehow I expected
> $('body').append( $(html) );
>
> to be functionally equivalent to
> $('body').append( html );
>
> Is that an unreasonable expectation, and if not, is it too late to
> fix?
>
>
> --
> Már
> >
>
--~--~-~--~~~---~--~~
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.2 unit test related question
For #1, a form element in IE is actually == form.elements (the
collection of elements within the form)... they are basically
indistinguishable.
For #2, I agree and I often have to look up the documentation for equals.
--
Brandon Aaron
On Thu, Aug 20, 2009 at 6:54 PM, chris
thatcher wrote:
> Hi all,
> We've got envjs passing about 1350 tests with jquery 1.3.2 and in many cases
> the tests that are failing make sense because, for example we haven't
> implemented external stylesheet support, or an ajax get to a local php file
> doesnt make sense. So really there are just a handful of meaningful error
> left.
>
> Below are a couple comment/questions:
> 1. I can't figure out this test...
>
> test("add(String|Element|Array|undefined)", function() {
> ...
> ok( jQuery([]).add( document.getElementById('form') ).length >= 13, "Add
> a form (adds the elements)" );
> });
>
> I'm not able to grep why a form element is treated specially with add, or
> where in the source the single element returned from document.getElementById
> becomes more than a dozen. Its probably something im overlooking but I
> don't see mention of it in the docs, so it's probably a dom property
> specific to forms thats checked for?
>
> (2 & 3 are comments)
> 2. I've noticed that the qunit function equals(a,b,c) is not used very
> consistently to communicate which of a or b is the 'expected' value and
> which is the 'actual' value. this starts to hurt my brain eventually as I
> try to track down issues. I know it's not a big deal.
>
> 3.We are still working on integrating an html compliant parser and/or
> providing a html to xml tidy filter, in the mean time the only error we get
> from the jquery unit tests in that realm is from qunit itself when it does
> the following:
> $('')
>
> though just a few lines above it does close the input tag with
> $('')
>
> so i was thinking this might have been a minor over sight.
>
> Thanks!
> Thatcher
>
>
> --
> Christopher Thatcher
>
> >
>
--~--~-~--~~~---~--~~
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 events binding
It is very simple to accomplish as a plugin:
jQuery.fn.multibind = function( events ) {
var $this = this;
jQuery.each( events, function( name, fn ) {
$this.bind( name, fn );
} );
};
--
Brandon Aaron
On Thu, Aug 6, 2009 at 2:42 PM, Már wrote:
>
>> And what's so bad about just using the normal object notation instead?
>> $(target).bind({
>> 'example.start': new Function(),
>> 'example.stop': new Function()
>> });
>
> Is that possible?
> I can't find it mentioned in the documentation, and after a *brief*
> look at the 1.3.2 source I can't see it there.
>
> Sounds like a neat idea though - at least for a plugin.
>
> --
> Már
> >
>
--~--~-~--~~~---~--~~
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: Difference between JavaScript and JQuery
I'm not sure I understand your question. If you want to know how jQuery implements the Ajax APIs then look here: http://dev.jquery.com/browser/trunk/jquery/src/ajax.js#L157 If you just want to know how to use the jQuery Ajax APIs then look here: http://docs.jquery.com/Ajax -- Brandon Aaron On Tue, Jul 28, 2009 at 8:11 AM, Brajesh wrote: > > Hello All, > I want to know use of Ajax in the JQuery. > > -- > Thanks > Brajesh > > > > --~--~-~--~~~---~--~~ 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: Patch to fix getJSON in a Firefox extension context
On Mon, Jul 27, 2009 at 7:47 PM, Gaël Pasgrimaud wrote: > This should work on all browser since you always have a head tag in a > html document. I don't think HTML 5 requires a head tag to be valid. This article by Remy Sharp seems to agree ( http://html5doctor.com/html-5-boilerplates/ ). -- Brandon Aaron --~--~-~--~~~---~--~~ 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: ajax() with method "PUT" - missing payload
No worries... thanks for creating the ticket. :) -- Brandon Aaron On Fri, Jul 24, 2009 at 4:07 PM, alx wrote: > > Seems like the Trac syntax corrupted my patch. :) > > Should be the line of my original post: > > xhr.send( (type === "POST" || type === "PUT") ? s.data : null ); > > Sorry for the inconvenience. > > -- > alx > On Jul 25, 1:03 am, alx wrote: >> Hi Aaron, >> >> created a ticket with patch:http://dev.jquery.com/ticket/4971 >> >> -- >> alx >> >> On Jul 25, 12:40 am, Brandon Aaron wrote: >> >> >> >> > Could you create a ticket for this? >> >> > -- >> > Brandon Aaron >> >> > On Fri, Jul 24, 2009 at 3:28 PM, alx wrote: >> >> > > Hi, >> >> > > during the update of one of my projects to the latest svn checkout >> > > (r6493) I ran into a confusing problem with the ajax() method. All >> > > calls with method "PUT" don't deliver any payload. Because of this >> > > problem I compared the svn version with latest stable release (1.3.2). >> >> > > 1.3.2 (working): xhr.send(s.data); >> >> > > 1.3.3pre (not-working): xhr.send( (type === "POST") ? s.data : null ); >> >> > > changed(working): xhr.send( (type === "POST" || type === "PUT") ? >> > > s.data : null ); >> >> > > Did I miss something or is this an unintentional behaviour? >> >> > > --- >> > > alx > > > --~--~-~--~~~---~--~~ 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: ajax() with method "PUT" - missing payload
Could you create a ticket for this? -- Brandon Aaron On Fri, Jul 24, 2009 at 3:28 PM, alx wrote: > > Hi, > > during the update of one of my projects to the latest svn checkout > (r6493) I ran into a confusing problem with the ajax() method. All > calls with method "PUT" don't deliver any payload. Because of this > problem I compared the svn version with latest stable release (1.3.2). > > > 1.3.2 (working): xhr.send(s.data); > > 1.3.3pre (not-working): xhr.send( (type === "POST") ? s.data : null ); > > changed(working): xhr.send( (type === "POST" || type === "PUT") ? > s.data : null ); > > > Did I miss something or is this an unintentional behaviour? > > --- > alx > > > --~--~-~--~~~---~--~~ 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: scrollTop - not working
This is now fixed in revision 6494. It was a silly mistake and I
hadn't written proper units tests for these methods yet... revision
6494 also adds the unit tests.
--
Brandon Aaron
On Fri, Jul 24, 2009 at 2:06 PM, jpcx01 wrote:
>
> Karl... $(document).scrollTop() used to work in jQuery 1.3.2. Seems to
> be currently broken in 1.3.3pre (nightly as of yesterday). JQuery UI
> 1.7.2's Dialog component uses $(document).scrollTop() all over the
> place so this bug causes major headaches.
>
> My solution was to paste the scrollTop / scrollLeft code from jQuery
> 1.3.2 into my jQuery 1.3.3 file. This solved my problem, but doesnt
> feel clean or stable.
>
> Anyone know if there's a ticket for this bug created already?
>
> Thanks
>
> On Jul 1, 5:21 am, Karl Swedberg wrote:
>> Hi there. Try $(window).scrollTop() instead.
>>
>> --Karl
>>
>>
>> Karl Swedbergwww.englishrules.comwww.learningjquery.com
>>
>> On Jul 1, 2009, at 3:33 AM, jagadeesh wrote:
>>
>>
>>
>>
>>
>> > how to find scrollTop in jquery?
>>
>> > $(document).ready(function () {
>> > $("body").click(function () {
>> > alert($("body").scrollTop());
>> > });
>> > });
>>
>> > the above code returns only 0.
>> > It seems doctype is not supporting.
>>
>> > > > "http://
>> >www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> >
>
--~--~-~--~~~---~--~~
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: enhancing "closest" delegation
Well specifically context is used in .live(). A .live() event handler
will be bound to the context. However, the .closest() method will look
beyond the context.
The context should limit the actions of jQuery to within the context's children.
--
Brandon Aaron
On Wed, Jul 22, 2009 at 4:28 PM, Jörn
Zaefferer wrote:
>
> Working or not, having public API methods rely on the context-property
> doesn't seem like a great idea - is that the case anywhere else?
>
> Jörn
>
> On Wed, Jul 22, 2009 at 11:32 PM, mike.helgeson
> wrote:
>>
>> That makes a lot of sense, except it does not work. The "context"
>> property of the jquery instance is always equal to the first element
>> when passing in DOM nodes. Unless I am mistaken.
>>
>> On Jul 22, 4:33 pm, Brandon Aaron wrote:
>>> I think it should just stop at the "context" of the jQuery object. So
>>> you'd do this instead:
>>>
>>> $("table").bind("click", function( event ) {
>>> var $td = $(event.target, this).closest("td");
>>>
>>> });
>>>
>>> --
>>> Brandon Aaron
>>>
>>> On Wed, Jul 22, 2009 at 1:07 PM, mike.helgeson
>>> wrote:
>>>
>>> > I propose adding a second argument to the "closest" method that will
>>> > act as the end point for searching up the document tree. It can behave
>>> > just like the "context" argument in the jQuery mother function. It
>>> > will optimize the performance of a common pattern I have seen in my
>>> > own code since the addition o this method.
>>>
>>> > $("table").bind("click",function( event ){
>>> > var $td = $( event.target ).closest("td", this );
>>> > });
>>>
>>> > Because I bound the handler to "table" I do not want to search an
>>> > higher than that element for selector matches. Furthermore, if there
>>> > was a selector match outside of the containing element, it could
>>> > potentially and accidentally be matched.
>>>
>>> >http://dev.jquery.com/ticket/4945
>>>
>>> > Any thoughts?
>> >
>>
>
> >
>
--~--~-~--~~~---~--~~
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: enhancing "closest" delegation
I think it should just stop at the "context" of the jQuery object. So
you'd do this instead:
$("table").bind("click", function( event ) {
var $td = $(event.target, this).closest("td");
});
--
Brandon Aaron
On Wed, Jul 22, 2009 at 1:07 PM, mike.helgeson wrote:
>
> I propose adding a second argument to the "closest" method that will
> act as the end point for searching up the document tree. It can behave
> just like the "context" argument in the jQuery mother function. It
> will optimize the performance of a common pattern I have seen in my
> own code since the addition o this method.
>
> $("table").bind("click",function( event ){
> var $td = $( event.target ).closest("td", this );
> });
>
> Because I bound the handler to "table" I do not want to search an
> higher than that element for selector matches. Furthermore, if there
> was a selector match outside of the containing element, it could
> potentially and accidentally be matched.
>
> http://dev.jquery.com/ticket/4945
>
> Any thoughts?
> >
>
--~--~-~--~~~---~--~~
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.event.special
I agree that return false proved to be the reverse of what most people think it should be. And it does seem inconsistent with the rest of the methods. I believe there are quite a few special events already created though. I say go ahead and fix the issues you've found with the add/remove hooks. I'm going to be slammed on other things for Nokia the next couple of weeks. -- Brandon Aaron On Sat, Jun 20, 2009 at 5:32 PM, Ariel Flesler wrote: > > Hi > > There're a few things I'd like to mention about jQuery.event.special. > > About returning false to keep the native binding... While this has > been around for a while already and it's painful to change stuff like > this, I think it's really counter-intuitive. > We sort of established returning false as a way to abort things > (events, iterations). In this case, you need to return false not to > abort the native binding. > > I can say that every time I used this (not that often) I expected > return false to avoid regular binding. Considering this isn't used all > that much, it wouldn't be THAT painful to change relatively. > > > About the addition of add & remove, I gave a quick look at the code to > see the arguments passed and noticed that if you pass multiple (space- > separated) events to $.event.add and any of those overrides the > handler, then the new handler will be used for the rest of the events. > If more than one return a function, then you keep stacking functions > (even worse). > > This should be fixed asap. I can open a ticket or even fix this > myself, but I'd rather let Brandon handle it I suppose. > > One last small thing, I think: > if ( modifiedHandler && jQuery.isFunction( modifiedHandler ) ) > > Doesn't need to check if modifiedHandler is null, as jQuery.isFunction > should handle null's. Of course you save a function call, but I don't > think it's really critical and we rather keep shorter and clearer > code. > > Cheers > -- > Ariel Flesler > > > --~--~-~--~~~---~--~~ 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: Proposal: All setters take functions
Sweet. No reason not to do it. -- Brandon Aaron On Wed, Jun 3, 2009 at 1:32 PM, Yehuda Katz wrote: > I'd like to submit a patch that lets all setters (val, html, text, etc.) > take a function as the second parameter, like the current .css() and > .attr(). Can anyone see a reason not to do that? > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 > > > > --~--~-~--~~~---~--~~ 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: [selectors] :visible and :hidden seems to be buggy
This has been fixed in SVN and will be in jQuery 1.3.3. :)
--
Brandon Aaron
On Fri, May 22, 2009 at 11:49 AM, Lideln wrote:
>
> Hi all,
>
> I noticed today what seems to be a bug in :visible and :hidden (two
> bugs, actually).
> I don't know if it has already been reported yet, but here they
> are ! :)
>
> 1) bug with :visible
> This seems to work nicely in FF3, but it does not work in IE6 (test
> case : test it on TR elems)
>
> 2) bug with :hidden
> Willing to fix the :visible bad behaviour for IE6 at work, I decided
> to use :hidden instead. But it seems to bug in FF3 (and maybe
> elsewhere, I did not try) : even if elements are displayed, it
> considers them as hidden.
>
> I ended in using css('display') == 'none', but I would love to use
> the :visible and :hidden selectors.
>
> Any thoughts about that ?
>
> Have a nice day !
>
> Kind regards,
>
> Renaud
>
> >
>
--~--~-~--~~~---~--~~
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: height() reporting different value in IE for hidden element
This is a fairly common issue in IE. Empty elements, even if you set a
height of 0, will have a height of it's font-size or line-height.
--
Brandon Aaron
On Thu, May 21, 2009 at 6:15 PM, Eric Martin wrote:
>
> I found this strange issue and wanted to see if 1) anyone else had
> stumbled upon it and 2) if there was a fix for it.
>
> Using jQuery 1.2.6+ (I haven't tested with earlier versions), consider
> these two statements:
>
> $('').appendTo('body').height();
> $('').appendTo('body').hide().height();
>
> In Firefox, both report 0. In IE (6 & 7), the first reports 0, the
> second, some value based on the font size. For example, on my site
> (ericmmartin.com), with IE, I get 0 and 22.
>
> Since it seems that jQuery sets display to none for hide(), it sounds
> like an IE bug.
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: IE8 detecting .is(':visible') incorrectly on tr elements
The difference was not intentional. The intention in keeping them separate is to avoid penalizing one (or both) of them by needing a second function call. However, considering these methods just grew in complexity compared to their current version... I'm more inclined to agree. That is unless the performance difference is worth the duplication? I haven't checked. -- Brandon Aaron On Mon, May 18, 2009 at 7:03 PM, Dave Methvin wrote: > >> It would be adding the following to the current code. > >> ... > > The visible says /^tr$/i.test( elem.tagName ) but hidden says /tr/ > i.test( elem.tagName ), was that intentional? > > Maybe the function for filters.visible could just call and invert the > function for filters.hidden, or vice versa? That would avoid the > application of DeMorgan's law. :) > > > > > --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
It is possible that this is happening on other elements in IE. Perhaps
we could match these known problematic elements and force a check of
the display style. It would be adding the following to the current
code.
Index: src/selector.js
===
--- src/selector.js (revision 6357)
+++ src/selector.js (working copy)
@@ -977,19 +977,21 @@
jQuery.expr[":"] = jQuery.expr.filters;
Sizzle.selectors.filters.hidden = function(elem){
- var width = elem.offsetWidth, height = elem.offsetHeight;
- return ( width === 0 && height === 0 ) ?
+ var width = elem.offsetWidth, height = elem.offsetHeight,
+ force = /tr/i.test( elem.tagName );
+ return ( width === 0 && height === 0 && !force ) ?
true :
- ( width !== 0 && height !== 0 ) ?
+ ( width !== 0 && height !== 0 && !force ) ?
false :
!!( jQuery.curCSS(elem, "display") === "none" );
};
Sizzle.selectors.filters.visible = function(elem){
- var width = elem.offsetWidth, height = elem.offsetHeight;
- return ( width === 0 && height === 0 ) ?
+ var width = elem.offsetWidth, height = elem.offsetHeight,
+ force = /^tr$/i.test( elem.tagName );
+ return ( width === 0 && height === 0 && !force ) ?
false :
- ( width > 0 && height > 0 ) ?
+ ( width > 0 && height > 0 && !force ) ?
true :
!!( jQuery.curCSS(elem, "display") !== "none" );
};
--
Brandon Aaron
On Mon, May 18, 2009 at 5:20 PM, Brandon Aaron wrote:
> Got to excited and spoke to soon. Using clientWidth/Height breaks 1
> unit test in IE7 and 5 in IE6... still need to investigate why.
>
> --
> Brandon Aaron
>
>
> On Mon, May 18, 2009 at 5:14 PM, Brandon Aaron
> wrote:
>> On Mon, May 18, 2009 at 5:07 PM, Brandon Aaron
>> wrote:
>>> Ugh... In IE8, even though the element is display: none, it has a
>>> width and height > 0. So, this still fails for IE. Not sure what other
>>> elements IE8 does this for.
>>>
>>> Thoughts anyone?
>>
>> Looks like clientWidth/Height instead of offsetWidth/Height behave
>> properly in all the browsers, including IE8. I still recommend keeping
>> the current logic in place to guard against ambiguous dimensions.
>>
>> --
>> Brandon Aaron
>>
>
--~--~-~--~~~---~--~~
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: IE8 detecting .is(':visible') incorrectly on tr elements
Got to excited and spoke to soon. Using clientWidth/Height breaks 1 unit test in IE7 and 5 in IE6... still need to investigate why. -- Brandon Aaron On Mon, May 18, 2009 at 5:14 PM, Brandon Aaron wrote: > On Mon, May 18, 2009 at 5:07 PM, Brandon Aaron > wrote: >> Ugh... In IE8, even though the element is display: none, it has a >> width and height > 0. So, this still fails for IE. Not sure what other >> elements IE8 does this for. >> >> Thoughts anyone? > > Looks like clientWidth/Height instead of offsetWidth/Height behave > properly in all the browsers, including IE8. I still recommend keeping > the current logic in place to guard against ambiguous dimensions. > > -- > Brandon Aaron > --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
On Mon, May 18, 2009 at 5:07 PM, Brandon Aaron wrote: > Ugh... In IE8, even though the element is display: none, it has a > width and height > 0. So, this still fails for IE. Not sure what other > elements IE8 does this for. > > Thoughts anyone? Looks like clientWidth/Height instead of offsetWidth/Height behave properly in all the browsers, including IE8. I still recommend keeping the current logic in place to guard against ambiguous dimensions. -- Brandon Aaron --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
Ugh... In IE8, even though the element is display: none, it has a width and height > 0. So, this still fails for IE. Not sure what other elements IE8 does this for. Thoughts anyone? -- Brandon Aaron On Mon, May 18, 2009 at 9:08 AM, John Resig wrote: > This change looks good - it'll probably take a perf hit in some cases, but > that seems to be ok, since those cases were causing problems anyway (such as > when the contents are floated outside of the element). > > --John > > > On Mon, May 18, 2009 at 9:54 AM, Brandon Aaron > wrote: >> >> Unfortunately checking for 0 or > 0 on both is not at straightforward >> as we'd like it to be. There are scenarios where one dimensions can be >> 0 and the element is still "visible". Or in the case of #4512, one >> dimensions can be > 0 and the element is still "hidden". o_O >> >> I've replied on the ticket and attached a patch that fixes these edge >> cases. In summary I use the dimensions check for speed and if the >> result is ambiguous then I fall back to checking the display property. >> >> -- >> Brandon Aaron >> >> >> On Mon, May 18, 2009 at 8:19 AM, Projet Master 104 - Contruction d'un >> portefeuille d'actions wrote: >> > >> > Hi brandon, >> > >> > I've also found this bug on ie6 and post a comment in the bug tracker. >> > >> > 1) I think the following code (jQuery/src/selector.js at line 984) : >> > return elem.offsetWidth > 0 || elem.offsetHeight > 0; >> > should be replaced by : >> > return elem.offsetWidth > 0 && elem.offsetHeight > 0; >> > >> > 2) Moreover, in your previous changeset (6337) the following code : >> > return elem.offsetWidth === 0 || elem.offsetHeight === 0; >> > is replaced by this : >> > return elem.offsetWidth === 0 && elem.offsetHeight === 0; >> > >> > This code will not work on ie6 as TR tr width > 0 even if its display >> > is none. >> > >> > Benoit >> > >> > >> > > >> > >> >> > > > > > --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
Unfortunately checking for 0 or > 0 on both is not at straightforward as we'd like it to be. There are scenarios where one dimensions can be 0 and the element is still "visible". Or in the case of #4512, one dimensions can be > 0 and the element is still "hidden". o_O I've replied on the ticket and attached a patch that fixes these edge cases. In summary I use the dimensions check for speed and if the result is ambiguous then I fall back to checking the display property. -- Brandon Aaron On Mon, May 18, 2009 at 8:19 AM, Projet Master 104 - Contruction d'un portefeuille d'actions wrote: > > Hi brandon, > > I've also found this bug on ie6 and post a comment in the bug tracker. > > 1) I think the following code (jQuery/src/selector.js at line 984) : > return elem.offsetWidth > 0 || elem.offsetHeight > 0; > should be replaced by : > return elem.offsetWidth > 0 && elem.offsetHeight > 0; > > 2) Moreover, in your previous changeset (6337) the following code : > return elem.offsetWidth === 0 || elem.offsetHeight === 0; > is replaced by this : > return elem.offsetWidth === 0 && elem.offsetHeight === 0; > > This code will not work on ie6 as TR tr width > 0 even if its display > is none. > > Benoit > > > > > --~--~-~--~~~---~--~~ 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: #3981 IE 6 & 7 reports incorrect CSS opacity values in jQuery 1.3.1
Sweet. I like more simple (even though I tend to find the more
complicated route). :)
and ... yeah I accidentally removed the check from elem.currentStyle
while I was trying other things. :( Thanks for pointing it out.
--
Brandon Aaron
On Thu, May 14, 2009 at 12:55 PM, Matt Kruse wrote:
>
> On May 14, 9:55 am, Brandon Aaron wrote:
>> Fixed in r6439 (http://dev.jquery.com/changeset/6349).
>
> This seems simpler:
>
> var ret="";
> if ( !jQuery.support.opacity && name=="opacity" && elem.currentStyle )
> {
> if ((elem.currentStyle.filter||'').match(/opacity=(\d+)/)) {
> ret = (parseFloat(RegExp.$1)/100)+'';
> }
> }
>
> since currentStyle will reflect the value being set inline or via a
> css rule. Also, it's necessary to verify that currentStyle exists,
> since it can't be assumed just because the jQuery.support.opacity
> check failed (inferring its existence is just as bad as browser
> detection).
>
> (btw, I tested the above code on a sample case, but not against the
> test suite)
>
> Matt Kruse
>
> >
>
--~--~-~--~~~---~--~~
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: #3981 IE 6 & 7 reports incorrect CSS opacity values in jQuery 1.3.1
Fixed in r6439 ( http://dev.jquery.com/changeset/6349 ). This actually brings up an interesting issue in regards to fixing clear type in IE when using filters. Most people just remove the filter if opacity is set to 1 or 0. However, you really have to double check to make sure it is actually set to 1 or 0 after removing it in-case the style sheet has a different opacity value. In which case it does, you'd have to do some trickery and potentially loose/overwrite the value in the style sheet. -- Brandon Aaron On Thu, May 14, 2009 at 5:20 AM, Jörn Zaefferer wrote: > > I'd like to give this ticket (http://dev.jquery.com/ticket/3981) a > bump, after stumbling about the same problem while trying to animate > an element with fadeIn, which has an opacity value set in a > stylesheet. > > The attached patch fixes the problem in my case. It duplicates parts > of whats already there for parsing the filter value, but otherwise it > looks fine. > > Any reason not to commit it to get it included in 1.3.3? > > 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: $( window.parent.document ).height() throws error from child iframe
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 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 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:
> >
> >
> >
> >
> >
> >
> > 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"
> >
> > }
> >
> > };
> >
> >
> >
> >
> >
> > 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 wrote:
> >
> > > Hello all.
> >
> > > I have two html documents.
> >
> > > (1) parent.html
> >
> > >
> > >
> > >
> > >
> > >
> >
> > > (2) child.html
> >
> > >
> > >
> > > http://ajax.googleapis.com/</a>
> > > ajax/libs/jquery/1.3.2/jquery.min.js">
> > >
> > > 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"
> > >
> > >
> > >
> >
> > > 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: Optional scope for events
Yes, that was left-over code from looking at implementing this feature in a different way (removed now, thanks). We are definitely looking into what it would take to bring this functionality to other methods within the library that use callbacks but wanted to go ahead and get this applied for events due to its popularity. -- Brandon Aaron On Thu, May 7, 2009 at 12:53 PM, Balazs Endresz wrote: > > I've just had a look at r6344 and there seems to be an extra argument > in jQuery.event.add but that function hasn't been modified (yet?). > And maybe it's been mentioned before but if you're really adding this > feature why not do the same with $.each? Hopefully no one uses the > internal `args` argument and it would be at least as useful as for > events. > > On May 5, 3:44 pm, Brandon Aaron wrote: > > How about "thisObject"? Taken from Mozilla's docs for the forEach method > (https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Object... > ). > > -- > > Brandon Aaron > > > > > > > > On Mon, May 4, 2009 at 11:38 PM, Michael Geary wrote: > > > > > I don't find this feature all that useful myself, since my callback > > > functions tend to be a mix of jQuery/DOM, setTimeout, Google > Maps/Earth, > > > and > > > other asynchronous APIs. If I can only bind an object to a callback in > one > > > of those types of APIs and not the others - or if they each sprout > > > independent ways of doing it - I may as well just use a closure so I > have > > > one way to handle them all. > > > > > But I've seen that a lot of people do like this capability, so I > certainly > > > don't object to it, unless of course it slows down my own code. > > > > > My one request: please do not call it "scope"! Not in the code, not in > the > > > comments, and not in the docs. > > > > > JavaScript has something called scope, and you create it by nesting > > > functions lexically (or using the "with" statement). Setting the "this" > > > value for an event or other callback isn't related in the slightest to > > > scope. > > > > > If you need a name for the concept, you could describe it as "binding > an > > > object to the event handler" or - probably better - "calling the event > > > handler as a method of an object". I don't know of a short and sweet > word > > > for it, but "scope" is already taken. :-) > > > > > Thanks, > > > > > -Mike > > > --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
And the ticket is... http://dev.jquery.com/ticket/4512 On Thu, May 7, 2009 at 11:36 AM, Brandon Aaron wrote: > There is an open ticket for this. It is interesting because IE says that > the TR element still has a width > 0 even though it isn't displayed. If you > check the TD of the hidden TR, it is hidden. > -- > Brandon Aaron > > > On Thu, May 7, 2009 at 7:10 AM, Paul Mills wrote: > >> >> Hi, >> I've come across this problem as well. Seems to be an issue >> with :visible selector on tr elements in all versions of IE. >> I think problem was introduced with 1.3.2. Older versions of jQuery >> are OK. >> >> Here's a link to the test page I set up. IE gets the count of visible >> rows wrong. >> http://jsbin.com/axoru >> >> Paul >> >> >> >> > --~--~-~--~~~---~--~~ 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: IE8 detecting .is(':visible') incorrectly on tr elements
There is an open ticket for this. It is interesting because IE says that the TR element still has a width > 0 even though it isn't displayed. If you check the TD of the hidden TR, it is hidden. -- Brandon Aaron On Thu, May 7, 2009 at 7:10 AM, Paul Mills wrote: > > Hi, > I've come across this problem as well. Seems to be an issue > with :visible selector on tr elements in all versions of IE. > I think problem was introduced with 1.3.2. Older versions of jQuery > are OK. > > Here's a link to the test page I set up. IE gets the count of visible > rows wrong. > http://jsbin.com/axoru > > Paul > > > > --~--~-~--~~~---~--~~ 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: Exception Thrown When Getting CSS Value
I believe that is exactly what we are trying to do. There is an ongoing
discussion about how to handle retrieval of CSS shorthand properties in the
ticket 4295 ( http://dev.jquery.com/ticket/4295 ). I think most of the
confusion, at least for me, has been around the use-case for getting the
short-hand. The reason for my first question... trying to understand the
actual need. From this thread (and the ticket) it sounds like maybe the
developer just needs to copy the padding from one element to another.
Reasonable use-case but what about when the developer wants to copy the
"background" property. Isn't it more confusing to support just a subset
versus all the shorthands? Maybe a better solution is to find a better way
to copy CSS from one element to another... if that really is the primary
use-case for supporting CSS shorthand properties.
--
Brandon Aaron
On Wed, May 6, 2009 at 9:36 PM, Matt Kruse wrote:
>
> On May 6, 8:28 pm, Brandon Aaron wrote:
> > Out of curiosity... what are you expecting back from the call to padding
> > when it is different for top/bottom vs left/right?
>
> I think an equally valid question is... what does jQuery intend to do
> in such situations? Clearly, crashing is not the best option.
>
> Anything that causes the code to completely crash should be avoided by
> either checking for valid input (if some inputs are considered
> invalid) or by deciding how to handle cases that don't have obvious
> answers (like this case). It's not enough, IMO, to ignore the tough
> questions of how jQuery should behave and point to an alternative. :)
>
> In the example case:
>
> #foo { padding: 5px 10px; }
>
> you may want to consider returning [5,10,5,10] for example.
>
> Matt Kruse
>
> >
>
--~--~-~--~~~---~--~~
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: Exception Thrown When Getting CSS Value
Out of curiosity... what are you expecting back from the call to padding
when it is different for top/bottom vs left/right? If it returns a string
then you'll have to do your own parsing. If it returns an object, then
you'll have to access each property separately. Also should the return value
be exactly what is in the stylesheet? In this case should it return a string
with two values (top/bottom and left/right)? Why not just request the
padding for the side that you need?
Currently jQuery doesn't support the retrieval of CSS shorthand properties.
You'll need to get the padding for each side separately.
$("div").css("padding-top");
--
Brandon Aaron
On Wed, May 6, 2009 at 8:13 PM, Stephen McKamey wrote:
>
> We've run into an issue where, when a style ("padding" in this case)
> with multiple parts ("5px 3px" in this case) is being set by a
> stylesheet (rather than inline) is accessed in IE6/7/8, jQuery 1.3.2
> causes the exception "Error: Invalid argument." The exception is
> thrown in the middle of "the awesome hack by Dean Edwards" on line
> 835.
>
> Has anyone else experienced this, and is there a known workaround?
>
> Here is a simple example which demonstrates it (in Internet Explorer):
>
>
>
>#foo { padding: 5px 10px; }
>
>http://ajax.googleapis.com/ajax/</a>
> libs/jquery/1.3.2/jquery.js">
>
>$(function() {
>alert($("#foo").css("padding"));
>});
>
>
>
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: Optional scope for events
How about "thisObject"? Taken from Mozilla's docs for the forEach method ( https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:forEach). -- Brandon Aaron On Mon, May 4, 2009 at 11:38 PM, Michael Geary wrote: > > I don't find this feature all that useful myself, since my callback > functions tend to be a mix of jQuery/DOM, setTimeout, Google Maps/Earth, > and > other asynchronous APIs. If I can only bind an object to a callback in one > of those types of APIs and not the others - or if they each sprout > independent ways of doing it - I may as well just use a closure so I have > one way to handle them all. > > But I've seen that a lot of people do like this capability, so I certainly > don't object to it, unless of course it slows down my own code. > > My one request: please do not call it "scope"! Not in the code, not in the > comments, and not in the docs. > > JavaScript has something called scope, and you create it by nesting > functions lexically (or using the "with" statement). Setting the "this" > value for an event or other callback isn't related in the slightest to > scope. > > If you need a name for the concept, you could describe it as "binding an > object to the event handler" or - probably better - "calling the event > handler as a method of an object". I don't know of a short and sweet word > for it, but "scope" is already taken. :-) > > Thanks, > > -Mike > > > > > --~--~-~--~~~---~--~~ 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: Optional scope for events
I still do not agree that this is better achieved by a static bind/hitch
method alone (for jQuery). Just because it is a typical power user feature
doesn't mean we shouldn't make it easily useable by non-power users. But for
me it is more than just catering to various levels of knowledge... it is
also about having cleaner code.
I'd much rather have my code look like this:
$('li').click(function( event ) {
// do some fun stuff here
}, myObj);
Than something like this:
$('li').click( $.bind(function( event ) {
// do some fun stuff here
}, myObj) );
The lack of extra syntax and power user features made easier are a jQuery
features.
--
Brandon Aaron
On Mon, May 4, 2009 at 9:08 AM, pete higgins wrote:
>
> I agree with Ariel, that this would be better served as a static
> method. Dojo does the (fn, scope) (actually, we do a mixmatch and
> allow curried args, but I digress) and it definitely is a learning
> curve for js n00bs, and certainly not very jQuery-ish. by making it a
> separate method, it becomes entirely opt-in for power users and is
> nearly as concise as the proposed further overloading of the existing
> signature.
>
> I ported dojo's .hitch(), which is likely more in line with Ariel's
> statement.
>
> http://higginsforpresident.net/js/jq.hitch.js
>
> My $0.02US
>
> Regards,
> Peter
>
> On Mon, May 4, 2009 at 3:56 PM, Brandon Aaron
> wrote:
> > I don't agree that this is confusing. I find it to be very beneficial to
> > have a method signature that grows to meet your needs but doesn't get in
> > your way when you don't need all of it. I know we've received both insult
> > and praise for our overloaded methods but that is how we roll! :)
> > It might be inconsistent for the moment but we can fix that. This has
> been
> > an oft-requested feature (even by the jQuery UI team) specifically for
> > events. Certainly we'll need to review the other places we use a callback
> > and see if it makes sense to provide an optional alternate scope. I'm all
> > for the pattern of anywhere we provide a callback, an optional scope
> should
> > follow. However, we need to make sure people still have access to the
> actual
> > element.
> > Although just giving everyone a $.bind method is much easier on us, I
> don't
> > think it fits very well into the philosophy of do more, write less. I'd
> also
> > argue that this would be more of a learning curve to some than the
> optional
> > scope param. I'm not adverse to providing both though since we'll most
> > likely need $.bind if we start adding optional scopes to other methods in
> > the API. It would be as simple as exposing another jQuery utility method.
> > Also, I forgot to include the helper methods, like click, in this patch.
> > These would also need include the ajax event methods and probably the
> ready
> > shortcuts.
> > --
> > Brandon Aaron
> >
> > On Mon, May 4, 2009 at 7:12 AM, Ariel Flesler
> wrote:
> >>
> >> I like it... but I think it is confusing and inconsistent.
> >> We add this for events, but why not for animations ? or ajax
> >> requests ?
> >>
> >> Also... you need to document, the 'this' of the handler will be the
> >> currentTarget, UNLESS you passed a scope to bind(). I think features
> >> like this affect the learning curve and confuse novice users.
> >>
> >> As I see it, I'd rather add a static method like $.bind.
> >>
> >> $(...).bind("type", $.bind(scope,fn));
> >>
> >> $.bind should copy the guid ($.event.proxy) so that the returned
> >> function can be unbound using just fn and there's no need to save it
> >> in a var.
> >>
> >>
> >> My $0.02
> >>
> >> Cheers
> >> --
> >> Ariel Flesler
> >> On May 4, 1:47 am, Brandon Aaron wrote:
> >> > Looking for any feedback on #3699 before committing, which is for
> >> > allowing
> >> > an alternative scope for events. There is a patch attached to the
> >> > ticket.
> >> > The ticket actually proposes a method signature that doesn't really
> fit
> >> > jQuery's style. I added a patch that allows the following call
> signature
> >> > instead.
> >> > $(...).bind("type", fn, scope);
> >> > $(...).bind("type", data, fn, scope);
> >> >
> >> > This also applies to .one() and .live().
> >> >
> >> > The patch utilizes the internal event.proxy method with a tweak to
> >> > include
> >> > an optional scope.
> >> >
> >> > --
> >> > Brandon Aaron
> >>
> >
> >
> > >
> >
>
> >
>
--~--~-~--~~~---~--~~
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: Optional scope for events
I don't agree that this is confusing. I find it to be very beneficial to
have a method signature that grows to meet your needs but doesn't get in
your way when you don't need all of it. I know we've received both insult
and praise for our overloaded methods but that is how we roll! :)
It might be inconsistent for the moment but we can fix that. This has been
an oft-requested feature (even by the jQuery UI team) specifically for
events. Certainly we'll need to review the other places we use a callback
and see if it makes sense to provide an optional alternate scope. I'm all
for the pattern of anywhere we provide a callback, an optional scope should
follow. However, we need to make sure people still have access to the actual
element.
Although just giving everyone a $.bind method is much easier on us, I don't
think it fits very well into the philosophy of do more, write less. I'd also
argue that this would be more of a learning curve to some than the optional
scope param. I'm not adverse to providing both though since we'll most
likely need $.bind if we start adding optional scopes to other methods in
the API. It would be as simple as exposing another jQuery utility method.
Also, I forgot to include the helper methods, like click, in this patch.
These would also need include the ajax event methods and probably the ready
shortcuts.
--
Brandon Aaron
On Mon, May 4, 2009 at 7:12 AM, Ariel Flesler wrote:
>
> I like it... but I think it is confusing and inconsistent.
> We add this for events, but why not for animations ? or ajax
> requests ?
>
> Also... you need to document, the 'this' of the handler will be the
> currentTarget, UNLESS you passed a scope to bind(). I think features
> like this affect the learning curve and confuse novice users.
>
> As I see it, I'd rather add a static method like $.bind.
>
> $(...).bind("type", $.bind(scope,fn));
>
> $.bind should copy the guid ($.event.proxy) so that the returned
> function can be unbound using just fn and there's no need to save it
> in a var.
>
>
> My $0.02
>
> Cheers
> --
> Ariel Flesler
> On May 4, 1:47 am, Brandon Aaron wrote:
> > Looking for any feedback on #3699 before committing, which is for
> allowing
> > an alternative scope for events. There is a patch attached to the ticket.
> > The ticket actually proposes a method signature that doesn't really fit
> > jQuery's style. I added a patch that allows the following call signature
> > instead.
> > $(...).bind("type", fn, scope);
> > $(...).bind("type", data, fn, scope);
> >
> > This also applies to .one() and .live().
> >
> > The patch utilizes the internal event.proxy method with a tweak to
> include
> > an optional scope.
> >
> > --
> > Brandon Aaron
> >
>
--~--~-~--~~~---~--~~
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: Optional scope for events
Yes, you can still unbind the named handler. The jQuery.event.proxy method
takes care of this.
--
Brandon Aaron
2009/5/4 Scott González
>
> Would you be able to unbind a specific function with a specific scope?
>
> $(el).bind('click', fn, foo);
> $(el).bind('click', fn, bar);
>
> $(el).unbind('click', fn, foo);
>
>
> On May 4, 12:47 am, Brandon Aaron wrote:
> > Looking for any feedback on #3699 before committing, which is for
> allowing
> > an alternative scope for events. There is a patch attached to the ticket.
> > The ticket actually proposes a method signature that doesn't really fit
> > jQuery's style. I added a patch that allows the following call signature
> > instead.
> > $(...).bind("type", fn, scope);
> > $(...).bind("type", data, fn, scope);
> >
> > This also applies to .one() and .live().
> >
> > The patch utilizes the internal event.proxy method with a tweak to
> include
> > an optional scope.
> >
> > --
> > Brandon Aaron
> >
>
--~--~-~--~~~---~--~~
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] Optional scope for events
Looking for any feedback on #3699 before committing, which is for allowing
an alternative scope for events. There is a patch attached to the ticket.
The ticket actually proposes a method signature that doesn't really fit
jQuery's style. I added a patch that allows the following call signature
instead.
$(...).bind("type", fn, scope);
$(...).bind("type", data, fn, scope);
This also applies to .one() and .live().
The patch utilizes the internal event.proxy method with a tweak to include
an optional scope.
--
Brandon Aaron
--~--~-~--~~~---~--~~
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: Detecting when CSS has loaded
Putting the css before the js doesn't always work. :( -- Brandon Aaron On Sun, May 3, 2009 at 12:57 AM, Kelvin Luck wrote: > > That suggestion has worked for some of my users. But some of them are > still having problems. It may be an issue in my code - I'm trying to find > the time to produce a striped down test case... But for example, visit > this site in Safari or Chrome: > > http://lolkeegan.com/ > > Everything works great on first load and refresh of the main page. But > then if you click the contact tab on the left hand side and then click > back to portfolio then the content is all missing. If you inspect you will > see that jScrollPaneContainer has a massive width and height. Refresh and > everything is fine - the width and height have been correctly copied from > the ul.thumb-gallery style in the stylesheet. The CSS is before the JS on > this page. And the problem is only seen in Webkit browsers. > > Like I said, the problem could be in my plugin code as I've yet to put > together a stripped down example. But when Jake mentioned issues with > ready not indicating CSS was loaded I thought I'd mention my experiences... > > Cheers, > > Kelvin :) > > > On Sat, 02 May 2009 21:21:45 -0700, John Resig wrote: > > > It tried to, in some cases, but in reality its implementation was pretty > > weak. Right now the better solution is to include your stylesheets before > > your jQuery code - which will force the CSS to load before the ready > > event > > occurs. > > > > --John > > > > > > On Sat, May 2, 2009 at 2:49 AM, Kelvin Luck > > wrote: > > > >> > >> So did document ready not wait for CSS to load in 1.2.6 then? When > >> Brandon > >> mentioned that it made sense to me because people started complaining > >> about the problems with jScrollPane shortly after 1.3 was released... > >> > >> On Fri, 01 May 2009 19:53:21 -0700, John Resig > >> wrote: > >> > >> > Unfortunately, it's not that easy - I wasn't able to find a set of > >> > techniques that worked in all browsers that waited for all CSS to load > >> > (save > >> > for the window onload event). > >> > > >> > If anyone has any insight, I'd appreciate it. > >> > > >> > --John > >> > > >> > > >> > On Fri, May 1, 2009 at 4:27 PM, Kelvin Luck > >> > wrote: > >> > > >> >> > >> >> Hmmm... Then I'd be happy if there was another event that waited for > >> CSS > >> >> and I could tell users of my plugin to use that event... Somewhere > >> >> between > >> >> onReady and onLoad... > >> >> > >> >> Kelvin :) > >> >> > >> >> On Fri, 01 May 2009 12:47:35 -0700, Brandon Aaron > >> >> wrote: > >> >> > >> >> > Eh... document.ready waited for CSS to load in 1.2.6 but then you'd > >> >> get a > >> >> > flash of unstyled content in some browsers. It is a very ugly > >> problem. > >> >> > -- > >> >> > Brandon Aaron > >> >> > > >> >> > On Fri, May 1, 2009 at 1:52 PM, Kelvin Luck > > >> >> > wrote: > >> >> > > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> I think that this is the source of a problem that has been > >> reported > >> >> by > >> >> >> some users of my jScrollPane script. It seems that sometimes > >> webkit > >> >> >> based > >> >> >> browsers are not loading the CSS before document ready which is > >> >> breaking > >> >> >> the jScrollPane. When the cache is empty it works as expected. > >> More > >> >> info > >> >> >> in this thread: > >> >> >> > >> >> >> > >> >> >> > >> >> > >> > http://groups.google.com/group/jquery-en/browse_thread/thread/978ef0b2877dac77 > >> >> >> > >> >> >> It would definitely be really useful if either document ready > >> waited > >> >> for > >> >> >> css to load or if there was an alternative event that I could tell > >> >> users > >> >> >> to use when initialising jScrollPane. > >> >> >> > >> >> >> Cheers, > >> >> >> > >> >> >> Kelvin :) > >> >> >> > >> >> >> On Fri, 01 May 2009 08:20:42 -0700, JaffaTheCake > >> >> >> > >> >> >> wrote: > >> >> >> > >> >> >> > > >> >> >> > Hi, > >> >> >> > > >> >> >> > I've been doing some research into how browsers load CSS files > >> and > >> >> how > >> >> >> > they impact on the parsing of script. > >> >> >> > > >> >> >> > A problem I'm having is reading styles of an element, but > >> getting > >> >> >> > incorrect values as the script is (sometimes) running before the > >> >> >> > stylesheets have loaded. > >> >> >> > > >> >> >> > When Firefox & IE encounter a
[jquery-dev] Re: Detecting when CSS has loaded
Eh... document.ready waited for CSS to load in 1.2.6 but then you'd get a flash of unstyled content in some browsers. It is a very ugly problem. -- Brandon Aaron On Fri, May 1, 2009 at 1:52 PM, Kelvin Luck wrote: > > Hi, > > I think that this is the source of a problem that has been reported by > some users of my jScrollPane script. It seems that sometimes webkit based > browsers are not loading the CSS before document ready which is breaking > the jScrollPane. When the cache is empty it works as expected. More info > in this thread: > > > http://groups.google.com/group/jquery-en/browse_thread/thread/978ef0b2877dac77 > > It would definitely be really useful if either document ready waited for > css to load or if there was an alternative event that I could tell users > to use when initialising jScrollPane. > > Cheers, > > Kelvin :) > > On Fri, 01 May 2009 08:20:42 -0700, JaffaTheCake > wrote: > > > > > Hi, > > > > I've been doing some research into how browsers load CSS files and how > > they impact on the parsing of script. > > > > A problem I'm having is reading styles of an element, but getting > > incorrect values as the script is (sometimes) running before the > > stylesheets have loaded. > > > > When Firefox & IE encounter a
[jquery-dev] Re: Ticket #4241 - Namespaced events cause memory leaks (was: Re: Blank jQuery page leaks memory in IE?)
I've fixed the issue with jQuery.event.remove not unbinding namespaced
events but had a very difficult time getting reliable results when testing
the memory leak. Please test r6321 and let me know if this fixes the memory
leak for you.
--
Brandon Aaron
On Sat, Apr 25, 2009 at 3:09 PM, Mike Park wrote:
>
> new thread, as requested (original message below):
> ---
>
> There is definitely a problem with the way jQuery (I'm using 1.3.2)
> handles cleaning up namespaced events (I'm tracing the 'unload' event
> codepath). The problem from what I can tell seems to be in
> jQuery.event.remove:
>
> 2540 // Handle multiple events seperated by a space
> 2541 // jQuery(...).unbind("mouseover mouseout", fn);
> 2542 jQuery.each(types.split(/\s+/), function(index, type){
> 2543 // Namespaced event handlers
> 2544 var namespaces = type.split(".");
> 2545 type = namespaces.shift();
> 2546 var namespace = RegExp("(^|\\.)" + namespaces.slice
> ().sort().join(".*\\.") + "(\\.|$)");
>
> ...during the 'unload' event-handler codepath, this code snippet here
> is expecting the passed in 'types' argument to contain the namespaced
> event-identifier (ex. 'click.foo'), but instead it is getting the
> common event-identifier instead (ex. 'click').
>
> You can firebug-trace this yourselves with the simple examples I put
> up here:
> http://emparq.com/ex/ex-good.html
> http://emparq.com/ex/ex-bad.html
>
> ...you'll notice the only difference between these two examples is
> that one binds 'click.foo' and the other binds 'click'. In the bad
> example, hitting reload constantly will see the process memory useage
> go up (in essense, a leak) due to 'jQuery.event.remove' not properly
> cleaning up the namespaced 'click.foo' event), while the good example
> will not suffer the same results.
>
> I'm still new-ish to jQuery and I'm not ready to hazard a solution
> just yet, but I'm guessing something either needs to be done with the
> way 'jQuery.event.remove' handles the value of the 'types' argument,
> or this code here:
>
> 2531 for ( var type in events )
> 2532 this.remove( elem, type + (types || "") );
>
> ...needs to be modified to properly put those namespaced suffixes back
> into the second argument. I'm not familiar enough with all of the use-
> cases that this function handles, so I don't know which is the best
> approach.
>
> Can anyone else shed some light on this subject?
>
>
> --Mike
> >
>
--~--~-~--~~~---~--~~
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: Massive jQuery + jQuery-UI memory leaks on IE7 and IE8
Actually it is on my list of things to work on today. Can't promise anything will be fixed today but I'll be working on it. :) --Brandon Aaron 2009/4/27 Janne Kytömäki > > I originally reported the problem on another thread (http:// > groups.google.com/group/jquery-dev/msg/52927e5708f3e930), but since > the thread discussed different sorts of IE leaks which may not be > related, I'll start a new one for this particular problem. > > Problem description from original posting: > > --- clip --- > Not sure if this is related, or if the problem is with jquery, jquery- > ui, the way we are using them or just IE, but we too are experiencing > problems with IE and growing memory use. Our application is heavyish, > uses lots of jquery-ui dialogs, and runs within one html page for long > times without reloading. We're starting to have problems with IE (7), > its memory consumption grows quite fast while using the app, and it > quickly becomes sluggish to use. > > I've created a simple test page at http://linux.kytomaki.com/jqtest/. > It creates empty jquery-ui dialogs and then immediately destroys them. > The test uses jquery-svn-trunk rev 6320 and jquery-ui 1.7.1. > > Monitoring memory usage from Windows XP task manager: > > On IE 7 consumption starts from 38M after loading the page. After > creating and destroying a dialog 100 times on one run, the consumption > ends up to 72M. Refreshing the page doesn't seem to have effect on it. > Minimizing and restoring the IE window takes mem to 10M, after which > refresh of the page takes it to 44M. Doing another 100 dialog create- > destroy-cycles takes it to 73M. > > With IE 8, mem usage starts from 21M. 100 create-destroy-cycles takes > it to 55M, so again memory seems to be leaked. This time, page reload > frees some memory bringing it to 30M, but now the page minimize- > restore-trick doesn't to do anything. Freeing memory by reload doesn't > help our case, since the app works within one page that shouldn't be > reloaded. > --- clip --- > > As suggested in the original thread, I've updated the example (http:// > linux.kytomaki.com/jqtest/) with calls to CollectGarbage() and set IE8 > compatibility mode to IE=edge, but the problem remains (and obviously > IE8 compatibility mode wouldn't fix the problem on IE7). > > This problem might be related to bug http://dev.jquery.com/ticket/4241, > also discussed in http://dev.jqueryui.com/ticket/4188 and more > recently in > http://groups.google.com/group/jquery-dev/browse_thread/thread/12ab14b05d3f6cfb. > #4241 hasn't been updated in a while, is it still being investigated? > > Anything else we might try to get around this problem? > > -Janne > > > --~--~-~--~~~---~--~~ 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: Blank jQuery page leaks memory in IE?
According to this jQuery UI ticket it is namespaced events that are causing their leaks. http://dev.jqueryui.com/ticket/4188 http://dev.jquery.com/ticket/4241 -- Brandon Aaron 2009/4/24 Janne Kytömäki > > Not sure if this is related, or if the problem is with jquery, jquery- > ui, the way we are using them or just IE, but we too are experiencing > problems with IE and growing memory use. Our application is heavyish, > uses lots of jquery-ui dialogs, and runs within one html page for long > times without reloading. We're starting to have problems with IE (7), > its memory consumption grows quite fast while using the app, and it > quickly becomes sluggish to use. > > I've created a simple test page at http://linux.kytomaki.com/jqtest/. > It creates empty jquery-ui dialogs and then immediately destroys them. > The test uses jquery-svn-trunk rev 6320 and jquery-ui 1.7.1. > > Monitoring memory usage from Windows XP task manager: > > On IE 7 consumption starts from 38M after loading the page. After > creating and destroying a dialog 100 times on one run, the consumption > ends up to 72M. Refreshing the page doesn't seem to have effect on it. > Minimizing and restoring the IE window takes mem to 10M, after which > refresh of the page takes it to 44M. Doing another 100 dialog create- > destroy-cycles takes it to 73M. > > With IE 8, mem usage starts from 21M. 100 create-destroy-cycles takes > it to 55M, so again memory seems to be leaked. This time, page reload > frees some memory bringing it to 30M, but now the page minimize- > restore-trick doesn't to do anything. Freeing memory by reload doesn't > help our case, since the app works within one page that shouldn't be > reloaded. > > Anything obviously wrong with the test case that might cause the > problem? > > -Janne > > On 23 huhti, 12:11, DBJDBJ wrote: > > I personaly will always call CollectGarbage() on window.unload if page > > is in IE and full IE8 enviuronment is not detected ... > > > > Here is why.I will make it obivous, since hardly anyone bothered to > > read ;o) > > > > http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx > > > > Crucial paragraph for us today : > > > > "... The CLR GC is also mark-n-sweep but it is generational – the more > > collections an object survives, the less often it is checked for > > life. This dramatically improves performance for large-working-set > > applications. Of course, the CLR GC was designed for industrial-grade > > applications, the JScript GC was designed for simple little web > > pages. ... " > > > > So in 2003 M$FT implemented JScript GC for "simple little web > > pages" ... the policy which we are suffering with in 2009, in IE6 and > > IE7. > > > > Also, herehttp:// > blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx > > , we are being convinced that due to numerous patches IE6 and IE7, > > memory leaks have been all sorted , beside a removeChild() problem. > > > > Also herehttp://blogs.msdn.com/heaths/archive/2005/06/06/425709.aspx, > > is another very interesting M$FT text from 2005. Apparently VBscript > > has no memory loss problem at all. Nice to know ;o( And yes, after all > > CollectGarbage() should be called to avoid "deadlocks" ? what " > > deadlocks" ;o( ? > > > > Ok, to put things in perspective, jQuery might find itslef on a > > windows machine. Where it will NOT have IE8 installed and on top of > > that it might NOT run "inside" IE6 or 7 at all. It might run "inside" > > mshta.exe or just as an windows js file. often used together with WMI > > scripting, WSH objects etc ... > > > > Conclusion: jQuery 1.3.2 will have all possible measures in place to > > minimize the IE6 and 7 (or otherwise) memory leaks. Apparently IE8 has > > no leaks. The only problem being that almost *all* companies will not > > have IE8 allowed before the end of 2009 or even latter. > > > > So one should use jQ 1.3.2 with all anti mem leak measures. Nothing > > else can be done. If and when everyone goes IE8 the probem should be > > (will be?) gone. > > > > So to repeat once more : > > I personaly will always call CollectGarbage() on window.unload if page > > is in IE and full IE8 enviuronment is not detected ... > > > > -- DBJ > > > > On Apr 23, 8:46 am, Danny Tuppeny wrote: > > > > > After much messing around, I've come to the conclusion Drip is indeed > > > flawed. If the Explorer toolbar is returning the same results, I can > > > only assume it&
[jquery-dev] Re: bug report: jquery.fn.offset on 1.3.x series + IE6/7 (works fine with 1.2.6)
I think the test pages are broken, maybe missing some styles/js? -- Brandon Aaron On Sat, Apr 4, 2009 at 7:13 PM, Maniquí wrote: > > Hi all. > > This bug seems to affect just IE6/7. So fire it up if you want to do > some quick testing :) > > == Testing environments == > > - Working version (jQuery 1.2.6 + jQuery ScrollTo 1.4.1 + > jQuery.localScroll 1.2.7): > > http://test.rudysmusic.com/electric-guitars/pre-owned/?jquery=1.2.6 > > - Failing version (jQuery 1.3.2 + idem): > > http://test.rudysmusic.com/electric-guitars/pre-owned/?jquery=1.3.2 > > - Working version (jQuery 1.3.2 patched using jQuery.fn.offset from > 1.2.6 + idem) > > http://test.rudysmusic.com/electric-guitars/pre-owned/?jquery=1.3.2-patched > > > == Expected behavior (working with 1.2.6) == > > As you can see, there is an horizontal list of products, and so, the > page is horizontally scrolled. > When clicking on arrows (plain anchor links) between products, the > page scrolls to the corresponing product. That's the magic of scrollTo > + localScroll. > > On the _working version_, if you click on the arrows between products, > page will scroll correctly. > > > == Triggering the bug (working with 1.3.2) == > > On the _failing version_, when you click on the arrows, it will fail > for those anchor links and products that are outside the viewport, > when the page was loaded. > > So, if you have a very wide viewport (a big screen), be sure to click > until the failing behavior is triggered. In other words, the arrows > inside the viewport (when page load) may not fail. > > You will see that the page scrolls erratically for the anchors outside > the viewport. > > == A bug on jquery.fn.offset? == > > I've been talking with Ariel Flesler (jQuery core developer and author > of jQuery scrollTo/serialScroll/localScroll plugin series) and he > suggested me to report it here. > Ariel also suggested me to patch the jquery.fn.offset on 1.3.2 using > the one from 1.2.6. > > == How can I help? == > > Is there anything else I can do to help? > This is my first post here, so sorry if I'm not following any > suggested convention. I've been looking for a "how to" report bugs for > jQuery but haven't found anything. > > Thanks, > Julián Landerreche > > > > --~--~-~--~~~---~--~~ 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] #4562: IE6-IE7: Object doesn't support this property or method
To help identify the issue try reducing the code down even further. Excluding plugins, your own code, commenting out blocks of code until you have the least amount of code required to create the issue. -- Brandon Aaron On Thu, Apr 23, 2009 at 1:23 AM, Zeeshan Khan wrote: > I've asked this in forum..so far no one knows what causing the > problem...you can check it for yourself the problem that i'm facing; > > http://aspspider.info/KhanZeeshan/ > > Check it IE6 & IE7 i chekced it in IE8,FF 3.0 Chorme & safari ti works gr8 > in All browsers xcpt IE6 & IE7. > > Regards; > > Zeeshan Ahmed Khan > > > On Thu, Apr 23, 2009 at 6:40 AM, jQuery wrote: > >> #4562: IE6-IE7: Object doesn't support this property or method >> >> --+- >> Reporter: KhanZeeshan | Owner: >> Type: bug | Status: closed >> Priority: major| Milestone: 1.3.2 >> Component: unfilled | Version: 1.3.2 >> Resolution: invalid |Keywords: Object doesn`t support this >> property or method >> Need: Review | >> >> --+- >> Changes (by dmethvin): >> >> * status: new => closed >> * resolution: => invalid >> >> >> Comment: >> >> This does not have any information that would help identify or fix the >> problem. Please supply a test case, a minimal set of html, css, and >> javascript that demonstrates the problem. Since you're new to jQuery it >> would be best to take these to the discussion forums before opening a >> bug. >> >> -- >> Ticket URL: <http://dev.jquery.com/ticket/4562#comment:1> >> jQuery <http://dev.jquery.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: globalEval in high conflict situations.
Well for example the changes I've made allow you to get the width/height of
a different document/window by passing them into jQuery...
$('iframe').contents().width() // should return the width of the iframe
document
Another example is the css method that use to be restricted to its loaded
window to return computed styles in Firefox.
--
Brandon Aaron
On Wed, Apr 22, 2009 at 4:49 PM, Julian Aubourg wrote:
> Sounds awesome but will it feature a way to change the internal window and
> document references globally for an instance of jQuery? Or is it an
> additional parameter? (just how of curiosity)
>
> 2009/4/22 Brandon Aaron
>
> Just an FYI... yesterday I checked in some patches that enable several
>> window/document dependent methods to work with other windows/documents than
>> the one jQuery is loaded in. I believe there are still some patches to be
>> made but overall jQuery 1.3.3 should operate better under situations like
>> this.
>> --
>> Brandon Aaron
>>
>>
>> On Wed, Apr 22, 2009 at 4:41 PM, Julian Aubourg > > wrote:
>>
>>> Yep, the someone was me. And as Daniel points out, the problem with
>>> sandboxing is that it is permeable but not transparent.
>>> You could go around onstart manipulations by hacking the script (i.e.
>>> point to window.top rather than window) but you'd also have to hack into all
>>> of the script's functionalities (as soon as it involves document
>>> manipulation without any given context -- i.e. a parameter that is the group
>>> of nodes to act on). And, beside, you'd need to hack jQuery itself too.
>>>
>>> But from an engine point of view, I think what could be interesting would
>>> be to have a way to make jQuery sandboxed in an iframe and have its internal
>>> window reference being redirected. Something like a
>>> jQuery.setContextWindow() function. But I'm pretty confident this would mean
>>> quite some refactoring within jQuery itself, wouldn't it? Unless redefining
>>> the window variable within the jQuery main function closure would be enough?
>>>
>>> Anyway, this would make it possible to have an iframe content like this:
>>>
>>>
>>> jQuery.setContextWindow(window.top);
>>>
>>>
>>> The icing on the cake would be to have access to this context window with
>>> something like jQuery.getContextWindow() so that plugins could use it and be
>>> as transparently sandboxed as jQuery itself.
>>>
>>> 2009/4/22 Daniel Friesen
>>>
>>>
>>>> There was someone who did some work on a jQuery JSONP plugin which did
>>>> more than the simple stuff jQuery does, including onerror callbacks. It
>>>> was done using an iframe trick as well.
>>>>
>>>> An iframe is a bit of a possibility.
>>>>
>>>> if( window.jQuery !=== jQuery)
>>>> var iframe = create iframe
>>>> iframe.contentWindow.jQuery = jQuery;
>>>> create script tag and insert
>>>> jQuery(iframe).remove();
>>>>
>>>>
>>>> However the issue with the iframe sandbox is that the document and
>>>> whatnot isn't properly available.
>>>>
>>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>>>
>>>> Andrea Giammarchi wrote:
>>>> > I feel "called in the cause" ... globalEval just evaulate code, if it
>>>> > causes problems, you need a sandbox to run multiple version of jQuery
>>>> > or whatever library (a sandbox for each library) and a manager to
>>>> > delegate tasks to the right sandbox when you need it.
>>>> >
>>>> > What's a sandbox? ... poorly speaking, an iframe and its window object
>>>> > with its global variables (libraries included)
>>>> >
>>>> > Hope this help.
>>>> >
>>>> > Best Regards
>>>> >
>>>> > On Wed, Apr 22, 2009 at 6:22 PM, John Resig >>> > <mailto:jere...@gmail.com>> wrote:
>>>> >
>>>> >
>>>> > Hmm... I do understand your predicament (wanting the
>>>> > dynamically-loaded script to use the right version of jQuery). I'm
>>>> > trying to imagine situations where your change could cause
>>>> potential
>>>> > problems, but I'm not sure, yet.
>>>> >
>>>> > FWIW, this problem also affects getScript when pulling scripts
>>>> fr
[jquery-dev] Re: globalEval in high conflict situations.
Just an FYI... yesterday I checked in some patches that enable several
window/document dependent methods to work with other windows/documents than
the one jQuery is loaded in. I believe there are still some patches to be
made but overall jQuery 1.3.3 should operate better under situations like
this.
--
Brandon Aaron
On Wed, Apr 22, 2009 at 4:41 PM, Julian Aubourg wrote:
> Yep, the someone was me. And as Daniel points out, the problem with
> sandboxing is that it is permeable but not transparent.
> You could go around onstart manipulations by hacking the script (i.e. point
> to window.top rather than window) but you'd also have to hack into all of
> the script's functionalities (as soon as it involves document manipulation
> without any given context -- i.e. a parameter that is the group of nodes to
> act on). And, beside, you'd need to hack jQuery itself too.
>
> But from an engine point of view, I think what could be interesting would
> be to have a way to make jQuery sandboxed in an iframe and have its internal
> window reference being redirected. Something like a
> jQuery.setContextWindow() function. But I'm pretty confident this would mean
> quite some refactoring within jQuery itself, wouldn't it? Unless redefining
> the window variable within the jQuery main function closure would be enough?
>
> Anyway, this would make it possible to have an iframe content like this:
>
>
> jQuery.setContextWindow(window.top);
>
>
> The icing on the cake would be to have access to this context window with
> something like jQuery.getContextWindow() so that plugins could use it and be
> as transparently sandboxed as jQuery itself.
>
> 2009/4/22 Daniel Friesen
>
>
>> There was someone who did some work on a jQuery JSONP plugin which did
>> more than the simple stuff jQuery does, including onerror callbacks. It
>> was done using an iframe trick as well.
>>
>> An iframe is a bit of a possibility.
>>
>> if( window.jQuery !=== jQuery)
>> var iframe = create iframe
>> iframe.contentWindow.jQuery = jQuery;
>> create script tag and insert
>> jQuery(iframe).remove();
>>
>>
>> However the issue with the iframe sandbox is that the document and
>> whatnot isn't properly available.
>>
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>
>> Andrea Giammarchi wrote:
>> > I feel "called in the cause" ... globalEval just evaulate code, if it
>> > causes problems, you need a sandbox to run multiple version of jQuery
>> > or whatever library (a sandbox for each library) and a manager to
>> > delegate tasks to the right sandbox when you need it.
>> >
>> > What's a sandbox? ... poorly speaking, an iframe and its window object
>> > with its global variables (libraries included)
>> >
>> > Hope this help.
>> >
>> > Best Regards
>> >
>> > On Wed, Apr 22, 2009 at 6:22 PM, John Resig > > <mailto:jere...@gmail.com>> wrote:
>> >
>> >
>> > Hmm... I do understand your predicament (wanting the
>> > dynamically-loaded script to use the right version of jQuery). I'm
>> > trying to imagine situations where your change could cause potential
>> > problems, but I'm not sure, yet.
>> >
>> > FWIW, this problem also affects getScript when pulling scripts from
>> an
>> > outside domain (and it can't be fixed used the technique described
>> > here since there's no window of opportunity where the global jQuery
>> > variable could be changed).
>> >
>> > I also note that you only change 'jQuery' and not '$' - it seems
>> like
>> > both would be necessary, in this case.
>> >
>> > But, again, I'm worried about the external affects of manipulating
>> the
>> > global variables.
>> >
>> > --John
>> >
>> >
>> >
>> > On Wed, Apr 22, 2009 at 1:04 PM, Mark Gibson > > <mailto:jollyt...@gmail.com>> wrote:
>> > >
>> > > Hi, I'm using jQuery in a high conflict situation, ie. multiple
>> > > versions of jQuery in one page.
>> > > Unfortunately I have no way around this other than not using the
>> > latest jQuery.
>> > >
>> > > So first off, jQuery 1.2 is loaded and noConflict() called.
>> > > Later, jQuery 1.3.2 is loaded and fed into a closure as such:
>> > >
>> > > (function($) {
>> > >
[jquery-dev] Re: Blank jQuery page leaks memory in IE?
Ahh, thanks. Okay I see the other leaks with this toolbar. I still don't see
the leaks in IE6 though. There are a few other places that we need to null
out some orphaned node references. Couple in Sizzle and a couple in offset.
Should have a patch soon.
--
Brandon Aaron
On Wed, Apr 22, 2009 at 1:48 PM, pete higgins wrote:
>
> We stumbled upon this:
>
> http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx
>
> It seems to be reporting the same type information Drip is. I cannot
> attest to it's accuracy, but it claims as of trunk (it is still in
> svn, right?) [6319] I see "leaked" elements listed:
>
>
>
> <div>
> + <a>
> <html>
> + <div>
>
> (the + is to indicate [i presume] the leaked node is within some other
> node?)
>
> My testcase is:
>
> <html><head>
><script src="jquery.min.js">yo
>
> hi
>
> Prior to svn up'ing just now, It was leaking the "full list" the original
> post.
>
> Also, unless I'm missing something, I am seeing 91 IE6 unit tests
> failures in tests/
>
> Regards,
> Peter
>
> On Wed, Apr 22, 2009 at 12:32 PM, Danny Tuppeny
> wrote:
> >
> > Thanks for the response Henry. I was wondering myself if pseudo-leaks
> > were being misreported, but I didn't get chance today to test this
> > outside of Drip.
> >
> > I'll see if I can reproduce this outside Drip using TaskManager and if
> > I can still reproduce, I'll post a new thread with a test case and
> > more details.
> >
> >
> >
> >
> > On Apr 22, 1:47 pm, Henry wrote:
> >> On Apr 22, 9:01 am, Danny Tuppeny wrote:
> >>
> >>
> >>
> >>
> >>
> >> > Here's a small sample page that seems to leak in the same
> >> > way as jQuery:
> >>
> >> >
> >> > function leakMe() {
> >> > var div = document.createElement("div");
> >> > document.body.appendChild(div);
> >> > document.body.removeChild(div);}
> >>
> >> >
> >>
> >> > The docs for Drip say that removeChild is just a psuedo-leak
> >> > and will be cleaned up when the page is unloaded, but that
> >> > doesn't happen. If you set the above page to Auto-refresh
> >> > in Drip, memory usage just goes up and up forever. If you
> >> > can find a way to stop that happening in the small sample,
> >> > I suspect fixing jQuery will be easy.
> >>
> >> There is a problem here but I suspect that problem is with Drip and
> >> not IE or JQuerry (there may be problems with IE and/or JQuery but if
> >> so they are not being demonstrated here).
> >>
> >> Starting with the following more extreme example of the - appendChild
> >> -, - removeChild - sequence; appending 100,000 DIVs, stopping with an
> >> - alert - (to give the opportunity for garbage collection to run and
> >> memory use to be examined), removing all of those DIVs from the DOM,
> >> stopping again, and then repeating/looping the process, should, if the
> >> memory leak issue exists (in relation to - removeChild - use) result
> >> in ever increasing memory consumption, which should be noticeable
> >> using crude examination techniques (such as reading the iexplorer
> >> process's "Mem Usage" in Task Manage) due to the number of DIVs
> >> created. However, using this test page:-
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> function createDivs(){
> >> var div;
> >> for(var c = 0;c < 10;++c){
> >> div = document.createElement('DIV');
> >> document.body.appendChild(div);
> >> }
> >> alert('Divs set');
> >> setTimeout(clearDom, 3000);
> >>
> >> }
> >>
> >> window.onload = createDivs;
> >>
> >> function clearDom(){
> >> while(document.body.lastChild){
> >> document.body.removeChild(document.body.lastChild);
> >> }
> >> alert('Divs cleared');
> >> setTimeout(createDivs, 3000);}
> >>
> >>
> >>
> >>
> >>
> >> (The 3 second delay between function calls is to give you time to
> >> close the browser when enough has been seen)
> >>
> >> - running in IE 6 (on XP) gives an oscillating
[jquery-dev] Re: Blank jQuery page leaks memory in IE?
On Apr 22, 2:44 am, Danny Tuppeny wrote: > Thanks Brandon, > > But this solution already came up, and does not seem to fix anything. > According to Drip, the same 11 elements leak on jQuery startup even > with your change. Could you attach your test case to the ticket? I'm not seeing any leaks caused by jQuery (SVN build) at runtime anymore. -- Brandon Aaron --~--~-~--~~~---~--~~ 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: Blank jQuery page leaks memory in IE?
I'm not seeing the memory usage continue to climb. It fluctuates but
doesn't climb. I added a for loop to try and make the results more
obvious...
function leakMe() {
for( var i=0; i<1000; i++ ) {
var div = document.createElement("div");
document.body.appendChild(div);
document.body.removeChild(div);
}
}
--
Brandon Aaron
On Apr 22, 3:01 am, Danny Tuppeny wrote:
> Here's a small sample page that seems to leak in the same way as
> jQuery:
>
>
> function leakMe() {
> var div = document.createElement("div");
> document.body.appendChild(div);
> document.body.removeChild(div);}
>
>
>
> The docs for Drip say that removeChild is just a psuedo-leak and will
> be cleaned up when the page is unloaded, but that doesn't happen. If
> you set the above page to Auto-refresh in Drip, memory usage just goes
> up and up forever. If you can find a way to stop that happening in the
> small sample, I suspect fixing jQuery will be easy.
--~--~-~--~~~---~--~~
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: Blank jQuery page leaks memory in IE?
FYI... I just committed r6130 a fix for the memory leaks at runtime. Please let me know if you find anymore leaks. -- Brandon Aaron On Apr 16, 8:18 am, Danny Tuppeny wrote: > Hi all, > > I've been using Drip to try and track down some memory leaks in my > app, but as I started stripping code out, I discovered a simple blank > page including jQuery seems to leak. The elements seem to be all those > created by the jquery.support object (script, a, divs). > > Happens in IE7 and IE8. If you run Drip on the jquery.com homepage > you'll see all the elements leaked. > > Is this a known issue? Is there any ETA for a fix? > > Our application is likely to be open in a browser for the entire day > (with lots of page loads), so we're keen to plug any leaks. I can > provide more info if needed, but just running Drip 0.5 on the > jquery.com homepage should show what I'm talking about. --~--~-~--~~~---~--~~ 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: [PATCH] jQuery, nbsp and firefox when serving application/xhtml+xml
Could you create a ticket for this so that it doesn't get lost on the mailing list. http://dev.jquery.com/newticket/ -- Brandon Aaron On Tue, Apr 21, 2009 at 6:19 AM, Sebastien Lambla wrote: > Hi, > > > > I’ve struggled for a couple of hours yesterday with firefox really not > liking my site served as xhtml 1.1. Took me a while to track down the > multitude of plugins and scripts that inject > > > > The problem comes from firefox not parsing external character references in > all situations. Whenever an html fragment gets inserted by firefox, and it > contains such character entity, all hell breaks loose and script processing > stops. > > > > So I’ve attached a patch that changes the uses of nbsp to the character > code. That said, I think it’d be much better for compat if the jquery > codebase as a whole was updated to never use any character entity beyond the > 5 xml defined ones. It certainly would’ve solved the problems I encountered. > > > > Stuff not included: widgets, any test code, and datepicker localization. > > > > Hope it helps. Keep up the good work. > > > > Seb > > > > --~--~-~--~~~---~--~~ 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 doesn't support dimensions-related methods when the body is positioned
On Thu, Apr 9, 2009 at 1:54 PM, Matt Kruse wrote: > > On Apr 9, 1:42 pm, Brandon Aaron wrote: > > Unfortunately it just isn't as simple as that. A positioned body element > > directly affects how the browser calculates the offsetTop/Left properties > of > > child elements. > > In what cases? Just curious. > > I suppose it depends on the browser and the exact layout/objects in > question, but I've used this solution several times and it's been > sufficient for me. It may be enough for the OP. It has been awhile since I last looked into this issue... so I don't have specifics off-hand. It usually relates to the border of elements. It is of course going to depend on your HTML structure and CSS (position, border, etc). I used to fix some of these issues like border and position on the body element when offset was a part of the dimensions plugin only. The extra code, overhead, and maintenance issues it caused was not worth it considering how edge case this is and that it has such a simple workaround. If anyone else wants to look into it... feel free to look under test/data/offset/ in jQuery SVN to find the tests for the offset method. Add body position to see how it reacts in the different browsers for the different tests. As I said, it has been a while and perhaps I just missed something back in the day. Maybe I can find the time to re-evaluate the issue as well. -- Brandon Aaron --~--~-~--~~~---~--~~ 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 doesn't support dimensions-related methods when the body is positioned
On Thu, Apr 9, 2009 at 1:04 PM, Matt Kruse wrote: > > On Apr 9, 6:36 am, Fernando Ferreira > wrote: > > In the jquery-ui-dev thread, I was informed that this is > > a deliberated shortcoming, and that "jQuery doesn't support > > dimensions-related methods when the body is positioned". Is that so? > > Just write your own function that uses jquery's return value and adds > in your calculations for your offset body. Unfortunately it just isn't as simple as that. A positioned body element directly affects how the browser calculates the offsetTop/Left properties of child elements. -- Brandon Aaron --~--~-~--~~~---~--~~ 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: $('#inputElement').text() returns empty string and a solution for it
Remember our documentation is partly community driven. If you feel something
is not explained well or there is an error. Please register on the wiki and
contribute! :)
--
Brandon Aaron
On Tue, Apr 7, 2009 at 9:28 PM, DBJDBJ wrote:
>
> For a software library as prominent as jQ this is not good enough, I
> am affraid.
> Beside input, there is textarea element, attribute is not called "val"
> but "value",
> etc ...
>
> --DBJ
>
> On Apr 7, 5:27 pm, Chuck Harmston wrote:
> > It actually is in the documentation:
> > "The result is a string that contains the combined text contents of all
> > matched elements. This method works on both HTML and XML documents.
> Cannot
> > be used on input elements. For input field text use the val attribute."
> >
> > (Fromhttp://docs.jquery.com/Attributes/text)
> >
> > Chuck Harmstonhttp://chuckharmston.com
> > no-s...@chuckharmston.com
> >
> > On Tue, Apr 7, 2009 at 12:09 PM, DBJDBJ wrote:
> >
> > > Very good comment Thomas.
> > > Documentation should indeed mention when and why to use .text()
> > > and .val().
> > > In my experience, 99% of jQuery novices do the same mistake.
> > > I suppose they are used to jQuery benign attitude and expect that
> > > jQuery "knows" what to do if one call's .text() on the input element.
> > > Novices subconsciously, expect form jQ to automagically return the
> > > value of the "value" attribute, or some simillar "magic" if element is
> > > input or textarea etc. So the jQ doc has to be clear this is not what
> > > will happen.
> >
> > > And of course, tutorial needs to explain the reasoning of
> > > allowing jQ code like this :
> >
> > > $().text()
> >
> > > --DBJ
> >
> > > On Apr 6, 5:14 pm, Thomas White wrote:
> > > > Chuck,
> >
> > > > Thank you very much for your detailed explanation.
> > > > I was so exited about jQuery last couple of days, that I spent most
> of my
> > > > time using it and very little time was left for reading the
> documentation
> > > > ;-).
> > > > It could be a good idea to include in the documentation for .text(),
> a
> > > > reference to .val() function stating the deference as you explained
> it.
> > > That
> > > > will help other people not going into the same confusion as I did.
> >
> > > > Regards,
> > > > Thomas
> > > > 2009/4/6 Chuck Harmston
> >
> > > > > Hello Thomas!
> >
> > > > > Welcome to the world of jQuery!
> >
> > > > > The .text() function is not intended to be used on input elements.
> It
> > > > > is designed to return the text (with HTML removed) of the contents
> of
> > > > > an HTML tag.
> >
> > > > > For example:
> >
> > > > > Hello world
> >
> > > > > $('p').text() would return "Hello world"
> > > > > $('p').html() would return "Hello world"
> >
> > > > > Since 's DOM element does store the inputted content in the
> DOM
> > > > > tree, a different method needs to be used to access it. Try using
> > > > > $('#inputElement').val():
> >
> > > > >http://docs.jquery.com/Attributes/val
> >
> > > > > Additionally, $('#inputElement').attr('value') would achieve the
> same
> > > > > effect.
> >
> > > > > Chuck Harmston
> > > > >http://chuckharmston.com
> >
> > > > > On Mon, Apr 6, 2009 at 4:30 AM, Thomas
> wrote:
> >
> > > > > > Dear jQuerians,
> >
> > > > > > I have learned about jQuery a couple of days and now I am using
> it
> > > all
> > > > > > over my code ;-).
> >
> > > > > > I have a problem and a solution.
> >
> > > > > > Then I use $('#inputElement').text() to get the value of an
> input
> > > > > > element, I receive an empty string. It turns out it is because:
> > > > > > 1) the text function is extracting the text only from the
> children
> > > > > > nodes.
> > > > > > 2) .nodeValue is used to get the content of the DOM node that in
> > > case
> > > > > > of INPUT element returns an empty string.
> >
> > > > > > The solution I am proposing is to here
> > > > >http://paste.pocoo.org/show/111208/
> > > > > > It deals with two cases - when there are children elements or not
> and
> > > > > > it checks for bouth .value attribute and .nodeValue attributes.
> >
> > > > > > I hope this will help.
> >
> > > > > > Regards,
> > > > > > Thomas
> >
> > > > --
> > > > Thomas White
> >
> > > > Mobile:+44 7711 922 966
> > > > Skype: thomaswhite
> > > > gTalk: thomas.0007
> > > > Linked-In:http://www.linkedin.com/in/thomaswhite0007
> >
>
--~--~-~--~~~---~--~~
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: Centering on the viewport
Could you show me the markup of the page that you are having these issues
on?
--
Brandon Aaron
On Wed, Apr 1, 2009 at 5:54 AM, Julian Aubourg wrote:
> I don't know if something changed with the 1.3.2 version shared on google
> but the viewport size is now correct Oo.
> Anyway, I have a couple more problems (though I found workarounds). They
> are all IE only (tested on IE7):
>
> 1) $(window).scrollTop() and .scrollLeft() do not work. You have to do
> $("html").scrollTop() & .scrollLeft() respectively.
> 2) element.offset() doesn't take scrolls into account (I'm pretty confident
> it is linked to bug #1). So you have to manually add $("html").scrollTop() &
> .scrollLeft() to have the correct coords.
>
> -- Julian
>
> 2009/3/30 Brandon Aaron
>
>> You could pull in the window logic from 1.2.6 (
>> http://dev.jquery.com/browser/tags/1.2.6/src/core.js#L1338 ) into the
>> 1.3.2 release (
>> http://dev.jquery.com/browser/tags/1.3.2/src/dimensions.js#L25 ).
>> --
>> Brandon Aaron
>>
>>
>> On Mon, Mar 30, 2009 at 3:48 PM, Julian Aubourg > > wrote:
>>
>>> Thanks for the quick answer Brandon.
>>> And yes, I can live with a nightly build though, as you can imagine, the
>>> client is like not understanding what's taking so long (go explain the joy
>>> of version migration to a client!). Any timeframe? I could also live with an
>>> ugly workaround until it's done if you happen to have one.
>>>
>>> -- Julian
>>>
>>> 2009/3/30 Brandon Aaron
>>>
>>> There is a bug open on window dimensions in jQuery 1.3.x... Unfortunately
>>>> it looks like we have a gap in unit tests that allowed this regression to
>>>> occur. It looks like it happened in r5985. It will be fixed for the 1.3.3
>>>> release but I'm unsure when that release will happen right now. I should be
>>>> able to allocate some time to fix this issue soon though if you don't mind
>>>> using a nightly build once it is fixed.
>>>> --
>>>> Brandon Aaron
>>>>
>>>>
>>>> On Mon, Mar 30, 2009 at 2:14 PM, Julian Aubourg <
>>>> aubourg.jul...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>> I'm in the process of migrating a site from 1.2.7 to 1.3.2.
>>>>>
>>>>> So far, I just ran into a bug in webkit browsers that forced me to
>>>>> rewrite "expr1, expr2, ... exprN" selectors into loops (I suppose you're
>>>>> aware of this one).
>>>>> I also have trouble with attaching event handlers to dynamically
>>>>> created elements, but I guess it's all a question of timing (and probably
>>>>> the correct spot to look into $.live() ).
>>>>>
>>>>> Anyway, I had some simple code to get the position for a div to appear
>>>>> at the center of the viewport:
>>>>>
>>>>> getCenterPosition: function(targetWidth,targetHeight) {
>>>>> var win = $(window);
>>>>> var target = {
>>>>> top: Math.round((win.height()-targetHeight)/2)+win.scrollTop(),
>>>>> left: Math.round((win.width()-targetWidth)/2)+win.scrollLeft()
>>>>> }
>>>>> if (target.top<0) target.top = 0;
>>>>> if (target.left<0) target.left = 0;
>>>>> return target;
>>>>> },
>>>>>
>>>>> It was cross-browser and quite simple indeed.
>>>>>
>>>>> Problem is, in 1.3.2, windows dimensions are those of the whole body,
>>>>> not just the viewport. I turned the code upside/down but just can't find
>>>>> the
>>>>> proper mean to do the exact same thing with the changes that probably
>>>>> occured at 1.3.0.
>>>>>
>>>>> Since you all know the internals of jQuery, I guess this is as good a
>>>>> place to ask for ideas or pointers.
>>>>>
>>>>> Take care all,
>>>>>
>>>>> -- Julian
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: Centering on the viewport
You could pull in the window logic from 1.2.6 (
http://dev.jquery.com/browser/tags/1.2.6/src/core.js#L1338 ) into the 1.3.2
release ( http://dev.jquery.com/browser/tags/1.3.2/src/dimensions.js#L25 ).
--
Brandon Aaron
On Mon, Mar 30, 2009 at 3:48 PM, Julian Aubourg wrote:
> Thanks for the quick answer Brandon.
> And yes, I can live with a nightly build though, as you can imagine, the
> client is like not understanding what's taking so long (go explain the joy
> of version migration to a client!). Any timeframe? I could also live with an
> ugly workaround until it's done if you happen to have one.
>
> -- Julian
>
> 2009/3/30 Brandon Aaron
>
> There is a bug open on window dimensions in jQuery 1.3.x... Unfortunately
>> it looks like we have a gap in unit tests that allowed this regression to
>> occur. It looks like it happened in r5985. It will be fixed for the 1.3.3
>> release but I'm unsure when that release will happen right now. I should be
>> able to allocate some time to fix this issue soon though if you don't mind
>> using a nightly build once it is fixed.
>> --
>> Brandon Aaron
>>
>>
>> On Mon, Mar 30, 2009 at 2:14 PM, Julian Aubourg > > wrote:
>>
>>> Hi all,
>>> I'm in the process of migrating a site from 1.2.7 to 1.3.2.
>>>
>>> So far, I just ran into a bug in webkit browsers that forced me to
>>> rewrite "expr1, expr2, ... exprN" selectors into loops (I suppose you're
>>> aware of this one).
>>> I also have trouble with attaching event handlers to dynamically created
>>> elements, but I guess it's all a question of timing (and probably the
>>> correct spot to look into $.live() ).
>>>
>>> Anyway, I had some simple code to get the position for a div to appear at
>>> the center of the viewport:
>>>
>>> getCenterPosition: function(targetWidth,targetHeight) {
>>> var win = $(window);
>>> var target = {
>>> top: Math.round((win.height()-targetHeight)/2)+win.scrollTop(),
>>> left: Math.round((win.width()-targetWidth)/2)+win.scrollLeft()
>>> }
>>> if (target.top<0) target.top = 0;
>>> if (target.left<0) target.left = 0;
>>> return target;
>>> },
>>>
>>> It was cross-browser and quite simple indeed.
>>>
>>> Problem is, in 1.3.2, windows dimensions are those of the whole body, not
>>> just the viewport. I turned the code upside/down but just can't find the
>>> proper mean to do the exact same thing with the changes that probably
>>> occured at 1.3.0.
>>>
>>> Since you all know the internals of jQuery, I guess this is as good a
>>> place to ask for ideas or pointers.
>>>
>>> Take care all,
>>>
>>> -- Julian
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: Centering on the viewport
There is a bug open on window dimensions in jQuery 1.3.x... Unfortunately it
looks like we have a gap in unit tests that allowed this regression to
occur. It looks like it happened in r5985. It will be fixed for the 1.3.3
release but I'm unsure when that release will happen right now. I should be
able to allocate some time to fix this issue soon though if you don't mind
using a nightly build once it is fixed.
--
Brandon Aaron
On Mon, Mar 30, 2009 at 2:14 PM, Julian Aubourg wrote:
> Hi all,
> I'm in the process of migrating a site from 1.2.7 to 1.3.2.
>
> So far, I just ran into a bug in webkit browsers that forced me to rewrite
> "expr1, expr2, ... exprN" selectors into loops (I suppose you're aware of
> this one).
> I also have trouble with attaching event handlers to dynamically created
> elements, but I guess it's all a question of timing (and probably the
> correct spot to look into $.live() ).
>
> Anyway, I had some simple code to get the position for a div to appear at
> the center of the viewport:
>
> getCenterPosition: function(targetWidth,targetHeight) {
> var win = $(window);
> var target = {
> top: Math.round((win.height()-targetHeight)/2)+win.scrollTop(),
> left: Math.round((win.width()-targetWidth)/2)+win.scrollLeft()
> }
> if (target.top<0) target.top = 0;
> if (target.left<0) target.left = 0;
> return target;
> },
>
> It was cross-browser and quite simple indeed.
>
> Problem is, in 1.3.2, windows dimensions are those of the whole body, not
> just the viewport. I turned the code upside/down but just can't find the
> proper mean to do the exact same thing with the changes that probably
> occured at 1.3.0.
>
> Since you all know the internals of jQuery, I guess this is as good a place
> to ask for ideas or pointers.
>
> Take care all,
>
> -- Julian
>
> >
>
--~--~-~--~~~---~--~~
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: Inserting content with each?
That is correct and to add to the solution... I'd recommend caching the
results of the ul selector and leaving out the 'div' part unless it is
necessary.
var $img = $('.gallery img'), $ul = $('#bild_spel ul');
$img.each(function() {
$ul.append(this);
});
--
Brandon Aaron
On Mon, Mar 30, 2009 at 6:52 AM, Gilles wrote:
>
> For some reason your answer doesn't show on here. You might have mail
> me directly, anyway if you want to insert the element straight away
> instead of creating a new image element maybe the fact that you are
> mixing string variable and an object in your appen() might cause the
> problem.
>
> In your code if you alert this you will see that it isn't src=".."> but an object, an image tag object, so i think your code
> fail because you are tying to append a string and an object together.
>
> this is not a string. Try appending this on its own and see which
> result it gives.
>
> This should work (also wont be wrapped in )
>
> var img = $(".gallery img");
> $(img).each(function() {
> $("#bild_spel div ul").append(this);
>
> });
>
> You'll just need to wrap it in your somewhere else
>
> On Mar 30, 12:17 pm, Gilles wrote:
> > Might want to try something like this instead:
> >
> > $(".gallery img").each(function()
> > {
> > $('#bild_spel div ul').append('');
> >
> > });
> >
> > haven't tested it but I believe it's correct :)
> >
> > On Mar 30, 11:48 am, smurkas wrote:
> >
> > > Hello.
> >
> > > I have a situation where I have grabbed a couple of images off a page
> > > and want to insert them again into an unordered list. Grabbing the
> > > images was no problem but I don't know what to write when inserting
> > > them again.
> > > The code below does not result in the images being inserted again,
> > > instead each list item contains
> > > [object HTMLImageElement] as text. I also tried wrapping this in $
> > > (this) but that didn't work either. The solution is probably dead
> > > simple but right now I am missing it. Can anyone help me out?
> >
> > > var img = $(".gallery img");
> > > $(img).each(function() {
> > > $("#bild_spel div ul").append(''+this+'');
> >
> > > });
> >
> > > 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: suggestion: delayed related AJAX requests
Just to add another use case of such methods... I recently wrote a delayed
mousemove special event that does similar functionality. I plan on
extracting the throttle/debounce functionality into its own plugin for
use-cases such as this ajax one.
--
Brandon Aaron
On Sat, Mar 28, 2009 at 1:53 AM, oliver wrote:
>
> Quick passes:
>
> jQuery.delay = function(callback, delay) {
>var timeout;
>return function() {
>clearTimeout(timeout);
>timeout = setTimeout(callback, delay);
>}
> }
>
> jQuery.throttle = function(callback, delay) {
>var prev = new Date().getTime() - delay;
>return function() {
>var now = new Date().getTime();
>if (now - prev > delay) {
>prev = now;
>callback.call();
> }
>}
> }
>
>
> On Mar 27, 11:38 pm, oliver wrote:
> > I agree that this is a common use case, and also that it would be
> > better implemented as an optional parameter to ajax rather than a
> > wholly separate method.
> >
> > I find I also use similar code within animations, so perhaps the code
> > could be implemented in such a way as to also be exposed as a utility
> > function.
> >
> > Perhaps: $.delay(function, delay) - returns a function handler which
> > can be called many times, but the registered function will only fire
> > once, [delay] milliseconds after the last time it was called. The
> > innards of the function would be mostly as Miloš has above.
> >
> > A potentially useful corollary might be: $.throttle(function, delay) -
> > returns a function handler which could be called as many times as
> > desired, but the registered function would only fire every [delay]
> > millis at most.
> >
> > Names are just off the top of my head, of course.
> >
> > oliver
> >
> > On Mar 27, 3:27 pm, Daniel Friesen wrote:
> >
> >
> >
> > > Rather than an entire other function, what about just a {delay: ms} to
> .ajax
> >
> > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
> >
> > > Miloš Rašić wrote:
> > > > Here's a suggestion for a feature that I think would be useful to
> AJAX
> > > > developers. Sometimes, we need an AJAX feature that could allow a
> user
> > > > to cause a large number of consequent AJAX requests, for example in
> > > > auto-complete for searches (like Google Suggest) or filter forms that
> > > > submit whenever something is changed in them. In a case like this,
> > > > especially when the user has a slow internet connection, we have no
> > > > way of knowing if the AJAX responses will arrive in the same order as
> > > > the requests were sent. A solution to this is to wait for some time
> to
> > > > make sure that the user has stopped manipulating the controls that
> > > > cause AJAX requests before sending a request. At the moment, I do it
> > > > like this:
> >
> > > >function submit_filter() {
> > > >$('#item_list').html('loading...');
> > > >$.post('some url',$('#filter').serialize(),function(data)
> {
> > > >$('#item_list').html(data);
> > > >});
> > > >return false;
> > > >}
> >
> > > >$('.ajax_control').change(function() {
> > > >clearTimeout(ajaxTimeout);
> > > >ajaxTimeout = setTimeout(submit_filter,2000);
> > > >});
> >
> > > > Basically, whenever a control is changed a timeout for ajax request
> is
> > > > reset to 2 seconds. A request is sent only when a user changes
> > > > something an hasn't made new changes last 2 seconds.
> >
> > > > Since this is a frequent use case, it would be great if there would
> be
> > > > a $.post_delayed() function which would have additional 2 parameters:
> > > > an id, which would be used to identify related controls, and a time
> > > > interval to wait before submitting the request.
> >
>
--~--~-~--~~~---~--~~
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: Set offset
Yeah, the core version would be much more simple than that ... I envision it
being very similar to Dan's plugin.
--
Brandon Aaron
2009/3/21 Scott González
>
> We're building this into jQuery UI, most likely for 1.8 (
> http://wiki.jqueryui.com/PositionTo ). We should figure out what
> parts can/should go into core and what should go into jQuery UI.
>
>
> On Mar 20, 8:35 pm, Brandon Aaron wrote:
> > Cool. I'll take a look at this soon. We might also want to make
> .position()
> > a setter at the same time. I've gone ahead and added it to the list of
> > potential features for 1.4.
> http://docs.jquery.com/JQuery_1.4_Roadmap#Offset
> > --
> > Brandon Aaron
> >
> > On Fri, Mar 20, 2009 at 6:49 PM, DanB wrote:
> >
> > > Currently you can't set the offset of jquery by passing in an object
> > > with left and top values. Some people set left and top with $(el).css
> > > ({left:px, top:px}, but that will not work if el is inside an element
> > > with position relative, because the left and top will be relative to
> > > that parent instead of the window. I created a plugin that keeps the
> > > getting of the offset intact, but also adds the ability to set the
> > > offset relative to the window - regardless of the positioning of
> > > parents. I think this should be added to the next release.
> >
> > >http://plugins.jquery.com/project/setOffset
> >
>
--~--~-~--~~~---~--~~
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: Set offset
Cool. I'll take a look at this soon. We might also want to make .position()
a setter at the same time. I've gone ahead and added it to the list of
potential features for 1.4. http://docs.jquery.com/JQuery_1.4_Roadmap#Offset
--
Brandon Aaron
On Fri, Mar 20, 2009 at 6:49 PM, DanB wrote:
>
> Currently you can't set the offset of jquery by passing in an object
> with left and top values. Some people set left and top with $(el).css
> ({left:px, top:px}, but that will not work if el is inside an element
> with position relative, because the left and top will be relative to
> that parent instead of the window. I created a plugin that keeps the
> getting of the offset intact, but also adds the ability to set the
> offset relative to the window - regardless of the positioning of
> parents. I think this should be added to the next release.
>
> http://plugins.jquery.com/project/setOffset
>
> >
>
--~--~-~--~~~---~--~~
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: iPhone+jQuery strangeness, jQuery loses touch with the DOM?
setTimeout in WebKit for JavaScript issues is becoming like zoom: 1
for CSS issues in IE
I fixed a lot of odd reflow issues I was having with the jQuery API
Browser for the iPhone using setTimeouts.
--
Brandon Aaron
On 3/5/09, Parand wrote:
>
> Finally found a work-around:
>
> I was calling my objective-c function using window.location . It
> turned out if I added a setTimeout around the call to window.location
> everything started working again. I'm guessing calling window.location
> would immediately call the objective-C code, interrupting the
> javascript thread, leaving things in a bad state. By adding the
> setTimeout it allows the javascript thread to finish before jumping
> into the objective-C code. Or something like that.
>
> Someday I'll have to write this up and post it somewhere...
>
> Parand
> http://parand.com/say/
>
> On Mar 5, 2:07 pm, John Resig wrote:
>> Unfortunately, I have no idea - it doesn't make it easier that it's
>> such a custom set up. Maybe someone with more iPhone dev experience
>> can speak to the situation.
>>
>> --John
>>
>> On Thu, Mar 5, 2009 at 4:52 PM, Parand wrote:
>>
>> > Hello,
>>
>> > I'm having a strange issue using jQuery on UIWebComponent on the
>> > iPhone - at some point jQuery becomes unable to add content to the
>> > DOM, while regular DOM methods (document.getElementById
>> > ('something').appendChild(x) ) continue to work.
>>
>> > I've posted details on stackoverflow, and I'll describe them below.
>> > I'm hoping someone here can point me in the right direction:
>>
>> >http://stackoverflow.com/questions/591949/iphone-webkit-jquery-strang...
>>
>> > I'm doing funky things with UIWebComponent, passing control back and
>> > forth between objective-C and WebKit: from WebKit I invoke Objective-C
>> > code by calling a special URL that the Objective-C handler catches,
>> > and from Objective-C I execute Javascript in WebKit. Works well for
>> > the most part.
>>
>> > I switch "pages" by showing and hiding divs on the same html page.
>> > After switching a couple of times and some objC-Webkit interactions,
>> > jQuery becomes unable to update the dom.
>>
>> > var x = document.createTextNode('THE FIRST THING');
>> > document.getElementById('thumbspage').appendChild(x);
>> > $('#thumbspage').append('-- THE SECOND THING');
>>
>> > "THE FIRST THING" shows up, "THE SECOND THING" doesn't .
>>
>> > I can still hide and remove elements using jQuery, but I can't add
>> > anything.
>>
>> > Any ideas?
>>
>> > Best,
>>
>> > Parand
>> >http://parand.com/say/
> >
>
--~--~-~--~~~---~--~~
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: ajax not posting
I haven't. Do you have a URL that we could see? Better yet could you create a test case and attach it to the ticket? -- Brandon Aaron On Tue, Feb 24, 2009 at 7:33 PM, treshug...@gmail.com wrote: > > http://dev.jquery.com/ticket/4239 > > I've created a ticket for this. > > Anyone else experience this? > > -Trey > > > --~--~-~--~~~---~--~~ 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
Do you still have those speed tests for this around. I'm more curious why it speeds things up than anything else. I understand why it speeds things up in hide... just not understanding how we are gaining any performance in show. -- Brandon Aaron On Mon, Feb 16, 2009 at 4:26 PM, John Resig wrote: > > The dual loop is actually a huge speed-up. If we set the display > inside the first loop (and then check the computed display of the next > element) this causes a fresh reflow of the page. For every single > element that we show/hide. Last check this is giving us a 2x speedup > (even with the extra loop and setting). Do you think this is still ok? > > --John > > On 2/16/09, Brandon Aaron wrote: > > Whoops... spoke to soon. The show method is throwing errors in IE 6. The > > main issue is that IE 6 doesn't like setting this[i].style.display to > > undefined. Second, it looks like the second for loop is sitting within > the > > first for loop when I believe the intention was to have them separate, > not > > nested. Resolved in R6215. > > Actually, is that second for loop in show really fixing anything? > Typically > > we shouldn't need to set the display property again b/c we already set it > > once in the first for loop (line 28 of fx.js). The only reason we would > set > > it again is if the element was still hidden. However, with the second for > > loop we are always resetting the display value even if we don't need to. > > > > Looks like we just need to remove the second for loop in show and move > the > > assignment of style.display back into the if block of the first for loop. > > However, I wanted to make sure I wasn't over looking something. > > > > -- > > Brandon Aaron > > > > On Mon, Feb 16, 2009 at 2:06 PM, Brandon Aaron > > wrote: > > > >> No issues here. > >> -- > >> Brandon Aaron > >> > >> > >> On Mon, Feb 16, 2009 at 12:31 PM, John Resig 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 > >>> > >>> >> > >>> > >> > > > > > > > > > > -- > --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
Whoops... spoke to soon. The show method is throwing errors in IE 6. The main issue is that IE 6 doesn't like setting this[i].style.display to undefined. Second, it looks like the second for loop is sitting within the first for loop when I believe the intention was to have them separate, not nested. Resolved in R6215. Actually, is that second for loop in show really fixing anything? Typically we shouldn't need to set the display property again b/c we already set it once in the first for loop (line 28 of fx.js). The only reason we would set it again is if the element was still hidden. However, with the second for loop we are always resetting the display value even if we don't need to. Looks like we just need to remove the second for loop in show and move the assignment of style.display back into the if block of the first for loop. However, I wanted to make sure I wasn't over looking something. -- Brandon Aaron On Mon, Feb 16, 2009 at 2:06 PM, Brandon Aaron wrote: > No issues here. > -- > Brandon Aaron > > > On Mon, Feb 16, 2009 at 12:31 PM, John Resig 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: jQuery 1.3.2 Alpha Ready
No issues here. -- Brandon Aaron On Mon, Feb 16, 2009 at 12:31 PM, John Resig 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: Dimensions Speed Improvement
Very nice... all so quick too! :)
--
Brandon Aaron
On Fri, Feb 13, 2009 at 5:00 PM, John Resig wrote:
>
> Ok, so I took some time and read through the patch more completely. It
> didn't seem like much had actually changed so I wanted to figure out
> the differences. The performance comes from two places:
>
> 1) Not using .is(":visible") (that speeds up height/width).
> 2) Re-organizing inner/outerWidth so that they could fast-path through
> the height/width calculations without having to have the dimension be
> re-added.
>
> So, I took those two concept and integrated them.
>
> The perf test suite:
> http://dev.jquery.com/~john/ticket/3082/<http://dev.jquery.com/%7Ejohn/ticket/3082/>
>
> The test suite (passing in all browsers):
> http://dev.jquery.com/~john/ticket/3082/test/?eight<http://dev.jquery.com/%7Ejohn/ticket/3082/test/?eight>(height
> tests)
> http://dev.jquery.com/~john/ticket/3082/test/?idth<http://dev.jquery.com/%7Ejohn/ticket/3082/test/?idth>(width
> tests)
>
> The patch:
> http://dev.jquery.com/attachment/ticket/3082/3082.patch
>
> Landing:
> http://dev.jquery.com/changeset/6195
>
> The result is even faster than what Mike originally proposed (as you
> can see from the perf test suite). I'm seeing 10-20% over Mike's on
> height/width, 20-30% on innerHeight/Width, 100% on outerHeight/Width,
> and 10-40% on outerHeight/Width(true).
>
> Thanks a ton, Mike, for this set of tweaks - it's a huge win!
>
> --John
>
>
>
> On Fri, Feb 13, 2009 at 4:25 PM, John Resig wrote:
> > Very interesting patch - sorry I apparently missed it/forgot about it
> > before. I'm loving the speed improvements (loaded up IE7 and I'm
> > seeing 2x+ improvements across the board - along with Firefox, etc.)
> >
> > There are a bunch of points though that we'll need to take into
> consideration:
> > 1) This isn't actually a patch right now - it's more of a plugin (a
> > patch would modify the existing codebase and provide a diff of the
> > changes that need to be made).
> > 2) The code, as it stands, doesn't match any of the existing coding
> > style of jQuery (braces not matching, $ used instead of jQuery, code
> > on the same line as an if, not enough spaces around statements).
> > 3) Why does $.size exist? Why not just have the functionality be in
> > .height()/.width() - or in .curCSS(). I don't see a need for a new
> > function here.
> > 4) Does it still pass the test suite?
> >
> > Any progress on this would definitely help to get this patch landed. I
> > can take a look at reorganizing all of it eventually - but it might
> > just get delayed - you help will make it go faster.
> >
> > Thanks!
> >
> > --John
> >
> >
> >
> > On Fri, Feb 13, 2009 at 4:00 PM, mike.helgeson
> wrote:
> >>
> >> I provided a patch about 8 months ago to improve the performance of
> >> the core height and width and dimensions inner/outer[height/width]
> >> methods.
> >>
> >>
> http://groups.google.com/group/jquery-dev/browse_thread/thread/a4becc9a5cc34fea/
> >>
> >> I put together a test page to help make my point...
> >>
> >> http://dev.helgeson.info/dimension/
> >>
> >> I average the following results using FF3/XP...
> >> (percentages of the unpatched method time)
> >> height & width ~ 73%
> >> innerHeight & innerWidth ~ 44%
> >> outerHeight & outerWidth ~ 19%
> >> outerHeight( true ) & outerWidth( true ) ~ 32%
> >>
> >> I updated the patch to be compatable with 1.3.x
> >>
> >> http://dev.jquery.com/ticket/3082
> >>
> >> In addition to being more efficient, the methods also simplify the API
> >> by overloading the height/width methods. By passing in a string
> >> ("padding" or "border" or "margin") you get in return, the dimension
> >> through that property.
> >> >>
> >>
> >
>
> >
>
--~--~-~--~~~---~--~~
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
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 wrote: > 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: Bug in css.outerHeight in firefox?
Could you create a test case for us to review?
--
Brandon Aaron
On Thu, Feb 12, 2009 at 10:43 PM, ebetancourt wrote:
>
> Hi, I was working with Kelvin Luck's great jScrollPane library, and
> found that it would stop rendering the scrollbars if I set a max-
> height property in the css.
>
> I found this conditional statement (things were cropped and pasted to
> just give the gist of the problem):
>
>$this = $(this);
>var paneHeight = $this.innerHeight();
>var contentHeight = $this.outerHeight();
>var percentInView = paneHeight / contentHeight;
>
>if (percentInView < .99) {...}
>
> in all other browsers, $this.outerHeight was equal (more or less) to
> $this[0].scrollHeight.
>
> in firefox, the value was mis-reported as the max-height value +
> padding;
>
> for now I modified my local version of jScrollPane so that
> contentHeight = $this[0].scrollHeight. But I figured it was something
> worth bringing up since the bug actually traces back to the main
> jQuery library.
>
> has anyone else run into this oddity with outerHeight? or is the
> combination of Firefox, outerHeight, and max-height a rare one?
>
> I am using Firefox 3 on an Intel Mac. Version Data:
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6)
> Gecko/2009011912 Firefox/3.0.6
>
>
> >
>
--~--~-~--~~~---~--~~
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: Suggestion.
Make sure you are using jQuery 1.3.1. In 1.3.0 there was an issue where live wasn't working properly for elements that were not matched in the DOM at run time. -- Brandon Aaron On Sat, Jan 31, 2009 at 12:20 PM, NeoTech wrote: > > I have been having to rewrite functions as append, html, before, and > so on. with a function callback. > And my suggestion is that give the html manipulation functions a > callback option. > > why? I have found it easier to bind events this way. Mainly because > the browser waits for the dom injection and THEN do the event binding. > > I have tried live. but that only works if you have data injected > before you start. > Others hacks that work is animating things that isnt there for 100ms > and then do the event binding as a function callback. But this is not > a clean way of doing it in my opinion. > > > > --~--~-~--~~~---~--~~ 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: Missing currentTarget in $.event.fix?
Sorry Ariel, your right. I believe I must have been thinking about relatedTarget. :) -- Brandon Aaron On Sat, Jan 31, 2009 at 6:02 AM, Ariel Flesler wrote: > > No, currentTarget was a 1.3.x addition. I added it within trigger and > thought event objects had it in IE. > I realized I was wrong some days ago. I'll add it once I get back. It > should be done within $.event.handle. > > -- > Ariel Flesler > http://flesler.blogspot.com > > On 30 ene, 19:17, Brandon Aaron wrote: > > I'm fairly certain we normalized this in pervious versions. Definitely a > > regression. Might want to file a ticket so it doesn't get lost on the > list. > > -- > > Brandon Aaron > > > > On Fri, Jan 30, 2009 at 11:51 AM, Arrix wrote: > > > I'm not sure whether jQuery used to fix currentTarget for IE but I > think > > > it's not an easy task. The only way I know to get the currentTarget in > IE > > > is to use this keyword, which is only available in the ele.onxxx = func > > > model. > > > > > On Sat, Jan 31, 2009 at 12:53 AM, Jörn Zaefferer < > > > joern.zaeffe...@googlemail.com> wrote: > > > > >> It looks like a regression to me: $.event.fix doesn't add > > >> currentTarget to the event object, which is missing in IE. Is that a > > >> regression? Or is there a reason it isn't added? > > > > > -- > > > Arrix > > > --~--~-~--~~~---~--~~ 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: Missing currentTarget in $.event.fix?
I'm fairly certain we normalized this in pervious versions. Definitely a regression. Might want to file a ticket so it doesn't get lost on the list. -- Brandon Aaron On Fri, Jan 30, 2009 at 11:51 AM, Arrix wrote: > I'm not sure whether jQuery used to fix currentTarget for IE but I think > it's not an easy task. The only way I know to get the currentTarget in IE > is to use this keyword, which is only available in the ele.onxxx = func > model. > > On Sat, Jan 31, 2009 at 12:53 AM, Jörn Zaefferer < > joern.zaeffe...@googlemail.com> wrote: > >> >> It looks like a regression to me: $.event.fix doesn't add >> currentTarget to the event object, which is missing in IE. Is that a >> regression? Or is there a reason it isn't added? > > -- > Arrix > > > > --~--~-~--~~~---~--~~ 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
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 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 call you need (GEBTN) > - restore the offending id on the element > > This technique also works for recovering overwritten "submit()" > methods in forms. > > Diego > > On 27 Gen, 19:41, John Resig wrote: > > > 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 "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: 20%+ faster replaceWith?
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 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.remove( this );
> jQuery.removeData( this );
> };
>
> jQuery.each({
> remove: function( selector ) {
>if ( !selector || jQuery.filter( selector, [ this ] ).length ) {
> jQuery( "*", this ).add([this]).each( kill );
> if (this.parentNode)
>this.parentNode.removeChild( this );
>}
> },
>
> empty: function() {
>jQuery( ">*", this ).each( kill );
>this.innerHTML = ""; // or whatever is fastest
> }
> }, function(name, fn){
> jQuery.fn[ name ] = function(){
>return this.each( fn, arguments );
> };
> });
>
> $.fn.extend({
> replaceWith: function() {
>this.find( "*" ).add([this]).each( kill );
> return this.domManip(arguments, false, function(elem){
> this.parentNode.replaceChild( elem, this );
>})
> }
> });
>
> Jed
>
> On Jan 19, 5:09 pm, Jed Schmidt wrote:
> > Ah, I suspected there might be something like that.
> >
> > 1.3 is great, keep up the good work!
> >
> > Jed
> >
> > On Jan 19, 5:02 pm, John Resig wrote:
> >
> > > I like it - but the one tricky part is that .remove() is actually
> > > functional beyond the simple .removeChild() call - it also removes any
> > > bound event handlers and bound data from the elements (which is
> > > something that this modified replaceWith would not do). That
> > > functionality would need to stay intact (this is the same reason why
> > > we do .empty().append() in .html() instead of using a straight
> > > innerHTML).
> >
> > > --John
> >
> > > On Mon, Jan 19, 2009 at 7:49 PM, Jed Schmidt wrote:
> >
> > > > Hey all,
> >
> > > > Looking at the new source code for 1.3, I was wondering why jQuery
> > > > doesn't take advantage of the native replaceChild method in the W3C
> > > > core. Currently, jQuery implements replaceWith using append and
> > > > remove, but since replaceChild is well supported[1] across browsers,
> > > > it seems like a safe place to optimize performance, since it reduces
> > > > two in-place DOM operations with one.
> >
> > > > So I replaced this on line 487 in 1.3:
> >
> > > > replaceWith: function( value ) {
> > > > return this.after( value ).remove();
> > > > },
> >
> > > > with this:
> >
> > > > replaceWith: function() {
> > > > return this.domManip(arguments, false, function(elem){
> > > >this.parentNode.replaceChild( elem, this );
> > > > });
> > > > },
> >
> > > > and put together a before[2] and after[3] page.
> >
> > > > On OS 10.5.6, Firefox 3.0.5 went from an average of 1239ms to 935ms,
> > > > and Safari 3.2.1 went from an average of 421ms to 331ms.
> >
> > > > What do you guys think?
> >
> > > > Jed Schmidt
> >
> > > > [1]http://www.quirksmode.org/dom/w3c_core.html
> > > > [2]http://s3.amazonaws.com/replacewith/before.html
> > > > [3]http://s3.amazonaws.com/replacewith/after.html
> >
> >
> >
>
--~--~-~--~~~---~--~~
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
On Fri, Jan 23, 2009 at 12:48 PM, John Resig wrote: > > > Specifically, I have a modal dialog plugin which needs to "detect" IE6 > > and IE7 in quirks mode. IE6 detection is needed for deciding whether > > or not to add an iframe behind the overlay to prevent element bleed- > > through. > > This first one is real tricky. I'm not sure what a good solution might > be. Anyone have any thoughts? > > The only "solution" that I can think of is to just bite the bullet and > put the iframe behind the overlay in every browser - but that's lame. This is something I need to solve soon to upgrade the bgIframe plugin! This is a _very_ visual issue and I haven't found a good way to detect this particular issue. I think I may end up just checking to see if the browser supports the filter property. Mainly b/c bgiframe makes heavy use of filter with default settings. This would make the iframe fix happen in IE7 as well but that seems acceptable. -- Brandon Aaron --~--~-~--~~~---~--~~ 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 under a different API
You might want to look at jQuery UI Effects for more advanced
animation/effects.http://ui.jquery.com/demos/effects_showhide
http://docs.jquery.com/UI/Effects
--
Brandon Aaron
On Wed, Jan 21, 2009 at 1:22 AM, Daniel Friesen
wrote:
>
>
> // Effects library code
> jQuery.extend( jQuery.fx, {
>animations: {
>partingSea: function(show, options) {
>if(show) {
>// show
>...
>} else {
>// hide
>jQuery(this).each(function() {
>jQuery(this).css({
>width:
> jQuery(this).innerWidth()+'px',
>height:
> jQuery(this).innerHeight()+'px'
>});
>
>var pos = false;
>var c = jQuery(this).children();
>c.each(function() {
>var p =
> jQuery(this).position();
>jQuery(this).css({
>left: p.left+'px',
>top: p.top+'px'
>});
>}).each(function() {
>
> jQuery(this).css({position:'absolute'});
>});
>
>function fly(i) {
>if(i<0) return;
>var n = c.eq(i);
>n.animate({
>left: (pos
>?
> jQuery(document).width()
>:
> -n.outerWidth(true) ) + 'px'
>}, {
>complete: function()
> {
>
> jQuery(this).hide({animate:false});
>fly(i-1);
>}
>});
>// ... code to modify parent
> height ...
>pos = !pos;
>};
>fly(c.length-1);
>});
>}
>}
>}
> });
>
> // App code
> $('#foo').hide(); // plain hide
> $('#foo').hide('slow'); // hide using simple animation
> $('#foo').hide({animate:'partingSea'}); // hide using partingSea animation
> $.fx.visibility.animate = 'partingSea';
> $('#foo').hide('fast'); // hide using partingSea animation
>
>
> Still trimmed down a good bit, I didn't even add the code to modify the
> parent itself. I used code to grab children, but you could easily
> provide a way for the user to provide a selector, like just 'p' tags.
> If you're curious about the animation i's just a trimmed example so it's
> nowhere complete. In fact I don't have the code that works with the
> parent yet. And conceivably the options objects should actually extend
> from the inputted options so that things like options.speed get
> transmitted to individual effects.
> Think of a big block with a number of paragraphs in it. Starting from
> the bottom individual paragraps fly outwards left and right and as that
> happens the actual container you are hiding shrinks in height. All the
> way up until the last paragraph flys off and the parent container
> collapses and disappears.
>
> I'm not a scriptaculous person, but even looking at an effects demo page:
> http://ndpsoftware.com/ScriptaculousEffectsDemo.php
> You can see that there are many conceivable ways to show or hide something.
> Actual individual animations wouldn't fit in jQuery itself, but perhaps
> in a ui library dedicated to visibility effects.
> Sure, it could provide those as plugin functions, but think about it. Do
> you honestly think it's a good idea for an effects library to provide 3
> new methods for each possible visibility animation i
[jquery-dev] Re: Event class for jQuery
I did, just wanted to make it very clear. :) -- Brandon Aaron On Sat, Nov 29, 2008 at 2:15 PM, Ariel Flesler <[EMAIL PROTECTED]> wrote: > > @Brandon & Karl > > Uh ? no one said we'd remove that... check the patch before jumping to > conclusions :D > > On Sat, Nov 29, 2008 at 5:59 PM, Karl Swedberg <[EMAIL PROTECTED]> > wrote: > > +1 for not taking away the ability to pass in the event type as a string > to > > trigger. I think it would break a lot of pre-existing code if that were > to > > happen. > > > > --Karl > > > > Karl Swedberg > > www.englishrules.com > > www.learningjquery.com > > > > > > > > On Nov 29, 2008, at 11:48 AM, Brandon Aaron wrote: > > > > I like this as well but I definitely wouldn't take away the ability to > just > > pass in the event type as a string to trigger. I don't want to have to > > create an event object every time I want to trigger an event but wouldn't > > mind passing it in if I already had it on hand. This will provide a nice > way > > to extend the event object itself. I believe Nathan Hammond was asking > about > > this in a thread recently on this list. > > -- > > Brandon Aaron > > > > On Fri, Nov 28, 2008 at 6: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 Flesler > >> http://flesler.blogspot.com > >> > > > > > > > > > > > > > > > > > > > > > -- > Ariel Flesler > http://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 options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Event class for jQuery
I like this as well but I definitely wouldn't take away the ability to just pass in the event type as a string to trigger. I don't want to have to create an event object every time I want to trigger an event but wouldn't mind passing it in if I already had it on hand. This will provide a nice way to extend the event object itself. I believe Nathan Hammond was asking about this in a thread recently on this list. -- Brandon Aaron On Fri, Nov 28, 2008 at 6: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 Flesler > http://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 options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Add a property
If you want or need to set an attribute you should use the .attr ( http://docs.jquery.com/Attributes ) function. If you want to set a custom property, you should use the .data ( http://docs.jquery.com/Core/data#name) function. -- Brandon Aaron On Mon, Nov 10, 2008 at 7:52 AM, Marco <[EMAIL PROTECTED]> wrote: > > It's possible to add a property (set and get) to a object, for example > a DIV? > > > Thanks > > > > --~--~-~--~~~---~--~~ 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: Window height in Safari is incorrect
Yeah that is definitely the issue I've run into before. The width/height
must be defined using the width and height attribute of the image tag to
avoid the issue.
--
Brandon Aaron
On Wed, Nov 5, 2008 at 3:49 PM, Jeffrey Kretz <[EMAIL PROTECTED]> wrote:
> Does it matter if the dimensions are set in an attached stylesheet
> instead of inline styles?
>
>
>
> I have a toolbar and items look something like this:
>
>
>
>
>
>
> Do something
>
>
> Do something Else
>
>
>
>
>
> With the CSS like this:
>
>
>
> div.tb_main { position:fixed;left:0px;top:0px;height:30px;width:auto; }
>
> div.tb_mainie6 { position:absolute; }
>
> div.tb_item { float:left;margin:3px; }
>
> div.tb_item img {
> vertical-align:middle;width:16px;height:16px;background-image:url(images/sprites.png);
> }
>
> div.tb_item span { vertical-align:middle;padding-left:10px;}
>
> img.btn1 { background-position:-32px -64px }
>
> img.btn2 { background-position:-48px -64px }
>
>
>
> So there is a width and height, but they are not defined in the attributes
> of the tag, nor in the inline styles of the images.
>
>
>
> Also note that the containing div.tb_main has an expressly defined css
> height.
>
>
>
> Yet after creation and adding to the DOM (appended to document.body), the
> calculated height is sometimes the full document height (1000px or
> whatever). This only happens when the element is POSITION:FIXED – the
> problem goes away with POSITION:ABSOLUTE.
>
>
>
> It's also not consistently reproducible (arrrgh), and it only happens in
> webkit browsers.
>
>
>
> For my own project, I have a workaround of not detecting the toolbar
> height, but assuming its 30px, hard-coded into my script.
>
>
>
> My fear is that this may be an underlying browser bug without a safe patch
> for it in the dimensions engine.
>
>
>
> JK
>
>
>
> *From:* jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Brandon Aaron
> *Sent:* Wednesday, November 05, 2008 12:44 PM
>
> *To:* jquery-dev@googlegroups.com
> *Subject:* [jquery-dev] Re: Window height in Safari is incorrect
>
>
>
> Jeff, do you have any images in the page or toolbar that don't have
> width/height set? This has caused issues like you are describing for me in
> the past in webkit based browsers.
>
>
>
> I'll see if I can't get around to taking a look at the window height issue
> later today.
>
>
>
> --
>
> Brandon Aaron
>
> On Wed, Nov 5, 2008 at 2:31 PM, Jeffrey Kretz <[EMAIL PROTECTED]>
> wrote:
>
>
> To add to this, I al have an error I (cannot consistently reproduce it,
> unfortunately) about height being incorrectly calculated.
>
> I have an "Admin Toolbar" added to the top of my CMS page, set for
> "position:fixed" the document.body element is moved down by the height of
> the toolbar.
>
> Periodically, when the toolbar is added, the .height() function, as well as
> the el[0].clientHeight property returns the FULL document height (rather
> than something small like 30px), causing my program to move the
> document.body element WA down the page.
>
> If I set a timeout of like 100ms before measuring the height, it comes out
> correctly.
>
> But immediately following the creation:
> $('').appendTo(document.body) the height was calculated
> incorrectly.
>
> It happened on Chrome, Safari Mac and Safari PC, but not on IE6/7, FF2/3
> and
> Opera, so I believe this is a bug in the underlying Webkit rendering
> engine.
>
> I've hacked it for now, hard coding the height of the toolbar, as I don't
> see a good workaround to what I believe is an underlying bug in the engine.
>
>
> JK
>
> -Original Message-
> From: jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED] On
>
> Behalf Of Jeffrey Kretz
> Sent: Wednesday, November 05, 2008 12:17 PM
> To: jquery-dev@googlegroups.com
> Subject: [jquery-dev] Re: Window height in Safari is incorrect
>
>
> I agree, and I have noticed this problem with other Webkit browsers, namely
> Chrome and Safari for Windows.
>
> I haven't gotten around to a suggested workaround for it yet, but I'll need
> to solve it before I launch my project, which works fine on IE6/7 FF2/3 and
> Opera, but not on Safari Mac/Win and Chrome.
>
> JK
>
> -Original Message-
> From: jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Tim Molendijk
> Sent: Wednesday, November 05, 2008 11:34 AM
> To: jQuery Development
> Subject: [jquery-dev] Window height in Safari is incorrect
>
>
> http://dev.jquery.com/ticket/3578
>
> people agree?
>
>
>
>
>
>
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: Window height in Safari is incorrect
Jeff, do you have any images in the page or toolbar that don't have
width/height set? This has caused issues like you are describing for me in
the past in webkit based browsers.
I'll see if I can't get around to taking a look at the window height issue
later today.
--
Brandon Aaron
On Wed, Nov 5, 2008 at 2:31 PM, Jeffrey Kretz <[EMAIL PROTECTED]> wrote:
>
> To add to this, I al have an error I (cannot consistently reproduce it,
> unfortunately) about height being incorrectly calculated.
>
> I have an "Admin Toolbar" added to the top of my CMS page, set for
> "position:fixed" the document.body element is moved down by the height of
> the toolbar.
>
> Periodically, when the toolbar is added, the .height() function, as well as
> the el[0].clientHeight property returns the FULL document height (rather
> than something small like 30px), causing my program to move the
> document.body element WA down the page.
>
> If I set a timeout of like 100ms before measuring the height, it comes out
> correctly.
>
> But immediately following the creation:
> $('').appendTo(document.body) the height was calculated
> incorrectly.
>
> It happened on Chrome, Safari Mac and Safari PC, but not on IE6/7, FF2/3
> and
> Opera, so I believe this is a bug in the underlying Webkit rendering
> engine.
>
> I've hacked it for now, hard coding the height of the toolbar, as I don't
> see a good workaround to what I believe is an underlying bug in the engine.
>
> JK
>
> -Original Message-
> From: jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Jeffrey Kretz
> Sent: Wednesday, November 05, 2008 12:17 PM
> To: jquery-dev@googlegroups.com
> Subject: [jquery-dev] Re: Window height in Safari is incorrect
>
>
> I agree, and I have noticed this problem with other Webkit browsers, namely
> Chrome and Safari for Windows.
>
> I haven't gotten around to a suggested workaround for it yet, but I'll need
> to solve it before I launch my project, which works fine on IE6/7 FF2/3 and
> Opera, but not on Safari Mac/Win and Chrome.
>
> JK
>
> -Original Message-
> From: jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Tim Molendijk
> Sent: Wednesday, November 05, 2008 11:34 AM
> To: jQuery Development
> Subject: [jquery-dev] Window height in Safari is incorrect
>
>
> http://dev.jquery.com/ticket/3578
>
> people agree?
>
>
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: Gradientz
Nice work! I've been meaning to investigate doing this for my gradient
plugin for so long. Just in case ... feel free to call it gradient() and my
gradient plugin can just die off. :)
Also ... since you manually use innerHTML for MSIE, you should register your
plugin with LiveQuery so that it can pick up the changes.
$.livequery && $.livequery.registerPlugin('gradientz');
--
Brandon Aaron
On Tue, Nov 4, 2008 at 10:21 AM, weepy <[EMAIL PROTECTED]> wrote:
>
> I know this group isn't really for jQuery plugins, but I thought you
> guys might appreciate this :
>
> http://www.parkerfox.co.uk/labs/gradientz/
>
> It renders gradient backgrounds using VML/Canvas without excanvas.
>
> Jonah
> >
>
--~--~-~--~~~---~--~~
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: Ultra-Chaining with jQuery
Maybe I just like JavaScript but I'd prefer to just pass
an anonymous function to do what I need within an event handler. Often times
my event handlers aren't that simple. I can understand queuing chained fx
methods but this just feels wrong. I'll admit though it is sexy at first and
an interesting experiment. However, once I start thinking about what my
existing code would look like in this syntax... it isn't so sexy anymore. We
would have to start re-creating the core language constructs in our DSL and
I think JavaScript does a fine job.
--
Brandon Aaron
On Sun, Oct 26, 2008 at 10:55 AM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
>
> What do you think of the events part ?
>
> $('div')
> .when('click')
> .addClass('active')
> .text('Hey')
> .done()
> // Also possible with on()
> .on('mouseout')
>.removeClass('active')
>.text('Ho')
> .done();
>
> At first event handler would only run once, now I improved that. It
> could also be possible to avoid the use of .done() for successive
> events. Assuming that you're not going to bind events inside an event
> handler, but I'm not sure that applies to all cases.
>
>
> --
> Ariel Flesler
> http://flesler.blogspot.com/
>
> On Oct 23, 9:24 pm, "Ariel Flesler" <[EMAIL PROTECTED]> wrote:
> > Thanks!!
> >
> > I created some more demos, I'm experimenting on different areas :)
> >
> >
> http://test.flesler.com/jquery.async/demos/fx.htmlhttp://test.flesler.com/jquery.async/demos/event.htmlhttp://test.flesler.com/jquery.async/demos/ajax.htmlhttp://test.flesler.com/jquery.async/demos/wait.html
> >
> > This is still work in progress.
> >
> > Cheers
> >
> > On Thu, Oct 23, 2008 at 4:54 PM, Jeffrey Kretz <[EMAIL PROTECTED]
> >wrote:
> >
> >
> >
> > > You are a SEXY BEAST!
> >
> > > I personally love that implementation.
> >
> > > And the syntax of "then" and "meanwhile" is very clear, with a separate
> > > "wait" method for a delay.
> >
> > > JK
> >
> > > *From:* jquery-dev@googlegroups.com [mailto:
> [EMAIL PROTECTED] *On
> > > Behalf Of *Ariel Flesler
> > > *Sent:* Thursday, October 23, 2008 10:46 AM
> > > *To:* jquery-dev@googlegroups.com
> >
> > > *Subject:* [jquery-dev] Re: Ultra-Chaining with jQuery
> >
> > > Indeed. As I said, I got into making a plugin out of this.
> > > I changed the semantics, added some features (more to come) and of
> course,
> > > implemented it.
> >
> > > Here's a very simple demo.
> > >http://test.flesler.com/jquery.async/
> >
> > > Cheers
> >
> > > On Thu, Oct 23, 2008 at 2:42 PM, Jeffrey Kretz <[EMAIL PROTECTED]>
> > > wrote:
> >
> > > I tend to agree. But either way, is a wait() function technically
> feasible?
> >
> > > I tried hacking my way though it last night, and couldn't figure out
> the
> > > implementation of code that would pause execution while a setInterval
> > > function did it's work, and only THEN return the "this" jQuery object.
> >
> > > Does anyone know how to solve the technical hurdle here?
> >
> > > I guess you could call it "asynchronous setInterval"
> >
> > > JK
> >
> > > -Original Message-
> > > From: jquery-dev@googlegroups.com [mailto:[EMAIL PROTECTED]
> On
> > > Behalf Of Bohdan Ganicky
> > > Sent: Thursday, October 23, 2008 4:07 AM
> > > To: jQuery Development
> > > Subject: [jquery-dev] Re: Ultra-Chaining with jQuery
> >
> > > HI ricardobeat,
> >
> > > I don't think this is a good idea. Most of the time I expect
> > > everything to happen as fast as possible. Waiting is mostly good for
> > > animations only and even that's not always true. At least that's how I
> > > feel it.
> >
> > > --
> > > Bohdan
> >
> > > On Oct 23, 2:43 am, ricardobeat <[EMAIL PROTECTED]> wrote:
> > > > That's exactly what I said the day before, you pratically read my
> > > > mind :]
> http://ejohn.org/blog/ultra-chaining-with-jquery/#comment-321336
> >
> > > > What about making all methods 'wait' by default? That's what most
> > > > people expect anyway, people new to jQuery only find out the
> > > > animations run "in parallel"
[jquery-dev] Re: Webkit CSS animations for jQuery
Remember also that we need to try and make this work without browser detection. I'm assuming we'll have to do a quick feature detection. -- Brandon Aaron On Mon, Oct 20, 2008 at 3:47 AM, Paul Bakaus <[EMAIL PROTECTED]>wrote: > > This is quite cool! > > I've been thinking about this for quite some time, and it's nice to > see > someone else having the same idea. If we could land a solid version of > that > in the core, that'd be awesome. > > I'm thinking about how feasible it would be to port easing as well - > CSS Transforms support easing, but I'm not sure about the format. Any > idea? > > On Oct 19, 10:57 am, weepy <[EMAIL PROTECTED]> wrote: > > I've put together a proof of concept for using Webkit CSS animations > > where possible. You can find it at : > > > > http://www.parkerfox.co.uk/labs/css-webkit-animation-jquery-proof-of-... > > > > It creates a wrapper function $.animate2 that runs the equivalent CSS > > animation if the $.browser.safari = true or runs the original animate > > code otherwise. > > > > There's also a stress test page here : > http://www.parkerfox.co.uk/labs/css-webkit-animation-jquery-stress-te... > > > > As you can see the test is too much for the JS animation, but the CSS > > animation works fine. > > > > Tested on Firefox, Chrome, iPhone. > > > > weepy > > > --~--~-~--~~~---~--~~ 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: smooth animation for iphone
I believe there are some efforts of making a plugin or extending the core to support the CSS animations. Not sure how far along they are. -- Brandon Aaron On Fri, Oct 17, 2008 at 7:32 AM, weepy <[EMAIL PROTECTED]> wrote: > > Apparently you can do CSS animations for webkit which looks quite > neat : > > http://webkit.org/blog/138/css-animation/ > > Anyone tried this out ? > > > > > On 17 Oct, 13:21, weepy <[EMAIL PROTECTED]> wrote: > > I'm finding it difficult to create nice animations for the iphone. > > They tended to be inconsistent and the frames trip over each other. > > Obviously its much more difficult because of the slow processor, but > > does any one have any tips ? > > > > I have one suggestion - I think the default interval of 13ms should be > > exposed. I've found that setting it to 83ms (=>12 f/s) improves things > > quite a bit. It tends to be less smooth, but much more consistent. > > > > Weepy > > > --~--~-~--~~~---~--~~ 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: Suggestion for better compatibility with Asp.Net
Would you mind creating an enhancement ticket for this, so it doesn't get lost? And please share anymore of your experiences like this of integrating .Net with jQuery! http://dev.jquery.com/newticket/ -- Brandon Aaron On Thu, Oct 9, 2008 at 1:44 AM, Travis Simon <[EMAIL PROTECTED]> wrote: > > Yes, I have managed to get it to work reasonably well for my purposes. > My suggestion is just that - a suggestion for the JQuery community. > Apparently Microsoft will be shipping JQuery in its next release > of .Net, and little issues like this will make the experience easier > for those users, and will hopefully make life easier for the JQuery > community as well (that is, there are whiners in every community, and > removing a few of the stumbling blocks should prevent some 'Microsoft > Ajax is so much better' type posts. > > Again, thanks to all. > > On Oct 9, 1:03 pm, "Thiago Cruz Santos" <[EMAIL PROTECTED]> > wrote: > > just use "classic" programming on asp.net, post normaly using jquery > then > > analyse on the code behind if the stuff you posted got there and then > fire > > your method. if you need a return just write it and end the response. > works > > dandy on the project i am > > > > On Wed, Oct 8, 2008 at 7:32 PM, Travis Simon <[EMAIL PROTECTED]> wrote: > > > > > Hello all, > > > > > I'm exploring JQuery with .Net (and loving it!), but I have hit a > > > small snag (that I was able to patch locally). > > > > > .Net has a convenient method for creating webservices in the same code > > > file that the page's logic - known as the code-behind. This is the > > > standard method for using AJAX with Microsoft Ajax. However, these > > > methods expect their parameters to be passed as JSON encoded strings, > > > as opposed to query strings. Would it be possible to add this as a > > > encoding option to the .ajax method? > > > > > In my case, I'm going via (the wondeful) jqGrid control, so I can't > > > perform the encoding myself before passing it to the .ajax call. > > > However, if it were an option were available, I'm sure jqGrid and > > > other controls would expose that property. > > > > > For my purposes, I'm using the .toJSON method located here: > > >http://code.google.com/p/jquery-json/ > > > > > Thanks and keep up the great work, > > > Travis > > > --~--~-~--~~~---~--~~ 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.plugin()
In a way it feels like we are trying to build just another class helper
instead of just using prototypes. I understand we want to make it easy to
build extendable and modular plugins/widgets. I think I see how the plugin
builder can help us do that but I think it would be wise to get it working
within jQuery UI first. Lets make some extendable and modular widgets within
jQuery UI using the plugin/widget builder/factory and then make it more
readily available when we've proven it meets our goals.
--
Brandon Aaron
On Sat, Oct 4, 2008 at 5:12 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> Brandon,
> I agree that this is not a generic plugin builder. However, its use-cases
> go further than just jQuery UI. It's useful for:
>
> * any plugin that needs to encapsulate state
> * any plugin that wants to be extended by other plugins
>
> Adding it to jQuery UI means that people who want to build simple
> extensible plugins need to think about adding a part of jQuery UI as a
> dependency for their plugin. As this is only 50 or so lines, I see a lot of
> value in adding it to -core, but making clear that it's only to be used if
> you mean to be writing something stateful or extensible.
>
> -- Yehuda
>
>
> On Sat, Oct 4, 2008 at 3:01 PM, Brandon Aaron <[EMAIL PROTECTED]>wrote:
>
>> Okay ... so I've been playing around with this for a little while and have
>> a few thoughts.
>>
>> First, it raises the barrier to entry on writing plugins... even if it is
>> small, it is one more thing to know and understand.
>>
>> Second, I've written a lot of plugins that certainly do not fit into this
>> structure very well. For example, I don't believe any of the methods found
>> within Dimensions would have benefited from this plugin builder. Live Query
>> is another example of a plugin that just doesn't fit into the mold for this.
>> Furthermore, I use $.fn to encapsulate chunks of functionality to make my
>> code more readable and maintainable. Using the plugin builder for these adds
>> unneeded complication.
>>
>> Third, the bgiframe plugin seemed to convert into this format the easiest
>> but I don't believe anything was gained by using the plugin builder vs just
>> $.fn. Only the overhead of the plugin builder itself.
>>
>> I'd like to hear anyone else's experience in converting their existing
>> plugins ... especially from Ariel and Joern. Right now I'm still believe
>> that this is best kept within jQuery UI and branded as a widget builder.
>>
>> --
>> Brandon Aaron
>>
>>
>> On Fri, Oct 3, 2008 at 9:27 AM, John Resig <[EMAIL PROTECTED]> wrote:
>>
>>> Hi Guys -
>>>
>>> At the Ajax Experience we talked about possibly making a reusable
>>> function for helping to encapsulate much of the functionality commonly seen
>>> in jQuery plugins.
>>>
>>> The important points seemed to be:
>>> - Plugins need a way to maintain state from one call to the next
>>> (generally in the form of 'options').
>>> - The state needs to be directly associated with the elements that
>>> they're called on
>>> - There needs to be a default set of options to load state from
>>> - Plugins need to clean-up any events or data that they bind to an
>>> element
>>> - All methods introduced by a plugin should have access to the same
>>> state
>>>
>>> I put my code up here:
>>> http://dev.jquery.com/~john/plugins/widget/
>>> http://dev.jquery.com/~john/plugins/widget/widget.js
>>>
>>> This is how you would use it:
>>>
>>> The most basic call: Adds a single method (.test()) whose 'this'
>>> represents an individual element wrapped in a jQuery set. An empty options
>>> object is provided, as well.
>>>
>>> jQuery.plugin("test", function(a, b){
>>> this.options = a;
>>> this.hide(b);
>>> });
>>>
>>> jQuery("div").test("woo", "slow");
>>>
>>> Equivalent to the first style shown above.
>>>
>>> jQuery.plugin("test", {
>>> setup: function(a, b){
>>> this.options = a;
>>> this.hide(b);
>>> }
>>> });
>>>
>>> jQuery("div").test("woo", "slow");
>>>
>>> Next step up: A default set of options is provided - which implies that
>>> the first argument to .test() will be an options object.
>>>
>>&
[jquery-dev] Re: jQuery.plugin()
On Sat, Oct 4, 2008 at 7:38 PM, Jörn Zaefferer <
[EMAIL PROTECTED]> wrote:
>
> About your subjection to $.plugin for the plugin you mentioned.
> Comparing these two looks like very little overhead when writing a
> plugin one or the other way:
>
> $.fn.myPlugin = function() {});
> $.plugin("myPlugin", function() {});
The syntax isn't that different at a glance but of course using the $.plugin
builder/factory is going to have more overhead.
Here is a trimmed down example from the TiVo JS (
http://www.tivo.com/assets/js/application.js ):
jQuery.fn.extend({
scalable_bg: function(options) { ... },
make_buttons: function() { ... },
make_dividers: function() { ... },
add_corners: function() { ... },
make_faqs: function() { ... },
make_tabs: function() { ... },
make_tooltips: function() { ... },
make_popups: function() { ... },
check_images_enabled: function() { ... }
...
});
That gets a whole lot uglier with $.plugin repeated... perhaps we could
create a $.plugins but still not the same.
> On the other hand, the latter would give a teardown method that cleans
> up custom data and events, without having to implement anything
> related to that. It also handles options, gives you an instance to
> store internal state and maybe a plugin-mechanism to add further
> extensions to your plugin, what Yehuda is promoting.
I agree that when porting the bgiframe plugin to this $.plugin builder it
got a standard way to then trigger a destroy. It was completely possible
before and documented but standards are nice. Just not sure that single
benefit was enough for me to use $.plugin for bgiframe.
> What I like about $.plugin is the ability to just make it part of the
> API documentation - so far the writing-plugins documentation really
> isn't that great, and you always have to explain what $.fn actually
> is.
I believe you will have to write (and answer) much more about $.plugin than
you would with $.fn. Your going to have to explain the main two ways to use
$.plugin. Then your going to have to explain what setup and teardown mean,
then what methods means, then what instance means... and so on. Your still
going to have to explain what 'this' is and all that normal stuff.
> I'm going to port a few plugins in the next days to $.plugin and try
> to make it work with jQuery UI. I hope to provide better usecases
> based on that.
I can't wait to hear your thoughts on using $.plugin for your validation
plugin and any others!
--
Brandon Aaron
--~--~-~--~~~---~--~~
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: bind "drag" events
On Sat, Oct 4, 2008 at 6:34 PM, mike.helgeson <[EMAIL PROTECTED]>wrote: > > Brandon, slightly off topic but related to drag/drop performance, Have > you gotten a chance to look at this? > > http://groups.google.com/group/jquery-dev/browse_thread/thread/a4becc9a5cc34fea > http://dev.jquery.com/ticket/3082 I hadn't seen that ticket or thread yet. I'll take a more in-depth look at it soon. -- Brandon Aaron --~--~-~--~~~---~--~~ 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.plugin()
Okay ... so I've been playing around with this for a little while and have a
few thoughts.
First, it raises the barrier to entry on writing plugins... even if it is
small, it is one more thing to know and understand.
Second, I've written a lot of plugins that certainly do not fit into this
structure very well. For example, I don't believe any of the methods found
within Dimensions would have benefited from this plugin builder. Live Query
is another example of a plugin that just doesn't fit into the mold for this.
Furthermore, I use $.fn to encapsulate chunks of functionality to make my
code more readable and maintainable. Using the plugin builder for these adds
unneeded complication.
Third, the bgiframe plugin seemed to convert into this format the easiest
but I don't believe anything was gained by using the plugin builder vs just
$.fn. Only the overhead of the plugin builder itself.
I'd like to hear anyone else's experience in converting their existing
plugins ... especially from Ariel and Joern. Right now I'm still believe
that this is best kept within jQuery UI and branded as a widget builder.
--
Brandon Aaron
On Fri, Oct 3, 2008 at 9:27 AM, John Resig <[EMAIL PROTECTED]> wrote:
> Hi Guys -
>
> At the Ajax Experience we talked about possibly making a reusable function
> for helping to encapsulate much of the functionality commonly seen in jQuery
> plugins.
>
> The important points seemed to be:
> - Plugins need a way to maintain state from one call to the next
> (generally in the form of 'options').
> - The state needs to be directly associated with the elements that they're
> called on
> - There needs to be a default set of options to load state from
> - Plugins need to clean-up any events or data that they bind to an element
> - All methods introduced by a plugin should have access to the same state
>
> I put my code up here:
> http://dev.jquery.com/~john/plugins/widget/
> http://dev.jquery.com/~john/plugins/widget/widget.js
>
> This is how you would use it:
>
> The most basic call: Adds a single method (.test()) whose 'this' represents
> an individual element wrapped in a jQuery set. An empty options object is
> provided, as well.
>
> jQuery.plugin("test", function(a, b){
> this.options = a;
> this.hide(b);
> });
>
> jQuery("div").test("woo", "slow");
>
> Equivalent to the first style shown above.
>
> jQuery.plugin("test", {
> setup: function(a, b){
> this.options = a;
> this.hide(b);
> }
> });
>
> jQuery("div").test("woo", "slow");
>
> Next step up: A default set of options is provided - which implies that the
> first argument to .test() will be an options object.
>
> jQuery.plugin("test", {
> options: { speed: "slow" },
> setup: function(){
> this.hide( this.options.speed );
> }
> });
>
> jQuery("div").test({ speed: "fast" });
>
> Add in some related methods (related to the root setup method) that also
> have access to the instance and options.
>
> jQuery.plugin("test", {
> options: { speed: "slow" },
> setup: function(){
>
>
> this.hide( this.options.speed );
> },
> methods: {
> test2: function(){
> this.show( this.options.speed );
> }
> }
> });
>
> jQuery("div").test({ speed: "fast" }).test2();
>
> Remove some functionality added previously:
>
> jQuery.plugin("test", {
> options: { name: "test" },
> setup: function(){
> this.addClass( this.options.name );
>
>
> },
> teardown: function(){
> this.removeClass( this.options.name );
> }
> });
>
> jQuery("div").test({ name: "blah" });
>
> and the cleanup is triggered by (where 'test' is the name of the plugin
> that you wish to remove):
>
> jQuery("div").trigger("remove.test");
>
> It's not completely clear yet what will happen with the above plugin - I
> just wanted to put it out there since there was some interest in seeing it.
>
> --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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: bind "drag" events
On Sat, Oct 4, 2008 at 2:03 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote: > > According to Paul, implementing everything as a normal event became > prohibitively slow with large sets of draggables/droppables, which is why > certain things in their draggables are implemented as callbacks (for speed). > I personally think it's worth investigating the possibility of speeding up > jQuery's events to make them scale better. > Has this been tested since the major speed up with events in 1.2.6. This speed up might make it possible again to use events. -- Brandon Aaron --~--~-~--~~~---~--~~ 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: Unelegant Code
Although it seems like we are getting further off-topic... I often pass
around function references as strings. For example this is a common pattern
that I use.
$('div')[ test() ? 'doSomething' : 'doSomethingElse' ]();
Using something like $.callback is very explicit as to its purpose. After
all callback is exactly what we call it in the docs, etc. Granted I don't
mind using anonymous callbacks, if I need the code to be cleaner, I'll use
named functions to be even more explicit. But of the other proposals I like
$.callback the best.
--
Brandon Aaron
On Sat, Oct 4, 2008 at 9:56 AM, Cloudream <[EMAIL PROTECTED]> wrote:
>
> I do not like passing a jQuery method name as a string to one special
> method.
>
> A new (and a little strange) usage to jQuery.
>
> On Oct 4, 5:06 am, "Brandon Aaron" <[EMAIL PROTECTED]> wrote:
> > I'd prefer this as well.
> >
> > I think this also helps a few common cases of var self = $(this);
> > --
> > Brandon Aaron
> >
> > On Fri, Oct 3, 2008 at 4:01 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> > > $.callback("addClass", "hello") is ok with me.
> > > -- Yehuda
> >
> > > On Fri, Oct 3, 2008 at 1:58 PM, Ariel Flesler <[EMAIL PROTECTED]>
> wrote:
> >
> > >> Yeah, well. We could provide an interface for registering these
> methods
> > >> for those plugins that are interested. Still, someone could expect a
> method
> > >> to be registered when it's not.
> >
> > >> The other option is to pass the method name as first argument, works
> > >> around this but it loses the I-call-the-analog-method thing.
> >
> > >> On Fri, Oct 3, 2008 at 5:51 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> >
> > >>> The only tricky thing here is that because JS has no method_missing
> or
> > >>> cross-browse __noSuchMethod__, we'd be forced to explicitly write all
> the
> > >>> proxies, which could become messy when they work for core methods,
> but not
> > >>> all plugins.
> > >>> Or maybe I'm just being a nervous nelly.
> >
> > >>> -- Yehuda
> >
> > >>> On Fri, Oct 3, 2008 at 1:46 PM, Ariel Flesler <[EMAIL PROTECTED]
> >wrote:
> >
> > >>>> Note that John's code doesn't do actual currying, but partial
> > >>>> evaluation.
> >
> > >>>>http://en.wikipedia.org/wiki/Partial_evaluation
> >
> > >>>> Currying is a complex concept in comparison to the latter.
> > >>>> Anyway, you can change the name if you want, the idea is simple,
> create
> > >>>> a closure with fixed parameters.
> > >>>> We can name it callback (though it's long)
> >
> > >>>> jQuery("#test").hide("slow", jQuery.callback.show("slow") );
> >
> > >>>> Not to hard to understand IMO, and no CS involved :)
> >
> > >>>> On Fri, Oct 3, 2008 at 5:41 PM, Yehuda Katz <[EMAIL PROTECTED]>
> wrote:
> >
> > >>>>> As in Computer Science.
> > >>>>> Using a currying function requires people new to jQuery to go look
> it
> > >>>>> up, where they'll encounter:
> >
> > >>>>>http://en.wikipedia.org/wiki/Curry
> >
> > >>>>> and probably eventually:
> >
> > >>>>>http://en.wikipedia.org/wiki/Currying
> >
> > >>>>> "Given a function *f* of type [image: f \colon (X \times Y) \to Z],
> > >>>>> then *currying* it makes a function [image: \mbox{curry}(f) \colon
> X
> > >>>>> \to (Y \to Z)]. That is, curry(*f*) takes an argument of type *X*
> and
> > >>>>> returns a function of type [image: Y \to Z].*Uncurrying* is the
> > >>>>> reverse transformation."
> >
> > >>>>> Prototype added features like this to 1.6, and while they're
> > >>>>> interesting and useful, they make it hard for people coming to a
> codebase
> > >>>>> (especially people new to the framework) to understand what's
> happening in
> > >>>>> the code.
> >
> > >>>>> On Fri, Oct 3, 2008 at 1:34 PM, Ariel Flesler <[EMAIL PROTECTED]
> >wrote:
> >
> > >>>>>> CS as in Counter Strike ? :D
> > >>>>>> Heh, no really..
[jquery-dev] Re: Packaging format for jQuery plugins
I'm all for this. Seems like we'd want a standard repository/location to
store these "packaged" plugins with the %imgDir% applied, etc. Maybe on
plugins.jquery.com or maybe on a new sub-domain like
packages.jquery.comthat just follows a particular directory structure
and naming scheme.
--
Brandon Aaron
On Fri, Oct 3, 2008 at 1:31 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> For a while, I've been trying to make it possible to build a system to
> automatically install jQuery plugins into an application. In particular,
> I've wanted to be able to let Merb (a Ruby web framework I maintain --
> http://merbivore.com/) install jQuery plugins simply and easily.
> There are a few problems I needed to see solved:
>
>- A way for package authors to describe the locations of the javascript
>files, the CSS files, and any images
>- A way for package authors to declare required dependencies
>- A way to write CSS files that don't need to provide explicit image
>paths
>
> I want to propose a packaging format that plugin authors can use. To get
> the ball rolling, I'm proposing a JSON file called metadata.json:
>
> {
> "name": "tabs.jquery",
> "author": "Yehuda Katz",
> "dependencies": [
> "core.ui.jquery",
> "mouse.ui.jquery"
> ],
> "javascript": [
> "lib/utility.tabs.jquery",
> "lib/tabs.jquery",
> ],
> "cssDir": "css",
> "imageDir": "images"
> }
>
> Additionally, I'd like to propose that CSS files containing image paths use
> the token %imageDir% to refer to the directory where the images will be
> placed. This will allow automated tools (or even users themselves) to
> quickly modify CSS files with the correct relative (or absolute) path.
>
> Does this stuff make sense? People seemed to be, in general, in favor of a
> more consistent package format, so I thought I'd get the ball rolling here.
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> >
>
--~--~-~--~~~---~--~~
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: Unelegant Code
I'd prefer this as well.
I think this also helps a few common cases of var self = $(this);
--
Brandon Aaron
On Fri, Oct 3, 2008 at 4:01 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> $.callback("addClass", "hello") is ok with me.
> -- Yehuda
>
>
> On Fri, Oct 3, 2008 at 1:58 PM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
>
>> Yeah, well. We could provide an interface for registering these methods
>> for those plugins that are interested. Still, someone could expect a method
>> to be registered when it's not.
>>
>> The other option is to pass the method name as first argument, works
>> around this but it loses the I-call-the-analog-method thing.
>>
>>
>> On Fri, Oct 3, 2008 at 5:51 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>>
>>> The only tricky thing here is that because JS has no method_missing or
>>> cross-browse __noSuchMethod__, we'd be forced to explicitly write all the
>>> proxies, which could become messy when they work for core methods, but not
>>> all plugins.
>>> Or maybe I'm just being a nervous nelly.
>>>
>>> -- Yehuda
>>>
>>>
>>> On Fri, Oct 3, 2008 at 1:46 PM, Ariel Flesler <[EMAIL PROTECTED]>wrote:
>>>
>>>> Note that John's code doesn't do actual currying, but partial
>>>> evaluation.
>>>>
>>>> http://en.wikipedia.org/wiki/Partial_evaluation
>>>>
>>>> Currying is a complex concept in comparison to the latter.
>>>> Anyway, you can change the name if you want, the idea is simple, create
>>>> a closure with fixed parameters.
>>>> We can name it callback (though it's long)
>>>>
>>>> jQuery("#test").hide("slow", jQuery.callback.show("slow") );
>>>>
>>>> Not to hard to understand IMO, and no CS involved :)
>>>>
>>>>
>>>> On Fri, Oct 3, 2008 at 5:41 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> As in Computer Science.
>>>>> Using a currying function requires people new to jQuery to go look it
>>>>> up, where they'll encounter:
>>>>>
>>>>> http://en.wikipedia.org/wiki/Curry
>>>>>
>>>>> and probably eventually:
>>>>>
>>>>> http://en.wikipedia.org/wiki/Currying
>>>>>
>>>>> "Given a function *f* of type [image: f \colon (X \times Y) \to Z],
>>>>> then *currying* it makes a function [image: \mbox{curry}(f) \colon X
>>>>> \to (Y \to Z)]. That is, curry(*f*) takes an argument of type *X* and
>>>>> returns a function of type [image: Y \to Z].*Uncurrying* is the
>>>>> reverse transformation."
>>>>>
>>>>>
>>>>> Prototype added features like this to 1.6, and while they're
>>>>> interesting and useful, they make it hard for people coming to a codebase
>>>>> (especially people new to the framework) to understand what's happening in
>>>>> the code.
>>>>>
>>>>>
>>>>> On Fri, Oct 3, 2008 at 1:34 PM, Ariel Flesler <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>> CS as in Counter Strike ? :D
>>>>>> Heh, no really... what is CS, forgive my ignorance :P
>>>>>>
>>>>>> On Fri, Oct 3, 2008 at 5:30 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> Any feature that requires knowledge of CS is a no-go in my book :P
>>>>>>> -- Yehuda
>>>>>>>
>>>>>>> On Fri, Oct 3, 2008 at 1:27 PM, Ariel Flesler <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> Eh, nothing, got it wrong.
>>>>>>>>
>>>>>>>> We could just save all these methods on a special object.
>>>>>>>>
>>>>>>>> jQuery("#test").hide("slow", jQuery.curry.show("slow") );
>>>>>>>>
>>>>>>>> The name could be changed of course.
>>>>>>>>
>>>>>>>> Or renamed methods (probably bad option)
>>>>>>>>
>>>>>>>> jQuery("#test").hide("slow", jQuery.curriedShow("slow") );
>>>>>>>>
>>>>>>>> On Fri, Oct 3, 2008 at 5:14 PM, John Resig &l
