I too noticed the omission of this feature,
and found it strange.
--
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
jque
Since everybody and their cat seem to have started writing their own
script loaders, I guess I migh as well post a link to my own effort in
this space:
Req.js - javascript lazy-loading and dependency managment
* About: http://mar.anomy.net/entry/2009/10/20/23.39.22/
* Code: http://github.com/mar
> 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
Am I right to think that there's a similar problem with the
window.onload event?
i.e. if you're too late in binding a handler to window.onload, it will
never fire?
--
Már
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this gro
> Put this in the top of your scripts and imho problem solved:
> (function(s,o,l,v,e,d){if(s[o]==null&&s[l+e]){s[v+e](d,function
> e(){s[l+e](d,e,!1);s[o]="complete"},!1);s[o]="loading"}})(document,"readyState","add","remove","EventListener","DOMContentLoaded");
Thanks Andrea, for this nice hack.
> $("htmlstring") converts the HTML to DOM elements using the innerHTML
> property of a element. That won't work if the string is an entire
> document, since an element can't be a child of a element.
True, that you won't get a full HTML document out, but with a little
pre-parsing you can at lea
> The HTML you send back to $.ajax should be an HTML fragment and not an
> entire page.
Begging the question, why on earth not?
--
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-...@google
I just got bitten by an unexpected (for me at least) behaviour of the
jQuery() function:
$(), $(''), $(0), $(null) and $(undefined), all return a collection
equal to $(document).
...this causes weird things to happen when one converts a String to a
dom, when the string happens to be empty.
Some
It seems possible to ever so slightly optimize $.className.add(),
$.className.remove(), and $.className.has() by adding an up-front
check to see if the `className` parameter is a non-falsy value (not
just `undefined`).
This would avoid triggering costly processing such as envoking $.each
loops, .
Hi.
If it hasn't been already considered (and rejected), I'd like to float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
> I believe this is a bug. Is there a workaround/fix tet?
It's intended as a feature.
Most jQuery newcomers must find out the hard way that .remove() is
really more like a "destroy" or "delete" method.
If you .remove() an element you're signalling that you don't intend to
use it again.
Fortunate
John,
I just wanted to point out that ticket #4374 (http://dev.jquery.com/
ticket/4374) has just been closed, fixing an important bug in
the :hidden() method that happens to be the cause of Rich Nurrre's
particular problem.
As of the next release, Rich won't have to resort to CSS tricks to
make h
> What version of jQuery/Sizzle are you using? A lot of clean-up was
> done recently.
Ah... this may very well have been residue from a time when we were
using jQuery 1.3.0 and/or 1.3.1
as I seem to be unable to reproduce this on the latest jQuery model.
Nice!!
--
Már Örl
ery1234377093764="43"` attributes all
over,
even in places that I'm pretty certain I haven't bound any event-
handlers or data to (not via my code, nor via any 3rd party plugins).
I wonder if there are any plans for making Sizzle less "obtrusive" in
this regard...
(See t
John:
> That's not happening. That will change a critical method of the
> jQuery API - breaking thousands of jQuery sites.
True. Flat out removing .remove() would be stupid and disastrous.
Gavin:
> Deprecation and aliasing is a quick path to API bloat, IMO.
Agreed, it's a slippery slope...
but
7;m derailing a bit...
what I was trying to get flying was the idea of renaming of `.remove()
` to `.destroy()`, to remove the last trace of confusion
with .removeChild()
Does anybody have an opinion on that?
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this
ch()` - with no nasty surprises attached. :-)
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To un
Filed: http://dev.jquery.com/ticket/4200
--
Már
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this gr
I was bitten by my assumption that $.fn.not was simply an inversed
$.fn.filter() ...
...which it isn't, as it doesn't accept functions as an argument.
Is there a good reason (API-wise) for this difference?
--
Már
--~--~-~--~~~---~--~~
You received this message be
> This has been fixed - FYI.
I noticed. Great!
One question though...
Does this also fix the problem of the source/prototype element being
*moved* to the first target location, rather than cloned like in
1.2.6 ?
--
Már
--~--~-~--~~~---~--~~
You received this mes
> it looks like it may be a duplicate of this one:
It is. I did my due diligence search a few days ago, and didn't find
any tickets back then.
Great to see this is being taken care of!
Thanks.
--
Már
--~--~-~--~~~---~--~~
You received this message because you are
I just created a ticket (http://dev.jquery.com/ticket/4174) with demo/
test-cases for both versions of jQuery...
---
The following code produces quite different results in jQuery 1.2.6
and 1.3.1 ...
var protoElm = $('#proto b');
protoElm
.bind(
gth == 1;
$('p:not(p.test)').length== 0; // Fail!
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev
> Putting your js at the bottom of the page is essentially the same as
> putting it in jQuery(function() {}), or .ready. The Yslow plugin
> doesn't take into account that you are using jQuery and are
> implementing the ready event. I have run a couple of tests for the
Actually, YUI has quite an a
last time I benchmarked, this whole thing was *way* slower
than a static RegExp.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send
I thought simple regular expressions were lightning fast in modern
browsers.
Bulking up the code with tagName hashes hardly seems worth it.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"j
s an easy fix.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, se
optional boolean argument
for `.remove()` to indicate when events and data shouldn't be stripped
away.
To my surprise, there wasn't.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Grou
riting your own
`.removeTemp()` plugin?
`$("#foo").remove(true)`
`$("#foo").remove(selector, true)`
feels like a natural way to express this.
any thoughts?
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
with
collection[index];
rather than
collection.get(index);
And you'll never notice the difference.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post
rated in the "patched" demo:
http://mar.eplica.is/ie-opacity-fixed.html
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send e
> Additionally elements with opacity set to `0` seem to return `1` in IE
Actually, I was wrong about this particular thing... but the rest
still applies.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
a.is/ie-opacity-fix.diff
I don't know, if this bug has been fixed or rejected.
My brief search came up empty.
--
Már Örlygsson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
> This was fixed in jQuery 1.3.
That's great news!
Thanks.
btw, I *thought* I was testing with 1.3.1 - but apparently I wasn't.
What a relief!
--
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Devel
s of other functionality?
possible fix would be to add something like:
while (div.lastChild) { div.removeChild(div.lastChild); }
*after* the line
elem = jQuery.makeArray( div.childNodes );
within `$.clean()`.
--
Már Örlygsson
--~--~-~--~~~---~--~~
Yo
36 matches
Mail list logo
