[jquery-dev] Are effects really not supported in IE/Quirksmode?
I don't use a lot of effects, so when I got the dreaded "flash of content" in IE6 when trying to a slideUp/slideDown, I did some quick searching to jog my memory. Found this: http://dev.jquery.com/ticket/1726 This is the bug, and it's "wontfix" because IE/Quirksmode is not supported for fx? IE6/7 are still the dominant browser, and quirksmode is still how many (most?) pages are operating (often out of our control). Is it not supported simply because you can't come up with a good fix? IE6 has been around for a decade, it's not rocket science! jQuery should normalize browser behavior, not label common and perfectly valid situations as "unsupported" simply because the fix requires some additional work. That's a very disappointing approach to development, IMO. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: [OT] Fixing IE's CSS with jQuery
On Nov 13, 8:12 am, Scott Sauyet wrote: > On Thu, Nov 12, 2009 at 4:59 PM, weepy wrote: > > Not strictly jQuery Dev, but you guys might find it an interesting > > technique: > > [ ... ] > >http://blog.parkerfox.co.uk/2009/11/12/css-in-your-face-only-ie-need-... > Well now I don't need to write it. I just thought of this idea last > week and starting working through it in my head. A co-worker and I were just talking about this yesterday, and he found Cssie. Like I always say: if I have thought of it, then someone else has probably already thought of it, brainstormed it, built it, and packaged it ;) > Looking at the implementation (without doing any real testing) I'm > wondering about something. Why do you start by looping through the > tags rather than starting with document.styleSheets. I wondered the same thing. It looks like it does an ajax call to retrieve each stylesheet, which is not efficient, and ignores css defined in-page. Instead, consider looking through document.styleSheets and inspecting .cssText of each and parsing that. 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=.
[jquery-dev] Re: Crash with $().attr("-moz-border-radius","6px") or "-webkit-border-radius"
On Dec 5, 5:42 pm, Mike Taylor wrote: > You're probably getting the Exception 5 due to the "-" in the attribute > name, which is illegal. Should jQuery crash when passed a value it doesn't like? 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] attr() is still very broken in 1.4a1
The release info for 1.4a1 says attr() has been heavily optimized, but
unfortunately it is still very broken. Since this commonly-used
method is a constant source of criticism for jQuery, and because its
behavior doesn't make much sense, isn't it time it gets replaced with
better logic?
Some observations:
1) It still confuses properties and attributes, which is its biggest
problem. Behavior is unpredictable. This is bad.
2) It looks like new code was added to call the jQuery method if the
requested attribute is in jQuery.fn. But what about attributes like
"height" or "wrap"? It won't retrieve the attribute value, but
instead, runs the height() or wrap() methods!
3) The list in jQuery.props is still incomplete
4) The "special" cases list is still incomplete
5) It forces values to be strings, so I can't set attributes like attr
('onclick',function(){...}) which in theory should work just fine. In
FF, for example, el.setAttribute('onclick',function(){...}) works as
expected.
There was a critique posted here, which started off the discussion
(again):
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d2c0407a7fc2e33a/
Referenced is a good, robust review of attribute handling with test
cases that should probably be in the jQuery test suite:
http://www.cinsoft.net/attributes.html
I think attr() needs some long-over-due re-thinking. It's definitely
very broken as-is, doesn't do what the documentation says it does, and
is a constant (justified) source of criticism of the jQuery library.
Any hopes of fixing it up soon?
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
On Dec 11, 11:10 am, John Resig wrote:
> > 1) It still confuses properties and attributes, which is its biggest
> > problem. Behavior is unpredictable. This is bad.
> Do you have any specific examples?
For example:
$('#x').attr('readonly') === true
This is a boolean property of the element, not its attribute value.
The name attr() implies that it deals with attributes. But the code
actually gets/sets properties as the first line of business. I would
expect to get back the string "readonly".
> > 2) It looks like new code was added to call the jQuery method if the
> > requested attribute is in jQuery.fn. But what about attributes like
> > "height" or "wrap"? It won't retrieve the attribute value, but
> > instead, runs the height() or wrap() methods!
> The wrap one was a mistake (the code in 1.4a1 covered too many
> methods) it's since been scaled back. In the case of height, for
> example, we definitely do want to get the height value as reported by
> .height(), especially since it's likely to be more accurate than
> trying to get elem.height.
But isn't the attr() method supposed to get the height _attribute_
value? If the attribute is set to "5" and I manipulate it via js, I
still want to get "5" if I look for the attribute value. Otherwise I
would just call height().
So now the attr() method either calls a jQuery method, gets/sets an
element's property, or gets/sets an element's attribute. How is a user
supposed to know what to expect? What exactly is the attr() method
intended to do, if not get/set an element's attributes?
Calling attr() becomes a crap-shoot, because you can never be sure
what it's going to do inside.
> > 3) The list in jQuery.props is still incomplete
> Do you have any specific examples?
cellPadding, useMap, accessKey, et al.
> > 4) The "special" cases list is still incomplete
> Do you have any specific examples?
How about 'action'?
> > 5) It forces values to be strings, so I can't set attributes like attr
> > ('onclick',function(){...}) which in theory should work just fine. In
> > FF, for example, el.setAttribute('onclick',function(){...}) works as
> > expected.
> I don't think that's a case that we particularly want to support,
> though. In 1.4 you can just do: .attr("click", function(){}) and it
> would work (albeit tied into the full event system, which is much
> better).
But now you have an setAttribute wrapper that causes a script error
when passed values that would work just fine with setAttribute(). This
seems like a step backwards.
> > Referenced is a good, robust review of attribute handling with test
> > cases that should probably be in the jQuery test suite:
> >http://www.cinsoft.net/attributes.html
> I don't see a particular license on those tests - are they available
> under an MIT license?
You'd have to contact the author, not sure about that. But the cases
being tested are certainly something that can be written again on
their own. I just saw that you've made some progress on this, which is
great.
> > Any hopes of fixing it up soon?
> Specific filed bugs and test cases would certainly accelerate the process.
This is core functionality, and filing/patching bugs on specific
problems with individual attributes wouldn't be very helpful. In fact,
that's perhaps what lead to the method being in the state it is (with
attmpted special cases for tabindex, selected, etc). Instead, I think
someone needs to step back and identify _exactly_ what it is that attr
() is supposed to do, and then code to that standard. Kind of hard now
that you want to maintain backwards-compatibility with this kind of
hybrid functionality, though. Throwing in the hidden execution of
jquery methods when trying to retrieve attribute values just adds to
the confusion even more, and I'm not sure what exactly attr() is
trying to accomplish if that is seen as necessary.
It's been pointed out that most users don't really need to interact
with attributes to begin with. In most cases, they want to get/set
properties of objects, not their attributes. A prop() method might be
more clear, along with attr() if you really, really need to get/set
attributes. Mixing the two (and trying to throw in xml support!) just
makes the whole thing kind of a mess.
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
On Dec 13, 6:06 pm, John Resig wrote:
> Just got word from Paul Irish that David Mark is refusing to provide
> an open license for his attribute test suite - in fact he's
> threatening legal action against me and the Software Freedom
> Conservancy if we should "cop[y] one word or the tiniest aspect of the
> design". Naturally, that branch with the test suite has been
> completely deleted.
David Mark is an ass. Unfortunately, he's an ass who has a very deep
understanding of js and makes very good observations about code
quality and robustness. Since I value critical looks and logic and
algorithms, and I use and develop for jQuery frequently, I find myself
in a position where both sides of the debate are valuable to me.
Trying to find the common ground sometimes proves frustrating.
> This attitude is why I refuse to read anything in comp.lang.javascript
> and every single time I even get a whiff of what goes on over there I
> completely regret it.
The group is growing increasingly irrelevant, but there are a number
of quality contributors who have very good understandings of the js
language. They can spot problems and identify potential issues better
than most. Although the environment is hostile and populated by many
guys I probably would not care to hang out with personally, sometimes
it's worthwhile to ignore all that and just focus on the objective
arguments being made. I can definitely sympathy with not wanting to
tread those waters, but that seems kind of like a "see no evil, hear
no evil" attitude.
> Matt, I definitely welcome your help or feedback to the jQuery
> project, but please provide your own test cases, test suites, and bug
> reports from now on - this goes for anyone else as well. As far as I'm
> concerned comp.lang.javascript is completely tainted and using any
> code or recommendations from them will be ignored.
Unfortunate, but understood.
> This is pretty amusing, actually - threatening legal action against
> others for using common-sense test cases is a sure-fire way to make
> sure that no one with any sense will read or use the contents in
> comp.lang.javascript again.
Some of the people there (David Mark especially) seem to have personal
issues with jQuery. Maybe jQuery stole their girlfriend in high school
or beat them up on the playground. I don't know. Their bias ends up
being a vendetta, and even if they have reasonable criticisms they end
up being lost in their diatribes. I don't understand the hostility.
> So it goes. If anyone that hasn't read the aforementioned thread/tests
> is interested in writing up some more-comprehensive attribute tests
> for us we'd definitely appreciate it.
I will take a look at this when I get a chance. I'm not going to copy
his code, but if there are any similarities then he can sue me.
I think one of the core problems is understanding what attr() is
intended to do. Clearly it is not just a get/setAttribute wrapper.
Clearly it is not just meant to access the properties of elements. It
is a mixture of several different ways to access "attributes" of an
element, and it apparently tries to pick the best approach and give
the user what they want. Calling height() instead of accessing
a .height property or doing getAttribute('height') may give some users
what they expect, but is it predictable? What if I really do want the
'height' property, and not the current computed value? How will I know
which I am going to get?
If my current markup has an 'xxx' attribute and jQuery successfully
gets the attribute value, but then later adds a xxx() method and
returns that value instead, upgrading jQuery will break my code. But
how could I have known that this would happen? Knowing what attr()
will do has become entirely unpredictable, and even writing test cases
becomes difficult because it's not clear what the method is _supposed_
to do.
As it is now, I always recommend that attr() be avoided in code, and
if someone uses it in code I am looking at, I tell them to remove it.
It's too fragile and the logic that it is intending to code is not
well documented, so we can't depend on it. Luckily, it's easily coded
around. Unfortunately, many plugins and examples use it quite a bit.
Since this single method is such a consistent base of attack on
jQuery's quality and robustness, and because it is used so often in
code, I think it would be a good idea to clarify what attr() is really
intended to do and put it into words. As it is now, I'm not sure
anyone can really concisely describe it.
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
On Dec 14, 12:31 am, John Resig wrote:
> For example, documenting that disabled/selected/etc. are expected to
> return boolean values. Documenting the expected value returned from
> zIndex. Documenting what happens with relative URL resolution across
> browsers.
> THEN we can go back and fill in the test suite as appropriate.
> [...]
> To start I've created a page that's a rough dump of the contents in
> the HTML 4 spec:http://www.w3.org/TR/html4/index/attributes.html
> Into the following page:http://docs.jquery.com/How_Attributes_Work
I think this is a great approach, and I hope it goes somewhere. How
exactly can I help with it?
Also, to further illustrate why I think calling jQuery methods when
calling attr() is a bad idea, take a look at the example page our
great friend David Mark has set up (ignore the insulting url):
http://www.cinsoft.net/jquerysucks.html
Because height() tries to do so much magic, it ends up that this:
$o.attr('height',$o.attr('height'));
actually gives wrong results. IMO, attr() should be reflexive in that
calling attr() to set a property with a value retrieved from attr()
should always maintain the same value. I just really think the whole
idea of calling methods when getting/setting attributes is bad. What
is the real basis for it?
Two other points:
1) I cannot find the rationale for this. Or even where this "bug" is
discussed. Can anyone point me to it? I am curious.
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
}
2) This seems like over-kill, still. Passing the second parameter will
never break things, so why not just pass it in every case?
var attr = !jQuery.support.hrefNormalized && notxml && special
// Some attributes require a special call on IE
? elem.getAttribute( name, 2 )
: elem.getAttribute( name );
could be simplified to:
var attr = elem.getAttribute(name,2);
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
On Dec 15, 10:24 am, Diego Perini wrote:
> it is not only "href" that has problems, seems all attributes having
> an URI string as value have to be read in the way you described.
> Some of them are: action, cite, codebase, data, href, longdesc,
> lowsrc, src, usemap.
The root cause, if I'm not mistaken, is that IE masks the element
attributes with properties when calling getAttribute(). So in the case
of url's, the full resolved url is stored in the property of the
object.
a.href==a.getAttribute('href')
If you want the true attribute value, this is when you have to specify
the second argument of 2.
> You will have to add ".cssText" in IE6/7 to read a slightly similar
> value:
> javascript:alert(document.getElementsByTagName('textarea')
> [0].getAttribute('style').cssText);
> I don't think all these cases/differences are currently handled and I
> don't think they can be handled in a reasonable way.
This case seems to be handled with this code:
if ( !jQuery.support.style && notxml && name == "style" ) {
if ( set ) {
elem.style.cssText = "" + value;
}
return elem.style.cssText;
}
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
On Dec 15, 11:21 am, John Resig wrote:
> Hmm, I don't remember the bug off-hand but here's the reproduction:
> Failing:http://ejohn.org/files/bugs/selected/
> Passing:http://ejohn.org/files/bugs/selected/fixed.html
Ah, I see. The description in the source is misleading.
Note that this only happens before the page is done loading (if you
fire the check in window.onload it works fine). Also, an may
exist in an element, so simply accessing
parentNode.selectedIndex isn't sufficient. How about this:
// In Safari, if no option is explicitly selected and the first
// option gets selected by default, this option will report
// selected==false _while the page is still loading_. Accessing the
// containing select element causes the option to set its
// selected state correctly. Since options may be nested in
// elements, access two levels up just to be safe.
// Simply accessing the .selectedIndex property even if it doesn't
// exist shouldn't cause a problem in any browsers.
// http://ejohn.org/files/bugs/selected/
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
if (elem.parentNode.parentNode)
{ elem.parentNode.parentNode.selectedIndex; }
}
> > var attr = elem.getAttribute(name,2);
> Unfortunately that's not the case - I know that in older versions of
> Opera if you tried to use the , 2 it would straight out crash the
> browser - which is why we had to do the extra check. It's silly, of
> course, since the extra argument shouldn't do anything.
Never seen that problem, and I'm too lazy to look for it. I'll trust
you on that one. May want to add a note to that effect in the source.
Explanatory documentation is valuable.
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
On Dec 15, 11:32 am, John Resig wrote:
> > I think this is a great approach, and I hope it goes somewhere. How
> > exactly can I help with it?
> Categorizing the "types" would be a great start. Types that should
> "just work", Types that should return booleans, types that we
> obviously don't care about (attributes of isindex, for example), and
> attributes that we provide better alternatives for (Using .click()
> instead of .attr("onclick", fn), for example).
I will take a look at this. I may come to different conclusions than
you, but I will propose something. Having a dump of all the attributes
and documenting what to expect from each would be fantastic.
> > Because height() tries to do so much magic, it ends up that this:
> > $o.attr('height',$o.attr('height'));
> I was 100% serious about a ban concerning everything from CLJ. Please,
> original ideas/concerns/bug reports/test cases only.
Seems petty to me. There is a good test case there that illustrates
the problem. I'm not going to reproduce it to shelter jQuery from CLJ.
Nevertheless, since attr() calls height() for both getter and setter,
the real problem is that
$o.height( $o.height() )
is not reliable in some cases. So perhaps the issue is there, instead
of with attr().
> On the whole though, I'd recommend to just stop reading the group as
> who knows what they will try to pull next.
I've never been a fan of head-in-the-sand. I can find the pearls of
wisdom in the posts there without taking anything personally. And
there is a lot of good, robust, deep stuff posted there that you won't
find in blog posts or discussions here. To each his own.
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
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.
[jquery-dev] Re: attr() is still very broken in 1.4a1
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: attr() is still very broken in 1.4a1
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] jQuery 1.1.2 ready() method causes IE7 problems?
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] A fix for the broken "selected" code in attr()
The attr() method contains this spooky code:
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
}
I previously made two points:
1) This code will not work of the is in an
(common)
2) The comment incorrectly identifies the quirk being corrected
After some discussion with colleagues, a better approach has been
identified. However, I would suggest that this simply be removed from
the code. The specs do not demand the behavior being sought after, and
the correct solution to the "problem" would be to simply add a
"selected" attribute to the first .
If you still want this "fix" in there, then I suggest adding this
method:
// Get the true "selected" property of an option.
// Safari mis-reports the selected property of the first (default)
selected
// option in a single-select list, when checked before the window's
onload
// event has fired.
function getOptionSelected(el) {
// Do a feature test to see if the "broken" functionality exists
var s = document.createElement("select");
s.add(new Option("a"));
if (s.options[0].selected) {
// Not broken, so unroll this method to be efficient next time
return (getOptionSelected = function(o) {return o.selected;})(el);
}
s=null;
// If we're getting a false value, it may be that the option
// will be selected when fully rendered, but has not happened yet.
return (getOptionSelected=function(o) {
if (o.selected === false) {
var s=(o.parentNode.tagName=="SELECT")?
o.parentNode:o.parentNode.parentNode;
// Verify selectedIndex because this doesn't apply to multiple-
selects
if (s.selectedIndex>=0) {
s.options[s.selectedIndex].selected=true;
}
}
return o.selected;
})(el);
}
Or you could put it in as jQuery.getOptionSelected, obviously.
Then in attr() replace these lines:
// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
}
with these:
if (name=="selected") {
return getOptionSelected(elem);
}
Then you'll have a more robust, feature-tested, efficient, correctly-
documented fix to this "problem".
Again, though, my suggestion is to just remove it. I don't think
generalized library code should try to normalize behavior that is not
demanded by the specs and that can be easily corrected through proper
HTML.
Hope that helps,
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: Bug in jQuery.val() in beta 1.4a2
On Dec 21, 9:21 pm, Devon Govett wrote:
> I have found a bug in the jQuery.val() function.
> ...
> to the following in jQuery 1.4:
> this.selected = jQuery.inArray( this.value || this.text, values ) >= 0;
Indeed, this is a (probably unnoticed) change in logic.
Consider this:
Dummy
Empty
$('#x').val('') ==> Will not select the second option!
> I can see why this optimization was done, but I think that this will
> cause problems for a lot of people!
Agreed, the change is broken! Wasn't there a test case for the above
scenario?
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: Bug in jQuery.val() in beta 1.4a2
On Dec 21, 10:32 pm, John Resig wrote:
> > Agreed, the change is broken! Wasn't there a test case for the above
> > scenario?
> The previous technique was definitely not the right one to use. Cases
> were coming up where the same string was being used for the value and
> the text in different places and it couldn't figure out what to
> select.
> See the previous
> discussion/ticket/changeset:http://groups.google.com/group/jquery-dev/browse_thread/thread/74dddc...
Looks like the quick code changed wasn't thought through enough. The
correct algorithm needs to be decided on, rather than quick-fixing a
bug report. It shouldn't matter whether a situation "makes sense" or
whether someone would actually do it in practice. The specs are very
specific about how controls should function under all scenarios,
whether it "makes sense" or not.
Selecting options based on their text, regardless of value, seems to
make the method results confusing. Because you aren't actually setting
the value, then, you're setting some unknown value that corresponds to
the text value that you have matched.
Consider the following cases:
#1)
Dummy
Empty
$('#x').val('')
should select the second option.
#2)
z
x
$('#x').val('x')
should select the first option only.
#3)
y
y
$('#x').val('y')
should select the second option only.
#4)
z
x
$('#x').val('x')
should select the first option only, IMO. It's kind of ambiguous and
jQuery should define what it wants to do.
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: Bug in jQuery.val() in beta 1.4a2
On Dec 22, 1:05 am, John Resig wrote:
> Just to clarify then, since jQuery already covers cases 2-4 as you're
> expecting it to and case #1 currently fails - and that case is
> decidedly not what this thread discussion started as.
I'm just pointing out several test cases that should be handled
correctly, possibly added to the test suite.
> >
> > Dummy
> > Empty
> >
> > $('#x').val('')
> > should select the second option.
> Agreed.
Broken in 1.4.1a2, but now corrected I see.
> >
> > z
> > x
> >
> > $('#x').val('x')
> > should select the first option only.
> Yep, as it does in 1.4.
Yes, but it didn't in 1.3.2.
> >
> > z
> > x
> >
> > $('#x').val('x')
> > should select the first option only, IMO. It's kind of ambiguous and
> > jQuery should define what it wants to do.
> Yep, as it does in 1.4.
Yes, but it didn't in 1.3.2.
> In fact, 1.4 removes the ambiguity completely
> by only using the value with the val method, which is much better.
I agree, but it is a change in the API and may make it difficult for
some to upgrade (it removes functionality). The wandering API
sometimes makes it difficult to upgrade jQuery versions, which is why
I have some projects stuck on 1.2.6 and one that was just recently
upped from 1.1.2! :(
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: Performance issues using $.ajax async
On Dec 30, 9:00 am, Julian Aubourg wrote: > If only it could be enough to set onreadystatechange to null :( The work-arounds for IE memory leaks have been well known for a long time. There shouldn't be any need to resort to timers and polling. Perhaps a good solution to the leaks wasn't immediately obvious originally, and polling seemed like a "good enough" alternative? 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: Performance issues using $.ajax async
On Dec 30, 10:58 pm, John Resig wrote:
> Interesting, I've, also, seen the = null; proposal before, but not the
> = function(){}; one. Doing some poking around I found mention of it
> here:http://www.ilinsky.com/articles/XMLHttpRequest/#bugs-ie-leak
I haven't inspected the jQuery ajax code much, but what you changed is
not what this link recommends.
They say:
self.object.onreadystatechange = new Function;
whereas you have done:
xhr.onreadystatechange = function(){};
Those are two very different things!
You've created an anonymous function with a scope chain that includes
the xhr object, etc. You need to do something like
jQuery.noop = function(){};
and set
xhr.onreadystatechange = jQuery.noop;
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: Performance issues using $.ajax async
On Dec 31, 8:53 am, John Resig wrote: > Looking at the new numbers I see: > Without patch: 19763200 > With patch: 19910656 > So still about a 1/5MB increase in memory usage. Do you have a test page that repeatedly makes ajax calls to exploit the memory leak issue? A .7% increase in memory use doesn't raise any red flags to me, it could just be how IE handles the new code differently. You'd have to repeat the test many times and watch Drip to see if the memory use steadily rises over time to know if there is still a real leak. 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: Performance issues using $.ajax async
On Dec 31 2009, 1:52 pm, John Resig wrote:
> Landed and closed:http://dev.jquery.com/ticket/5735
John, good to see this change in jQuery.
Another ajax area that needs attention is the xhr creation:
// Create the request object; Microsoft failed to properly
// implement the XMLHttpRequest in IE7, so we use the ActiveXObject
when it is available
// This function can be overriden by calling jQuery.ajaxSetup
xhr: function(){
return window.ActiveXObject ?
new ActiveXObject("Microsoft.XMLHTTP") :
new XMLHttpRequest();
}
1) What problems exist in IE7 that make you prefer ActiveX?
2) If an IE user has ActiveX disabled (common for many corporate
users), this will throw a nasty error like:
"Automation server can't create object"
to the user and cause scripts to stop running. This is not good,
especially if the user has IE>=7 with native XMLHttpRequest that would
work fine.
Assuming you want to keep ActiveX as the preferred method in IE (I'd
like to know why) then I suggest:
xhr: function() {
if (window.ActiveXObject) {
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch(e) { }
}
if (window.XMLHttpRequest) {
return new XMLHttpRequest();
}
return null;
}
And then later in the ajax() method you need to check to make sure
that xhr() doesn't return null. If it does, don't try to proceed.
In fact, this should be a feature-test early on, so developers can
decide whether ajax functionality will even be supported in the user's
browser. Right now there isn't even a way to check for ajax support
and degrade gracefully if it doesn't exist.
jQuery.support.ajax = (xhr()!=null);
Hope that helps some 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.
[jquery-dev] Re: Performance issues using $.ajax async
On Jan 5, 10:04 am, John Resig wrote:
> The current logic is imperfect (in that, theoretically, someone could
> be trying to use jQuery on a local file, in IE 7, with ActiveX
> disabled and it would error out) but for now that's something that I
> can live with.
It will still fail in IE6 with ActiveX disabled, pop up a scary
warning to an unsuspecting user, and stop scripts from running.
Just because window.ActiveX exists doesn't mean that
window.ActiveXObject("Microsoft.XMLHTTP") will be successful.
You still need try/catch to avoid the potential error.
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: Performance issues using $.ajax async
On Jan 5, 10:04 am, John Resig wrote:
> The current logic is imperfect (in that, theoretically, someone could
> be trying to use jQuery on a local file, in IE 7, with ActiveX
> disabled and it would error out) but for now that's something that I
> can live with.
Why live with it? It fails in IE6 under the same conditions as well.
That, as far as I can tell, should be a jQuery-supported environment.
It also fails under FF, local file because your logic is incorrect:
return window.XMLHttpRequest && window.location.protocol !== "file:"
|| window.ActiveXObject ?
new window.XMLHttpRequest() :
new window.ActiveXObject("Microsoft.XMLHTTP");
In FF:
return (true && false || false)? : new window.ActiveXObject
("Microsoft.XMLHTTP")
ERROR:
"window.ActiveXObject is not a constructor"
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: jQueryLINT
On Jan 15, 1:11 pm, Scott Sauyet wrote: > I like the idea, and I think it would be possible to do this as a > plug-in, which replaces calls to jQuery functions with calls that > check the parameters, store errors, then delegate to the the original > function. But have no time at the moment to help implement it. Check the archives. This comes up every few months, everyone agrees it would be cool, everyone agrees it could be implemented relatively easily, yet no one wants to spend the time to build, test, and release it. Bummer. 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: Can we have an honest discussion about Zoho?
On Jan 24, 2:31 pm, John Resig wrote: > It's a done deal. If you have specific things that you'd like to see > get fixed then please let us know so that we can communicate it to the > Zoho guys. Is there somewhere specific to report this stuff? I read the forums via my jQuery universe gadget in iGoogle: http://www.javascripttoolbox.com/gadget/jquery/ (And I've received email from others who do the same) It gets content via RSS, and the zoho RSS feeds seem to be limited to 15 items. This is not sufficient in a forum that gets a lot of messages. I need at least 50 if not 100 posts in the feed, which the previous Google Groups interface allowed me to retrieve. I would like the zoho feeds to give more items, perhaps with an optional "?num=50" type argument in the url. 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: Unelegant Code
On Sep 26, 1:58 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> But that reminds me. I've been wanting this for a long time:
> $("#one").click(false);
That would be handy, and I would also still like to pass a string in
some cases, as described here:
http://groups.google.com/group/jquery-en/browse_frm/thread/1f6790e31d33e32a
$('#one').click(" alert('you clicked me!'); ");
instead of
$('#one').click( function() { alert('you clicked me!'); } );
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Unelegant Code
On Oct 3, 12:46 pm, "mike.helgeson" <[EMAIL PROTECTED]> wrote:
> $('#foo').fadeOut('normal',function(){ $(this).remove(); });
> Do you have any suggestions to improve it?
I was originally going to post this same thing as an example of
unelegant code as well.
In my jQuery toolbox I have this:
$.fn.fadeOutAndRemove = function(speed,callback) {
return this.each(function() {
$(this).fadeOut(speed,function(){ $(this).remove();
callback.call(this); });
});
}
The same could be done for other effects also, but this is the only
one I use. It works well enough for me without modifying jQuery core.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: event delegation
On Oct 10, 3:17 pm, Ariel Flesler <[EMAIL PROTECTED]> wrote: > So... it uses is()... I think your plugin is very very similar to > Intercept/Delegate, just adding the parent traversal. And I'm a little uncertain about how it differs from my event delegation code at: http://groups.google.com/group/jquery-en/browse_frm/thread/c39f52b6c5d1feac I've also been messing with my version to only .is() if it is a simple selector, otherwise matching the selector against the entire document and seeing if the element exists in the results. This allows for more complex selectors to be used involving descendents, etc. For things as critical and commonly used as this, I think it would be great to have a single "official" plugin maintained by the jQuery team that takes all these things into consideration. Rather than everyone inventing their own plugin and adding the stuff that they think is most important. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Debug Plugin?
In development mode, sometimes we make stupid mistakes like
misspelling a selector. Many people have been caught by passing a
"complex" selector to .is() and expecting it to work.
There is little debugging or error-checking done in jQuery to alert
you of potential problems.
I had a thought after discussing this with someone recently - would a
"debug" plugin be useful to detect common mistakes and warn the
developer? Not all the info would necessarily be errors or problems,
but if you are not seeing things work as expected it might be a way to
find the problem more quickly.
I wrote a quick proof-of-concept to illustrate how it might work.
http://www.javascripttoolbox.com/jquery/jquery.debug.html
The code is also pasted below.
The logging/alerting mechanism is obviously crude, but it's just a
poc.
Ideally I would like to see a heavily-commented jQuery source that
includes error-checking and warnings built-in as a "developer"
package. But assuming that won't happen, this is a way to "patch in"
this kind of functionality.
Any thoughts?
Matt Kruse
SOURCE:
http://code.jquery.com/jquery-</a>
latest.pack.js">
(function($) {
$.fn._init = $.fn.init;
$.fn.init = function(selector, context) {
var result = $.fn._init(selector,context);
if (typeof selector=="string" && result.length==0) {
$.fn.debugWarn("selector ["+selector+"] returned 0
matches");
}
return result;
}
$.fn._fadeOut = $.fn.fadeOut;
$.fn.fadeOut = function(speed,callback) {
if (typeof speed!="number" && typeof
$.fx.speeds[speed]=="undefined") {
$.fn.debugWarn("speed ["+speed+"] is not a valid jQuery
speed
constant");
}
return $.fn._fadeOut(speed,callback);
}
$.fn._is = $.fn.is;
$.fn.is = function(selector) {
// This test would obviously need to be improved
if (typeof selector=="string" && /[\s\>]/.test(selector)) {
$.fn.debugError("selector ["+selector+"] is too complex
to pass
to .is()");
}
return $.fn._is(selector);
}
$.fn.debugWarn = function(str) {
if (window.console) { window.console.warn("jQuery: "+str); }
else { alert("jQuery WARNING: "+str); }
}
$.fn.debugError = function(str) {
if (window.console) { window.console.error("jQuery: "+str); }
else { alert("jQuery ERROR: "+str); }
}
})(jQuery);
$(function() {
$('div.x').fadeOut("really slow");
$('test');
$('div.y').is("body > div");
});
Test DIV
Test DIV 2
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery, 'document', and FF extensions
On Nov 12, 1:24 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > I'm curious - which cases of 'document' are you having trouble with > (which methods are having problems)? I think we'd like to try our hand > at fixing those bugs first before we consider more 'drastic' > solutions. It's not a "bug" per se. jQuery makes the assumption that a global variable exists named 'document' and that it refers to the containing document element. This is not true in all cases where jQuery might be used - like in a FF add-on, for example. In the example posted, the code is passed a reference to the document object. Since jQuery assumes that 'document' is a global reference to the document, anywhere it is used will break. The solution is simple - instead of directly referencing 'document' in the jQuery code, create a jQuery variable that references the document. Any code not in the expected environment can change it as needed. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery, 'document', and FF extensions
On Nov 12, 2:26 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > However, what we've done is try to enforce the proper > context wherever we can (grabbing the .ownerDocument, for example). I > wasn't aware of outstanding issues in that regard. I'd much rather fix > those bugs from the get go since it would make jQuery that much more > able to handle multiple contexts, to begin with. Ah. Well a quick search of the latest nightly shows 48 unqualified references to "document". For example, anywhere with document.createElement() or document.getElementById() or document.getElementsByTagName(), just to start. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3 Released
On Jan 14, 8:45 am, John Resig wrote: > jQuery 1.3 is out! Fantastic! There is definite improvement here. Now I just need to do a bunch of testing to work it into some existing apps and benefit from the performance increases. One of the common criticisms of jQuery has been the browser sniffing, and I'm happy that feature testing is now being used. But I'm concerned about how it's implemented. It seems backwards to me in some cases. For example, opacity. The "support" check is whether style.opacity works correctly, but if it doesn't then it is _assumed_ that using alpha is the fix. This is the wrong logic. Instead, you should check specifically for whether alpha is required. A browser may exist (in theory) that doesn't support style.opacity or alpha, and needs some other fix. Same thing with cssFloat vs. styleFloat or style vs. cssText, etc. You should be testing for non-standard functionality, not testing for the standard behavior and if it's not correct then assuming what the fix should be. Is there any reason feature detection was implemented in this way? Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3 Released
On Jan 14, 12:37 pm, John Resig wrote: > Why would we test for non-standard behavior first? This would mean > that a browser that implements both a standard and non-standard > behavior would see a non-standard preference - which seems quite > wrong. Agreed. > As to the logic structure that we use: > if ( support_standards ) > use_standards_technique() > else > use_other_known_technique(); I think it might be better as: support check: use_fix = ( !support_standards && supports_fix ) then: if ( use_fix ) use_fix() else use_standards() This way, you're applying the fix only if you can't do it the normal way and you _know_ the fix works. ( If !A && B Then B ) Using the existing logic, you're applying the fix if you can't do it the normal way, but you've never checked that the fix works! ( If !A Then B ) You're testing one behavior, then inferring another behavior based on your knowledge of a subset browsers you support. There is no test in your code that tells you that "cssText" will fix a broken "style". Instead of explicitly taking action based on the user agent string, you're assuming that the browser must be X if it doesn't support Y, and you know how to fix browser X, so you do that. This is not the spirit of feature detection, and is only a minor improvement over browser sniffing. > The reason why we choose this structure is that there really isn't a > third option. Yet. > If any of our jQuery.support > tests had three possible solutions then we would certainly opt for > that instead (but, as it turns out, all the things that we test for > only fail in a single browser, yielding only one correct alternative > solution). New browsers can pop into existence that you may wish to support (Chrome?). If you think of it only as a binary condition, there is no room for a new browser that implements it differently. Or, say IE 8.1 has a bug with opacity and needs its own little tweak. Just having a support check for "opacity" won't tell you which fix is needed, and you'll be stuck. > You're confusing our solution with a different problem set - we > designed this to work well with all browsers that we support and their > future releases (for when bug fixes come down the line) - you're > talking about something that works for all current browsers and any > theoretical past releases. That is a fools game and one that is both > impractical and illogical to follow. IMO, it is _more_ future-proof and just better logic. If it's a binary decision right now, then it should be all the same from your point of view. But if it becomes a non-binary situation, the existing logic fails whereas the other method would not. In the end, it works as-is and I'm thankful for it. It's just a bit disappointing to see the effort go into moving toward feature detection, but have it implemented in a way that will still not satisfy the js experts, and leave jQuery open to further criticism in this area. IMO. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] jquery 1.3 select elements
I cant seem to set the value of any select elements using val. Input
type=text is working fine.
So I have something like:
$('#usa_reference_state_id').val("2")
alert($('#usa_reference_state_id').val() )
and the alert is "" so no value was set. I am 100% sure that 2 is in
the list of options for #usa_reference_state_id.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3 Released
On Jan 14, 3:11 pm, "David Zhou" wrote: > A new browser to be support would be enough to warrant a new version > of jQuery, I think. Which would be entirely unnecessary if feature detection is done correctly and the new browser doesn't have any bugs to account for. > In terms of logic, I think it definitely makes sense to test for > standards support *first* and then fall back. This (rightly, I think) > assumes that over time browsers will get *more* compliant. Perhaps, but jQuery has the potential to support browsers like those in phones and other obscure agents that may not be common. It doesn't _need_ to limit its browser support to such a small subset if it would just handle things correctly. As people move towards more mobile apps, wouldn't it be great if jQuery continued to work in that environment? Or when Chrome is released, it could be assumed that it worked correctly until/unless there are specific quirks to fix? > If there's ever a case where a third condition arises, it'd be > relatively trivial to do: > if supports_ standard > standard > else if supports_other_method > other_method > else > other_method2 Why would you want to make the assumption that if a browser doesn't support the standards way or the other_method, that it must support other_method2? Without ever checking if it really does support other_method2? That is logically error-prone. If a browser update is released with a bug that breaks the standards approach, you wouldn't want to then apply a fix that is meant for an entirely different browser, would you? If FF 3.2 breaks "opacity" (for some strange reason, in theory), why would you then want to apply the IE fix of using alpha? It makes no sense. It's the wrong logic! These concepts have been around for a number of years and are used often in robust, reliable, browser-agnostic applications. jQuery needs to catch up with the times if it is to be taken more seriously as a solid js framework. Again, IMO. And I am a jQuery user and advocate (for the right situations), so I say this not because of some desire to nit-pick or criticize, but because I want the js framework that I use to be as solid as possible. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3 Released
On Jan 14, 10:52 pm, "David Zhou" wrote: > Can you elaborate on these concepts? Simple. Don't make the assumption that if the standard approach doesn't work, then a specific fix will. That's almost as bad as saying "if the user agent string says X, then method Y must be available." If the standard approach fails, you must first test to see if the possible fix is available and will correct things before branching to that code. Don't make the assumption that it's the only possible fix and apply it blindly. What is being done now is called "feature inference" rather than "feature detection". The code doesn't detect that "alpha" is needed to fix an "opacity" bug, it just assumes it because "opacity" (et al) doesn't seem to work and "alpha" is the only known fix in a small subset of browsers that jQuery chooses to support. This is not feature detection. If you don't like the looks of testing for fixes before defaulting back to standards behavior, you could use logic like: use_standards = true if (!standards_test) use_standards = false if (fix1_test) use_fix1 = true endif endif Then you have a real picture of what the browser supports. Then in the code you can simply do if (use_standards) do_standard_way else if (use_fix1) do_fix1_way else blow up or do nothing or return false or something If a buggy browser is improved to support the standard method, it will always be used. If a browser doesn't support standards but supports an alternate, it will be used. If neither are supported, an incorrect fix is NOT applied and assumed to work, and the code can either blow up and say the browser is unsupported or give the calling code some way to correct itself for missing browser functionality. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3 Released
Could anyone explain this statement on the wiki page? "You should always be sure to run your page in standards mode. There are known issues with methods not working correctly in quirks mode (including errors in the selector engine in Safari). " Is there a list of the known issues somewhere? (I browsed the bug tracker but it's difficult to find things). It's not always possible to run pages in standards mode. If jQuery 1.3 will break my quirks pages, I need to know what to look for. Matt Kruse On Jan 14, 8:45 am, John Resig wrote: > Hey Everyone - > > jQuery 1.3 is out! Full details > here:http://blog.jquery.com/2009/01/14/jquery-13-and-the-jquery-foundation/ > > Happy 3rd Birthday, jQuery! > > --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 23, 12:48 pm, John Resig wrote: > > Specifically, I have a modal dialog plugin which needs to "detect" IE6 > > and IE7 in quirks mode. IE6 detection is needed for deciding whether > > or not to add an iframe behind the overlay to prevent element bleed- > > through. > This first one is real tricky. I'm not sure what a good solution might > be. Anyone have any thoughts? This is one of the few cases where javascript experts agree that there is no possible feature detection that can address the problem. The generally agreed upon solution is to use conditional comments (as mentioned by others in this thread). In its simplest form: var useIframe=false; /*...@cc_on useIframe=true; @*/ I prefer to use this, as I've done in my context menu plugin: useIframe:/*...@cc_on @*//*...@if (@_win32) true, @else @*/false,/*...@end @*/ Since the problem only exists on windows, this will save other platforms from the unnecessary inclusion of the iframe. No one should be using browser sniffing or inferring this problem from things like maxHeight! This problem and solution has been around for many years and developers should be familiar with it by now. Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 26, 10:36 am, Jörn Zaefferer wrote: > How do you get that code through a minifier? A good minifier shouldn't mess it up. A custom-built minifier I use works fine. Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 26, 10:38 am, Elijah Insua wrote: > that is really smelly, IMHO Why would you think it is smelly? It's technically sound and, IMO, the preferred solution. Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 26, 1:02 pm, Kevin Dalman wrote: > @Matt: This may be functional... > useIframe:/*...@cc_on @*//*...@if (@_win32) true, @else @*/false,/*...@end @*/ > But using a conditional comment 'hack' is just browser/platform > sniffing by another name. It's a different, more reliable method. > You could have written: > var isWin32 = false; > /*...@cc_on isWin32=true; @*/ > var useIframe = isWin32; > So how is this 'better' than: > var useIframe = $.browser.msie && $.browser.version < 7; Browser "sniffing" relies on the user-agent header of the browser. This has been shown to be unreliable. Any browser can insert any string it wishes. Browsers are known to fake this to appear as IE, for example. Just because a browser says it is IE doesn't mean that it has the IE functionality that you may be expecting. This is why the concept of feature detection is vital. Conditional comments will be ignored by any browser except IE. If another browser is pretending to be IE, it would fool your test, but not the cc version. It is a more robust (although still imperfect) test. > Even the skilled developers in this forum cannot agreement how best to > 'replace' $.browser functionality. It would be great to address each concern as they come in. Nearly every issue can be addressed using proper feature detection strategies rather than browser sniffing. And once this is done, jQuery and plugins may begin working properly in browsers that technically aren't in the supported list. This would be a great step forward. > FYI, here is just one example of where I use 'browser detection' to > optimize functionality... > // IE CAN read dims of 'hidden' elements - FF CANNOT > As with bgIframe, there is no 'feature' to check, so $.support is > useless. Why not just check the value, and if it is 0 or undefined/null, apply the "visibility" fix? Then you are completely browser-agnostic. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
I'll try not to beat a dead horse, since I've stated my views. But it does often take some repeated pushing to get js developers to change their thinking and see the benefits of true feature detection. I'm happy to continue this discussion and really get into the dirty details of finding the best solutions if anyone is interested. I think it's an interesting technical challenge. On Jan 26, 7:35 pm, Kevin Dalman wrote: > @Matt: Re: "Why not just check the value, and if it is 0 or undefined/ > null, apply the "visibility" fix?" > Because this is a generic method - some properties can be read when > hidden and some can't. Plus '0' is a valid dimension, so it might mean > there is no border or it might not! Then you only apply the fix for the properties that you know cause this "quirk". The reasoning is simple - Try not to make assumptions, and try to only fix what is broken. If you know that you need a dimension, and in some browsers this dimension is returned incorrectly, then if you are checking that dimension you need to apply the fix if the value is invalid. I don't think it's a good strategy to use a less-effective fix simply because it requires a few more if conditions. > I *could* create and test a bunch > of alternate work-arounds, but if it ain't broke, don't fix it! It just depends on what your version of "broke" means. jQuery and many plugins purposely limit the "supported browser" list because of the techniques being used. It becomes unmanageable to try to support many browsers if you are using browser sniffing and hacks and work-arounds. However, if you use proper feature-detection and apply fixes only in the cases where there are known problems, and if you fix problems in a way that applies only if the problem exists, then you become completely browser-agnostic. For example, IE8RC1 is out now. If a bug in IE7 somehow crept back into this version of IE8, and you were checking the browser version and applying a fix for only <=7, the bug wouldn't be fixed in the new browser. If you fixed the problem in a generic way, then _any_ browser - whether IE or not, and for all previous and future versions - would be fixed. Isn't this preferred? Chrome is a good example - it uses WebKit but has its own js engine, so it may have some bugs similar to Safari and it may have some of its own. If existing code is checking specifically for Safari to apply fixes, then these fixes wouldn't be applied to Chrome. Wouldn't it be better to detect the problems known to exist in Safari and fix them if they are detected? Then any browser using WebKit that may have the same problems would also be fixed. What about browsers on portable devices? They are a different beast in many respects, but well-written code should continue to function and apply fixes for known problems, regardless of the user agent. jQuery is growing in popularity and becoming the framework of choice for many developers and web sites. It should continue to use more robust and browser-agnostic coding practices to ensure that it works on as many browsers as possible, in as many environments as possible. Developers shouldn't be just looking for "what works" in the official supported browser list. They should be challenged to fix problems in a reliable, logical, robust way. That will only make the library better and more able to stand up to criticisms from the js gurus. > Just for the heck of it, here's another example from the same plugin. > I'm sure there are other ways to detect IE6 and IE7 quirks-mode, but I > doubt any are more consise and readable than this if-statement... I don't really understand the problem this is trying to fix, so I'm not sure of a better alternative. > A non-compatible browser that *claims* to be IE will break millions of > websites Only those written poorly. >, so frankly I don't care about such fringe examples. The > dozens of browsers I've tested that emulate/shell IE - including > FireFox with its "IE Tab" plugin - all work *perfectly* with browser > sniffing. Why? Because they are designed to do so That's because they _are_ IE and report themselves as such. If the IETab plugin reported itself as Firefox, you would have all kinds of problems with any code using browser sniffing. But proper feature- detecting would work no matter what the browser called itself. New browsers that share a rendering engine like WebKit but have a completely new and unrecognized user-agent header are more of a concern. Browser sniffing effectively locks them out from fixes that would make the browser behave correctly. Feature detection would allow those browsers to work correctly. Especially for web sites where traffic=money, why would someone want to purposely _reduce_ browser support by choosi
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 27, 7:12 am, Diego Perini wrote: > I just wrote in another thread that there are cases where I prefer to > use the following: > var IE = typeof document.fileSize !== 'undefined', // IE6, IE7 or IE8 > as a general boolean to detect any IE version Is that really a good test? Do you know for a fact that no other browser has document.fileSize defined, and never will? And are using this test to apply fixes for features completely unrelated to document.fileSize? > I have to repeat I like feature testing but sometimes it proves to be > inadequate for the task It's not inadequate, just possibly an unsolved challenge :) > most of the cases are IE related anyway And in these cases, when feature detection does not work, CC is a better option than browser sniffing, and _certainly_ better than feature inference (like checking document.fileSize and making other assumptions about the browser based on that property). Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 27, 11:12 am, Karl Swedberg wrote: > I really appreciate your knowledge and your passion regarding feature > detection. You've definitely given me a lot to think about in this > thread. Thanks, I think it's an interesting discussion. I apologize if I come across "preachy", btw. My interest is purely technical and I have an interest in making jQuery more robust and solid, since I rely on it daily. If you search the archives of comp.lang.javascript, I've had this war many times there (I can't believe I've been writing js for over a decade...) and have slowly adapted my thinking. I look at my old code compared to what I write today and it's embarrassing! I understand the hesitation from many people to adapt true feature detection techniques, and the desire to hold on to existing ways that "seem" to work correctly. But there is a better way, and it opens the door to wider browser support, less concern about browser versions and new releases when browsers get updated, and fewer bugs and quirks in code. I am still amazed at the ways that some of the experts in c.l.j. approach problems with FD and solve them in a very generalized, robust way. > In the case of jQuery core, one of the biggest accomplishments of > version 1.3 was that it eliminated browser sniffing in favor of > feature detection. Are "the techniques being used" in the current > version still problematic? And, if so, how? The currently-used techniques are an improvement, but are not what the "spirit" of feature detection is all about. The current implementation seems like kind of a twisted version of FD, and one that is not as robust as it should be. I go into some details here: http://groups.google.com/group/jquery-dev/tree/browse_frm/thread/5e87613fc36ff7bd/90808be61349b42c?rnum=11 and here: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/b9a5c81d3d683020 Basically, the current logic in some places is: if (standards_supported) use_standards_method() else apply_ie_fix() This is short-sighted, and only logically sound if you limit your browser set to a specific number of common browsers. As a general approach, it fails and is not logically correct. Feature Detection is all about checking how a feature behaves, and if it behaves in a known faulty way, then apply the known fix. Instead of checking whether browsers "support" each of the standard way of doing things, the detection should be checking for known failures that need fixing. Knowing that a browser does not support a standard way of doing something does _not_ logically tell you the correct way to fix it. You need to test to see how the feature behaves to know which fix, if any, is most appropriate. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 28, 9:30 am, John Resig wrote:
> You're still assuming that there's more than one possible fix. If we
> need more than one fix then we would certainly test for the
> applicability of each and work our way down
But then you're just rolling over to the logic that I'm proposing
should be there to begin with. Why not start with it?
> if (standards_supported)
> use_standards_method()
> else
> apply_ie_fix()
> // non-ie, non-compliant, browsers are broken
The problem is if a browser comes along that does not support
standards, but will break even further if you try to apply the IE fix.
You may make things _worse_ by blindly applying the IE fix. Or
whatever browser it is that you have the fix for.
> It doesn't matter - one way or the other the broken browser is still
> going to be broken
It is preferable to have a browser be "broken" in the sense that a
standard method was tried and didn't work correctly, than to have a
bad fix applied and have unpredictable results.
> Feature detection is all about new and unknown browsers - hoping that
> your code will continue to persist. You conflate it with supporting
> old browsers that are lacking features - which is a completely
> separate set of discussions.
Ancient browsers aren't my concern. Unpredictable current and future
browsers are.
Properly handling older browsers is just a bonus when feature
detection is done correctly.
> For example, right now different parts of jQuery may break in older
> browsers - but the library, as a whole, will continue to try and
> operate. It's not clear if that's desirable - if we can't guarantee
> that all of the library should work, should we just quietly fail
> instead?
This is a problem with the current design, IMO. If a person wants to
use jQuery to do "graceful degradation", there is no way to check up-
front to see if everything is going to work correctly. The code
doesn't run through a battery of tests on initial setup to make sure
nothing is going to fail catastrophically down the line.
So, if I am going to convert an UL into tabs, for example, and I want
to maintain the existing interface for browsers that jQuery will
break, then I have a problem. If I run the code, I may get an error
somewhere in the middle and leave the screen in an unusable state. If
it fails silently, then I still have no way of knowing up-front if I
should even call the method to setup my tabs. Again I may be stuck in
some strange state that is unusable.
What would be preferable, IMO, is to be able to check up-front whether
jQuery is going to run without any problems:
if (jQuery.supported) {
// Do all my fancy stuff
}
Another option is to not even define jQuery if it is not available, so
I would then do:
if (jQuery) {
// Do jQuery stuff
}
Then, of course, any plugins or components that try to use jQuery
would need to take into account that it may not exist.
> One idea that I've been thinking of is to make it so that the
> callback passed to $(document).ready(function(){}) will just not
> execute if we can't guarantee that all of jQuery will work.
That is not the only place that jQuery is used, though. For example,
> 2) This limits the set of possible browsers that will ever even hit
> the "jQuery.support" code to those that we actually have solutions
> for.
This can be tricky. What if a particular browser has an opacity bug
with no fix and doesn't pass the "support" test, but works with
everything else? If I never mess with opacity in my scripts, why
should every other function of jQuery become unavailable?
That means you could then add a lot of different levels of jQuery
"support", and the developer could choose what they require and make
sure that it is available. This might be logically best, but it could
also create a mess. There may be a place in the middle that is ideal.
> But - again - this is not feature detection as it's typically defined
> and should not be confused with feature detection. You're worried
> about old browsers failing gracefully - and that's a completely
> different set of issues from what normal bug fix feature detection
> should be handling.
Again, past browsers is just a small part of the concern. Current and
future browsers in environments that may be unpredictable (portable
devices, embedded devices, kiosks, higher security, etc) is the bigger
concern.
Consider an IE6 user in an environment where the administrators have
disabled ActiveX and ajax is not available. What happens? Will jQuery
choke, or continue to function in the most optimal way? Is there any
way for me, the author of a jQuery plugin, to know that some features
will not work correctly and should not be called? And how can I plan
for graceful degradation if I don't know where things will ra
[jquery-dev] Re: IE6 feature detection - possible solution
n cases exactly like the above. It would be unfortunate to remove jQuery from webapps simply because ajax wouldn't work correctly, when it may not be used at all anyway. If jQuery wouldn't run because a single component wasn't supported, that would make it less useful, IMO. Using the pseudo-code above, you could do: ajax_available = true use_xhr = xhr_test() if (!use_xhr) if (activex_test()) use_activex = true else ajax_available = false endif endif This way, my script could check ajax_available early to see if it's going to succeed. I can then make choices based on that. Another example of this approach is: http://www.cinsoft.net/mylib.html It's a little more extreme in its attempts to be robust, but it is interesting to say the least. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: IE6 feature detection - possible solution
On Jan 28, 2:42 pm, David Zhou wrote: > And for the something, you say: "blow up or do nothing or return false > or something". Well, I wouldn't actually recommend "blowing up" as the best choice, it was just an example. :) Perhaps it would be better to do nothing, but hopefully the code will never get to that block because the user was able to detect up-front that this particular feature would not run correctly and therefor wouldn't call it. It's really a design decision at that point, of what to do when the code realizes it cannot succeed. But it is definitely preferable to _know_ that you are not going to succeed and do something, vs applying a fix blindly and assuming it worked. > It seems like you're claiming that falling back naively to alternate > is bad because things could break, beyond visual artifacts. And yet, > it's acceptable to "blow up" in your ultimate else clause? Falling back to a particular fix just because the standard way didn't work is just plain faulty logic. It's just waiting to fail. Intentionally falling into an "else" clause and designing a proper handling mechanism is the better approach. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Selector :enabled no longer finds hidden elements
On Jan 29, 3:50 pm, Diego Perini wrote: > None of them specify if the field would be submitted or not, if I > recall correctly all of the form elements values should be serialized > and submitted, "enabled", "disabled" and "hidden". Disabled form elements are not submitted. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Proposal: Attributed events
On Jan 29, 8:24 pm, Yehuda Katz wrote:
> $("p").bind("keydown[keyCode=119]", function() {})
Could you also just redefine 'keydown' as a plugin?
$('p').keydown( 119, function(){} );
or
$('p').keydown( [119,120,121], function(){} );
or
$('p').keydown( 'enter', function(){} );
etc.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: There must be a better way !
On Feb 9, 3:44 pm, weepy wrote: > Any ideas on the second part regarding jQuery not writing out single > quotes properly for background images ? As an aside, why use single quotes? They aren't required, and I've always believed that in general it's better for browser compatibility to leave them out. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery 1.3.2 Alpha Ready
On Feb 16, 12:31 pm, John Resig wrote: > There were some logic changes ... how :visible/:hidden work Previously, elements with visibility:hidden were not :visible, but now they are (tested in IE6,FF3). Was this an intentional change? Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Improvements to .each()
This is the current .each() function:
-
// args is for internal usage only
each: function( object, callback, args ) {
var name, i = 0, length = object.length;
if ( args ) {
if ( length === undefined ) {
for ( name in object )
if ( callback.apply( object[ name ], args ) === false )
break;
} else
for ( ; i < length; )
if ( callback.apply( object[ i++ ], args ) === false )
break;
// A special, fast, case for the most common use of each
} else {
if ( length === undefined ) {
for ( name in object )
if ( callback.call( object[ name ], name, object[ name ] )
=== false )
break;
} else
for ( var value = object[0];
i < length && callback.call( value, i, value ) !== false;
value = object[++i] ){}
}
-
First, the only place I could find that calls each() with an "args"
argument is in the ajax load() function:
self.each( callback, [res.responseText, status, res] );
(hopefully this really is the only place each() is called like this,
but if not then perhaps this is a moot point)
The entire first half of the each() method could be removed by using
code like this in load() instead:
self.each( function() {
callback.call(this,res.responseText,status,res);
});
Second, this bug: http://dev.jquery.com/ticket/4366
which is addressed in this thread:
http://groups.google.com/group/comp.lang.javascript/msg/468705660cc10d82
talks about a bug in each() that can be fixed by changing the loop
structure.
This clarifies the loop structure that is there, and assures the code
won't break in cases like that noted in the bug report.
The result would be something like this:
-
each: function( object, callback ) {
var name, i = 0, length = object.length;
if ( length === undefined ) {
for ( name in object )
if ( callback.call( object[ name ], name, object[ name ] ) ===
false )
break;
} else {
for ( i=0; ihttp://groups.google.com/group/jquery-en/browse_thread/thread/b4945457c20aa21b/0b20ebdc9c517d0c
This could easily be done by adding:
-
each: function( object, callback ) {
var name, i = 0, length = object.length;
if ( length === undefined ) {
for ( name in object )
if ( callback.call( object[ name ], name, object[ name ],
object ) === false )
break;
} else {
for ( i=0; ihttp://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: conditional chaining, reincarnated
On Jun 2, 1:06 pm, ajpiano wrote:
> Over the years there has been considerable interest in providing
> conditional chaining functionality to jQuery, though nothing has ever
> been cemented.
I still don't understand the desire to do all this chaining. How is it
at all beneficial?
You take perfectly readable javascript code like this:
var elem = $('div');
elem.append( '1' );
if ( my_test( 'foo' ) ) {
elem.append( '2' );
}
elem.append( '3' );
and turn it into less-readable, jquery-specific, less-maintainable
code like this:
$('div')
.append( '1' )
.iff( my_test, 'foo' )
.append( '2' )
.end()
.append( '3' );
Same number of lines, but you've made it more cryptic and less
javascripty. How is this a good thing?
As part of my "jQuery Best Practices" I recommend that developers
never chain across multiple lines. I always encourage assigning $()
calls to a variable, then using that variable.
Any line beginning with a . should be discouraged, IMO.
Just my $.02...
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Setting a to selected inside a IE6
On Jun 11, 9:39 am, Alan Williamson wrote:
> Got an interesting little problem with IE6 and selecting a particular
> item within a SELECT box.
Wow, why would you want to use jQuery to do this? Instead, try:
document.getElementById('selectTest').options[idx].selected = true;
Or if you really wanted to use jQuery a little:
$('#testSelect options')[idx].selected = true;
> Is this a bug in JQuery?
Yes. Avoid the attr() function in jQuery, it's been broken for a long
time.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Are effects really not supported in IE/Quirksmode?
On Jun 11, 3:50 pm, John Resig wrote:
> This is due to the issue where if an element has a height or width
> equal to 0, in IE in quirksmode, the full height/width of the element
> is shown.
I'm aware of the issue, it has been around for a long time...
> jQuery use to have a fix for this - anytime a value of 0 was
> set a value of 1 was set instead - unfortunately this caused other
> strange side-effects with other browsers so it became preferable to
> require that the page not be in quirksmode.
This is the leap of logic that doesn't seem rational to me. Instead of
finding a better fix, you throw out common functionality in a huge set
of pages on the web? I don't like the approach that jQuery seems to
take too often - If a problem proves to be too tricky or a browser is
just a pain to support, just declare that feature or browser
unsupported! That seems lazy to me in a library that is suppose to
normalize browser behavior, not toss out those that don't normalize
easily. Especially when the browser is the most common on the web, and
in quirksmode which is also still a very common environment.
> Now, we could feature detect this bug occurring (which is obviously
> possible, as shown in the test case) and only do the "set 1 only, not
> 0" in browsers that have that specific problem - however that creates
> the situation where Internet Explorer in quirksmode will have a
> completely different style of animation (at least one that is, still,
> only fixable by pushing your page out of quirksmode).
How would it be completely different?
I put this fix in the page where I needed this effect:
jQuery.fx.prototype.originalCustom = jQuery.fx.prototype.custom;
jQuery.fx.prototype.custom = function(from,to,unit) {
if (this.prop=='height') {
to = to || 1;
from = from || 1;
}
this.originalCustom(from,to,unit);
}
> As always, a patch with a better solution for this problem would
> certainly be welcome.
Just don't animate height to/from 0 as long as the units are px -
always use 1 instead. I can't think of why this would be a problem in
any browser, would it?
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: fadeIn and fadeOut and display / visibility
On Jun 26, 1:14 pm, Jonny007-MKD wrote:
> i wanted to call your attention the the fadeIn and fadeOut function.
> after fadeout reduced the opacity to 0, it sets display = none and
> then exits. fadeIn first reverses this and then fades the object.
> i use this effect when i load new content via ajax combined with an
> animation to set the div height to the new value. the problem is, that
> display=none removes the placeholder for the element, so the elements
> at the bottom jump upward, then back down and then get moved.
> i know the workaround with the callback function, setting display to
> block and visibility to hidden, but i think it should also be no
> problem to insert an argument for fadeIn/Out what it shall do at the
> end, hide it with display or with visibility.
Just don't use fadeIn/fadeOut. They are intended to be simple ways to
show/hide an element with a fade effect.
Use animate instead:
$obj.animate( {'opacity':0} ); // fade out
$obj.animate( {'opacity':1} ); // fade in
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: IE6: alive, well and prosperous
On Jul 16, 10:41 pm, tres wrote: > Maybe the IT industry should just grow some balls and stop supporting > IE6, or IE in general. The the industry has everything to gain and > nothing to lose by severing all ties to IE. People will be forced to > indulge in a newer, better, faster and more secure browser. IE6/7 won't run on Windows 2000, and many businesses are still stuck there. IE allows administrators to setup options and security from a centralized location, which is vital to many organizations. IE has ActiveX - a nightmare on the general web but very useful internally for many businesses. In the end, continuing to use IE6 costs very little, while moving to a new browser may cost a considerable amount of money (upgrading OS's, re-building webapps and processes to not use ActiveX, finding some way to centrally control browser installations, etc). Only when keeping IE6 becomes more painful than upgrading will these last hold-outs change. I suspect that time is coming soon... Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: isFunction() that works in IE too
On Aug 4, 11:03 am, Henry wrote: > That must depend on what is meant by "working" and "solution". This > thread does not contain a clear statement of what it is this - > isFunction - function is supposed to do; the discrimination that it is > supposed to make. This has been the repeated problems in "isFunction" debates over the years. What -exactly- is this supposed to do? Can anyone define it? You cannot test for success with out a strict definition of intended behavior. But once you start trying to nail down that question, you find yourself in a maze of questions, and the easiest way out is to avoid the need for isFunction to begin with (ie, stop all the overloading). Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Bug: selectors with commas in IE 7
I recently posted this bug regarding selectors with commas in IE 7. It includes a minimal test case. http://dev.jquery.com/ticket/4999 I was just wondering if anybody had had the time to look into it. :) -matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Bug? attr(name) return false in IE8
On Aug 27, 11:16 am, William Chang wrote: > I don't think the attribute is defined by default, after I did some > more testing. I find the value return is not consistent between > Firefox and IE8 (and probably previous versions of Microsoft Internet > Explorer). First of all, the attr() function has had problems for a long time. Don't use it. Properties and attributes are different things, and jQuery confuses the two in unpredictable ways. Although you are requesting the attribute value, it really returns the property value. Read through the source of attr() and it becomes pretty clear what is happening. The difference you are seeing is due to the (name in elem) check. IE is returning true, causing the property [false] to be returned. FF is returning false, causing getAttribute() to be called, which returns null, which gets "normalized" to undefined. Depending on what type of element you are calling this on, the results may be the same (input, for example), or different (img, for example). It's always best to avoid using attr() because of it's poor implementation. IMO. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: JQuery could throw nicer errors
On Sep 4, 9:32 am, Moi Ce Soir wrote: > Well I had a thought. It might be a bad thing to add extra code into > JQuery simply to check if the developer has been stupid. It'd be > better to have a plug in that developers can add and temporarily use. > I'm working on such an proof of concept plug in, so I'll post here > again with the example. See a short discussion and proof-of-concept here: http://groups.google.com/group/jquery-dev/browse_frm/thread/5360f7b3d67a2ddc Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Javascript syntax oddity
Read up on the specs of how js is required to parse and execute - this
behavior is defined there.
When entering an execution context (either the global scope or
function), all variables declared with 'var' are parsed before any
execution actually begins.
So just because 'var $inner' appears at the end doesn't mean anything.
The compiler actually finds it first, creates a new variable in the
current scope, then begins executing the function.
Otherwise, if you had code like this:
function() {
myVar = 5;
var myVar = 6;
}
the first line would alter the global (or containing) scope, while the
second would be local to the function. However, in reality since the
'var' is found first, both variables refer to the same item.
This is a reason why it is common and recommended practice to declare
all local variables at the top of a function, using 'var', so it is
very clear.
Matt Kruse
On Sep 14, 5:15 am, ajp wrote:
> I didn't expect this to work (with my 'compiler' hat on) but it does:
>
> var clickFunction = function() { $inner.doSomething() };
> $("div")
> .append("bla")
> .click(clickFunction);
>
> var $inner = $div.find("#inner");
>
> I was expecting an error for $inner to be undefined when the
> javascript parsed the first line, but the browser script engines seems
> quite happy with this sort of super-late declaration.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: find on large selects
Slightly slower actually. Maybe a few milliseconds, I believe. I don't
recall the exact times.
I could set up another test case with some timing if you want.
On Mon, Sep 21, 2009 at 11:00 AM, Samer Ziadeh wrote:
> How does it perform if you remove the .find(), so you get $('#mySelect
> option:selected').text()
>
>
> On 2009-09-21, at 10:50 AM, matthew_maxwell wrote:
>
>
> I've been using jQuery for a little bit now, and have noticed that
> whenever you are attempting to use jQuery on selects with a large
> amount of options, it adds a few seconds of lag to the operation.
>
> An example I ran into was when I had a select of about 4,000 options
> or so (one for every user of my site), and wanted to use jQuery to
> change from a select to a plain text field, using the following:
>
> $("#user").html( $("#mySelect").find("option:selected").text() );
>
> The time from when the user initiates the change until it actually
> completes is about 1 or 2 seconds.
>
> I notice there's also a delay when it goes to add the select back:
>
> $("#user").html(
>$( myApp.Selects.Users.HTML ).change(
>function () {
>$("#user").html( $("#mySelect").find
> ("option:selected").text() );
>}
>)
> );
>
> The lag time also appears when I go to do a simple remove:
> $("#mySelect").remove();
>
> When I use the DOM equivalents, though, this works almost instantly.
>
> Just figured I'd give you a heads up.
>
> No other issues, though. Solid library. Good 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-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: find on large selects
The thing is, I need the actual text of the selected option. I wound up
using a mix of DOM/jQuery on this, but was just wondering if anyone had
experienced similar issues.
I didn't actually set the innerHTML to nothing, I did:
document.getElementById("select").parentNode.removeChild(document.getElementById("select"));
On Mon, Sep 21, 2009 at 12:25 PM, Michael Geary wrote:
> Is this a single-selection or multiple-selection select element?
>
> If it's single selection, then change:
>
> $("#mySelect").find("option:selected").text()
>
> to:
>
> $("#mySelect").val()
>
> This will be fast in all browsers, because it uses the .selectedIndex
> property from the DOM. It won't help on a multiple selection element,
> though.
>
> For this code:
>
> $("#mySelect").remove()
>
> You've probably replaced it with:
>
> $("#mySelect")[0].innerHTML = "";
>
> Is that right? That's what I would do, assuming that there are no jQuery
> event handlers on the individual option elements.
>
> -Mike
>
> On Mon, Sep 21, 2009 at 7:50 AM, matthew_maxwell <
> leftwithoutli...@gmail.com> wrote:
>
>>
>> I've been using jQuery for a little bit now, and have noticed that
>> whenever you are attempting to use jQuery on selects with a large
>> amount of options, it adds a few seconds of lag to the operation.
>>
>> An example I ran into was when I had a select of about 4,000 options
>> or so (one for every user of my site), and wanted to use jQuery to
>> change from a select to a plain text field, using the following:
>>
>> $("#user").html( $("#mySelect").find("option:selected").text() );
>>
>> The time from when the user initiates the change until it actually
>> completes is about 1 or 2 seconds.
>>
>> I notice there's also a delay when it goes to add the select back:
>>
>> $("#user").html(
>>$( myApp.Selects.Users.HTML ).change(
>>function () {
>>$("#user").html( $("#mySelect").find
>> ("option:selected").text() );
>>}
>>)
>> );
>>
>> The lag time also appears when I go to do a simple remove:
>> $("#mySelect").remove();
>>
>> When I use the DOM equivalents, though, this works almost instantly.
>>
>> Just figured I'd give you a heads up.
>>
>> No other issues, though. Solid library. Good 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-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: find on large selects
Well, the select lists everyone that has access to utilize the ticketing
system for submitting feedback/kudos on them, so everyone needs to be in the
select.
I'll try the suggestions here.
Thanks for all the good advice!
On Tue, Sep 22, 2009 at 3:49 AM, DBJDBJ wrote:
>
> Web 2.0 Apps and "multi-thousand chidlren" dom collections is an issue
> (aka: problem) I already am thinking about.
> There will be a point in a "single page + ajax" web apps which will
> make this (widely used) ad-hoc app design not-feasible.
> And Matt's problem is showing this clearly. Not yet, but probably
> soon, if huge ajax result sets do result in generation of huge dom
> collections , even direct dom manipulation will show a visible (over 1
> sec) delay.
>
> --DBJ
>
> PS: Why such a large number of options in a single select ? In any
> case since we are in a "visible delay" problem teritory, maybe this
> innocent looking advice will help :
>
> "Always use (one dom node as) the jQuery context argument"
>
> In your case :
> Instead of this : $("#mySelect").find("option:selected").text()
> use this:$("option:selected", document.getElementById
> ("mySelect") ).text()
>
> And yes, context argument will "work" only if it is a single dom
> node. Documented and proved by "the Team".
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: find on large selects
It's very possible as the company continues to expand :P. Now that you mention it, though, I could probably break them out into a department and then manager menu/submenu which would filter the list out quite nicely. Though, of all the things I've used jQuery for, this being the only issue really says a lot about it. Optimizing the menu like that might even eliminate, or at least greatly reduce, this issue. Thanks for the ideas and help. I probably would have continued to over think the situation and may have taken even longer to come up with the idea to break the menu into department/manager groups, haha. Over thinking is sometimes worse than inexperience, I think. On Tue, Sep 22, 2009 at 9:23 AM, DBJDBJ wrote: > > I have created quick and dirty test of adding 50K options to the > single elements. > Then I started it on this desktop and IE8 ... and waited > Then I did not believed what I have seen, and executed the same test > on the WIN7 64 bit + IE8 64bit ( 2 core Intel + 2GB RAM). > The result was almost exactly the same (as on single core , 1GB > laptop ) > > "...Tests completed in 1168643 milliseconds..." > > To append 50.000 options to a select element ?! > The latest Chrome Beta on the same W7 machine, jQ unit test reports 1 > millisecond (which can't be right) > Same is on the latest FF ...although FF "complaints" message box > popped-up. > > Maybe not an "real life example" ... but ... I hope Matt wil not have > 50K+ users ;o) > > --DBJ > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: fadeIn with IE 8 Compatibility Mode forced off
Have you tried using fadeTo or animate instead? I had similar issues with IE8 a while ago and from what I recall switching to fadeTo did the trick. On Sep 23, 12:08 am, Mad-Halfling wrote: > Hi, I originally posted this in the general discussion, but it is > probably more appropriate here. > > Are there problems with the animation with IE8 compatibility mode > forced off? > I am using meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" > to force IE 8 out of compatibility mode for my site, as I need to use > the new CSS support that IE 8 finally properly implements (it's an > internal site, so I'm not worried about any other browsers), but I > notice that in doing that the fadeIn (and Out) no longer seems to work > - the content the method is being applied to just sits there for the > fade duration and then disappears. This isn't a great hardship, but > it would be nice to be able to showcase what jQuery can do and these > effects would add a bit more wow-factor to the site. > > Thx > > MH --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: What is the key difference ?
My example code uses this selector syntax: t...@class^=child-] Support for [...@attribute...] has been changed to just [attribute...] with jQuery 1.3. Remove the @ and it should work for you. Btw, I find this change very annoying. It has prevented a few projects I've touched from upgrading their jQuery version, because it would require going in and fixing lots of code. I wish there was more backwards-compatibility! Matt On Oct 2, 5:58 am, DBJDBJ wrote: > Matt Kruse has an nice and simple jQuery "ideas page". I could not > make it work for me. > > http://dbj.org/h.htm > > The difference is I am using the latest jQuery.And I have also removed > some parts from Matt's page. > The first example. "Details" Table . My page is (obviously) not > working. Why? > Link to the Matt's page is there. His page uses (I think) jQ 1.2 and > is working. > > Simple Tree View works on both pages. > > Also when using IE the behaviour of my page is much worse. > > Any advice? Idea? > > --DBJ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
Re: [jquery-dev] Improve Performance
My first guess would be the use of :DropDownList.
Why not use a more specific selector for your find?
Also, I'm not sure this is the right place for this question.
On Fri, Nov 20, 2009 at 5:53 AM, Nizam wrote:
> Hi,
> In the below Code takes too much of time for execute I don't know
> did I made any mistake.
>
> function chkLicense() {
>var firstLicDD = '', secLicDD = '', ddLicValue = '', ddStateValue
> = '';
>var firstStateDD = '', SecStateDD = '';
>var IsTwoDentLICandSTATEsame = false, firstDDIndex = null,
> isLicenseNotSel = false;
>var isStateNotSel = false, isTwoLICsameExceptDental = false;
>var isDntlMedHaveAllState = false; isLicEmpty = false;
>var $myTable = $('#Licenses tr');
>$myTable.each(function(index) {
>var LicNo = '', ddindex = '';
>firstDDIndex = index;
>if (index > 0) {
>firstLicDD = $(this).find('td :DropDownList').eq(2).val();
>/*For PA DropDown*/
>//firstStateDD = $(this).find('td :DropDownList').eq
> (11).val();
>/*For Html DropDown*/
>firstStateDD = $(this).find('td :DropDownList').eq(10).val
> ();
>//if ((firstLicDD == 1) || (firstLicDD == 5)) {
>if (({ 1: 1, 5: 1 })[firstLicDD]) {
>if (firstStateDD == 0) {
>isDntlMedHaveAllState = true;
>}
>}
>//if (firstLicDD == '' || firstLicDD == null) {
>if (firstLicDD == '' || firstLicDD == null) {
>isLicenseNotSel = true;
>}
>if (firstStateDD == '' || firstStateDD == null) {
>isStateNotSel = true;
>}
>LicNo = $(this).find("td").eq(2)[0].childNodes[0].value;
>if (LicNo == '' || LicNo == null) {
>isLicEmpty = true;
>}
>
>if (firstLicDD != "") {
>$myTable.each(function(index) {
>if (index > 0) {
>secLicDD = '', SecStateDD = '';
>secLicDD = $(this).find('td :DropDownList').eq
> (2).val();
>/*For PA DD*/
>//SecStateDD = $(this).find
> ('td :DropDownList').eq(11).val();
>/*For Html.DD*/
>SecStateDD = $(this).find
> ('td :DropDownList').eq(10).val();
>if (SecStateDD != '') {
>for (var i = 0; i <= parseInt(SecStateDD)
> + 1; i++) {
>/*For PA DD*/
>//if ($(this).find('td :DropDownList')
> [11][i].value == SecStateDD) {
>/*For Html.DD*/
>if ($(this).find('td :DropDownList')
> [10][i].value == SecStateDD) {
>ddindex = i;
>}
>}
>}
>if (secLicDD != "") {
>if (firstDDIndex != index) {
>if (firstLicDD == secLicDD) {
>if ((firstLicDD == 1) && (secLicDD
> == 1)) {
>if ((secLicDD == 1) &&
> (SecStateDD > 0)) {
>/*For PA DD*/
>//var ddSelectedText = $
> (this).find('td :DropDownList')[11][ddindex].innerHTML;
>/*For Html DD*/
>var ddSelectedText = $
> (this).find('td :DropDownList')[10][ddindex].innerHTML;
>var Prvid = $
> ('#PrimaryKey')[0].value;
>var stateCode =
> ddSelectedText;
>var LicenseTypeID =
> firstLicDD;
>//fnIsAllStateForDenMed
> (Prvid, stateCode, LicenseTypeID);
>}
>if (SecStateDD != "") {
>if (firstStateDD ==
> SecStateDD) {
>
> IsTwoDentLICandSTATEsame = true;
>}
>}
>}
>else {
>isTwoLICsameExceptDental =
> true;
>}
>}
>}
>}
>}
>});
>
>}
>}
>});
>if (isStateNotSel || isLicenseNotSel || IsTwoDentLICandSTATEsame
>|| isTwoLICsameExceptDental || isLicEmpty ||
> isDntlMedHaveAllState) {
>var message = ' ';
>if (isLicenseNotSel) {
>message += " Select Licence \n" + "";
>}
Re: [jquery-dev] Re: next()
I would do something like
$("select.country").change(function () {
var country = $(this),
country_id = country.attr("id"),
state = country.next("select.state");
});
state isn't the DOM element, it's the jQuery object, so you'd have to go
alert(state.attr("id"));
Hope this helps.
Also, I agree with Dave, this isn't the place for this kind of question.
On Wed, Dec 2, 2009 at 6:20 PM, Dave Methvin wrote:
> The jQuery-en group is a better fit for this question. This group is
> for the discussion of the development of jQuery itself.
>
> --
>
> 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
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.
Re: [jquery-dev] $.fn.contains is not consistent with :contains
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.
>>
>>
>>
>
Re: [jquery-dev] $.fn.contains is not consistent with :contains
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
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 2:15 pm, Mike Hostetler wrote: > If the > jQuery team adopted a few choice plugins, like a debugging plugin, a data > layer plugin, and by putting the widget code into the core, allowed these > plugins to be extended, I think a very powerful foundation would be provided > to developers. I've often said that plugins are vital to jQuery's success, but also it's weakest link. IMO, there must be: 1. A roadmap for plugins. Someone needs to sit down and design a strategy for breaking up functionality into reusable parts, and make a list of what plugins are needed 2. A specific list of requirements, documentation standards, and development style needs to be decided on 3. A core list of "official" plugins needs to be created and maintained by developers, and integrated into the test suites. The concept of a "jQuery Enterprise" suite could just be a collection of official plugins that do most of what a developer may need in a single package. Similar in concept to "My Eclipse" which offers a package of Eclipse plugins based on your development environment and goals. > 3. Lastly, I'm involved with collecting and writing down the latest > information and practices of building jQuery plugins Is this a public effort? Because I have struggled so much with the quality of existing plugins and their lack of extensibility (IMO, of course), I've been trying to advocate a plugin structure in projects that I've worked on. If you're looking for any new thoughts on the issue, I'd like to participate. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 3:57 pm, John Resig wrote:
> Does anyone have
> any examples of plugins that they wished to extend in a particular
> manner? (I needed the validation plugins X method to do Y - examples
> like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
context menu, etc. Others I have abandoned completely because they
were overly restrictive. I don't recall the reason in each case.
I've arrived at some guidelines I think should be followed when
writing plugins:
1. No method should be private. Not every method needs to be part of
the API, but don't hide any logic from being customized by a
developer. Just because you can't imagine a case where someone would
need to change the internal logic doesn't mean it won't happen.
2. All static values (strings, class names, numbers, defaults, etc)
should be stored as plugin properties that can be changed
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
4. All logic should be broken up into the smallest logical chunks
possible. Each method should have a very specific task, which can be
over-ridden if needed
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Allow the user to over-ride this default behavior if they wish. Don't
assume you know how to calculate a container's size using the built-in
jquery methods - separate that logic out to a function so I can
customize it if needed. In general, AVOID ASSUMPTIONS.
6. Any time HTML is created inside the plugin, generate it inside a
function that can be over-ridden if the user wants to generate
something slightly different
7. If your plugin has dependencies, do a quick check up-front to make
sure they are there, otherwise alert the developer
8. Any time you have static quoted text (or id's or class names, or
element names, etc), you better have a really good reason for assuming
that the user would never want to change it. And if you have a reason,
it's probably not good enough.
9. Provide many options, but also provide a logical default
implementation. Let the user do as little as possible to begin using
the plugin in a reasonable way, then show them just how much power
they have to customize it.
10. Pass in an {options} parameter instead of a hard-coded list of
options
11. Provide useful examples
12. Use a good code structure like ;(function($){ })(jQuery) and other
common recommendations
That's a short brain-storm at least. Key concept when writing a
general-use plugin - Avoid Assumptions! :)
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 24, 5:44 pm, John Resig wrote:
> > 3. Users should be able to over-ride defaults at the plugin level
> > (true for all instances) or per-instance
> Do you mean something like: .myplugin({ myprop: "override" }) where
> passing in the option overrides it for that instance? (I think that's
> what you meant, just wanted to clarify.)
I'm not sure if you mean what I mean :)
For example, in my context menu plugin (which is the only plugin I've
published so far as an example of some of the concepts I promote):
http://www.javascripttoolbox.com/lib/contextmenu/
source:
http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js
You can do this:
$.contextMenu.shadow = false;
This will set the default value of the 'shadow' property to false for
all instances created from then on. So what I typically do is include
the contextmenu plugin, then in a separate include file per project I
will setup the defaults. From then on, everywhere I use the plugin in
the app I don't have to worry about setting it up, I can just use it
in the "default" state.
If I want to over-ride defaults for one specific context menu, I can
do it using the options array like:
$(".context").contextMenu( [menu] , {options} );
> > 5. No assumptions should be made about the user's environment. For
> > example, don't blindly append newly created DOM elements to the body.
> Do you mean in the sense that appending to the body is bad - or that
> "body" is a static word and thus should be a mutable option in the
> plugin (#8).
The latter. I've had situations where appending objects to the body
caused issues (because of weird layouts, etc). I've also had some
situations where I wanted newly-created objects to be children of a
specific container, not of the whole body. It's just one example of a
situation where a plugin author may assume that every object like an
absolutely-position menu should be appended to the body, but by making
it configurable it gives the developer flexibility without negatively
impacting the plugin functionality at all.
> > 10. Pass in an {options} parameter instead of a hard-coded list of
> > options
> I think the corollary to this would be: If you start having optional
> arguments you should really push your users towards using the
> {options} object exclusively.
Agreed. And required attributes should be hard-coded parameters before
the {options}.
> This gives a lot to work with, though. I think I'll probably do a
> quick re-write of the jQuery.plugin stuff to try and codify some of
> these notions.
I hope you'll take a quick look at
http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js
I don't propose it as a perfect or ideal solution. But it's one
approach, and I've built a template from it that I use in developing
new plugins. There are some places in the code where I could do some
re-writes to better incorporate my own guidelines!
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: A Modest Proposal: jQuery Enterprise
On Feb 25, 11:36 am, Daniel Friesen wrote: > I also thought about the idea of a jquery-debug.js at one point. My > thought was adding a number of logging statements for various warnings > (selector found 0 nodes but you try to style or do stuff to it; common > issue for not understanding why nothing has been styled sometimes) which > would hook into a variety of debuggers including FireBug. I've posted something very much like this in the past: http://groups.google.com/group/jquery-en/browse_thread/thread/5e3b22a592d27247?fwc=1 My proof-of-concept tried to catch things like selectors that return no matches and passing complex selectors to .is (which often tripped up many developers in the past). Putting debug code into the core itself for a "debug version" and then filtering it out for the "release version" of jQuery would be the ideal solution, IMO. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: .remove() without the event+data stripping
On Feb 25, 5:46 pm, Már Örlygsson wrote: > Thus we'd have two quite unambiguously named methods - `.destroy()` > and `.detach()` - with no nasty surprises attached. :-) But why do you need another jQuery method just to call parentNode.removeChild? The .remove() method handles all the jQuery internals, as a jQuery method should. If you just want to remove an object from the DOM, just use simple, standard javascript. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: .remove() without the event+data stripping
On Feb 26, 12:10 am, Daniel Friesen wrote:
> jQuery is supposed to simplify things, not force the user to shove ugly
> native DOM code into something programmed in jQuery.
Here is my view...
jQuery exists to normalize browser behavior and to simplify mundane
tasks. It is vital for anyone using jQuery to understand javascript
and be able to write "plain old javascript" (POJS).
jQuery is not a "replacement" for POJS. It's not even a layer on top
of POJS. It is just a tool to do a few common tasks in a different
way. Nothing is "programmed in jQuery", and thinking in that way is a
bad idea.
jQuery is just another API to learn. Reading documentation to learn
what a .detach() method does and then using it is no better than
learning the core .removeChild() method. In fact, it's worse because
if you're in a situation without jQuery, you won't know how to remove
a child node! The advantage to using .remove() is that it does all the
jQuery stuff that might need done.
Trying to encourage people to do everything "the jQuery way" rather
than using POJS is a bad idea. I have seen some terrible and
inefficient code written because people only knew how to do things
"the jQuery way" and end up writing code that is uglier, slower, and
harder to maintain than the POJS they were trying to improve on. When
developers learn only the jQuery way to do things, then they start to
try to solve every problem using it, even when it's not warranted.
When all you have is a hammer, everything looks like a nail.
I've seen this many times:
var id = $(this).attr('id');
and I just saw this today:
var tr = $(td).parents('tr:first').get(0);
I refer to this kind of stuff as "jQuery Obfuscation" :)
> You're suggesting instead of creating a simple .detach() method, we
> force programmers to type in
> $('.someMultiNodeSelector').each(function()
> {this.parentNode.removeChild(this);});
Is "forcing" someone to write POJS so bad? :) I use jQuery often, but
I still write POJS in most cases unless jQuery would make something
significantly easier or more concise, or fix browser quirks that I
don't want to do myself.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Detecting IE8 operating in IE7 mode
On Mar 4, 3:26 pm, lrbabe wrote: > I'm aware that jQuery promotes features detection over browser > sniffing but currently we provide no way for the user to figure out > easily when the browser is IE8 operating in the so called > "compatibility mode". Why would you need to detect this? What problem are you trying to solve? This is exactly why any type of browser sniffing is inherently error- prone, and feature-detection strategies should be used instead. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: 1st array element $('input[value='+$(this).text()+']'
On Mar 10, 9:48 pm, Bas wrote:
> if I with the selector $('input[value='+$(this).text()+']') all the
> objects grab they match with the value and count them i got 3 results.
> i want to remove the first object in the array from the DOM, i tried
> already some different thins like:
> $('input[value='+$(this).text()+']')[0].remove();
When you do [0] you get the first DOM element, which is no longer a
jQuery object, so it doesn't have the remove() method.
Instead, you want this:
$('input[value='+$(this).text()+']:first').remove();
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Detecting IE8 operating in IE7 mode
On Mar 29, 2:27 pm, "Jeffrey Kretz" wrote:
> While I am completely behind feature detection as a solution and am using it
> wherever possible, it is important to realize that feature detection doesn't
> always identify the ability of the browser to render the VISUAL layout of a
> page correctly.
And if there is no way other than visually inspecting the results to
see if they worked, then that is a case where feature detection will
not work. There are fewer of these cases than most people think.
> As an example, take the broken implementation of PNG alpha in IE6.
This is one of the few cases mentioned above. Two typical approaches
are:
1) Refactor out the dependency on PNG alpha. Design to the lowest
common denominator using GIFs.
2) Use IE's cc mode to include an additional style sheet that targets
the specific browser with issues.
In these cases, it is often more problematic for a user to see a
broken PNG than to see an ugly GIF, which is why many users opt for
#1. But doing #2 is simple and doesn't depend on user-agent sniffing.
> Another example is for "zones" in my CMS. I am using the min-width and
> min-height CSS property while in design mode. These CSS attributes are not
> supported by IE6, so when I detect that client, I use alternate means to
> render the design mode.
Same solutions apply. Still no need for sniffing the user-agent.
> A few months ago there was a jquery user having troubles animating
> relatively positioned elements with percentages. {left:"-=25%"} and
> {left:"+=25%"}, etc. It wasn't working the same in all browsers. The
> FUNCTION worked, but the rendering on the screen was broken. Would it not
> be correct to detect the browser and provide an alternate animation to
> ensure the correct rendering?
I don't know of the exact situation, but I would suspect that the real
issue may be fixable, and probably would not need browser sniffing to
figure it out. Especially if something is measurable, you can usually
do a test for it. The guys over at comp.lang.javascript are especially
good at detecting and correcting for quirky behavior in browsers
without the need for sniffing at all.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Improvements to .each()
On Apr 4, 10:44 am, DBJDBJ wrote: > Plugins use $.each() with third argument, to pass "things". > For example: jquery.treeview.async.js Then the comment "args is for internal usage only" isn't quite true? :) Is that method signature in the public API? If not, then using it is probably a bad idea to begin with, as internals often change. Any callers using args could easily be updated to avoid its usage, but whether that's worth it is up to John, I guess. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery doesn't support dimensions-related methods when the body is positioned
On Apr 9, 6:36 am, Fernando Ferreira wrote: > In the jquery-ui-dev thread, I was informed that this is > a deliberated shortcoming, and that "jQuery doesn't support > dimensions-related methods when the body is positioned". Is that so? Just write your own function that uses jquery's return value and adds in your calculations for your offset body. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery doesn't support dimensions-related methods when the body is positioned
On Apr 9, 1:42 pm, Brandon Aaron wrote: > Unfortunately it just isn't as simple as that. A positioned body element > directly affects how the browser calculates the offsetTop/Left properties of > child elements. In what cases? Just curious. I suppose it depends on the browser and the exact layout/objects in question, but I've used this solution several times and it's been sufficient for me. It may be enough for the OP. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Test for equality (.equals)
On Apr 17, 2:21 am, Rick wrote:
> It would be nice to have a function to test for JQuery equality.
As previous discussed here:
http://groups.google.com/group/jquery-en/browse_thread/thread/002d7543186ddaa6
This is a bit cleaner and uses !== which is better than !=
$.fn.equals = function(compareTo) {
if (!compareTo || !compareTo.length || this.length!
=compareTo.length) {
return false;
}
for (var i=0; ihttp://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Blank jQuery page leaks memory in IE?
On Apr 20, 2:29 am, Danny Tuppeny wrote: > Unfortunately none of your suggestions help - the leaks are within the > jQuery source (mostly elements used temporarily and removed with > removeChild). > The problem is finding a way of removing the elements without leaking > in IE. This thread came up in a longer thread on comp.lang.javascript recently. This issue of memory leaks is addressed: Thread: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/9ba20706f3b3fc73/aa56d57c625b404c#aa56d57c625b404c Msg: http://groups.google.com/group/comp.lang.javascript/msg/aa56d57c625b404c Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Exception Thrown When Getting CSS Value
On May 6, 8:28 pm, Brandon Aaron wrote:
> Out of curiosity... what are you expecting back from the call to padding
> when it is different for top/bottom vs left/right?
I think an equally valid question is... what does jQuery intend to do
in such situations? Clearly, crashing is not the best option.
Anything that causes the code to completely crash should be avoided by
either checking for valid input (if some inputs are considered
invalid) or by deciding how to handle cases that don't have obvious
answers (like this case). It's not enough, IMO, to ignore the tough
questions of how jQuery should behave and point to an alternative. :)
In the example case:
#foo { padding: 5px 10px; }
you may want to consider returning [5,10,5,10] for example.
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: #3981 IE 6 & 7 reports incorrect CSS opacity values in jQuery 1.3.1
On May 14, 9:55 am, Brandon Aaron wrote:
> Fixed in r6439 (http://dev.jquery.com/changeset/6349).
This seems simpler:
var ret="";
if ( !jQuery.support.opacity && name=="opacity" && elem.currentStyle )
{
if ((elem.currentStyle.filter||'').match(/opacity=(\d+)/)) {
ret = (parseFloat(RegExp.$1)/100)+'';
}
}
since currentStyle will reflect the value being set inline or via a
css rule. Also, it's necessary to verify that currentStyle exists,
since it can't be assumed just because the jQuery.support.opacity
check failed (inferring its existence is just as bad as browser
detection).
(btw, I tested the above code on a sample case, but not against the
test suite)
Matt Kruse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
On May 19, 5:32 am, DBJDBJ wrote: > This is an discussion on library develeopment philosophy. > There are only two sides to this coin: fast and dangerous and safe and > slow. I think this is another use for a jQuery "development" build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the "production" version of jQuery and avoid the penalty his that comes with all the debug stuff. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
On May 19, 7:51 am, David Zhou wrote: > I wonder if it's feasible to monkeypatch debugging wrappers around > jQuery core methods. You don't even need it to throw errors -- a > simple console.log warning would suffice. Definitely feasible. See something I posted here a while ago: http://groups.google.com/group/jquery-dev/browse_thread/thread/5360f7b3d67a2ddc The problem is that jQuery changes fairly frequently (unfortunately) and the debug plugin would need to constantly be changed to stay up-to- date since it would be so closely tied to the jQuery code. It would be better to put the debugging into the source itself, then use a builder to create a debug version and a release version. In the absence of that, though, it would be fantastic to have a group of people working on a debug plugin. Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.each and JS 1.6's forEach
On May 19, 9:19 am, diogobaeder wrote: > Brainstorming: what about a $.each2 method, to avoid messing with the > original signature (name + parameters), but using > Array.prototype.forEach? Why not just call Array.prototype.forEach in your code if it exists? Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: new project
On May 19, 1:26 pm, "jquerypla...@gmail.com" wrote: > i started a new project called jplanet. it's a content aggregator > about jquery. > see more inhttp://jplanet.tumblr.com/ What are your sources? The list I see is a little confusing and I'm not sure where it's all coming from. I also took a stab at "aggregating" jQuery info here: http://www.javascripttoolbox.com/gadget/jquery/ I've been using it in my iGoogle page for a few weeks and it's been great for me. I plan to clean it up a bit more and possibly add more content sources. I've also been messing with a tool to monitor Twitter for searches, such as "jquery" or "javascript" and aggregate posted url's, show relationships between users posting on the topic, find the most "important" users for the topic, etc. I may release that at some point in the future. It's kind of a cool way to see what's going on in the "jQuery Cloud". Matt Kruse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
