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
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
>
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 a
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 ge
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
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 th
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, a
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 woul
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 ac
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 t
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.
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 cont
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
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() sho
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 Re
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')
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 wh
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 va
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 on
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++;
> 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
> 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
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 return
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
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 wh
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'), sin
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% s
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 l
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
> 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 over
> 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 fo
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 n
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 $(""), $(nul
33 matches
Mail list logo