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 $(),
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
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
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
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
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
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
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
Just to clarify: .attr(height) no longer exists.
--John
On Thu, Dec 17, 2009 at 11:47 AM, Karl Swedberg k...@englishrules.com 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?
On Dec 17, 10:29 am, John Resig jere...@gmail.com 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.
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
Actually, the compelling reason is that the specified attribute height
will quickly lose sync with the actual height of the element.
iframe height=100.../
$(iframe).height( 1 ).attr(height)
// 100... but it's height isn't 100 any more.
Getting the current, computed, value is much more
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++;
On Dec 16, 12:42 pm, Tobias Hoffmann smilingt...@googlemail.com
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.
On Dec 17, 11:41 am, John Resig jere...@gmail.com 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
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
On Dec 17, 2:26 pm, Leeoniya leeon...@gmail.com 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
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 k...@englishrules.comwrote:
On Dec 16, 2009,
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()
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
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
leftwithoutli...@gmail.com wrote:
It's a selector or a string of
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.
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
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
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
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,
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
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
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
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 geoffreykjqu...@gmail.com wrote:
I have entered bug #5670
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
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
aubourg.jul...@gmail.com wrote:
Never heard of it before (Zoho) but the interface seems nice...
32 matches
Mail list logo
