From: David Mark on
On Dec 11, 5:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Stefan Weiss wrote:
> > On 11/12/09 08:35, Garrett Smith wrote:
> >> Garrett Smith wrote:
> >>> jQuery.attr has specific handling for many odd cases. What does attr
> >>> have to do with:
>
> >>> | if ( name == "selected" && elem.parentNode )
> >>> |    elem.parentNode.selectedIndex;
>
> >> Note that the statement inside the if test is entirely useless, as it is
> >> not assigned to anything.
>
> > 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?

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. :)
From: David Mark on
On Dec 11, 12:08 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Dec 11, 10:47 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > > You must live in a bubble.
> > 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.

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.
From: David Mark on
On Dec 12, 6:11 am, RobG <rg...(a)iinet.net.au> wrote:
> On Dec 12, 7:26 am, "S.T." <a...(a)anon.com> wrote:
>
>
>
> > On 12/7/2009 8:59 AM, David Mark wrote:
>
> > > 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.
>
> 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). ;)
From: Garrett Smith on
Andrew Poulos wrote:
> On 12/12/2009 8:26 AM, S.T. wrote:
>> On 12/7/2009 8:59 AM, David Mark wrote:
>>> 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.

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Hans-Georg Michna on
On Fri, 11 Dec 2009 06:03:46 -0800 (PST), Matt Kruse wrote:

>I know what
>problems I have with jQuery, and I code around them.

Matt,

it would be nice to have a list of these. Care to publish one?

Hans-Georg