New jQuery announced!

[David Mark]

[...]

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();
});

On closer inspection, those *in/out methods need a first argument,
which is an object specifying various options. Minimum needed to make
sense is a duration as the default is 0.

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

At a glance, it appears the other options are ease (easing function--
see API.ease), repeat, revert (reverts altered styles after hide), dir
(reversals and "round trip" transitions), to, from (both percentages)
and fps (frames per second).

The stock reveal effects include "fade", "slide", "drop", "fold",
"zoom", "horizontalblinds" and "verticalblinds" (see API.effects).

And, as with everything in the library, it is trivial to detect
features, allowing for controlled degradation. There are various host
methods and properties that must be present and functional to make
these animation methods work. Those are taken care of behind the
scenes. The calling app only needs to detect the methods on the API
objects. For example, if an enhancement requires fadeIn/out and will
use the OO interface, the gateway would look like this:-

if (E.prototype.fadeIn) { // undefined if not supported
// Cool enhancement goes here
}

It's interesting that libraries like jQuery preach progressive
enhancement, yet there is no way to determine if their methods are
viable in the given environment. Seems a huge contradiction to me.
If you have no way of knowing what will fail, you have no way of
knowing what to present to the user. Present something that fails
unexpectedly (i.e. throws an exception) and the aspiring enhancement
ends up an annoyance at best and a hindrance at worst.

 

[Matt Kruse]

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

I've read a few replies on the thread here and there over the weekend
but haven't had a chance to reply until now.

I've had a thought on the attr() method which might frame it
differently. Basically, I've realized that it's not a wrapper for get/
setAttribute, which is what you always criticize it for. It is a
method that attempts to get an attribute value that makes sense to the
user. And by attribute, I mean "a characteristic of an entity" which
is one good definition I found. It does _not_ necessarily mean the
same as getAttribute().

So if you frame it that way, which makes sense, then the requirements
change. It does not have to pass your test suite to be correct. When a
user wants the "height" attribute of an element, they don't really
want the height="x" attribute in the source. They want the height of
the element. So calling the jQuery height() method makes sense.

And if the element has a property that matches the attribute name the
user is looking for, it makes sense to return it rather than the
underlying getAttribute() value. A call to .attr('checked') should
return a boolean, because that just makes sense! In that sense, it's
similar to search engines or things like Wolfram|Alpha that take user
input and try to figure out what it is that the user really wants, and
give it to them. Attr() seems to try to do that. Unfortunately, for
computer programming, logical and predictable results are what matter
most, so such a "magical" function is surely asking for trouble.
Nevertheless, I think many developers find the convenience and
"magical accuracy" of attr() to be very handy.

Now, is it documented correctly? Surely not. Is it robust? Surely not.
Does it have some issues? Of course. But in the end, I bet that
jQuery's attr() method returns what the average developer wants more
consistently than your attribute wrappers.

So your issues with it seem to be:
1) It doesn't do what you think it should do
2) It doesn't behave the same way your methods do
3) The documentation doesn't describe in detail what its purpose is or
how it works

So perhaps the real problem is NOT that attr() doesn't do what it
should, but that you don't like what it is or how it works.

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.

It amazes me to see the extent that you go to prove (again) that
you're an ass.

Matt Kruse

 

[Matt Kruse]

In conclusion, results for attribute-related queries would make decent
seeds for random number generators.

Can you come up with a real test-case that fails?

Matt Kruse

 

[Garrett Smith]

[sni[\

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);

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

It is a pity that this style of programming has become so widely adopted.

The design of making a query and performing an action is inherently
inefficient.

A simple event library can go much further, with much fewer bugs, much
less code, much faster performance.

Long menthod chains and complex expressions are harder to debug, then
again, one-letter functions like 'E' aren't very descriptive, either.

Aside: I do mean to get back to that getWindowSize post, I am sorry I
have many things going on right now. I have not forgotten that one.

 

[David Mark]

I've read a few replies on the thread here and there over the weekend
but haven't had a chance to reply until now.

I've had a thought on the attr() method which might frame it
differently. Basically, I've realized that it's not a wrapper for get/
setAttribute, which is what you always criticize it for. It is a
method that attempts to get an attribute value that makes sense to the
user. And by attribute, I mean "a characteristic of an entity" which
is one good definition I found. It does _not_ necessarily mean the
same as getAttribute().

You are very confused. I never claimed it was a get/setAttribute
wrappers at all. Quite the opposite. The "attr" name has always been
a source of irony. I explained this (again) in the post you replied
to. What I have always criticized is that it _uses_ getAttribute,
which is broken in various IE versions and modes.

The thing you describe is the - prop - wrapper from the test page,
which is closer to what jQuery's attr does (but as noted, not
exactly).

So if you frame it that way, which makes sense, then the requirements
change.

Nobody knows exactly what his requirements are. Including him, of
course.

It does not have to pass your test suite to be correct.

That's exactly what I said. It's not necessarily what he is after.
The trouble is that nobody (including him) knows what he is after.

When a
user wants the "height" attribute of an element, they don't really
want the height="x" attribute in the source. They want the height of
the element. So calling the jQuery height() method makes sense.

Not even close. Read this:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/4c5043cffb1826fa#

And if the element has a property that matches the attribute name the
user is looking for, it makes sense to return it rather than the
underlying getAttribute() value.

If that is what the design calls for, which is what the - prop -
wrapper does. I covered _both_ bases with _two_ wrappers. The jQuery
thing tries to cram them both into one, which is impossible. Get it?

A call to .attr('checked') should
return a boolean, because that just makes sense!

Except for the unfortunate name, that does make sense. Who needs a
string for that?

In that sense, it's
similar to search engines or things like Wolfram|Alpha that take user
input and try to figure out what it is that the user really wants, and
give it to them.

Similar to what?! It's a "glorified" way to read DOM properties.
Quoting from Resig:-

"It's only a backwards step if you're attempting to use .attr() as a
glorified way to set DOM 0 events - which is not really something that
jQuery is designed for nor does it encourage"

Or is it?

http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033

Attr() seems to try to do that.

Seems to try.

Unfortunately, for
computer programming, logical and predictable results are what matter
most, so such a "magical" function is surely asking for trouble.
Nevertheless, I think many developers find the convenience and
"magical accuracy" of attr() to be very handy.

Then they'd find one that doesn't produce random results even
handier. That's been the point all along.

Now, is it documented correctly? Surely not. Is it robust? Surely not.

It's B-R-O-K-E-N. Always has been. You've been talked into something
else, but whatever.

Does it have some issues? Of course. But in the end, I bet that
jQuery's attr() method returns what the average developer wants more
consistently than your attribute wrappers.

My "attribute wrappers" were never marketed as magic tools, nor do
they deal only in attributes. The idea is that they prove how futile
it is for most scripts to try to read/write/remove attributes. And,
of course, jQuery does those things, unnecessarily and inaccurately.

So your issues with it seem to be:
1) It doesn't do what you think it should do

No. That's _never_ what I was saying. As mentioned, nobody knows
what the hell that thing is supposed to do,l

2) It doesn't behave the same way your methods do

No. I specifically told you my tests were not appropriate for testing
jQuery. I laughed when I saw Resig run with them (as if they were
magic tests for _his_ logic).;

3) The documentation doesn't describe in detail what its purpose is or
how it works

Nothing does and how it "works" keeps changing.

So perhaps the real problem is NOT that attr() doesn't do what it
should, but that you don't like what it is or how it works.

You are just making a fool of yourself now. Too bad, it seeemed like
you almost understood at one point. Go back and re-read this whole
thread from the start.

It amazes me to see the extent that you go to prove (again) that
you're an ass.

No, it shows I am not about to let Resig steal my code. I _gave_ him
the fix for broken attributes two years ago. He apparently couldn't
understand it. I thought you did at one point. Are you drunk or
what?

And he's an idiot too. He thinks I'm talking about the "common sense"
tests. Hell, even if I was, tell him to get his own common sense.

 

[David Mark]

Can you come up with a real test-case that fails?

Now you are parroting Resig? You really don't get it either, do you?

 

[David Mark]

On Dec 13, 11:55 am, Hans-Georg Michna <hans-
(e-mail address removed)> wrote:
 I made an exception a couple of years back (Google "browser

[sni[\

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);
[sni[

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

It is a pity that this style of programming has become so widely adopted.

The design of making a query and performing an action is inherently
inefficient.
Yes.


A simple event library can go much further, with much fewer bugs, much
less code, much faster performance.
Absolutely.


Long menthod chains and complex expressions are harder to debug, then
again, one-letter functions like 'E' aren't very descriptive, either.

Yes. I don't like the constructor names either. At the time, I was
demonstrating an alternative to the less-descriptive "$".

Aside: I do mean to get back to that getWindowSize post, I am sorry I
have many things going on right now. I have not forgotten that one.

NP.

 

[David Mark]

I've read a few replies on the thread here and there over the weekend
but haven't had a chance to reply until now.

I've had a thought on the attr() method which might frame it
differently. Basically, I've realized that it's not a wrapper for get/
setAttribute,

You've realized shit. That was in the next couple of sentences, which
you handily snipped. What a weasel.

Quoting the part snipped with simplified translations:-

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

_He_ thinks those test(s) (one anyway) are appropriate to test _his_
design.

"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."

_You_ don't quite understand these terms either.

"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."

_I_ explained it to you again.

"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."

Note that last sentence.

"The biggest unanswered question, which Resig seems unwilling to
address, is what the hell is his attr method supposed to do?"

So, what is it supposed to do? What about the "companion"
removeAttr? And how can you be wasting time "explaining" this shit to
me?

 

[Matt Kruse]

Now you are parroting Resig? You really don't get it either, do you?

I'm trying to imagine a case where this actually matters. Digging into
code and finding logic flaws that will pop up in real cases is one
thing. Dreaming up edge cases that may in theory fail under obscure
conditions for obscure input is another, and not necessarily useful.

So, an element like this:-
<div></div>
...will produce a test like this:-
return (" null ").indexOf( match ) > -1;
...in some browsers and modes.

So? I guess if you are trying to match elements where class=="null"
this will cause problems? Or did I miss something?

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.

Why would you be writing a query to match the 'onclick' attribute, or
anything that might return a stringified function? Or a
CSSStyleDeclaration?

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.  

"enabled" is a poor word choice. The intent is different than what
many might expect.

disabled: function(elem){
        return elem.disabled === true;},
checked: function(elem){
        return elem.checked === true;
Wrong.  That includes user input.  

Because it's supposed to, of course. If I want to get a reference to
all checkboxes that are currently checked, I of course want to
consider user input.

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.

I am curious as to the origins of this.

So how could you possibly trust any script from these people, let
alone something as convoluted and confused as jQuery?  

You seem very interested in pointing out every little potential
logical flaw in the source code, without any consideration for whether
the flaw will ever be practically applicable. Sure, it would be great
to have 100% perfect code that considers every possible scenario
ideally. But in reality, this isn't always possible (no software is
perfect). Just because you dream up a potential case where the logic
will fail does not invalidate its usefulness in all the realistic
cases where it will work correctly.

It makes no sense to throw out functionality that will work correctly
for almost every case just because you find one case that is difficult
or impossible to handle correctly - especially if no one actually
needs that case in practice!

Your tunnel vision prevents you from seeing the bigger picture, where
this code is useful for many cases that work just fine.

Matt Kruse

 

[David Mark]

Can you come up with a real test-case that fails?

Squawk! Show me an example (as if examples will help you understand
the underlying logic). And what is a "real test-case" anyway?

I took five minutes to put together a demonstration, which touches
upon most of the issues discussed in this thread.

http://www.cinsoft.net/jquerysucks.html

There are three images. The middle one is forced to use the border-
box model (a la IE quirks mode). All I want to do is get the height
and then put it back the same as it was. In DOM terms:-

img.height = img.height;

In "concise" jQuery terms:-

$(img).attr('height', $(img).attr('height'));

I believe that would have worked in all (most?) previous jQuery
versions, where the attr method remained a "glorified way to set
properties" (with a few detours into attributes).

It's pretty easy to visualize, but there is also a log.

FF3.5

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 32
attr height #2 after put back = 0
attr height #3 = 32
attr height #3 after put back = 32

IE8 (standards)

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 32
attr height #2 after put back = 0
attr height #3 = 0
attr height #3 after put back = 0

IE8 (compatibility)

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 72
attr height #2 after put back = 72
attr height #3 = 0
attr height #3 after put back = 0

IE8 (quirks)

attr height #1 = 12
attr height #1 after put back = 0
attr height #2 = 52
attr height #2 after put back = 32
attr height #3 = 0
attr height #3 after put back = 0

Looks like random numbers to me.

I'll skip the middle (user input) tests as they will only confuse you
further. But the last one should be obvious. One of the images is a
map:-

<img id="testimage" src="images/cinsoft.gif" height="32" width="32"
ismap alt="">

I tried to query it in two ways (one right, one wrong).

FF3.5

Image map (right way) : [object HTMLImageElement]
Image map (wrong way) : undefined

IE8 (standards)

Image map (right way) : [object HTMLImageElement]
Image map (wrong way) : undefined

IE8 (compatibility)

Image map (right way) : undefined
Image map (wrong way) : [object]

IE8 (quirks)

Image map (right way) : undefined
Image map (wrong way) : [object]

Yeah, that's just the sort of inconsistency that "programmers" often
need.

Those were the first tests I tried. I'm sure you can come up with
more. If you understand the code, attributes, properties, box models,
etc., the results are fairly trivial to predict. But why bother when
the author is clearly beyond help?

Don't bring up documentation or community again as the documentation
is invariably wrong (hardly surprising) and the community, right up to
the leader, is clueless. Just admit that it was (and is) a terrible
mistake to trust jQuery.

And understand that My Library is 100% box model _agnostic_ and
handles attributes properly (more or less, the new wrappers are
slightly improved). And, as we've seen, it has the toddler interface
you so covet for your team. You've spent two years defending and
fighting with jQuery, without any understanding of what is going on
under the hood. You can't even upgrade from 1.3 as it will break your
apps, so you are stuck with UA sniffing as well. Every time there is
an inkling of understanding, you talk to Resig and he confuses you
again. The code's logic (or lack thereof) remains constant throughout
your endless waffling.

 

[Matt Kruse]

You are very confused.  I never claimed it was a get/setAttribute
wrappers at all.  

I may have misunderstood your constant criticisms to the effect of
"jQuery can't even handle attributes correctly!"

Nobody knows exactly what his requirements are.  Including him, of
course.

I pointed this out in the jQuery-dev thread. Hopefully he takes this
seriously, since it can only help improve the attr() method, or at
least clarify what it is intended to do. I suspect the result will be
new test cases derived from the clarified documentation, and possibly
improved code to handle those cases.

If that is what the design calls for, which is what the - prop -
wrapper does.  I covered _both_ bases with _two_ wrappers.  The jQuery
thing tries to cram them both into one, which is impossible.  Get it?

Clearly, it is possible. It just doesn't behave the way you think it
should.

What if the method were documented as "retrieve the property value
from an element if it exists (with exceptions x, y, z), otherwise fall
back to retrieving the attribute value if possible."? Maybe you think
that functionality is stupid, but oh well.

My "attribute wrappers" were never marketed as magic tools, nor do
they deal only in attributes.  The idea is that they prove how futile
it is for most scripts to try to read/write/remove attributes.  And,
of course, jQuery does those things, unnecessarily and inaccurately.

It would be more accurate to say that for some cases, it is futile. In
many other cases, it's simple and works just fine cross-browser.

No, it shows I am not about to let Resig steal my code.  I _gave_ him
the fix for broken attributes two years ago.  

It's always an ego thing for you. Unfortunate.

He apparently couldn't
understand it.  I thought you did at one point.  Are you drunk or
what?

Likely.

Matt Kruse

 

[David Mark]

I'm trying to imagine a case where this actually matters. Digging into
code and finding logic flaws that will pop up in real cases is one
thing. Dreaming up edge cases that may in theory fail under obscure
conditions for obscure input is another, and not necessarily useful.

You just don't get it. Lets start from the beginning. In what way
are the attribute methods broken in IE < 8 and IE8 compatibility
mode? It's not something you should have to memorize as the
"wonderful" script's authors should have known about it and dealt with
it.

On Dec 12, 2:06 pm, David Mark <[email protected]> wrote:

A two-fer?

So? I guess if you are trying to match elements where class=="null"
this will cause problems? Or did I miss something?

You missed that this is obviously broken logic. If one line is
broken, how do you trust the next (and the thousands that follow that
one)?

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.

Why would you be writing a query to match the 'onclick' attribute, or
anything that might return a stringified function? Or a
CSSStyleDeclaration?

I wouldn't be writing a query to match _any_ attribute with this piece
of crap. I've seen inside the $ black box and the mechanism is
rusting and broken.

"enabled" is a poor word choice. The intent is different than what
many might expect.

What many might expect? What are you talking about?

Because it's supposed to, of course.

And that's defined where? Since when does a document query include
user input? XPath certainly doesn't. Same for QSA I'm sure.
Furthermore, what sort of document query includes DOM defaults?

If I want to get a reference to
all checkboxes that are currently checked, I of course want to
consider user input.

Then you better hope they short-circuited the QSA fork for the related
pseudo-selectors (e.g. selected, checked, etc.) ISTM they did because
they thought they were "buggy". And how does any of this parallel
what an XML query would do?

I am curious as to the origins of this.

I'm not. It is funny that, rather than use their own attr method,
they are re-inventing it elsewhere.

You seem very interested in pointing out every little potential
logical flaw in the source code, without any consideration for whether
the flaw will ever be practically applicable.

Practically applicable? Do code monkeys consider practicality? Who
educates them about what is practical?

And see the test cases. Querying the document for a single image
should not be impractical for a CSS selector query engine. Isn't that
what they set out to write?

Sure, it would be great
to have 100% perfect code that considers every possible scenario
ideally.

These are not "edge cases". They represent a complete
misunderstanding of the DOM (specifically the MSHTML DOM).

But in reality, this isn't always possible (no software is
perfect).

"Nobody is perfect" doesn't fly here. It never takes more than ten
seconds to spot an outrageous gaffe in their code. They've been
working on it for years. Hell, I gave them the one answer that could
have saved all of this MSHTML confusion. Remember?

Just because you dream up a potential case where the logic
will fail does not invalidate its usefulness in all the realistic
cases where it will work correctly.

And who maintains the "realistic" use case list? Do you not
understand that this stuff is handed out to people who haven't the
faintest concept of programming? Of course you do as that's what you
claim to do with it. Do you tell them "just use jQuery", but be
"realistic" about it?

It makes no sense to throw out functionality that will work correctly
for almost every case just because you find one case that is difficult
or impossible to handle correctly - especially if no one actually
needs that case in practice!

Difficult or impossible? Where do you get this stuff? The evidence
is right in front of you this time.

As for no one actually needing whatever case you are talking about,
that's a ludicrous argument as all of the tutorials use the attr
method and none explains what it does. The typical explanation is
that it makes it easier to get "attributes" from elements. I've seen
every use case imaginable, no matter how "unrealistic".

Your tunnel vision prevents you from seeing the bigger picture, where
this code is useful for many cases that work just fine.

Your mind's gone. You are just frustrated and confused. That I
understand, but it is hardly due to my "tunnel vision".

 

[Matt Kruse]

I took five minutes to put together a demonstration, which touches
upon most of the issues discussed in this thread.
http://www.cinsoft.net/jquerysucks.html

The attr('height') argument is obvious. I objected to that in the
jQuery-dev thread also. I think it is an absurd addition to the code.
Your example page illustrates that nicely.

But the last one should be obvious.  One of the images is a
map:-
<img id="testimage" src="images/cinsoft.gif" height="32" width="32"
ismap alt="">
I tried to query it in two ways (one right, one wrong).

Interesting. I'm not sure that anyone would ever actually do this, but
it does illustrate a potential problem.

Don't bring up documentation or community again as the documentation
is invariably wrong (hardly surprising) and the community, right up to
the leader, is clueless.  Just admit that it was (and is) a terrible
mistake to trust jQuery.

It has its limitations, the API choices are unwise, and some of the
code inside is definitely "oh look an obscyre failing test case lets
apply some blogged-about browser-specific hack to fix it rather than
really understanding the root cause and correct logical solution."
I'll admit that, certainly. Always have.

Matt Kruse

 

[David Mark]

I may have misunderstood your constant criticisms to the effect of
"jQuery can't even handle attributes correctly!"

You have. I was referring to the _use_ of get/set/removeAttribute
inside jQuery. I've repeated numerous times that they'd be better off
without those methods, _except_ when it comes to the queries, which
should _not_ take DOM defaults into account. I never looked past attr
before, but it appears the attribute-based queries are similarly
botched.

I pointed this out in the jQuery-dev thread. Hopefully he takes this
seriously, since it can only help improve the attr() method, or at
least clarify what it is intended to do. I suspect the result will be
new test cases derived from the clarified documentation, and possibly
improved code to handle those cases.

Yeah, you were really rolling there (with one minor misconception)
until Resig confused you again. I laughed when I saw Resig trying
to correlate the test results for _my_ two wrappers with the results
for his. I'll put up a jQuery set when I get a chance, but I'll have
to guess at what the thing is supposed to do. Likely will put 1.3 and
1.4 on the same page to compare and contrast. I can tell you that at
least a half dozen attributes will throw exception on calling
removeAttr and at least another dozen more will fail silently. And -
this is the point - it can all be traced to the same misunderstanding,
which has already been explained to them (more than once). They are
never going to figure it out by observing test cases (those just
produce more confused patches).

Clearly, it is possible. It just doesn't behave the way you think it
should.

It doesn't behave the way anyone (sane) thinks it should. BTW, what
do you think this thing returns for XML documents?

What if the method were documented as "retrieve the property value
from an element if it exists (with exceptions x, y, z), otherwise fall
back to retrieving the attribute value if possible."?  Maybe you think
that functionality is stupid, but oh well.

Of course it is stupid and that description is not accurate. Does it
return a string (attribute) or a number (property) for tabindex?
Well, it depends on the browser, mode, jQuery version, etc. It even
changes based on the element type.

It would be more accurate to say that for some cases, it is futile. In
many other cases, it's simple and works just fine cross-browser.

Odd that mine, which were thrown together over a weekend and barely
touched since, have no such problems. And who maintains the matrix of
working features per browser, jQuery version, etc.?

It's always an ego thing for you. Unfortunate.

It has nothing to do with me. Various incarnations of this idiotic
and obviously broken script are all over the Web (largely thanks to
parroting by people like you). That's not going to be good for
anyone. Except me perhaps as I've been recently fielding queries
about jQuery abatement. I figured IE8 would be the point where most
people figured it out it was poison.

Likely.

That's what I figured. Don't waste my time.

 

[David Mark]

The attr('height') argument is obvious. I objected to that in the
jQuery-dev thread also. I think it is an absurd addition to the code.
Your example page illustrates that nicely.

Thank you, but I could have sworn you were swinging back the other way
on that one.

Interesting. I'm not sure that anyone would ever actually do this, but
it does illustrate a potential problem.

Always with the same preface. It's not the only attribute that will
fail. You should be able to recite most of the others. Then there
are the ones that fail in stranger ways (e.g. class, href, etc.). As
for href (and the like), _those_ they try to treat like attributes
(returning unresolved paths). Of course, their attempts don't work
consistently at all. I am sure as I already solved this problem (some
code needs resolved paths, some needs unresolved paths, so they both
need to be available).

It has its limitations, the API choices are unwise, and some of the
code inside is definitely "oh look an obscyre failing test case lets
apply some blogged-about browser-specific hack to fix it rather than
really understanding the root cause and correct logical solution."

That's the story of all of the "major" libraries. They are dumping
grounds for misconceptions, guarded by bitchy neophytes who think they
are browser scripting Gods. I saw how Resig referred to your
questioning of his obviously idiotic design and code as "drama".
That's the mindset and it has no place in programming.

I'll admit that, certainly. Always have.

You change your tune daily. It's tiresome.

 

[David Mark]

[...]

Interesting. I'm not sure that anyone would ever actually do this, but
it does illustrate a potential problem.

Second try at a successful (and very basic) test failed as well. Just
wanted to know which link in the document had the tabindex specified.
Various IE versions and modes think there are two of them (1 != 2).

See, these are trivial to do with XPath or QSA. How many of jQuery's
"supported" browsers lack both? IE6/7 I presume and those are the
browsers least likely to work with jQuery (that's why they never stop
bitching about them and threatening to drop support). Of course, if
they did drop those two (as if they ever had them), what possible
justification would there be for jQuery's crumbling monolith? The
active community?

 

[Matt Kruse]

Second try at a successful (and very basic) test failed as well.  Just
wanted to know which link in the document had the tabindex specified.
Various IE versions and modes think there are two of them (1 != 2).

Hmmm...

Using "My Library" source here:
http://www.cinsoft.net/mylib-build....attribute&dom=on&setattribute=on&action=Build

Sample html:
<table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
table>

Using IE6 and "My Library":
API.getAttribute(document.getElementById('x'),'onlyonce') => null
API.getAttribute(document.getElementById('x'),'cellspacing') => null

Using jQuery:
$('#x').attr('onlyonce') => "yes"
$('#x').attr('cellspacing') => 5

Seems like jQuery gives me the right answers, and "My Library" fails.

Matt Kruse

 

[David Mark]

Hmmm...

Using "My Library" source here:http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattri...

Sample html:
<table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
table>

Using IE6 and "My Library":
API.getAttribute(document.getElementById('x'),'onlyonce') => null

Yeah, I told you the new wrappers were slightly improved. Custom (non-
standard) attribute support is one such improvement.

API.getAttribute(document.getElementById('x'),'cellspacing') => null

A workaround for broken "cell span attributes" in IE (as they are
called by the tester) are another. The new Blackberry browser had a
similar problem. I'll transplant the updated version back into My
Library when I get a chance.

Using jQuery:
$('#x').attr('onlyonce') => "yes"
$('#x').attr('cellspacing') => 5

Seems like jQuery gives me the right answers, and "My Library" fails.

You don't have a clue what the "right" answers are from jQuery as attr
has no defined behavior. All it did was read the cellSpacing property
(which it would do whether an attribute existed or not). And, as you
know, it would have missed had you used cellPadding. I suggest you
revisit your tests here:-

http://www.cinsoft.net/attributes.html

And realize that jQuery fails for _dozens_ of these tests, no matter
how you attempt to define the behavior. No matter how many times I
tell Resig (or whomever) about the MSHTML attribute problem, it never
seems to sink in.

 

[David Mark]

$('#x').attr('cellspacing') => 5

As this was the only real bug you found, I looked (and I'm sure you
did too). As I expected, the older version is missing attribute
aliases:-

This is from the newer version and it is clear I added the two cell-
related attribute names last. As I mentioned a month ago, I need to
put this newer version into My Library, but it is hardly a priority
for me.

var attributeAliases = {'for':'htmlFor', accesskey:'accessKey',
codebase:'codeBase', frameborder:'frameBorder',
framespacing:'frameSpacing', nowrap:'noWrap', maxlength:'maxLength',
'class':'className', readonly:'readOnly', longdesc:'longDesc',
tabindex:'tabIndex', rowspan:'rowSpan', colspan:'colSpan',
ismap:'isMap', usemap:'useMap', cellpadding:'cellPadding',
cellspacing:'cellSpacing'};

That's a silly omission by one person from two years ago. Now, how do
you correlate that with jQuery's failings in this area? I know they
are batting .500 on the cell* attributes as of today. But those
are the _least_ of the mistakes.

 

[David Mark]

Hmmm...

Using "My Library" source here:http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattri...

Sample html:
<table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
table>

Using IE6 and "My Library":
API.getAttribute(document.getElementById('x'),'onlyonce') => null
API.getAttribute(document.getElementById('x'),'cellspacing') => null

Using jQuery:
$('#x').attr('onlyonce') => "yes"
$('#x').attr('cellspacing') => 5

Seems like jQuery gives me the right answers, and "My Library" fails.

I updated the alias list to match the one from the sequel. No massive
rewrite necessary (unlike jQuery). Custom attributes are not
supported by that function (you _can_ use the native attribute methods
for those in all browsers).

I'll bet you don't get that sort of support from the jQuery "team".
Special orders don't upset me.