New jQuery announced!

D

David Mark

The two lines above the quoted part are:

  // Safari mis-reports the default selected property of a hidden option
  // Accessing the parent's selectedIndex property fixes it

This looks like another confused "bug report" that has been translated
to "logic". It is clear that the "default selected property" is not
what this function is after (defaultSelected corresponds to the
SELECTED _attribute_).

We know they intend for this thing to read properties (mostly), so
talk of defaults is evidence of them losing their way. The mention of
a "hidden option" confirms the confusion as there is no way a user
could select something they can't see.
It would appear that this was intended as a bug workaround, and that
reading the selectedIndex property is all that's required. Still, it's a
strange thing to do, and could very well be optimized away by a minifier
tool or by the JS engine itself.

Definitely not something to rely on.
 
D

David Mark

I didn't look at the source closely enough. I thought they got rid of
accessing properties of elements and went purely to get/setAttribute.

Quite the contrary, their hybrid is mostly property-centric, with a
few detours into attributes. Take the tabIndex property. Some "smart
egg" observed that DIV's have 0 for a default in some browsers and -1
in others and decided to write a long blog ranting about it rather
than research what those values mean (typical). So Resig (or
whomever) saw the article, copied the code and pasted in a cite. The
end result is that a significant detail is lost due to a silly
misunderstanding. DIV's missing that attribute all return 0 (number),
while others return a string (e.g. "1"). It's wrong but in their mind
it is "consistent". :)
I was incorrect. Disappointing.
Yes.


Indeed, which has been David's criticism for a long time. It looks
like Resig still doesn't get it.

He's not alone. ;)
$(':checkbox[name=foo]').run("this.checked==true");
run() is obviously a little eval wrapper that I plugged into jQuery.
That sounds dangerous.

Not if you know what you are doing. I use it for very simple things,
to avoid lots of anonymous functions.

Lots of anonymous functions is often a sign of trouble (i.e. same
functions are created over and over).

var myCheckerFunction = function() {
this.checked = true; // Assume above == is a typo
};

Now you know where to find it. :)
Documented well

Read the docs for the basic functions (e.g. attr, removeAttr). If
they couldn't understand or explain what those do, how can you trust
the rest of it?
Lots of examples

Virtually every jQuery example out there uses attr, including checking
checkboxes. They might as well not exist as that function has no
defined behavior.
Printed material available for developers to read from

Print whatever you want.
An active support community

Um. A support community of two managed to get a basic attribute
wrapper working consistently in virtually every browser overnight.
jQuery's community doesn't understand the basic concepts so they just
tell people they are using the functions wrong (for three years).
Once in a blue moon, somebody will go in and introduce a new wrinkle
(e.g. tabIndex handling), breaking compatibility, further ballooning
the code, etc. How is that seem helpful (unless you don't know any
better).
Active development and bug fixing

See above. Active development doesn't mean twiddling with the same
code for years just to tread water in the very latest browsers in
their default configurations. Nor does it mean piling new crap on to
existing code that has never worked properly in the first place.
That's called wasting time.
Supported by various editors and environments
etc

Intellisense? For one, who cares. For two, anything can hook into
that.
If you're just a stand-alone developer choosing the best tool, jQuery
may not be the best pick. If you're trying to organize a team of 10-20
developers, some onshore some offshore, all of differing experience
levels, who all need to touch the js of the webapp, then having a tool
like jQuery is very important.

You mean if you are trying to fail?
In my experience, I have found that
without such a library the code quality is consistently lower and the
number of problems is way higher.

Sounds like you need new programmers. What could be lower than
jQuery's code?
jQuery sure has its problems, and
it's not a perfect solution, but it's way better than the other
alternatives I've found. When I find a better option, I'll switch.
Whatever.


That would be great, but I have no desire to write it. I know what
problems I have with jQuery, and I code around them. If I were being
paid for it, I would certainly write such an article :)

There's the rub.
 
M

Matt Kruse

Sounds like you need new programmers.  What could be lower than
jQuery's code?

You must live in a bubble.

I regularly see code that is much, MUCH worse. Less predictable. Less
robust. Less stable.

Telling a team that is writing bad code to "just use jQuery" can
instantly improve performance, reduce bugs, and improve cross-browser
support. Is it perfect? No. But it's better than the status quo. And
it's regularly updated, documented, supported, etc. It takes very
little effort to make a big improvement in code quality. That's why
jQuery is valuable.

Now, if you never have to deal with such a situation, then you're in
luck. No wonder you can't see the value in jQuery.

Think of it this way - When js code quality is at a 1 or 2 on a scale
of 1-10 (10 being best), then introducing jQuery and raising it to a 4
or 5 with virtually no pain is an obvious win. Versus trying to raise
it to an 8 or 9 with considerable coding, time, cost, coaching,
documentation, testing, etc. In a perfect world we could all set our
sights high to ideal coding practices, but in the real world many
people deal with, lowered expectations helps maintain sanity.
Especially when js code quality is less of a concern compared to
other, bigger problems.

Matt Kruse
 
M

Michael Haufe (\TNO\)

Telling a team that is writing bad code to "just use jQuery" can
instantly improve performance, reduce bugs, and improve cross-browser
support. Is it perfect? No. But it's better than the status quo. And
it's regularly updated, documented, supported, etc. It takes very
little effort to make a big improvement in code quality. That's why
jQuery is valuable.

Ever try a code review instead?
 
D

David Mark

You must live in a bubble.

No, I deal with JS and JS developers every day.
I regularly see code that is much, MUCH worse. Less predictable. Less
robust. Less stable.

Take just he basic attr and removeAttr methods. They can't even run
the basic gamut of attributes without throwing exceptions. Other
cases fail silently. These quirky behaviors vary across browsers
_and_ jQuery versions. So, what could be worse than that? Random
gibberish? Don't use that either?
Telling a team that is writing bad code to "just use jQuery" can
instantly improve performance, reduce bugs, and improve cross-browser
support.

No, it might create the illusion that they are all suddenly competent.
Is it perfect? No. But it's better than the status quo.

It a team is writing bad code, you teach them how to write good code.
That's primarily what I do for a living. ;)
And
it's regularly updated, documented, supported, etc.

The regular updates are indicative of 60K of JS that has been in
endless Alpha for years. That's certainly detrimental to anyone
foolish enough to plop a snapshot of their efforts on a Website.
Documented? As I mentioned, you can't document what you don't
understand. And we've been over their "support" too. Same principle
applies. Three strikes.
It takes very
little effort to make a big improvement in code quality.

It's like a magic trick! :)
That's why
jQuery is valuable.

No, that's why it is poison.
Now, if you never have to deal with such a situation, then you're in
luck. No wonder you can't see the value in jQuery.

You are jumping to conclusions to say the least.
Think of it this way - When js code quality is at a 1 or 2 on a scale
of 1-10 (10 being best),

Easy. Get new programmers.
then introducing jQuery and raising it to a 4
or 5 with virtually no pain is an obvious win.

Not in my book. Looks like a punt.
Versus trying to raise
it to an 8 or 9 with considerable coding, time, cost, coaching,
documentation, testing, etc.

All bullshit. What considerable coding? What project are we talking
about? These generalizations are just not reality.
In a perfect world we could all set our
sights high to ideal coding practices, but in the real world many
people deal with, lowered expectations helps maintain sanity.

No, they help incompetents keep a toe-hold on their precarious
positions. It's not good for business in any way, shape or form. I
_know_ a lot of code monkeys will tell you (and anyone who will
listen) different.
Especially when js code quality is less of a concern compared to
other, bigger problems.

I don't know what that means. The typical Website uses ten times the
script needed. So code quality concerns are magnified ten times.
There is nothing with more power to wreck a site than script
(especially of poor to middling quality), so the obvious best strategy
is to use as little of it as possible. Therefore, your proposed
strategy of starting out with 60K of thoughtless "4 level" code is
counter-productive. If it fools code monkeys into thinking they are
Ninjas, that will lead to further ruin down the road as things break,
libraries are "upgraded" to "fix" them, apps are re-tested (or not)
from scratch, etc. I've seen it a thousand times (and we've discussed
this almost as many).

And exceptions and other land mines are not covered by variations in
"code quality". Code can be of poor quality and still work. Code
that doesn't work isn't really code at all. It's called trash and
there's only one place for it.
 
M

Matt Kruse

No, I deal with JS and JS developers every day.

There's no point in going over this again. You cannot relate to those
who face development situations and business cases different than
yours. There are some really bad projects out there, being completed
by really poor developers, at a quality level that is very low. If you
never see or touch those, good for you. But they still exist.
Take just he basic attr and removeAttr methods.  They can't even run
the basic gamut of attributes without throwing exceptions.  Other
cases fail silently.  These quirky behaviors vary across browsers
_and_ jQuery versions.  So, what could be worse than that?

Oh, things can be much worse.
It a team is writing bad code, you teach them how to write good code.

If only it were that easy.
Easy.  Get new programmers.

Of course! Everyone should just fire the people they have and hire the
best!
Not in my book.  Looks like a punt.

It's progress. It's better than it was. Idealism is not always
realistic. Sometimes "just make it work" is a lofty goal.
I don't know what that means.

When the js is running in a pseudo-xhtml document containing invalid
markup, elements with multiple duplicated id's, 80k of whitespace
bloat, styles and js embedded directly into the tags, css that is not
cross-browser, table-based layouts, and spacer gif's... well, jQuery
messing up an attr() call condition that will never actually be called
seems like a minor concern.

But seriously... this is the same old discussion of "don't you
understand how bad it can get and why something like jQuery is
actually an improvement?!" and there's really no point to it. I'm fine
with just seeing it differently than you.

Matt Kruse
 
G

Garrett Smith

Matt said:
Me: "This code is bad. Fix it."
Looks like a straw code review.

Two documents are in order:
1) Code authoring guidelines
2) Code review guidelines

The FAQ covers (1) in a general sense. Number 2 would be very helpful
for a FAQ note/addendum, to be linked from #postCode.

The organization that is making the sorts of messes you described in
another post could benefit from making such document.

Would you like to work on #2?

E.g.
| A code review should focus on problems. Saying "the code is bad" is
| not a helpful review.
|
| Rebuttals
| The reveiwee may challenge a criticism and...

For example, where the markup is invalid, the reviewee will often say:
"literal ampersand doesn't cause problems". Or "but the browser
detection works."

This is where the guidelines doc comes in handy, so you don't have to go
over again the importance of eliminating all validator errors, or what
sorts of harm is caused by browser detection, using the HTML doctype, etc.

The validator results either with green PASS or with one or more errors
at which point it is clear that the reviewee's code is not completed to
standard.

The benefit is that the w3c validation tools can be used to quickly find
errors that cause problems.

Nobody should have to pore over a long list of validation errors for
'&', et al, to find the validation error(s) that could be related to
whatever it is that the invalid code created. In that scenario when an
HTML error is found to cause a problem, the next task finding when the
"error" creeped in, why it is there, what other code is relying on the
problematic area, who wrote that other code, where is he now, so a
possible fix can be discussed, etc. At this point it is obvious how much
of a waste of time using invalid HTML is.

Working with invalid code like can be very time consuming. Running the
w3c validator is a little extra effort that saves a lot of time.

Problems with the code should be clearly explained so that they can be
understood. The solutions to the types of code obscenities you described
in your other post are usually self-evident. Where they aren't, then
further discussion can help find solutions.
 
S

S.T.

But it has the same old attr method. :(

attr: function( elem, name, value ) {

// don't set attributes on text and comment nodes

... and on and on and on.

For all these massive bugs, future browser incompatibility issues, code
breaking on every library update and inept coding that you claim litters
jQuery -- I don't seem to see any effects of them. Ever. Nor do my
users. Nor other developers I communicate with.

Weird, isn't it?

Guess I'm just really, really lucky.
 
G

Garrett Smith

Stefan said:
The two lines above the quoted part are:

// Safari mis-reports the default selected property of a hidden option
// Accessing the parent's selectedIndex property fixes it

It would appear that this was intended as a bug workaround, and that
reading the selectedIndex property is all that's required. Still, it's a
strange thing to do, and could very well be optimized away by a minifier
tool or by the JS engine itself.
A workaround, but to what problem?

<body onload ="alert(document.getElementById('c').selected)">
<select id="x">
<option id="a">a</option>
<option id="b">b</option>
<option id="c" style="visibility: hidden;" selected>c</option>
<option id="d">d</option>
</select>

In Safari, the 'c' is selected, the alert is - true - and when the
select is expanded, the 'c' option is blacked out.

Perhaps someone can demonstrate what the workaround actually fixes.

Anyway, attr is dealing with non-string value property.
 
D

David Mark

For all these massive bugs

You deny their existence? Go back a few years and start reading...
, future browser incompatibility issues,

Well, of course. They have to constantly fiddle with the code to keep
up with the latest browsers. Where does that leave your site(s)? Do
you think the owners want a subscription development service with you
coming back every six months to swap out 60K of crap that you don't
understand. I don't. ;)
code
breaking on every library update and inept coding that you claim litters

They always introduce incompatibilities with each release. Some they
know about. Some they don't.
jQuery -- I don't seem to see any effects of them. Ever.

What can you say to that? Your testing must be for shit. :) It's
very easy to test in a handful of the latest browsers and dismiss
everything that came before as "out of date" and "unsupported".
Nor do my
users.

How do you know? Users aren't QA testers. You can't assume that a
lack of bug reports from users means... anything.
Nor other developers I communicate with.

Other jQuery developers? You are in a cult. How can you figure your
fellow cult members' silence on issues they don't understand at all
trumps the broken logic detailed here? Do you not understand that the
broken logic indicates broken thinking? These are the "experts" you
have entrusted with browsers scripting and they are clearly lost.
Weird, isn't it?

Not really.
Guess I'm just really, really lucky.

Or really, really loopy.
 
R

RobG

For all these massive bugs, future browser incompatibility issues, code
breaking on every library update and inept coding that you claim litters
jQuery -- I don't seem to see any effects of them. Ever. Nor do my
users. Nor other developers I communicate with.

Weird, isn't it?

Guess I'm just really, really lucky.

Or don't read the jQuery GG forum. A quick scan over the last two days
of posts turned up the following:

Random problems with load()?????
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/cc155eede7fcc562?hl=en
Problem with Jquery Superfish in IE7
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/422d435663db6f65?hl=en#
IE 7-8 bug on menu loading when mouse is over the menu
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/87d54847af752079?hl=en#
load() function and IE8
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/a12e5d47c17e93a3?hl=en#
 
D

David Mark

There's no point in going over this again. You cannot relate to those
who face development situations and business cases different than
yours. There are some really bad projects out there, being completed
by really poor developers, at a quality level that is very low. If you
never see or touch those, good for you. But they still exist.


Oh, things can be much worse.

Sure, you could hire a trained chimp to bang away at the keyboard at
random.
If only it were that easy.

It really is. They typically don't have to write a CSS selector query
engine. You teach them how to do basic DOM scripting and soon they
are laughing at jQuery's foibles.
Of course! Everyone should just fire the people they have and hire the
best!

Not everyone can afford the best, nor do most projects need them.
There's a big difference between the best and incompetents.
It's progress. It's better than it was.

No, it's just trading one set of problems for another. A 4 or 5 is a
failing grade BTW. Why program for failure?
Idealism is not always
realistic. Sometimes "just make it work" is a lofty goal.

If something doesn't work, what good is it?
When the js is running in a pseudo-xhtml document containing invalid
markup, elements with multiple duplicated id's, 80k of whitespace
bloat, styles and js embedded directly into the tags, css that is not
cross-browser, table-based layouts, and spacer gif's...

And you don't care to fire the bums that slapped that together?
That's your problem.
well, jQuery
messing up an attr() call condition that will never actually be called
seems like a minor concern.

You don't have any idea what arguments work with attr (or for which
version(s) of jQuery). And the messed up attr/removeAttr "pair" (just
two of many botched functions in jQuery) is indicative that your
chosen saviors are false prophets. It's been years and they are still
using the same old nonsense code. That's the main point.
But seriously... this is the same old discussion of "don't you
understand how bad it can get and why something like jQuery is
actually an improvement?!" and there's really no point to it. I'm fine
with just seeing it differently than you.

That's not the typical spin anyway. Persuse sites like Ajaxian and
you will see that many developers think jQuery is the greatest thing
to ever happen to the Web. :)
 
D

David Mark

A workaround, but to what problem?

Something in their head likely.
<body onload ="alert(document.getElementById('c').selected)">
<select id="x">
<option id="a">a</option>
<option id="b">b</option>
<option id="c" style="visibility: hidden;" selected>c</option>
<option id="d">d</option>
</select>

In Safari, the 'c' is selected, the alert is - true - and when the
select is expanded, the 'c' option is blacked out.

Perhaps someone can demonstrate what the workaround actually fixes.

Unlikely. But they won't take it out because somebody has fuzzy
memories of a "problem" that they can't really explain.
Anyway, attr is dealing with non-string value property.

Certainly, except when it branches off into attributes (e.g. "special
properties" href and src). It makes absolutely no sense and provides
a far less consistent interface than the "buggy" DOM implementations.
The indoctrinated neophytes don't see it because they don't know any
better. One of their luminaries remarked recently that it "uses
properties and always has" and couldn't understand why people are
claiming it is broken. :)
 
D

David Mark

There's no point in going over this again. You cannot relate to those
who face development situations and business cases different than
yours.

Nice try (seriously) in your recent attempt to educate John Resig
about his own attr/removeAttr methods.

He's obviously confused about what those test results mean, so let me
explain.

The first two strictly deal with attributes. You made one mistake in
your explanation to Resig in that manipulating most DOM properties by
script will reflect back to the attributes. It's the DOM defaults and
user input that must be filtered to gain a clear view of the document
structure.

The latter two do the exact same thing, but resolve the "raw"
attributes to their DOM interpretations, still returning null for
missing attributes (except for booleans, of course). For example,
URI's are resolved, booleans return true/false, numeric attributes
return numbers, etc.

All four are attempts to produce a consistent interface for reading
the DOM, filtering out DOM defaults. I recently modified the two
wrappers slightly to filter out user input as well. I'll post as soon
as I finish updating the tests (there are about 100 now). That's the
view you need for a CSS selector query engine, WYSIWYG editor or like
application. As you mentioned, it is _not_ a view that the typical
Web app needs to see.

The biggest unanswered question, which Resig seems unwilling to
address, is what the hell is his attr method supposed to do? Who
knows? Is it a view of the underlying document structure, does it
include DOM defaults, user input, etc.? It clearly does nothing
predictable or consistent in any browser. As an aside, notice that he
only ever tests your suggestions in FF3.5. ;)

He did mention that it is _not_ "designed" to read DOM properties. So
now I am really confused. It's clearly not designed to read
attributes either (except for "special" properties). Are file paths
to be resolved or not? Are DOM defaults to be ignored, embraced or
stepped on? His method does a little of each. What about user
input? I get the idea that he doesn't comprehend the various layers
at all.

And yeah, spot on about the new jQuery method entanglement, which
makes this thing even worse (hard to believe). I forgot they had
methods called "height", "width", etc. So his "solution" to "onclick"
throwing an exception (in FF!) is to use "click" instead as it will
then call the jQuery click method, which does... God knows what. And
somehow he thinks this "improves" his already muddled API. (!)

The guy is clearly not qualified to write even the simplest DOM
scripts. He doesn't understand the basic concepts. The attr and
removeAttr methods and the years of confusion and twiddling that have
followed, leading up to this latest pathetic denial, are all the proof
you should need. But the typical code monkey will load up their app
(which may well have straddled the land mines in the specific version
of jQuery used) in IE8 and FF3.5, note that it appears to work (just
don't disable ActiveX in IE!) and chafe that such "petty" criticism is
unrealistic for such an obviously magical script (turned them into a
programmer!)

I'll post similar tests with the jQuery methods when I get a chance.
I'll have to guess at what they are trying to do, but there are only
so many possibilities. I know they are incapable of providing a
consistent and symmetrical interface for anything though. Initial
testing shows that removeAttr throws exceptions and fails silently for
several attribute names. If the caller switches gears and passes
property names instead, a few of the failures go away. but new ones
take their place.

As for licensing, which I see Resig is interested in, tell him he can
license the whole test suite, wrappers, etc., but it won't be cheap.
Hell, tell the "foundation" to pick up the bill. :) And if he copies
one word or the tiniest aspect of the design, brutal legal action will
follow. I'm tired of seeing my ideas show up in his "cutting edge"
script years later.
 
D

David Mark

Nice try (seriously) in your recent attempt to educate John Resig
about his own attr/removeAttr methods.

It's even worse than I thought. I always wondered what the logic in
the "crown jewel" (and only reason for existence) CSS selector query
engine. I remembered that it didn't actually call attr, but it
actually might have been better off doing so.

CLASS: function(elem, match){
return (" " + (elem.className || elem.getAttribute("class")) + "
").indexOf( match ) > -1;


Focus on this bit:-

(elem.className || elem.getAttribute("class"))

If elem.className === '' the first is falsy, so the second is
consulted. There are two possible results for the second: '' and
null. Results will vary according to browser and mode.

- IE6/7 and 8 in compatibility mode always return ''
- IE8 in standards mode will return null if the attribute is missing
or '' if it is empty.
- Previous applies to other quasi-standards based browsers.

So, an element like this:-

<div></div>

....will produce a test like this:-

return (" null ").indexOf( match ) > -1;

....in some browsers and modes.

Of course, if Resig and co. understood how attributes and properties
work, they would know that this:-

(elem.className || elem.getAttribute("class"))

....is much better written as:-

elem.className

It's simpler, more concise, actually works cross-browser, etc. Of
course, the second part may be a perverse attempt to support XML, but
that's as maybe. They really need to figure out HTML first.

},
ATTR: function(elem, match){
var name = match[1],
result = Expr.attrHandle[ name ] ?
Expr.attrHandle[ name ]( elem ) :
elem[ name ] != null ?
elem[ name ] :
elem.getAttribute( name ),
value = result + "",

There it is. The selector engine is broken too and incompatible
with... everything. XPath and QSA are popular alternate approaches
(IIRC, jQuery and/or "Sizzle" uses the latter). Neither of those will
work anything like this.

elem[ name ] != null

That's everything but null or undefined. So property values that are
neither end up converting this to a string:-

elem[ name ]

....which could end up as "true" or "function anonymous() { ... }" or
"[object CSSStyleDeclaration]" or whatever.

On the contrary, properties that are non-existent or have null values
end up converting:-

elem.getAttribute( name )

....which, as (hopefully) everyone knows by now is a crap shoot. Here
the converted "result" will either be "null" or "undefined" or the
value of a custom attribute (which may well be "null" or
"undefined"). I'm sure that won't cause any confusion. ;)

In conclusion, results for attribute-related queries would make decent
seeds for random number generators. I assume the answer can't be
"don't use those" as they've gone to "great" pains to "support" them
over the years. Are they all blind or mad? And how can they demand
examples in the face of such obviously incorrect logic?

Here's more madness:-

enabled: function(elem){
return elem.disabled === false && elem.type !== "hidden";
},

Sure, hidden inputs are always disabled. We needed that smoothed
over. :)

disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},

Wrong. That includes user input. But they'll never be able to change
it at this point.

selected: function(elem){
// Accessing this property makes selected-by-default
// options in Safari work properly
elem.parentNode.selectedIndex;
return elem.selected === true;
},

LOL. There's _that_ again. Look at what it says: "selected-by-
default". Sure sounds like they are after the defaultSelected
property, which reflects the presence or absence of the SELECTED
attribute. Or maybe they just have no clue what they want at all
(that's my guess at this point).

And I wonder how well that incantation will work if the option is in
an OPTGROUP. Poorly I assume, but then it likely doesn't do anything
anyway.

So how could you possibly trust any script from these people, let
alone something as convoluted and confused as jQuery? It's not even a
stationery target as they keep "optimizing" (changing the logic) and
introducing bizarre "overloading" like using attribute names to call
jQuery methods.

I can understand how code monkeys can look at sites built with jQuery
(in a few browsers) and protest that it "just works" and any perceived
gaps in its internal logic must be imagined. But any programmer knows
such an unpredictable and illogical interface is poison (particularly
for browser scripting). Working on an app with this thing, I would
cringe changing even one attr call or query, let alone "upgrading" the
library.
 
D

David Mark

Or don't read the jQuery GG forum. A quick scan over the last two days
of posts turned up the following:

Random problems with load()?????
<URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/cc155ee...



Problem with Jquery Superfish in IE7
<URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/422d435...



IE 7-8 bug on menu loading when mouse is over the menu
<URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/87d5484...



load() function and IE8
<URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/a12e5d4...

On a positive note, posts to that list are dwindling. I guess people
are tired of wrong (or no) answers. :)

Quoting from that last one:-

"I fat fingered the last one so...

I have this piece of code

$("#AP_PONum").live("change", function(){
ap_po = $("option:selected",this).val();
$("#content-box").load("webapps/finished_jewelry/PurReq/display/
dsp_addPurchaseRequest.cfm?poNum="+ap_po);

});

which works like a champ in firefox.

it's called from a drop down grabs the ColdFusion template and load it
in a div called content-box.

This does nothing in IE8, no error, no load, no love.. nothing

any ideas on how to work around this?"

They better test in more than IE8 and FF. :)

Look at the three (!) queries in this one line. Two can be replaced
with document.getElementById. The other one is sure to be a disaster
as it uses ":selected".

http://groups.google.com/group/comp.lang.javascript/msg/05416b9fc93b2092

And what is that other one doing? Looking for the selected option of
a SELECT? jQuery makes it so easy... to shoot yourself in the foot,
even when the target is right in front of your face. ;)

Assuming there are no options with empty or missing values:-

var el = document.getElementById('AP_PONum');

el.onchange = function() {
ap_po = this.options[this.selectedIndex].value;
...
};

In modern browsers, you can even get away with:-

el.onchange = function() {
ap_po = this.value;
...
};

Something like that is much faster, easier to read and understand, not
prone to bizarre inconsistencies, etc. For the macro-challenged, the
keystroke count is reduced as well.

The jQuery list's answer to this is (typically) no answer at all
(literally). ;)
 
G

Garrett Smith

Probably.

Bugs do not always manifest in the scenario. If they did, there would be
value in unit testing.

[...]
Yes, many developers are lucky.
Like all things in life, there is more than meets the eye.
 
D

David Mark

Thanks, interesting!

A compatible jQuery replacement may be something interesting
too. Ever thought of that?

The stock OO interfaces are just a thin (and optional) layer over the
API (as they should be). You could put whatever "face" you want on
the API, including jQuery's grotesque profile. Mine is somewhat
jQuery like, but instead of $ to create a single type of object, it
has:-

E - element
Q - one or more elements (query)
D - document
W - window

Also, inheriting from E with a few augmentations:-

F - form
I - image

I didn't put a lot of thought into them and I never use them, so they
haven't been tested thoroughly. But the typical method is 2-3 lines
long. As you might expect, reading those short methods gives quite an
insight into the API and how to create an alternative interface. And,
of course, they are all "chainable".

Q('.myclass').fadeIn().onclick(function() {
this.fadeOut();
}, this);

Something like that. Perhaps somebody should explore and document
these features, but it won't be me. I'm working on something else
(and was never particularly interested in the OO interfaces).
Or maybe a jQuery add-on that fixes jQuery's worst errors,
perhaps by replacing the worst functions with new ones?

What I typically do for those who are married to the jQuery interface
is to figure out what parts of jQuery they actually use and provide
reliable alternatives wrapped in a jQuery-like object. That
eliminates the biggest maintenance headache (upgrading jQuery to "keep
up" with the latest browsers) and, of course, the parts under the hood
actually work. ;)

There's no way to write an add-on for jQuery that fixes it. The
design was terribly flawed from day one and now they are stuck with
it. Sure, there are lots of things that could be improved internally,
but who has time to fight with the jQuery people? When it comes to
logic and interface design, they are clearly insane (and you just
can't argue with crazy people).
 
D

David Mark

The stock OO interfaces are just a thin (and optional) layer over the
API (as they should be).  You could put whatever "face" you want on
the API, including jQuery's grotesque profile.  Mine is somewhat
jQuery like, but instead of $ to create a single type of object, it
has:-

E - element
Q - one or more elements (query)
D - document
W - window

Also, inheriting from E with a few augmentations:-

F - form
I - image

I didn't put a lot of thought into them and I never use them, so they
haven't been tested thoroughly.  But the typical method is 2-3 lines
long.  As you might expect, reading those short methods gives quite an
insight into the API and how to create an alternative interface.  And,
of course, they are all "chainable".

Q('.myclass').fadeIn().onclick(function() {
    this.fadeOut();

}, this);

Oops, that second argument is obviously wrong. Looking at the
prototype, I had the method name wrong too. And I forgot to wrap the
- this - identifier.

var q = Q('.myclass');

q.fadeIn().on('click', function() {
this.fadeOut();
}, q);

That would fade all of them out on clicking any. The second argument
is the context (the query object in this case).

To fade out one at a time:-

Q('.myclass').fadeIn().on('click', function() {
E(this).fadeOut();
});

Want to remove the click listener for each in turn?

var fn = function() {
E(this).fadeOut().off('click', fn);
};

Q('.myclass').fadeIn().on('click', fn);

As for these (poorly named) on/off methods, they do no munging of
events (e.g. mouseenter means mouseenter). Cross-browser "smoothing"
is done through higher-level methods (e.g. onhover, onmousewheel,
oncontextclick). That's the way it should be for clarity (i.e.
knowing what to expect from the call) and flexibility (i.e. not
restricting the events that can be attached). Such layering is done
throughout. For example, setting the opacity style means just that.
The higher-level setOpacity method provides the cross-browser opacity
solution (which may or may not set that specific style). In contrast,
jQuery smashes everything together so that you have no recourse when
it's meddling fails (other than to "step outside" of jQuery).

For me, I can't see coding like this. But the interface is there (and
works efficiently) for those who can.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,045
Latest member
DRCM

Latest Threads

Top