Re: [jquery-dev] About the group

[John Resig]

There will be a way to subscribe to threads but it's likely that the
predominant manner of interfacing with it will be through the web
site.

--John



On Fri, Dec 18, 2009 at 12:51 AM, Julian Aubourg
 wrote:
> Never heard of it before (Zoho) but the interface seems nice... I guess that
> means no more gmail or is there a way to get the messages sent to our
> mailbox automagically?
>
> Anyway, kudos for the efforts, switching from one discussion system to
> another is always a nightmare.
>
> 2009/12/18 John Resig 
>>
>> We've already exported all the data and we're in the process of
>> putting together the final details of our new solution (we're
>> switching to Zoho Discussion). We're planning on making the switch
>> over the holiday break and will make the final push on Jan. 4th. We'll
>> have plenty more details when we get closer to the final switch.
>>
>> --John
>>
>>
>>
>> On Thu, Dec 17, 2009 at 8:33 PM, Julian Aubourg
>>  wrote:
>> > I was browsing John's blog (because I sometimes like a good read) and I
>> > came
>> > upon this post I hadn't seen before:
>> > http://ejohn.org/blog/google-groups-is-dead/
>> >
>> > First of all, thanks to all those that moderate this list and the others
>> > (I
>> > wasn't aware of the nightmare behind). I was curious, though, as to the
>> > state of the migration. Where, what, when? Just being curious after a
>> > looong day of work.
>> >
>> > --
>> >
>> > 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.
>>
>>
>
> --
>
> 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] About the group

[Julian Aubourg]

Never heard of it before (Zoho) but the interface seems nice... I guess that
means no more gmail or is there a way to get the messages sent to our
mailbox automagically?

Anyway, kudos for the efforts, switching from one discussion system to
another is always a nightmare.

2009/12/18 John Resig 

> We've already exported all the data and we're in the process of
> putting together the final details of our new solution (we're
> switching to Zoho Discussion). We're planning on making the switch
> over the holiday break and will make the final push on Jan. 4th. We'll
> have plenty more details when we get closer to the final switch.
>
> --John
>
>
>
> On Thu, Dec 17, 2009 at 8:33 PM, Julian Aubourg
>  wrote:
> > I was browsing John's blog (because I sometimes like a good read) and I
> came
> > upon this post I hadn't seen before:
> > http://ejohn.org/blog/google-groups-is-dead/
> >
> > First of all, thanks to all those that moderate this list and the others
> (I
> > wasn't aware of the nightmare behind). I was curious, though, as to the
> > state of the migration. Where, what, when? Just being curious after a
> > looong day of work.
> >
> > --
> >
> > 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.
>
>
>

--

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] BUG :visible broken in IE8 on element following a display:inline

[John Resig]

Hi Geoffrey -

I saw your bug pop up and while I haven't had time to dig into the
test case yet I do agree about the suckage. I hope to be able to
investigate the issue some more, soon.

--John



On Thu, Dec 17, 2009 at 2:24 PM, Geoffrey  wrote:
> I have entered bug #5670 for this issue. Details are in the bug.
>
> High level:
>  in IE8
> a hidden div following a div with display:inline will be reported as
> visible
>
> IE reports the the height and width as greater than 0 for the hidden
> div when if follows an inline div
>
> This sucks
>
> --
>
> 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] About the group

[John Resig]

We've already exported all the data and we're in the process of
putting together the final details of our new solution (we're
switching to Zoho Discussion). We're planning on making the switch
over the holiday break and will make the final push on Jan. 4th. We'll
have plenty more details when we get closer to the final switch.

--John



On Thu, Dec 17, 2009 at 8:33 PM, Julian Aubourg
 wrote:
> I was browsing John's blog (because I sometimes like a good read) and I came
> upon this post I hadn't seen before:
> http://ejohn.org/blog/google-groups-is-dead/
>
> First of all, thanks to all those that moderate this list and the others (I
> wasn't aware of the nightmare behind). I was curious, though, as to the
> state of the migration. Where, what, when? Just being curious after a
> looong day of work.
>
> --
>
> 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.

[jquery-dev] jQuery 1.1.2 ready() method causes IE7 problems?

[Matt]

I debugged a tricky problem today in an app that came down to jQuery
hanging IE. I know v1.1.2 is ancient, but I am trying to understand
the root cause, so I'm just curious if anyone else has seen anything
like this. Just trying to gather info.

The problem:
On one page in a webapp, the content is fully delivered but IE
continues showing the "spinner" and "Waiting for ..." appears in the
status bar. jQuery's ready() event doesn't fire and IE just hangs in
that state.

Here is the info:
1) jQuery 1.1.2, IE7 on a dual-core HP laptop
2) Problem only happens in above configuration, and even then it is
"random". When BIOS is changed to disable dual-core, problem
disappears
3) When the IE "hack" to detect domcontentloaded is removed from the
jQuery source (and window.onload is used instead), the problem
disappears

Apparently, the hack of inserting the 

[jquery-dev] BUG :visible broken in IE8 on element following a display:inline

[Geoffrey]

I have entered bug #5670 for this issue. Details are in the bug.

High level:
 in IE8
a hidden div following a div with display:inline will be reported as
visible

IE reports the the height and width as greater than 0 for the hidden
div when if follows an inline div

This sucks

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] About the group

[Julian Aubourg]

I was browsing John's blog (because I sometimes like a good read) and I came
upon this post I hadn't seen before:
http://ejohn.org/blog/google-groups-is-dead/

First of all, thanks to all those that moderate this list and the others (I
wasn't aware of the nightmare behind). I was curious, though, as to the
state of the migration. Where, what, when? Just being curious after a
looong day of work.

--

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] $.fn.contains is not consistent with :contains

[Karl Swedberg]

I see. Yeah, that might work, except that Sizzle is currently very  
liberal about quotation marks:

PSEUDO: /:((?:[\w\u00c0-\u-]|\\.)+)(?:\((['"]*)((?:\([^\)]+\)|[^\2\ 
(\)]*)+)\2\))?/

I think it's a fairly common misconception that you have to use quotes  
within match[3], so at best it would take a lot of re-education and at  
worst it would break a lot of code.

--Karl

p.s. sorry about the tone of my last email. I just re-read what I  
wrote (the "how in the world" part, especially), and I think I sounded  
like an arrogant bastard. My apologies.

On Dec 17, 2009, at 5:08 PM, Matt Maxwell wrote:

> The text search would be surrounded by quotes, whereas searching by  
> an actual selector would not be in quotes, i.e.
> $("div:contains(p)") would find all descendant p elements
> $("div:contains('bar')") would find all divs containing the text 'bar'
>
> etc, etc
>
> Though, John makes a good point.  I guess the way I see it is,  
> jQuery already has a pretty intuitive design, and this sounded right  
> up its alley to me.
>
> Just my idea.  Obviously, if it doesn't fit the bill, don't go with  
> it.
>
> On Thu, Dec 17, 2009 at 4:02 PM, Karl Swedberg  
>  wrote:
> how in the world would jQuery know if you're trying to filter on the  
> text content "div" or on a descendant div element?
>
> --Karl
>
> On Dec 17, 2009, at 4:35 PM, Matt Maxwell wrote:
>
>> It's a selector or a string of text.  jQuery already contains the  
>> ability to intuitively decipher its selectors.
>>
>> For example, filter can contain an expression or a function.  These  
>> are two completely different things as well.
>>
>> On Thu, Dec 17, 2009 at 3:13 PM, Karl Swedberg  
>>  wrote:
>> But :has() and :contains() do two completely different  
>> things. :contains() filters based on text contents while :has()  
>> filters based on selectors. So, I think it would be a really bad  
>> idea to try to combine them.
>>
>> --Karl
>>
>>
>> On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:
>>
>>> I think .has() should return a bool, :has() should be combined  
>>> with :contains() (the finished filter named :contains()),  
>>> and .contains() should go away.
>>>
>>> That seems to make the most sense to me, anyways.
>>>
>>> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg >> > wrote:
>>> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>>>
 People are use to using .has()? It was only just added - at the  
 same
 time as .contains() as well.

 I'll mull over the .contains() discrepancy. I may just punt it and
 push people towards .has() anyway.

 Looking at .has() now I'm not 100% sure why it's filtering and not
 just returning a boolean, like .is(). Hmm. If .has() returns a  
 boolean
 then yeah, consider .contains() gone (and a jQuery.contains will be
 provided for those that need a lightweight method).

 --John
>>>
>>>
>>> But if .has() returns a boolean, then we have the same problem  
>>> with :has() vs. .has() as we had with :contains() vs. contains().
>>>
>>> Since :has() is a filter, I would expect .has() to be a filter.
>>>
>>> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
 John, I tend to assume that anything prefixed with 'is' or 'has'  
 will return a boolean. I think this is likely a common assumption.
>>>
>>> I typically assume the same thing, but in this case .has() is not  
>>> a prefix; it's the full method name. And we already have the  
>>> pseudo-selector :has() that acts as a filter.
>>>
>>>
>>> --Karl
>>>
 On Wed, Dec 16, 2009 at 11:04 PM, ajpiano   
 wrote:
> It seems like a matter of course that means of filtering that are
> exposed as both pseudoselectors and methods on the jQuery  
> prototype
> return the same set of elements, or at least that they generally  
> apply
> the same principle in filtering.  Examples include eq, not, first,
> last, and has.  While the :parent pseduo doesn't work the same
> as .parent(), most developers know what they're looking for if  
> they're
> using :parent.
>
> The new $.fn.contains method, however, doesn't work  
> like :contains.
> Rather than searching for the text content of  
> elements, .contains() is
> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure  
> why
> this is really a necessary shortcut, given that most people are  
> plenty
> used to doing something like .has().length anyway.  I tend to  
> think,
> however, that .contains () should work like :contains, for
> consistency's sake.
>
> This would have the added benefit of allowing those people who do
> use :contains to write code like this:
>
> var foo = "barbazbat";
> $("div").contains(foo);
>
> instead of
> $("div:contains("+foo+")");
>
> Anyone else have any thoughts on this?
>
> --adam
>
> --
>
> You received this message because you are subscribed to the  
> Goo

[jquery-dev] jquery.color.js no longer maintained?

[John Arrowwood]

All,

I got bit by a number of bugs in the Color Animations plugin.  So, I fixed
them and uploaded the fix to the comments on the issue I submitted against
it.

Then I noticed, other people have submitted patches as far back as almost 2
years ago.  So it looks like this module is no longer being actively
maintained.

If that is the case, how do we go about getting a new release out there?

More importantly, when will this functionality be added to the core?  :)

-- 
John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com
--
http://arrowwood.blogspot.com
Pablo Picasso
- "Computers are useless. They can only give you answers."

--

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] $.fn.contains is not consistent with :contains

[Matt Maxwell]

The text search would be surrounded by quotes, whereas searching by an
actual selector would not be in quotes, i.e.
$("div:contains(p)") would find all descendant p elements
$("div:contains('bar')") would find all divs containing the text 'bar'

etc, etc

Though, John makes a good point.  I guess the way I see it is, jQuery
already has a pretty intuitive design, and this sounded right up its alley
to me.

Just my idea.  Obviously, if it doesn't fit the bill, don't go with it.

On Thu, Dec 17, 2009 at 4:02 PM, Karl Swedberg wrote:

> how in the world would jQuery know if you're trying to filter on the text
> content "div" or on a descendant div element?
>
> --Karl
>
> On Dec 17, 2009, at 4:35 PM, Matt Maxwell wrote:
>
> It's a selector or a string of text.  jQuery already contains the ability
> to intuitively decipher its selectors.
>
> For example, filter can contain an expression or a function.  These are two
> completely different things as well.
>
> On Thu, Dec 17, 2009 at 3:13 PM, Karl Swedberg wrote:
>
>> But :has() and :contains() do two completely different things. :contains()
>> filters based on text contents while :has() filters based on selectors. So,
>> I think it would be a really bad idea to try to combine them.
>>
>> --Karl
>>
>>
>> On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:
>>
>> I think .has() should return a bool, :has() should be combined with
>> :contains() (the finished filter named :contains()), and .contains() should
>> go away.
>>
>> That seems to make the most sense to me, anyways.
>>
>> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg wrote:
>>
>>> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>>>
>>> People are use to using .has()? It was only just added - at the same
>>> time as .contains() as well.
>>>
>>> I'll mull over the .contains() discrepancy. I may just punt it and
>>> push people towards .has() anyway.
>>>
>>> Looking at .has() now I'm not 100% sure why it's filtering and not
>>> just returning a boolean, like .is(). Hmm. If .has() returns a boolean
>>> then yeah, consider .contains() gone (and a jQuery.contains will be
>>> provided for those that need a lightweight method).
>>>
>>> --John
>>>
>>>
>>> But if .has() returns a boolean, then we have the same problem with
>>> :has() vs. .has() as we had with :contains() vs. contains().
>>>
>>> Since :has() is a filter, I would expect .has() to be a filter.
>>>
>>> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>>>
>>> John, I tend to assume that anything prefixed with 'is' or 'has' will
>>> return a boolean. I think this is likely a common assumption.
>>>
>>>
>>> I typically assume the same thing, but in this case .has() is not a
>>> prefix; it's the full method name. And we already have the pseudo-selector
>>> :has() that acts as a filter.
>>>
>>>
>>>  --Karl
>>>
>>> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>>>
>>> It seems like a matter of course that means of filtering that are
>>>
>>> exposed as both pseudoselectors and methods on the jQuery prototype
>>>
>>> return the same set of elements, or at least that they generally apply
>>>
>>> the same principle in filtering.  Examples include eq, not, first,
>>>
>>> last, and has.  While the :parent pseduo doesn't work the same
>>>
>>> as .parent(), most developers know what they're looking for if they're
>>>
>>> using :parent.
>>>
>>>
>>> The new $.fn.contains method, however, doesn't work like :contains.
>>>
>>> Rather than searching for the text content of elements, .contains() is
>>>
>>> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>>>
>>> this is really a necessary shortcut, given that most people are plenty
>>>
>>> used to doing something like .has().length anyway.  I tend to think,
>>>
>>> however, that .contains () should work like :contains, for
>>>
>>> consistency's sake.
>>>
>>>
>>> This would have the added benefit of allowing those people who do
>>>
>>> use :contains to write code like this:
>>>
>>>
>>> var foo = "barbazbat";
>>>
>>> $("div").contains(foo);
>>>
>>>
>>> instead of
>>>
>>> $("div:contains("+foo+")");
>>>
>>>
>>> Anyone else have any thoughts on this?
>>>
>>>
>>> --adam
>>>
>>>
>>> --
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> --
>>> You received this messa

Re: [jquery-dev] $.fn.contains is not consistent with :contains

[Karl Swedberg]

how in the world would jQuery know if you're trying to filter on the  
text content "div" or on a descendant div element?

--Karl

On Dec 17, 2009, at 4:35 PM, Matt Maxwell wrote:

> It's a selector or a string of text.  jQuery already contains the  
> ability to intuitively decipher its selectors.
>
> For example, filter can contain an expression or a function.  These  
> are two completely different things as well.
>
> On Thu, Dec 17, 2009 at 3:13 PM, Karl Swedberg  
>  wrote:
> But :has() and :contains() do two completely different  
> things. :contains() filters based on text contents while :has()  
> filters based on selectors. So, I think it would be a really bad  
> idea to try to combine them.
>
> --Karl
>
>
> On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:
>
>> I think .has() should return a bool, :has() should be combined  
>> with :contains() (the finished filter named :contains()),  
>> and .contains() should go away.
>>
>> That seems to make the most sense to me, anyways.
>>
>> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg  
>>  wrote:
>> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>>
>>> People are use to using .has()? It was only just added - at the same
>>> time as .contains() as well.
>>>
>>> I'll mull over the .contains() discrepancy. I may just punt it and
>>> push people towards .has() anyway.
>>>
>>> Looking at .has() now I'm not 100% sure why it's filtering and not
>>> just returning a boolean, like .is(). Hmm. If .has() returns a  
>>> boolean
>>> then yeah, consider .contains() gone (and a jQuery.contains will be
>>> provided for those that need a lightweight method).
>>>
>>> --John
>>
>>
>> But if .has() returns a boolean, then we have the same problem  
>> with :has() vs. .has() as we had with :contains() vs. contains().
>>
>> Since :has() is a filter, I would expect .has() to be a filter.
>>
>> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>>> John, I tend to assume that anything prefixed with 'is' or 'has'  
>>> will return a boolean. I think this is likely a common assumption.
>>
>> I typically assume the same thing, but in this case .has() is not a  
>> prefix; it's the full method name. And we already have the pseudo- 
>> selector :has() that acts as a filter.
>>
>>
>> --Karl
>>
>>> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
 It seems like a matter of course that means of filtering that are
 exposed as both pseudoselectors and methods on the jQuery prototype
 return the same set of elements, or at least that they generally  
 apply
 the same principle in filtering.  Examples include eq, not, first,
 last, and has.  While the :parent pseduo doesn't work the same
 as .parent(), most developers know what they're looking for if  
 they're
 using :parent.

 The new $.fn.contains method, however, doesn't work like :contains.
 Rather than searching for the text content of  
 elements, .contains() is
 just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
 this is really a necessary shortcut, given that most people are  
 plenty
 used to doing something like .has().length anyway.  I tend to  
 think,
 however, that .contains () should work like :contains, for
 consistency's sake.

 This would have the added benefit of allowing those people who do
 use :contains to write code like this:

 var foo = "barbazbat";
 $("div").contains(foo);

 instead of
 $("div:contains("+foo+")");

 Anyone else have any thoughts on this?

 --adam

 --

 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 
>>> .
>>>
>>>
>>
>>
>> --
>>
>> 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.
>> T

Re: [jquery-dev] $.fn.contains is not consistent with :contains

[John Resig]

There's no place in jQuery where we accept a selector of a string of
text. There are places where we accept a selector or an HTML string -
but that's another matter entirely.

--John



On Thu, Dec 17, 2009 at 4:35 PM, Matt Maxwell
 wrote:
> It's a selector or a string of text.  jQuery already contains the ability to
> intuitively decipher its selectors.
> For example, filter can contain an expression or a function.  These are two
> completely different things as well.
>
> On Thu, Dec 17, 2009 at 3:13 PM, Karl Swedberg 
> wrote:
>>
>> But :has() and :contains() do two completely different things. :contains()
>> filters based on text contents while :has() filters based on selectors. So,
>> I think it would be a really bad idea to try to combine them.
>>
>> --Karl
>>
>> On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:
>>
>> I think .has() should return a bool, :has() should be combined with
>> :contains() (the finished filter named :contains()), and .contains() should
>> go away.
>> That seems to make the most sense to me, anyways.
>> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg 
>> wrote:
>>>
>>> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>>>
>>> People are use to using .has()? It was only just added - at the same
>>> time as .contains() as well.
>>>
>>> I'll mull over the .contains() discrepancy. I may just punt it and
>>> push people towards .has() anyway.
>>>
>>> Looking at .has() now I'm not 100% sure why it's filtering and not
>>> just returning a boolean, like .is(). Hmm. If .has() returns a boolean
>>> then yeah, consider .contains() gone (and a jQuery.contains will be
>>> provided for those that need a lightweight method).
>>>
>>> --John
>>>
>>> But if .has() returns a boolean, then we have the same problem with
>>> :has() vs. .has() as we had with :contains() vs. contains().
>>> Since :has() is a filter, I would expect .has() to be a filter.
>>> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>>>
>>> John, I tend to assume that anything prefixed with 'is' or 'has' will
>>> return a boolean. I think this is likely a common assumption.
>>>
>>> I typically assume the same thing, but in this case .has() is not a
>>> prefix; it's the full method name. And we already have the pseudo-selector
>>> :has() that acts as a filter.
>>>
>>> --Karl
>>>
>>> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>>>
>>> It seems like a matter of course that means of filtering that are
>>>
>>> exposed as both pseudoselectors and methods on the jQuery prototype
>>>
>>> return the same set of elements, or at least that they generally apply
>>>
>>> the same principle in filtering.  Examples include eq, not, first,
>>>
>>> last, and has.  While the :parent pseduo doesn't work the same
>>>
>>> as .parent(), most developers know what they're looking for if they're
>>>
>>> using :parent.
>>>
>>> The new $.fn.contains method, however, doesn't work like :contains.
>>>
>>> Rather than searching for the text content of elements, .contains() is
>>>
>>> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>>>
>>> this is really a necessary shortcut, given that most people are plenty
>>>
>>> used to doing something like .has().length anyway.  I tend to think,
>>>
>>> however, that .contains () should work like :contains, for
>>>
>>> consistency's sake.
>>>
>>> This would have the added benefit of allowing those people who do
>>>
>>> use :contains to write code like this:
>>>
>>> var foo = "barbazbat";
>>>
>>> $("div").contains(foo);
>>>
>>> instead of
>>>
>>> $("div:contains("+foo+")");
>>>
>>> Anyone else have any thoughts on this?
>>>
>>> --adam
>>>
>>> --
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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 u

Re: [jquery-dev] $.fn.contains is not consistent with :contains

[Matt Maxwell]

It's a selector or a string of text.  jQuery already contains the ability to
intuitively decipher its selectors.

For example, filter can contain an expression or a function.  These are two
completely different things as well.

On Thu, Dec 17, 2009 at 3:13 PM, Karl Swedberg wrote:

> But :has() and :contains() do two completely different things. :contains()
> filters based on text contents while :has() filters based on selectors. So,
> I think it would be a really bad idea to try to combine them.
>
> --Karl
>
>
> On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:
>
> I think .has() should return a bool, :has() should be combined with
> :contains() (the finished filter named :contains()), and .contains() should
> go away.
>
> That seems to make the most sense to me, anyways.
>
> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg wrote:
>
>> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>>
>> People are use to using .has()? It was only just added - at the same
>> time as .contains() as well.
>>
>> I'll mull over the .contains() discrepancy. I may just punt it and
>> push people towards .has() anyway.
>>
>> Looking at .has() now I'm not 100% sure why it's filtering and not
>> just returning a boolean, like .is(). Hmm. If .has() returns a boolean
>> then yeah, consider .contains() gone (and a jQuery.contains will be
>> provided for those that need a lightweight method).
>>
>> --John
>>
>>
>> But if .has() returns a boolean, then we have the same problem with :has()
>> vs. .has() as we had with :contains() vs. contains().
>>
>> Since :has() is a filter, I would expect .has() to be a filter.
>>
>> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>>
>> John, I tend to assume that anything prefixed with 'is' or 'has' will
>> return a boolean. I think this is likely a common assumption.
>>
>>
>> I typically assume the same thing, but in this case .has() is not a
>> prefix; it's the full method name. And we already have the pseudo-selector
>> :has() that acts as a filter.
>>
>>
>>  --Karl
>>
>> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>>
>> It seems like a matter of course that means of filtering that are
>>
>> exposed as both pseudoselectors and methods on the jQuery prototype
>>
>> return the same set of elements, or at least that they generally apply
>>
>> the same principle in filtering.  Examples include eq, not, first,
>>
>> last, and has.  While the :parent pseduo doesn't work the same
>>
>> as .parent(), most developers know what they're looking for if they're
>>
>> using :parent.
>>
>>
>> The new $.fn.contains method, however, doesn't work like :contains.
>>
>> Rather than searching for the text content of elements, .contains() is
>>
>> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>>
>> this is really a necessary shortcut, given that most people are plenty
>>
>> used to doing something like .has().length anyway.  I tend to think,
>>
>> however, that .contains () should work like :contains, for
>>
>> consistency's sake.
>>
>>
>> This would have the added benefit of allowing those people who do
>>
>> use :contains to write code like this:
>>
>>
>> var foo = "barbazbat";
>>
>> $("div").contains(foo);
>>
>>
>> instead of
>>
>> $("div:contains("+foo+")");
>>
>>
>> Anyone else have any thoughts on this?
>>
>>
>> --adam
>>
>>
>> --
>>
>>
>> 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.
>>
>>
>>
>>
>> --
>> 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.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to jquery-...@go

Re: [jquery-dev] $.fn.contains is not consistent with :contains

[Karl Swedberg]

But :has() and :contains() do two completely different  
things. :contains() filters based on text contents while :has()  
filters based on selectors. So, I think it would be a really bad idea  
to try to combine them.

--Karl


On Dec 17, 2009, at 3:48 PM, Matt Maxwell wrote:

> I think .has() should return a bool, :has() should be combined  
> with :contains() (the finished filter named :contains()),  
> and .contains() should go away.
>
> That seems to make the most sense to me, anyways.
>
> On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg  
>  wrote:
> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>
>> People are use to using .has()? It was only just added - at the same
>> time as .contains() as well.
>>
>> I'll mull over the .contains() discrepancy. I may just punt it and
>> push people towards .has() anyway.
>>
>> Looking at .has() now I'm not 100% sure why it's filtering and not
>> just returning a boolean, like .is(). Hmm. If .has() returns a  
>> boolean
>> then yeah, consider .contains() gone (and a jQuery.contains will be
>> provided for those that need a lightweight method).
>>
>> --John
>
>
> But if .has() returns a boolean, then we have the same problem  
> with :has() vs. .has() as we had with :contains() vs. contains().
>
> Since :has() is a filter, I would expect .has() to be a filter.
>
> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>> John, I tend to assume that anything prefixed with 'is' or 'has'  
>> will return a boolean. I think this is likely a common assumption.
>
> I typically assume the same thing, but in this case .has() is not a  
> prefix; it's the full method name. And we already have the pseudo- 
> selector :has() that acts as a filter.
>
>
> --Karl
>
>> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>>> It seems like a matter of course that means of filtering that are
>>> exposed as both pseudoselectors and methods on the jQuery prototype
>>> return the same set of elements, or at least that they generally  
>>> apply
>>> the same principle in filtering.  Examples include eq, not, first,
>>> last, and has.  While the :parent pseduo doesn't work the same
>>> as .parent(), most developers know what they're looking for if  
>>> they're
>>> using :parent.
>>>
>>> The new $.fn.contains method, however, doesn't work like :contains.
>>> Rather than searching for the text content of  
>>> elements, .contains() is
>>> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>>> this is really a necessary shortcut, given that most people are  
>>> plenty
>>> used to doing something like .has().length anyway.  I tend to think,
>>> however, that .contains () should work like :contains, for
>>> consistency's sake.
>>>
>>> This would have the added benefit of allowing those people who do
>>> use :contains to write code like this:
>>>
>>> var foo = "barbazbat";
>>> $("div").contains(foo);
>>>
>>> instead of
>>> $("div:contains("+foo+")");
>>>
>>> Anyone else have any thoughts on this?
>>>
>>> --adam
>>>
>>> --
>>>
>>> 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 
>> .
>>
>>
>
>
> --
>
> 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 
> .

--

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] $.fn.contains is not consistent with :contains

[Matt Maxwell]

I think .has() should return a bool, :has() should be combined with
:contains() (the finished filter named :contains()), and .contains() should
go away.

That seems to make the most sense to me, anyways.

On Thu, Dec 17, 2009 at 9:20 AM, Karl Swedberg wrote:

> On Dec 16, 2009, at 11:14 PM, John Resig wrote:
>
> People are use to using .has()? It was only just added - at the same
> time as .contains() as well.
>
> I'll mull over the .contains() discrepancy. I may just punt it and
> push people towards .has() anyway.
>
> Looking at .has() now I'm not 100% sure why it's filtering and not
> just returning a boolean, like .is(). Hmm. If .has() returns a boolean
> then yeah, consider .contains() gone (and a jQuery.contains will be
> provided for those that need a lightweight method).
>
> --John
>
>
> But if .has() returns a boolean, then we have the same problem with :has()
> vs. .has() as we had with :contains() vs. contains().
>
> Since :has() is a filter, I would expect .has() to be a filter.
>
> On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
>
> John, I tend to assume that anything prefixed with 'is' or 'has' will
> return a boolean. I think this is likely a common assumption.
>
>
> I typically assume the same thing, but in this case .has() is not a prefix;
> it's the full method name. And we already have the pseudo-selector :has()
> that acts as a filter.
>
>
> --Karl
>
> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>
> It seems like a matter of course that means of filtering that are
>
> exposed as both pseudoselectors and methods on the jQuery prototype
>
> return the same set of elements, or at least that they generally apply
>
> the same principle in filtering.  Examples include eq, not, first,
>
> last, and has.  While the :parent pseduo doesn't work the same
>
> as .parent(), most developers know what they're looking for if they're
>
> using :parent.
>
>
> The new $.fn.contains method, however, doesn't work like :contains.
>
> Rather than searching for the text content of elements, .contains() is
>
> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>
> this is really a necessary shortcut, given that most people are plenty
>
> used to doing something like .has().length anyway.  I tend to think,
>
> however, that .contains () should work like :contains, for
>
> consistency's sake.
>
>
> This would have the added benefit of allowing those people who do
>
> use :contains to write code like this:
>
>
> var foo = "barbazbat";
>
> $("div").contains(foo);
>
>
> instead of
>
> $("div:contains("+foo+")");
>
>
> Anyone else have any thoughts on this?
>
>
> --adam
>
>
> --
>
>
> 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.
>
>
>
>  --
> 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.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Matt]

On Dec 17, 2:26 pm, Leeoniya  wrote:
> attr('width') would get the computed
> width but attr('width', '5') sets the width attribute? there's too
> much room for ambiguity in my opinion.

Just to clarify, in the case of width the width() method would get
called in both cases.

So
  $o.attr('width') == $o.width()
and
  $o.attr('width',5) == $o.width(5)

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-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Leeoniya]

i agree with matt on this 100%.

an attr() method should return the attribute's value, always. there
are way too many common cases when interpretation would make this
method unreliable and unusable. making something that has so much
functionality overlap with css() is not good at all, especially when
it is both a getter and a setter. attr('width') would get the computed
width but attr('width', '5') sets the width attribute? there's too
much room for ambiguity in my opinion.

if anything it is much more confusing for beginners, not easier...when
an attr() method returns NOT the value of attr, and will cause MANY
more problems than is solves. when you're a beginner, you dont need
magic methods with names that imply specific strict functionality.

you can introduce a new method..maybe getComputed(), .computed() or
something similar.

Leon

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Matt]

On Dec 17, 11:41 am, John Resig  wrote:
> Much of this comes back to the intention of .attr() - I think that
> .attr() should work more like .css(). Giving you the current,
> computed, attribute value - and should actively try to route around
> unexpected values (such as .value returning useless values on selects
> or making sure that rowSpan and colSpan will always return a value on
> TDs even if one isn't set).

Careful... that opens a can of worms.

If I have html like:

Then what should .attr('rows') return? The computed value is surely
not 5, but you can't get a computed value. Toss out that attribute?

Same would go for any attribute that can be over-ridden by css:

test
attr('bgcolor') => ???


attr('size') => ???

So do you make a list of presentation attributes and not support them
also? (there are quite a few)

> Actually, the compelling reason is that the specified attribute height
> will quickly lose sync with the actual height of the element.
> 
> $("iframe").height( 1 ).attr("height")
> // 100... but it's height isn't 100 any more.

The attribute still is! The computed height is not. With a method
named attr(), I would expect the former, not the latter.

> Getting the current, "computed", value is much more useful and
> practical to everyday users.

Only if it is logical and predictable. People calling attr() are
programmers, not casual computer users. The results of calling an API
should be very predictable, not open to interpretation and having 10
different outcomes depending on what you pass in, forcing a user to
consult a big table to see what they can expect to get back for each
input parameter. IMO.

> > On a related note, you said that the inserted method-calling
> > functionality was too broad. What attributes do you plan to map to
> > methods - just height and width? Or more?
> Initially it mapped to anything in jQuery.fn. Now it just maps to some
> of the common getter/setters in jQuery: val, css, html, text, data,
> width, height, and offset (and the events).

Hmmm... $('').attr('data') => ???

You may run into a number of cases that may need "special handling",
at which point you have to have really good documentation about the
intent of the method and what to expect. And as you go forward, you'll
probably find more "oops, I didn't think of that" situations where
this logic causes problems.

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-...@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: Timers in the jQuery core?

[stephb...@googlemail.com]

On Dec 16, 12:42 pm, Tobias Hoffmann 
wrote:

> Note that you can supply a step-callback:
>   jQuery.animate({},{step:function() {...}})

I noticed the other day that step gets called for every property in
the object being animated.  This is not clear in the documentation.  A
callback that fires only once all properties have been updated would
be useful.  I couldn't think of a neat way to implement one using
step.  Any ideas?

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: Timers in the jQuery core?

[stephb...@googlemail.com]

Here's a timer abstraction that I use. My most frequent gotcha with
setTimeout / setInterval is the scope of the function you pass in.
Here, the scope is always the timer object:

function Timer( fn, fd ) {
var self = this,
clock;

function update(){
self.frameCount++;
fn.call(self);
}

this.frameDuration = fd || 25 ;
this.frameCount = -1 ;
this.start = function(){
update();
clock = setInterval(update, this.frameDuration);
};
this.stop = function(){
clearInterval( clock );
clock = null;
};
}

Set it going with:

var thing = new Timer( function, frameDuration );
thing.start();

I'm not sure I see the need to include timers in the core, because the
plugin architecture is there for you to adapt jQuery specifically to
your project.

For an events-based way of animating (using the code above), check
out:

http://webdev.stephband.info/events/frame/

It allows you to start an animation timer simply by binding a 'frame'
event to something.  The act of binding starts the timer, and the
bound function gets called on every frame.

--

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: attr() is still very broken in 1.4a1

[John Resig]

> Actually, the compelling reason is that the specified attribute height
> will quickly lose sync with the actual height of the element.
>
> 
>
> $("iframe").height( 1 ).attr("height")
> // 100... but it's height isn't 100 any more.
>
> Getting the current, "computed", value is much more useful and
> practical to everyday users. height attributes are simply a bit of
> legacy left over from ancient documents (as is bgcolor and inline
> onTYPE event handlers). If we cut the crufty legacy code we can build
> APIs that are much more cohesive and match the intentions and
> expectations of the user better.

An alternative that might work here - and one that would go together
with a mapping of the available attributes - is to simply deprecate
the use of certain attributes (height, width, bgcolor, onTYPE, etc.
come to mind off hand). It's pretty easy to do if we just point people
towards the alternatives that we already provide. Then we can focus
all of our energy on just making the remaining set of attributes work
identically (and expectedly) across all platforms.

--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=en.

Re: [jquery-dev] Re: attr() is still very broken in 1.4a1

[John Resig]

> Like Karl said, I have had cases where I want to compare the current
> height of an element with what was specified. I've also had cases
> where height="x" were hard-coded in the html and I wanted to access
> the value (without having control over the html to use css, just
> injecting script into the page).

We don't provide a way to get at the original height, or color, or
left offset of an element via .css() and somehow people still manage -
I'm not sure why this should be any different. Additionally it's not
clear that .height() would be returning a different value than the one
that was originally embedded in the page (at least until it's further
manipulated - at which point the current value is the expected result
anyway).

Much of this comes back to the intention of .attr() - I think that
.attr() should work more like .css(). Giving you the current,
computed, attribute value - and should actively try to route around
unexpected values (such as .value returning useless values on selects
or making sure that rowSpan and colSpan will always return a value on
TDs even if one isn't set).

> I'm not sure that a good way to define requirements is to ask whether
> or not anyone would do it that way, and whether they had a good enough
> reason to do so. When attr() retrieves property/attribute values in
> almost all other cases, and the user can easily map the results to the
> source, then introducing new behavior with height() etc only adds
> confusion. You cannot explain simply what value will be returned,
> because the height() logic is convoluted. And it considers margins and
> padding, etc, which is _not_ the same as the height of the element
> itself.
>
> Here is my argument: Users can already get the computed height using
> height(). There is no compelling reason to return the computed height
> when doing attr('height'). In fact, making this change _removes_
> functionality, and forces the user to manually code property/attribute
> access if they want to retrieve the value in the source.

Actually, the compelling reason is that the specified attribute height
will quickly lose sync with the actual height of the element.



$("iframe").height( 1 ).attr("height")
// 100... but it's height isn't 100 any more.

Getting the current, "computed", value is much more useful and
practical to everyday users. height attributes are simply a bit of
legacy left over from ancient documents (as is bgcolor and inline
onTYPE event handlers). If we cut the crufty legacy code we can build
APIs that are much more cohesive and match the intentions and
expectations of the user better.

> On a related note, you said that the inserted method-calling
> functionality was too broad. What attributes do you plan to map to
> methods - just height and width? Or more?

Initially it mapped to anything in jQuery.fn. Now it just maps to some
of the common getter/setters in jQuery: val, css, html, text, data,
width, height, and offset (and the events).

--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=en.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Matt]

On Dec 17, 10:29 am, John Resig  wrote:
> I would be much more convinced if there were examples where:
> 1) People were legitimately using inline-specified height/width and in
> a way that was different from specifying the value in pixels and in
> way that was superior to using CSS.
> 2) The returned result from .height() (not .attr('height'), since
> that's been temporarily disabled) was somehow different from the
> expected value.

Like Karl said, I have had cases where I want to compare the current
height of an element with what was specified. I've also had cases
where height="x" were hard-coded in the html and I wanted to access
the value (without having control over the html to use css, just
injecting script into the page).

I'm not sure that a good way to define requirements is to ask whether
or not anyone would do it that way, and whether they had a good enough
reason to do so. When attr() retrieves property/attribute values in
almost all other cases, and the user can easily map the results to the
source, then introducing new behavior with height() etc only adds
confusion. You cannot explain simply what value will be returned,
because the height() logic is convoluted. And it considers margins and
padding, etc, which is _not_ the same as the height of the element
itself.

Here is my argument: Users can already get the computed height using
height(). There is no compelling reason to return the computed height
when doing attr('height'). In fact, making this change _removes_
functionality, and forces the user to manually code property/attribute
access if they want to retrieve the value in the source.

On a related note, you said that the inserted method-calling
functionality was too broad. What attributes do you plan to map to
methods - just height and width? Or more?

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-...@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: attr() is still very broken in 1.4a1

[John Resig]

Just to clarify: .attr("height") no longer exists.

--John



On Thu, Dec 17, 2009 at 11:47 AM, Karl Swedberg  wrote:
> I'm curious about what the rationale was for having .attr('height') return
> the same thing as .css('height'). Was it just in case people use the wrong
> method?
> I could see the usefulness of having .attr('height') return the actual
> attribute value in cases where, for example, I needed to see whether the
> current height of an element is less than or greater than the height set by
> the attribute.
>
> --Karl
>
> On Dec 17, 2009, at 11:29 AM, John Resig wrote:
>
> I would be much more convinced if there were examples where:
> 1) People were legitimately using inline-specified height/width and in
> a way that was different from specifying the value in pixels and in
> way that was superior to using CSS.
> 2) The returned result from .height() (not .attr('height'), since
> that's been temporarily disabled) was somehow different from the
> expected value.
>
> For the moment ignore XML documents, I think it probably makes sense
> to disable attrFn on XML documents.
>
> --John
>
>
>
> On Thu, Dec 17, 2009 at 6:45 AM, alexander farkas
>  wrote:
>
> The way how jQuery does mixing properties with attributes is a very
>
> clever thing. One simple API for multiple different things is a very
>
> nice thing, but has its constraints.
>
> An example:
>
> jQuery returns the value-property on form-elements, instead of the
>
> value-attribute. This is a really good thing, because
>
> a) a lot of novice developers don´t know about the difference and are
>
> expecting this behavior
>
> b) more advanced developers know the difference, but want in general
>
> to know the value-property of a form element
>
> With other words the developer gets what he/she wants/expects here.
>
> But if jQuery starts to make .attr('height') equal to .height(), the
>
> behavior becomes very unexpected. Everybody knows that the height-
>
> attribute can be simply "overridden" by using css. This is why a
>
> developer would use height to get the height-dimension of an element
>
> and if a developer wants to know what the height-attribute, he would
>
> call attr('height').
>
> If you change your API to this behavior you will
>
> a) break existing code
>
> a) do unexpected things
>
> b) you don´t have a jQuery-method, wich returns the height-/width-
>
> attribute anymore
>
> To be clear:
>
> I think, you did a great job mixing properties and attributes and if
>
> you know start to take this a step further, I am also on your side,
>
> but you have to make wisley decissions (and small steps) here.
>
> If you can solve the discrepancy in event-binding with attr, Robert is
>
> mentioing, it could be a nice feature, but please don´t do this with
>
> height/width!
>
> On 17 Dez., 11:28, Már Örlygsson  wrote:
>
> Never ever, would I have guessed that .attr('height') would report a
>
> value on elements that don't have an explicit height `attr`ibute.
>
> Somehow I have the feeling that it would be useful for developers to
>
> be able to access plain old element attributes - in a cross-browser
>
> way - without any overt aliasing/magic.
>
> --
>
> 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-...@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.
>
>
>
> --
>
> 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: attr() is still very broken in 1.4a1

[Karl Swedberg]

I'm curious about what the rationale was for having .attr('height')  
return the same thing as .css('height'). Was it just in case people  
use the wrong method?

I could see the usefulness of having .attr('height') return the actual  
attribute value in cases where, for example, I needed to see whether  
the current height of an element is less than or greater than the  
height set by the attribute.

--Karl


On Dec 17, 2009, at 11:29 AM, John Resig wrote:

> I would be much more convinced if there were examples where:
> 1) People were legitimately using inline-specified height/width and in
> a way that was different from specifying the value in pixels and in
> way that was superior to using CSS.
> 2) The returned result from .height() (not .attr('height'), since
> that's been temporarily disabled) was somehow different from the
> expected value.
>
> For the moment ignore XML documents, I think it probably makes sense
> to disable attrFn on XML documents.
>
> --John
>
>
>
> On Thu, Dec 17, 2009 at 6:45 AM, alexander farkas
>  wrote:
>> The way how jQuery does mixing properties with attributes is a very
>> clever thing. One simple API for multiple different things is a very
>> nice thing, but has its constraints.
>>
>> An example:
>>
>> jQuery returns the value-property on form-elements, instead of the
>> value-attribute. This is a really good thing, because
>> a) a lot of novice developers don´t know about the difference and are
>> expecting this behavior
>> b) more advanced developers know the difference, but want in general
>> to know the value-property of a form element
>>
>> With other words the developer gets what he/she wants/expects here.
>>
>> But if jQuery starts to make .attr('height') equal to .height(), the
>> behavior becomes very unexpected. Everybody knows that the height-
>> attribute can be simply "overridden" by using css. This is why a
>> developer would use height to get the height-dimension of an element
>> and if a developer wants to know what the height-attribute, he would
>> call attr('height').
>>
>> If you change your API to this behavior you will
>> a) break existing code
>> a) do unexpected things
>> b) you don´t have a jQuery-method, wich returns the height-/width-
>> attribute anymore
>>
>> To be clear:
>>
>> I think, you did a great job mixing properties and attributes and if
>> you know start to take this a step further, I am also on your side,
>> but you have to make wisley decissions (and small steps) here.
>>
>> If you can solve the discrepancy in event-binding with attr, Robert  
>> is
>> mentioing, it could be a nice feature, but please don´t do this with
>> height/width!
>>
>> On 17 Dez., 11:28, Már Örlygsson  wrote:
 Never ever, would I have guessed that .attr('height') would  
 report a
 value on elements that don't have an explicit height `attr`ibute.
>>>
>>> Somehow I have the feeling that it would be useful for developers to
>>> be able to access plain old element attributes - in a cross-browser
>>> way - without any overt aliasing/magic.
>>>
>>> --
>>> 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-...@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 
> .
>
>

--

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: attr() is still very broken in 1.4a1

[John Resig]

I would be much more convinced if there were examples where:
1) People were legitimately using inline-specified height/width and in
a way that was different from specifying the value in pixels and in
way that was superior to using CSS.
2) The returned result from .height() (not .attr('height'), since
that's been temporarily disabled) was somehow different from the
expected value.

For the moment ignore XML documents, I think it probably makes sense
to disable attrFn on XML documents.

--John



On Thu, Dec 17, 2009 at 6:45 AM, alexander farkas
 wrote:
> The way how jQuery does mixing properties with attributes is a very
> clever thing. One simple API for multiple different things is a very
> nice thing, but has its constraints.
>
> An example:
>
> jQuery returns the value-property on form-elements, instead of the
> value-attribute. This is a really good thing, because
> a) a lot of novice developers don´t know about the difference and are
> expecting this behavior
> b) more advanced developers know the difference, but want in general
> to know the value-property of a form element
>
> With other words the developer gets what he/she wants/expects here.
>
> But if jQuery starts to make .attr('height') equal to .height(), the
> behavior becomes very unexpected. Everybody knows that the height-
> attribute can be simply "overridden" by using css. This is why a
> developer would use height to get the height-dimension of an element
> and if a developer wants to know what the height-attribute, he would
> call attr('height').
>
> If you change your API to this behavior you will
> a) break existing code
> a) do unexpected things
> b) you don´t have a jQuery-method, wich returns the height-/width-
> attribute anymore
>
> To be clear:
>
> I think, you did a great job mixing properties and attributes and if
> you know start to take this a step further, I am also on your side,
> but you have to make wisley decissions (and small steps) here.
>
> If you can solve the discrepancy in event-binding with attr, Robert is
> mentioing, it could be a nice feature, but please don´t do this with
> height/width!
>
> On 17 Dez., 11:28, Már Örlygsson  wrote:
>> > Never ever, would I have guessed that .attr('height') would report a
>> > value on elements that don't have an explicit height `attr`ibute.
>>
>> Somehow I have the feeling that it would be useful for developers to
>> be able to access plain old element attributes - in a cross-browser
>> way - without any overt aliasing/magic.
>>
>> --
>> 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-...@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] $.fn.contains is not consistent with :contains

[Karl Swedberg]

On Dec 16, 2009, at 11:14 PM, John Resig wrote:

> People are use to using .has()? It was only just added - at the same
> time as .contains() as well.
>
> I'll mull over the .contains() discrepancy. I may just punt it and
> push people towards .has() anyway.
>
> Looking at .has() now I'm not 100% sure why it's filtering and not
> just returning a boolean, like .is(). Hmm. If .has() returns a boolean
> then yeah, consider .contains() gone (and a jQuery.contains will be
> provided for those that need a lightweight method).
>
> --John


But if .has() returns a boolean, then we have the same problem  
with :has() vs. .has() as we had with :contains() vs. contains().

Since :has() is a filter, I would expect .has() to be a filter.

On Dec 17, 2009, at 12:45 AM, Rick Waldron wrote:
> John, I tend to assume that anything prefixed with 'is' or 'has'  
> will return a boolean. I think this is likely a common assumption.

I typically assume the same thing, but in this case .has() is not a  
prefix; it's the full method name. And we already have the pseudo- 
selector :has() that acts as a filter.


--Karl

> On Wed, Dec 16, 2009 at 11:04 PM, ajpiano  wrote:
>> It seems like a matter of course that means of filtering that are
>> exposed as both pseudoselectors and methods on the jQuery prototype
>> return the same set of elements, or at least that they generally  
>> apply
>> the same principle in filtering.  Examples include eq, not, first,
>> last, and has.  While the :parent pseduo doesn't work the same
>> as .parent(), most developers know what they're looking for if  
>> they're
>> using :parent.
>>
>> The new $.fn.contains method, however, doesn't work like :contains.
>> Rather than searching for the text content of elements, .contains()  
>> is
>> just a shortcut to $(elem).has("foo").length > 0.  I'm not sure why
>> this is really a necessary shortcut, given that most people are  
>> plenty
>> used to doing something like .has().length anyway.  I tend to think,
>> however, that .contains () should work like :contains, for
>> consistency's sake.
>>
>> This would have the added benefit of allowing those people who do
>> use :contains to write code like this:
>>
>> var foo = "barbazbat";
>> $("div").contains(foo);
>>
>> instead of
>> $("div:contains("+foo+")");
>>
>> Anyone else have any thoughts on this?
>>
>> --adam
>>
>> --
>>
>> 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 
> .
>
>

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: Mutation Events

[DBJDBJ]

MutationEvents are fired by document host, when anything inside the
document hierarchy has been subjected to any CRUD operation. Any dom
node or attribute.

Our "imaginary" "$ listeners" are actually better described as
"mutation listeners". they will be receiving MutationEvents only when
w3c dom level 2 spec, says they should be fired. Which is *only* when
and if some CRUD operation is changing the state of the document tree.

So ...

$.ajax({
   url: "data.xml",
   dataType: ($.browser.msie) ? "text" : "xml",
   success: function(data){
 var xml;
 if (typeof data == "string") {
   xml = new ActiveXObject("Microsoft.XMLDOM");
   xml.async = false;
   xml.loadXML(data);
 } else {
   xml = data;
 }
 // Returned data available in object "xml"
   }
 });

Above does not affect document tree in any way and is not going to
provoke MutationEvent-s firing.

var div = document.createElement('div'); $(div)...

is also *not* mutating the current document in any way . until one
does (for example) this :

$(div).appendTo( document.body )

At which moment jQuery future "mutator" receives the request to append
the div to the document.body, does it and then signals all the
registered $ "listeners" with MutationEvent objects as specified by
the DOM Level 2 spec.

When time allows, I think I should make a small demo page which will
do this with "normal"  javascript, , while "inside"  CHROME ...

How much is this "breaking the new ground" or not, I do not know. But
it solves a whole category of issues which are (or have been)
"overlooked" in todays "single page app".

--DBJ


On Dec 17, 4:25 am, John Arrowwood  wrote:
> And what would this mean in the case where I have downloaded an XML document
> via $.ajax()?  That $ will not be an observer of the $(document) instance,
> will it?
>
> Or if I create fragments that are not yet in the DOM, such as
>
> var foo = document.createElement('div');
> $(foo)...
>
> That instance should not be a listener, should it?
>
>
>
> On Thu, Dec 17, 2009 at 12:50 AM, DBJDBJ  wrote:
> > MutationEvents are fired whenever and wherever any CRUD operation is
> > done on the document tree.
> > To do this, one needs to redesign jQuery to follow an Observer
> > pattern.
> > Where observable is a single instance of jQ 'mutator'. Imagine that
> > instead of this (currently in core.js )
>
> > // Handle $(""), $(null), or $(undefined)
> > if ( !selector ) {      return this;  }
>
> > We do this (and a lot more) :
>
> > // Handle $(""), $(null), or $(undefined)
> > if ( !selector ) {      return rootjQuery ;  }
>
> > Now we have rootjQuery (aka $(document) ) as an single observable
> > which sends MutationEvents to 'observers', which are all the other $
> > instances.
> > So every $(selector,context) is *also* an observer of the rootjQuery
> > (aka 'mutator'). rootjQuery  publishes (fires) MutationEvents to which
> > all the other '$' are subscribed.
> > In that (imaginary) context, every  '$' is an 'client' of the
> > rootjQuery which is a single 'mutator'. The only one who deals with
> > DOM.
> > The 'others' are just sending it commands to be executed on the
> > document tree, by rootjQuery. Which does it and signals back to all
> > the registered listeners, by publishing to all the subcribers,
> > appropriate MutationEvent objects.
>
> > Important moment here: "to ALL the subscribers". If one '$' removes a
> > node, all the other '$' are sent a MutationEvent about the removal.
>
> > All of this would apply to jQ 'mutator' in every browser host.
> > Regardless of if the browser implements MutationEvents natively or
> > not. For the ones that do not, some internal MutationEvents mechanism
> > will be implemented. Much like Sizzle implements querySelectorAll() if
> > host is not having it.
>
> > This obviously is a "non trivial" change to how jQ works today. Or any
> > other glow, dojo, moo, extjs, fusejs or prototype I know of.
> > But, is the only legal way, to have 2 or more simultaneous dom
> > document tree users.
> > Same applies (conceptually) to any situation with 2 or more users of a
> > single persistent structure.
>
> > --DBJ
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "jQuery Development" group.
> > To post to this group, send email to jquery-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jquery-dev?hl=en.
>
> --
> John Arrowwood
> John (at) Irie (dash) Inc (dot) com
> John (at) Arrowwood Photography (dot) com
> John (at) Hanlons Razor (dot) com
> --http://arrowwood.blogspot.com
> Mike Ditka   -
> "If God had wanted man to play soccer, he wouldn't have given us arms."

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send e

[jquery-dev] Re: attr() is still very broken in 1.4a1

[alexander farkas]

The way how jQuery does mixing properties with attributes is a very
clever thing. One simple API for multiple different things is a very
nice thing, but has its constraints.

An example:

jQuery returns the value-property on form-elements, instead of the
value-attribute. This is a really good thing, because
a) a lot of novice developers don´t know about the difference and are
expecting this behavior
b) more advanced developers know the difference, but want in general
to know the value-property of a form element

With other words the developer gets what he/she wants/expects here.

But if jQuery starts to make .attr('height') equal to .height(), the
behavior becomes very unexpected. Everybody knows that the height-
attribute can be simply "overridden" by using css. This is why a
developer would use height to get the height-dimension of an element
and if a developer wants to know what the height-attribute, he would
call attr('height').

If you change your API to this behavior you will
a) break existing code
a) do unexpected things
b) you don´t have a jQuery-method, wich returns the height-/width-
attribute anymore

To be clear:

I think, you did a great job mixing properties and attributes and if
you know start to take this a step further, I am also on your side,
but you have to make wisley decissions (and small steps) here.

If you can solve the discrepancy in event-binding with attr, Robert is
mentioing, it could be a nice feature, but please don´t do this with
height/width!

On 17 Dez., 11:28, Már Örlygsson  wrote:
> > Never ever, would I have guessed that .attr('height') would report a
> > value on elements that don't have an explicit height `attr`ibute.
>
> Somehow I have the feeling that it would be useful for developers to
> be able to access plain old element attributes - in a cross-browser
> way - without any overt aliasing/magic.
>
> --
> 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-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Már Örlygsson]

> Never ever, would I have guessed that .attr('height') would report a
> value on elements that don't have an explicit height `attr`ibute.

Somehow I have the feeling that it would be useful for developers to
be able to access plain old element attributes - in a cross-browser
way - without any overt aliasing/magic.


--
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-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: attr() is still very broken in 1.4a1

[Már Örlygsson]

> I am afraid, that I will not be the only confused one...

I, for one, am very much confused.

Never ever, would I have guessed that .attr('height') would report a
value on elements that don't have an explicit height `attr`ibute.

Should I now expect $(element).attr('color') to work as an alias for
`.css('color')`?  How about other properties, such as 'border-width'
or 'offset'?  (*wanders off to a different browser tab to try for
himself*)



--
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-...@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: Mutation Events

[John Arrowwood]

And what would this mean in the case where I have downloaded an XML document
via $.ajax()?  That $ will not be an observer of the $(document) instance,
will it?

Or if I create fragments that are not yet in the DOM, such as

var foo = document.createElement('div');
$(foo)...

That instance should not be a listener, should it?



On Thu, Dec 17, 2009 at 12:50 AM, DBJDBJ  wrote:

> MutationEvents are fired whenever and wherever any CRUD operation is
> done on the document tree.
> To do this, one needs to redesign jQuery to follow an Observer
> pattern.
> Where observable is a single instance of jQ 'mutator'. Imagine that
> instead of this (currently in core.js )
>
> // Handle $(""), $(null), or $(undefined)
> if ( !selector ) {  return this;  }
>
> We do this (and a lot more) :
>
> // Handle $(""), $(null), or $(undefined)
> if ( !selector ) {  return rootjQuery ;  }
>
> Now we have rootjQuery (aka $(document) ) as an single observable
> which sends MutationEvents to 'observers', which are all the other $
> instances.
> So every $(selector,context) is *also* an observer of the rootjQuery
> (aka 'mutator'). rootjQuery  publishes (fires) MutationEvents to which
> all the other '$' are subscribed.
> In that (imaginary) context, every  '$' is an 'client' of the
> rootjQuery which is a single 'mutator'. The only one who deals with
> DOM.
> The 'others' are just sending it commands to be executed on the
> document tree, by rootjQuery. Which does it and signals back to all
> the registered listeners, by publishing to all the subcribers,
> appropriate MutationEvent objects.
>
> Important moment here: "to ALL the subscribers". If one '$' removes a
> node, all the other '$' are sent a MutationEvent about the removal.
>
> All of this would apply to jQ 'mutator' in every browser host.
> Regardless of if the browser implements MutationEvents natively or
> not. For the ones that do not, some internal MutationEvents mechanism
> will be implemented. Much like Sizzle implements querySelectorAll() if
> host is not having it.
>
> This obviously is a "non trivial" change to how jQ works today. Or any
> other glow, dojo, moo, extjs, fusejs or prototype I know of.
> But, is the only legal way, to have 2 or more simultaneous dom
> document tree users.
> Same applies (conceptually) to any situation with 2 or more users of a
> single persistent structure.
>
> --DBJ
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to jquery-...@googlegroups.com.
> To unsubscribe from this group, send email to
> jquery-dev+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>


-- 
John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com
--
http://arrowwood.blogspot.com
Mike Ditka   -
"If God had wanted man to play soccer, he wouldn't have given us arms."

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.

[jquery-dev] Re: Mutation Events

[DBJDBJ]

MutationEvents are fired whenever and wherever any CRUD operation is
done on the document tree.
To do this, one needs to redesign jQuery to follow an Observer
pattern.
Where observable is a single instance of jQ 'mutator'. Imagine that
instead of this (currently in core.js )

// Handle $(""), $(null), or $(undefined)
if ( !selector ) {  return this;  }

We do this (and a lot more) :

// Handle $(""), $(null), or $(undefined)
if ( !selector ) {  return rootjQuery ;  }

Now we have rootjQuery (aka $(document) ) as an single observable
which sends MutationEvents to 'observers', which are all the other $
instances.
So every $(selector,context) is *also* an observer of the rootjQuery
(aka 'mutator'). rootjQuery  publishes (fires) MutationEvents to which
all the other '$' are subscribed.
In that (imaginary) context, every  '$' is an 'client' of the
rootjQuery which is a single 'mutator'. The only one who deals with
DOM.
The 'others' are just sending it commands to be executed on the
document tree, by rootjQuery. Which does it and signals back to all
the registered listeners, by publishing to all the subcribers,
appropriate MutationEvent objects.

Important moment here: "to ALL the subscribers". If one '$' removes a
node, all the other '$' are sent a MutationEvent about the removal.

All of this would apply to jQ 'mutator' in every browser host.
Regardless of if the browser implements MutationEvents natively or
not. For the ones that do not, some internal MutationEvents mechanism
will be implemented. Much like Sizzle implements querySelectorAll() if
host is not having it.

This obviously is a "non trivial" change to how jQ works today. Or any
other glow, dojo, moo, extjs, fusejs or prototype I know of.
But, is the only legal way, to have 2 or more simultaneous dom
document tree users.
Same applies (conceptually) to any situation with 2 or more users of a
single persistent structure.

--DBJ

--

You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.