jQuery still (very) confused about attributes and properties

  • Permalink
  • submit to reddit
  • Email
  • Follow


Here they "grow" again:

http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clarification

"Using 1.7.2 and 1.8pre, whether you call .prop() or attr(), jQuery
will internally always actually use .prop for:

async, autofocus, autoplay, checked, controls, defer, disabled,
hidden, loop,
multiple, open, readonly, required, scoped, selected"

This is what's known as an "active" project. Basically, they fiddle
around with the logic behind the "simple" API forever. You never know
what to expect from one version to the next. This is largely caused by
flailing around trying to make the results match their confused
expectations. I call it a "never finished" project.

Though I didn't see this specific misstep coming, I knew from reading
the recently mentioned "attr vs. prop" discussion (for lack of a
better word) on StackOverflow (for lack of a better site) that they
were confused about how to handle boolean properties/attributes. I
just had no idea *how* confused. Here they've lumped all booleans (or
at least the ones they've heard of) into a single group for special
treatment (apparently starting with version 1.7.2).

The above is a partial list of attributes (left out ismap for one)
that are reflected as boolean properties. Two of them should stand out
as fundamentally different from the rest. The "checked" and "selected"
attributes are reflected by DOM properties with the "default" prefix
(e.g. "defaultChecked"). The reason for this is simple: user actions
may change the "checked" and "selected" properties and the DOM must
keep track of the default values of these attributes (e.g. to reset
forms). This is all spelled out very clearly in the DOM
specifications, which predate jQuery by several years (so much for
moving forward).

So, once again, in trying to dumb down interfaces that they themselves
don't understand, they've just made things more complicated for their
users. If they'd have bothered to *read* this example (as opposed to
just copying it into their repository for testing), they'd have
understood the basic concept of "attr" vs. "prop":

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

To be specific, they've created collisions where the DOM (and my
example) specifically avoided them.

Right:

$(el).prop('checked') == el.checked;
$(el).attr('checked') == el.defaultChecked;

Wrong:

$(el).prop('checked') == el.checked;
$(el).attr('checked') == el.checked;

Yes, the wrong version may indeed get the correct results in some
cases, which further confuses the issue. Obviously, if el.checked ==
el.defaultChecked, it doesn't matter which method is used (even a
broken clock is right twice per day).

The general attitude of jQuery users since the infamous attr/prop
split has been: why do we need two methods? The above comparison
should answer that question. But now, in their infinite wisdom, the
jQuery authors have now bypassed the split, but only for boolean
properties/attributes. This, of course, makes no sense at all.

A good example of when this is important is the case of a script that
needs to determine if the checked state of a checkbox has changed (by
the user of programmatically). In other words, is the control "dirty"?
This comes up all the time, for example, if one of the controls in a
form (or fieldset) has changed, an application may want to warn the
user before they navigate to another location and lose their changes.

That's the "getter" end of it. As for the "setter", this should set
the "checked" property to true:

$(el).prop('checked', true);

....And this should set the "defaultChecked" property to true:

$(el).attr('checked', 'checked');

....And this should set the "defaultChecked" property to false:

$(el).removeAttr('checked');

Unfortunately, that last one has never worked consistently, even
within their short list of "supported" browsers. More on that later.

The jQuery user need have no knowledge of the "defaultChecked"
property. That's the complication that should be abstracted away (as
opposed to shaved off).

The example use case for the "setter" is also common (and related to
the "getter" example). If a form is submitted via XHR and the request
succeeds, you would typically do this to update a checkbox to reflect
the newly updated data on the server:

el.defaultChecked = el.checked;

....Or in jQuery terms:

if ($(el).prop('checked')) {
  $(el).attr('checked', 'checked');
} else {
  // Note this will fail by throwing an exception in at least some
combinations of jQuery and IE versions.
  // Will cause an infinite loop in others. :(
  $(el).removeAttr('checked');
}

....But as of 1.7.2, the first branch will evaluate to a very costly
(in more ways than one) no-op. In other words, prior to 1.7.2, that
line would do something useful, but thereafter will do *nothing*
(other than waste time). As noted in the comments, nobody really knows
what the second branch will do (lot of variables to consider). Well,
this will hold true until they realize their latest goof and revert
it.

Who keeps track of all of these changes? As noted here, it's scary to
think what this will do to all of the plug-ins in the "jQuery
universe":

http://stackoverflow.com/questions/5874652/prop-vs-attr/5876747

....Not to mention all of the existing sites and applications. Even the
famously naive jQuery enthusiasts smell a rat here. It's really hard
to miss, even without a solid frame of reference.

But wait, there's more. The "value" property is also subject to change
(by user or script), yet it has been left off the above convergence
list, likely due to the fact that it is not a boolean. Have a headache
yet? :)

$(el).prop('value') == el.value;
$(el).attr('value') != el.value;

Against all odds, it gets even worse (get out the aspirin). All of the
above jQuery examples are based on the rules introduced in 1.6, which
were clearly (loosely) based on the "attr" and "prop" functions found
in the above-mentioned attributes primer. Unfortunately for everybody
that relies on jQuery for simplified DOM manipulation, they half-
reverted these changes (almost immediately) as soon as I reviewed them
here (literally the next day IIRC).

If only they would have asked, but then the CLJ "ban" was in effect.
These bumblers constantly screw up even the simplest DOM operations,
all the while warning their users to avoid the "trolls" in CLJ (who
most certainly have the answers the jQuery *authors* are desperately
seeking themselves). How stupid and self-defeating can you get? I
suppose that, years from now, when they finally figure this stuff out,
they won't have to share credit with those awful "trolls" that have
caused them so much grief over the years. :)

Obviously, they should have never changed the legacy "attr" method to
match mine. The very idea was lunacy (as I pointed out in my review).
The act of copying my code into their repository for testing was a
harbinger. Unfortunately, not known for reading comprehension, they
decided *not* to follow my advice for a fix that would preserve
backward compatibility with previous jQuery versions, while actually
simplifying this issue going forward. No, they reverted "attr" back to
its original confused logic (mixes up properties and attributes in a
maddening combinations that have proven unreliable, even in their
"supported" browsers) and left "prop" alone. This left them with a
broken "attr", the long-since busted "removeAttr" and a "prop" that
(presumably) works as intended. Now I know you have a headache, unless
you took my advice five years ago and avoided this miserable project
like the plague. ;)

The ongoing jQuery effort is clearly the most futile attempt to
simplify DOM manipulation since... well, it's really in a class by
itself in this dubious category. Not unexpected at all as to simplify
DOM manipulation, the authors would first need to understand the
basics of DOM manipulation, as well as common use cases. Reminds me of
the old Monty Python sketch about the botched English-Hungarian
phrasebook.

http://www.youtube.com/watch?v=G6D1YI-41ao&feature=player_detailpage

I will not use thees library. It ees botched. :)

http://www.youtube.com/watch?v=G6D1YI-41ao&feature=player_detailpage#t=240s

So how on earth is this brand name so popular? The answer is simple.
The primary users of the jQuery API are plug-in and widget authors.
They are just jumping on a brand name bandwagon, so they don't care if
the underlying script is a piece of junk. They put up with the endless
mix-ups because they know that Web developers will download their
widgets if they say "jQuery" on them. The widget developers abdicate
responsibility for the DOM to jQuery (come hell or high water) and the
Web developers abdicate responsibility for jQuery to the widget
developers. It's a two-tiered system of abdication; when things go
wrong it is easy enough to blame the next guy. The buck stops with
Resig, but relentless marketing has convinced virtually everybody
outside of this newsgroup that he's on the ball, so the blame is
passed on to the evil browsers and their indecipherable DOM
implementations. It was amusing five years ago (when IE 6/7 reigned),
but absolutely perverse today as it has never been easier to write
cross-browser code (degrading in the IE legacy versions as needed).

http://en.wikipedia.org/wiki/Cross-browser

The final (I hope) punchline is coming in early 2013 when they drop
all support for IE 8- (not a misprint, they really are lumping IE 8 in
with the previous versions) from the main branch. At that point, the
entire project becomes superfluous. Hopefully it will vanish quickly,
but realistically it will take years to scrape this mess off the Web
(see Prototype).
0
Reply dmark.cinsoft (347) 9/19/2012 5:57:15 AM

See related articles to this posting


On Sep 19, 1:57=A0am, David Mark <dmark.cins...@gmail.com> wrote:
> Here they "grow" again:
>
> http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clari...
>
> "Using 1.7.2 and 1.8pre, whether you call .prop() or attr(), jQuery
> will internally always actually use .prop for:
>
> async, autofocus, autoplay, checked, controls, defer, disabled,
> hidden, loop,
> multiple, open, readonly, required, scoped, selected"
>
> This is what's known as an "active" project. Basically, they fiddle
> around with the logic behind the "simple" API forever. You never know
> what to expect from one version to the next. This is largely caused by
> flailing around trying to make the results match their confused
> expectations. I call it a "never finished" project.
>
> Though I didn't see this specific misstep coming, I knew from reading
> the recently mentioned "attr vs. prop" discussion (for lack of a
> better word) on StackOverflow (for lack of a better site) that they
> were confused about how to handle boolean properties/attributes. I
> just had no idea *how* confused. Here they've lumped all booleans (or
> at least the ones they've heard of) into a single group for special
> treatment (apparently starting with version 1.7.2).
>
> The above is a partial list of attributes (left out ismap for one)
> that are reflected as boolean properties. Two of them should stand out
> as fundamentally different from the rest. The "checked" and "selected"
> attributes are reflected by DOM properties with the "default" prefix
> (e.g. "defaultChecked"). The reason for this is simple: user actions
> may change the "checked" and "selected" properties and the DOM must
> keep track of the default values of these attributes (e.g. to reset
> forms). This is all spelled out very clearly in the DOM
> specifications, which predate jQuery by several years (so much for
> moving forward).
>
> So, once again, in trying to dumb down interfaces that they themselves
> don't understand, they've just made things more complicated for their
> users. If they'd have bothered to *read* this example (as opposed to
> just copying it into their repository for testing), they'd have
> understood the basic concept of "attr" vs. "prop":
>
> http://www.cinsoft.net/attributes.html
>
> To be specific, they've created collisions where the DOM (and my
> example) specifically avoided them.
>
> Right:
>
> $(el).prop('checked') =3D=3D el.checked;
> $(el).attr('checked') =3D=3D el.defaultChecked;
>

A couple of clarifications. As mentioned, the jQuery examples are
based on their 1.6 hack job, but obviously just the "right" examples.
The "wrong" examples are based on their new take.

Regardless, the second example above is an oversimplification. Like
the primer they copied, their 1.6 "attr" returned only strings or
undefined. Actually, null in my examples; but I guess they wanted to
be (slightly) different.

$(el).attr('checked') =3D=3D el.defaultChecked ? 'checked' : undefined;

Something like that. I suppose the historical record is irrelevant at
this point as they reverted back to the hybrid "attr" (which returns a
boolean value for "checked") within days of my review of 1.6. Then
again, given the widespread abuse of these scripts, there's probably
people somewhere in the world upgrading from 1.6 to 1.6.1 as I write
this. If only Resig hadn't placed this newsgroup on the "banned"
list. :)

It really amazes me that jQuery users are so eager to "upgrade" every
time they see a new version. Do they think these things are like movie
sequels? I suppose, in a way, they are. They repeat the same basic
plot with minor tweaks and certainly get worse over time. But
programming and watching movies are very different things (newbs take
note of that). Swapping out foundation-level scripts on websites
requires a bit more consideration than trading in movies at the
mall. ;)
0
Reply dmark.cinsoft (347) 9/19/2012 10:21:56 AM

On Tue, 18 Sep 2012 at 22:57:15, in comp.lang.javascript, David Mark 
wrote:

   <snip>
>The final (I hope) punchline is coming in early 2013 when they drop
>all support for IE 8- (not a misprint, they really are lumping IE 8 in
>with the previous versions) from the main branch. At that point, the
>entire project becomes superfluous. Hopefully it will vanish quickly,
>but realistically it will take years to scrape this mess off the Web
>(see Prototype).

Seriously, are they really thinking of stopping all Win XP users from 
buying on-line ? (IE9+ aren't available for XP).

   John
-- 
John Harris
0
Reply john2010 (326) 9/19/2012 2:43:32 PM

On 9/19/2012 7:43 AM, John G Harris wrote:
> Seriously, are they really thinking of stopping all Win XP users from
> buying on-line ? (IE9+ aren't available for XP).

No, David's just desperate for attention.

The jQuery 2.* release (which hasn't seen an alpha yet) strips a bunch 
of IE-focused code and won't support < IE9, while the 1.* branch will 
continue development in parallel, with the same APIs as the 2.* branch, 
and continue IE6+ support. Developers decide which version fits their 
needs. It's not quite as controversial as David wants it to sound.

It's worth noting... "Earlier this week Google Apps announced that 
they�ll soon drop support for Internet Explorer 8, the most up-to-date 
version of Microsoft�s web browser available on XP. After November 15, 
anyone trying to access Gmail, Google Calendar, or Google Docs/Drive 
from IE8 will see a message recommending that they upgrade their browser."
0
Reply anon (312) 9/19/2012 3:33:53 PM

On Tue, 18 Sep 2012 22:57:15 -0700 (PDT), David Mark wrote:

>Here they "grow" again:
>
>http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clarification
>...

Have you ever thought of writing a jQuery-compatible kQuery?
(:-)

I guess there could be money in this too. Unless, of course,
jQuery then copies your code.

Hans-Georg
0
Reply hans-georgNoEmailPlease (75) 9/19/2012 3:34:19 PM

On Sep 19, 10:44=A0am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Tue, 18 Sep 2012 at 22:57:15, in comp.lang.javascript, David Mark
> wrote:
>
> =A0 =A0<snip>
>
> >The final (I hope) punchline is coming in early 2013 when they drop
> >all support for IE 8- (not a misprint, they really are lumping IE 8 in
> >with the previous versions) from the main branch. At that point, the
> >entire project becomes superfluous. Hopefully it will vanish quickly,
> >but realistically it will take years to scrape this mess off the Web
> >(see Prototype).
>
> Seriously, are they really thinking of stopping all Win XP users from
> buying on-line ? (IE9+ aren't available for XP).

Yes, they really are that ignorant. Notice that I said "from the main
branch" though. They are freezing 1.9 and will ostensibly mirror all
changes to the new 2.x branch in 1.9. So you can just pick whichever
version "suits your needs". I can't explain it further or I'll start
laughing uncontrollably. :)

See their press release (and subsequent public outcry).
0
Reply dmark.cinsoft (347) 9/19/2012 6:20:33 PM

On Sep 19, 11:33=A0am, "S.T." <a...@anon.com> wrote:
> On 9/19/2012 7:43 AM, John G Harris wrote:
>
> > Seriously, are they really thinking of stopping all Win XP users from
> > buying on-line ? (IE9+ aren't available for XP).
>
> No, David's just desperate for attention.

Spoken like somebody who doesn't know me from Adam. I think "S.T." is
following me around again. :)

>
> The jQuery 2.* release (which hasn't seen an alpha yet) strips a bunch
> of IE-focused code and won't support < IE9, while the 1.* branch will
> continue development in parallel,

And, uh... LOL. Can't take it. What's wrong with *that* picture (hint:
re-read my OP). ;)

> with the same APIs as the 2.* branch,
> and continue IE6+ support.

That they have yet to get anywhere close to write. In over five years
of near constant development. :(

> Developers decide which version fits their
> needs.

LOL. One version falls apart in unpredictable ways in IE 8- (and
compatibility modes). The other is the SOS that... well, see my
reviews over the years.

> It's not quite as controversial as David wants it to sound.

What I "want" is neither here nor there.

http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/

This one opens with:

"Please check out the followup post before jumping to the wrong
conclusion."

http://blog.jquery.com/2012/07/01/jquery-1-9-and-2-0-tldr-edition/

If you think that sounds defensive, read on. The jQuery community
(save for shills) is definitely upset about splitting the project in
two (as well they should be).

The whole idea is nuts; but, as predicted, the split was inevitable
(they had nowhere else to go). Two branches when they can't even keep
plug-ins in sync with one branch? The "jQuery Universe" is going to
get messier in 2013 and beyond, simply because jQuery is not a cross-
browser script (as has been noted numerous times over the years).

>
> It's worth noting... "Earlier this week Google Apps announced that
> they=92ll soon drop support for Internet Explorer 8, the most up-to-date
> version of Microsoft=92s web browser available on XP. After November 15,
> anyone trying to access Gmail, Google Calendar, or Google Docs/Drive
> from IE8 will see a message recommending that they upgrade their browser.=
"

I did note that on Twitter (and had a good laugh). Have you forgotten
Google's long incompetent relationship with browser scripting? They
are certainly not a good concern to emulate. In other words, if Google
does it, you should think twice about whether it is a really good
idea. In this case, it shouldn't take much thought, unless you are
completely clueless about this stuff. (?)
0
Reply dmark.cinsoft (347) 9/19/2012 6:32:36 PM

On Sep 19, 11:34=A0am, Hans-Georg Michna <hans-
georgNoEmailPle...@michna.com> wrote:
> On Tue, 18 Sep 2012 22:57:15 -0700 (PDT), David Mark wrote:
> >Here they "grow" again:
>
> >http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clari...
> >...
>
> Have you ever thought of writing a jQuery-compatible kQuery?
> (:-)

Not really. My Library has a set of jQuery-like interfaces that
demonstrate how trivial they are to implement. It's fairly
comprehensive, wrapping most of the API functions. One difference is
that it does not use a single constructor to abstract such wildly
different objects as windows, document and elements.

E =3D one element
Q =3D one or more elements (query result or array)
D =3D document
W =3D window

Then there are a couple that inherit from E:

I =3D image
C =3D control (inputs)

See the TaskSpeed tests for examples of how those are used.

>
> I guess there could be money in this too. Unless, of course,
> jQuery then copies your code.

There's no money in giving away free scripts. That's why they sell T-
shirts and support services.

Currently, I'm the "executive producer" of this project, which is more
like what I had envisioned for My Library at the start:

https://github.com/rassie/jessie

There are about a dozen developers working on it and I know of one
huge concern in Europe that is already using it (despite its infancy).
Perhaps I'll sell support services for that effort in the future. In
the meantime, I do mostly consulting and training, occasionally
revisiting the book when I get a breather.

And, believe it or not, posting here is still a great way to get
leads. I sure don't do this for my health alone. :)
0
Reply dmark.cinsoft (347) 9/19/2012 6:44:02 PM

On Sep 19, 2:44=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 11:34=A0am, Hans-Georg Michna <hans-
>
> georgNoEmailPle...@michna.com> wrote:
> > On Tue, 18 Sep 2012 22:57:15 -0700 (PDT), David Mark wrote:
> > >Here they "grow" again:
>
> > >http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clari.=
...
> > >...
>
> > Have you ever thought of writing a jQuery-compatible kQuery?
> > (:-)
>
> Not really. My Library has a set of jQuery-like interfaces that
> demonstrate how trivial they are to implement. It's fairly
> comprehensive, wrapping most of the API functions. One difference is
> that it does not use a single constructor to abstract such wildly
> different objects as windows, document and elements.
>
> E =3D one element
> Q =3D one or more elements (query result or array)
> D =3D document
> W =3D window
>
> Then there are a couple that inherit from E:
>
> I =3D image
> C =3D control (inputs)
>
> See the TaskSpeed tests for examples of how those are used.
>
>
>
> > I guess there could be money in this too. Unless, of course,
> > jQuery then copies your code.
>
> There's no money in giving away free scripts. That's why they sell T-
> shirts and support services.
>

Oh, and advertising. Did you know that My Library is now brought to
you in part by Big Fish Games? :)

http://www.bigfishgames.com/

A New Game Every Day.
0
Reply dmark.cinsoft (347) 9/19/2012 7:16:37 PM

On Sep 19, 2:32=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 11:33=A0am, "S.T." <a...@anon.com> wrote:
>
> > On 9/19/2012 7:43 AM, John G Harris wrote:
>
> > > Seriously, are they really thinking of stopping all Win XP users from
> > > buying on-line ? (IE9+ aren't available for XP).
>
> > No, David's just desperate for attention.
>
> Spoken like somebody who doesn't know me from Adam. I think "S.T." is
> following me around again. :)
>
>
>
> > The jQuery 2.* release (which hasn't seen an alpha yet) strips a bunch
> > of IE-focused code and won't support < IE9, while the 1.* branch will
> > continue development in parallel,
>
> And, uh... LOL. Can't take it. What's wrong with *that* picture (hint:
> re-read my OP). ;)
>
> > with the same APIs as the 2.* branch,
> > and continue IE6+ support.
>
> That they have yet to get anywhere close to write. In over five years
> of near constant development. :(

Right, not write. Sorry, laughing too hard to pay attention.

Two branches, "continued" IE6+ (presumably means IE 8-) support, and
uh... Sorry, can't do this. :)
0
Reply dmark.cinsoft (347) 9/19/2012 7:23:55 PM

On Sep 19, 6:21=A0am, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 1:57=A0am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Here they "grow" again:
>
> >http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clari...
>
> > "Using 1.7.2 and 1.8pre, whether you call .prop() or attr(), jQuery
> > will internally always actually use .prop for:
>
> > async, autofocus, autoplay, checked, controls, defer, disabled,
> > hidden, loop,
> > multiple, open, readonly, required, scoped, selected"
>
> > This is what's known as an "active" project. Basically, they fiddle
> > around with the logic behind the "simple" API forever. You never know
> > what to expect from one version to the next. This is largely caused by
> > flailing around trying to make the results match their confused
> > expectations. I call it a "never finished" project.
>
> > Though I didn't see this specific misstep coming, I knew from reading
> > the recently mentioned "attr vs. prop" discussion (for lack of a
> > better word) on StackOverflow (for lack of a better site) that they
> > were confused about how to handle boolean properties/attributes. I
> > just had no idea *how* confused. Here they've lumped all booleans (or
> > at least the ones they've heard of) into a single group for special
> > treatment (apparently starting with version 1.7.2).
>
> > The above is a partial list of attributes (left out ismap for one)
> > that are reflected as boolean properties. Two of them should stand out
> > as fundamentally different from the rest. The "checked" and "selected"
> > attributes are reflected by DOM properties with the "default" prefix
> > (e.g. "defaultChecked"). The reason for this is simple: user actions
> > may change the "checked" and "selected" properties and the DOM must
> > keep track of the default values of these attributes (e.g. to reset
> > forms). This is all spelled out very clearly in the DOM
> > specifications, which predate jQuery by several years (so much for
> > moving forward).
>
> > So, once again, in trying to dumb down interfaces that they themselves
> > don't understand, they've just made things more complicated for their
> > users. If they'd have bothered to *read* this example (as opposed to
> > just copying it into their repository for testing), they'd have
> > understood the basic concept of "attr" vs. "prop":
>
> >http://www.cinsoft.net/attributes.html
>
> > To be specific, they've created collisions where the DOM (and my
> > example) specifically avoided them.
>
> > Right:
>
> > $(el).prop('checked') =3D=3D el.checked;
> > $(el).attr('checked') =3D=3D el.defaultChecked;
>
> A couple of clarifications. As mentioned, the jQuery examples are
> based on their 1.6 hack job, but obviously just the "right" examples.
> The "wrong" examples are based on their new take.
>
> Regardless, the second example above is an oversimplification. Like
> the primer they copied, their 1.6 "attr" returned only strings or
> undefined. Actually, null in my examples; but I guess they wanted to
> be (slightly) different.
>
> $(el).attr('checked') =3D=3D el.defaultChecked ? 'checked' : undefined;
>
> Something like that. I suppose the historical record is irrelevant at
> this point as they reverted back to the hybrid "attr" (which returns a
> boolean value for "checked") within days of my review of 1.6. Then
> again, given the widespread abuse of these scripts, there's probably
> people somewhere in the world upgrading from 1.6 to 1.6.1 as I write
> this. If only Resig hadn't placed this newsgroup on the "banned"
> list. :)
>
> It really amazes me that jQuery users are so eager to "upgrade" every
> time they see a new version. Do they think these things are like movie
> sequels? I suppose, in a way, they are. They repeat the same basic
> plot with minor tweaks and certainly get worse over time. But
> programming and watching movies are very different things (newbs take
> note of that). Swapping out foundation-level scripts on websites
> requires a bit more consideration than trading in movies at the
> mall. ;)

Left off one other twist to this convoluted tale. The "attr" method is
supposed to work with both HTML and XML DOM's (XML from XHR results,
not XHTML of course). That's always been one of its biggest handicaps
as it led to code that must first distinguish between the two types of
DOM's (impossible to do reliably) and then process them in completely
different ways. This is partly to blame for the lack of maintenance on
that method as, despite being brief, it is virtually impossible to
follow (and what comments exist are as confusing as the code).

If you read through the "support" discussions regarding "attr" vs.
"prop", you'll find that nobody from the jQuery side mentioned this
issue at all. In short, they just keep saying "use prop" for "most"
cases. Obviously, "prop" won't work XML at all. It's almost as if they
don't know what their own code is designed (using that term loosely)
to do. (?)
0
Reply dmark.cinsoft (347) 9/19/2012 7:47:22 PM

On Sep 19, 1:57=A0am, David Mark <dmark.cins...@gmail.com> wrote:

>
> The final (I hope) punchline is coming in early 2013 when they drop
> all support for IE 8- (not a misprint, they really are lumping IE 8 in
> with the previous versions) from the main branch. At that point, the
> entire project becomes superfluous. Hopefully it will vanish quickly,
> but realistically it will take years to scrape this mess off the Web
> (see Prototype).

For more information:

https://gist.github.com/3445646
0
Reply dmark.cinsoft (347) 9/19/2012 7:51:29 PM

> $(el).prop('value') == el.value;
> $(el).attr('value') != el.value;

The .val() method should be used for getting and setting value. Read the 
docs, man :)

> Unfortunately for everybody
> that relies on jQuery for simplified DOM manipulation, they half-
> reverted these changes (almost immediately) as soon as I reviewed them
> here (literally the next day IIRC).

The notion that they reverted anything because of you is laughable. :)

There are logistical issues to altering an API on a library with 
millions of users. It's much easier on a library with a user base I can 
count using my fingers - a luxury your library has enjoyed for half a 
decade. :)

http://ejohn.org/blog/jquery-16-and-attr/ :)
0
Reply anon (312) 9/19/2012 9:26:56 PM

On Sep 19, 5:26=A0pm, "S.T." <a...@anon.com> wrote:
> > $(el).prop('value') =3D=3D el.value;
> > $(el).attr('value') !=3D el.value;
>
> The .val() method should be used for getting and setting value. Read the
> docs, man :)
>
> > Unfortunately for everybody
> > that relies on jQuery for simplified DOM manipulation, they half-
> > reverted these changes (almost immediately) as soon as I reviewed them
> > here (literally the next day IIRC).
>
> The notion that they reverted anything because of you is laughable. :)

Sorry, no. Not only did they split "attr" and "prop" as a direct
result of both my near-constant and well-deserved criticism of "attr",
but Resig even copied my Attributes primer to their repository for
testing (but then you knew that). Not to mention that Resig
participated in a thread back in the fall of 2007 where the "attr"
problems were first outlined.

I'm not revisiting that *again*; suffice to say that there were
numerous, long-winded discussions related to that thread (and "attr"
specifically) in the *jQuery group* for years to come. Matt Kruse
initiated a couple of them. Resig also copied (almost verbatim) the
"magic attributes flag" that I gave him in that thread. It was the
cornerstone for their "breakthrough" 1.3 version (which ostensibly
eliminated all browser sniffing). But then, you knew that too; so what
is all of your noise in aid of?

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

Furthermore, someone called "Timmy" (last name escapes me) wrote a
blog entry describing the split. I commented and told him exactly how
he screwed it up and that he would either have to fix it or revert the
whole mess. Clearly he chose the latter (the next day IIRC), after a
few juvenile insults were tossed around, and then proceeded to delete
all of my comments. :(

https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/a=
195f1fff1975ca0/5cee91ec32a72bc2

You know you've won an argument when the other side tries to hide all
evidence that it ever took place. I suspect your comment is also along
these lines (i.e. trying to obscure the obvious facts). You simply
can't accept the fact that your chosen brand of browser scripts is so
heavily influenced by my work. Get over it and perhaps re-think your
whole view of the history behind these machinations.

> There are logistical issues to altering an API on a library with
> millions of users.

Yes, thanks for that. That's roughly what I told Timmy when they
changed the "attr" method instead of deprecating it and creating some
new method to handle attributes properly (something they still lack to
this day). It's ironic that a CSS selector query engine would try to
get by without proper attribute-handling code, but that's basically
the story of "Sizzle".

> It's much easier on a library with a user base I can
> count using my fingers - a luxury your library has enjoyed for half a
> decade. :)

Even easier when you design and build it right from the start and
therefore don't have to keep changing tacks. ;)

>
> http://ejohn.org/blog/jquery-16-and-attr/:)

That just shows Resig is a transparent and disingenuous twit. He
didn't even think to thank me for all of my contributions. The idea
that you would use that to somehow support your... well, you don't
really have any arguments, do you? :)
0
Reply dmark.cinsoft (347) 9/19/2012 9:59:25 PM

On Sep 19, 5:59=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 5:26=A0pm, "S.T." <a...@anon.com> wrote:
>
> > > $(el).prop('value') =3D=3D el.value;
> > > $(el).attr('value') !=3D el.value;
>
> > The .val() method should be used for getting and setting value. Read th=
e
> > docs, man :)
>
> > > Unfortunately for everybody
> > > that relies on jQuery for simplified DOM manipulation, they half-
> > > reverted these changes (almost immediately) as soon as I reviewed the=
m
> > > here (literally the next day IIRC).
>
> > The notion that they reverted anything because of you is laughable. :)
>
> Sorry, no. Not only did they split "attr" and "prop" as a direct
> result of both my near-constant and well-deserved criticism of "attr",
> but Resig even copied my Attributes primer to their repository for
> testing (but then you knew that). Not to mention that Resig
> participated in a thread back in the fall of 2007 where the "attr"
> problems were first outlined.
>
> I'm not revisiting that *again*; suffice to say that there were
> numerous, long-winded discussions related to that thread (and "attr"
> specifically) in the *jQuery group* for years to come. Matt Kruse
> initiated a couple of them. Resig also copied (almost verbatim) the
> "magic attributes flag" that I gave him in that thread. It was the
> cornerstone for their "breakthrough" 1.3 version (which ostensibly
> eliminated all browser sniffing). But then, you knew that too; so what
> is all of your noise in aid of?
>
> http://www.cinsoft.net/host.html
>
> Furthermore, someone called "Timmy" (last name escapes me) wrote a
> blog entry describing the split. I commented and told him exactly how
> he screwed it up and that he would either have to fix it or revert the
> whole mess. Clearly he chose the latter (the next day IIRC), after a
> few juvenile insults were tossed around, and then proceeded to delete
> all of my comments. :(
>
> https://groups.google.com/group/comp.lang.javascript/browse_thread/th...
>
> You know you've won an argument when the other side tries to hide all
> evidence that it ever took place.

Update, on clicking the link to Timmy's explanation of the attr/prop
split, I ended up on his home page. So he has since deleted the entire
post (or is simply an incompetent Web developer). :(

Furthermore, that guy is a major contributor to jQuery, along with
other well-known buffoons like light-saber guy and Resig. These are
not just bad programmers. These are truly *stupid* (not to mention
dishonest) people. I should know as I've spent years coaching them and
they still can't figure out where they are going wrong. They just plod
along, year after year, on the same stupid course, occasionally
hurling insults at people who are genuinely trying to help them (to
help the Web). Then again, give them a break as I think they are all
in their twenties, so their brains are still trying to develop. :)

No sensible business would want anything to do with a software project
like this (and run by such obvious frauds). It's really that simple
(painful as it may be to swallow).

You may not like me for saying so (and I really don't care), but it's
not me that's lying to you. See if you can count the number of
misleading statements on the front page of the jQuery site. If you
can't spot any then you need to do some (real) due diligence (and
reading blog posts by jQuery fans doesn't count).
0
Reply dmark.cinsoft (347) 9/19/2012 10:13:38 PM

On Sep 19, 5:59=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 5:26=A0pm, "S.T." <a...@anon.com> wrote:
>
> > > $(el).prop('value') =3D=3D el.value;
> > > $(el).attr('value') !=3D el.value;
>
> > The .val() method should be used for getting and setting value. Read th=
e
> > docs, man :)
>
> > > Unfortunately for everybody
> > > that relies on jQuery for simplified DOM manipulation, they half-
> > > reverted these changes (almost immediately) as soon as I reviewed the=
m
> > > here (literally the next day IIRC).
>
> > The notion that they reverted anything because of you is laughable. :)
>
> Sorry, no. Not only did they split "attr" and "prop" as a direct
> result of both my near-constant and well-deserved criticism of "attr",
> but Resig even copied my Attributes primer to their repository for
> testing (but then you knew that). Not to mention that Resig
> participated in a thread back in the fall of 2007 where the "attr"
> problems were first outlined.
>
> I'm not revisiting that *again*; suffice to say that there were
> numerous, long-winded discussions related to that thread (and "attr"
> specifically) in the *jQuery group* for years to come. Matt Kruse
> initiated a couple of them. Resig also copied (almost verbatim) the
> "magic attributes flag" that I gave him in that thread. It was the
> cornerstone for their "breakthrough" 1.3 version (which ostensibly
> eliminated all browser sniffing). But then, you knew that too; so what
> is all of your noise in aid of?
>
> http://www.cinsoft.net/host.html
>
> Furthermore, someone called "Timmy" (last name escapes me) wrote a
> blog entry describing the split. I commented and told him exactly how
> he screwed it up and that he would either have to fix it or revert the
> whole mess. Clearly he chose the latter (the next day IIRC), after a
> few juvenile insults were tossed around, and then proceeded to delete
> all of my comments. :(
>
> https://groups.google.com/group/comp.lang.javascript/browse_thread/th...
>
> You know you've won an argument when the other side tries to hide all
> evidence that it ever took place. I suspect your comment is also along
> these lines (i.e. trying to obscure the obvious facts). You simply
> can't accept the fact that your chosen brand of browser scripts is so
> heavily influenced by my work. Get over it and perhaps re-think your
> whole view of the history behind these machinations.
>
> > There are logistical issues to altering an API on a library with
> > millions of users.
>
> Yes, thanks for that. That's roughly what I told Timmy when they
> changed the "attr" method instead of deprecating it and creating some
> new method to handle attributes properly (something they still lack to
> this day). It's ironic that a CSS selector query engine would try to
> get by without proper attribute-handling code, but that's basically
> the story of "Sizzle".
>
> > It's much easier on a library with a user base I can
> > count using my fingers - a luxury your library has enjoyed for half a
> > decade. :)
>
> Even easier when you design and build it right from the start and
> therefore don't have to keep changing tacks. ;)
>
>
>
> >http://ejohn.org/blog/jquery-16-and-attr/:)
>
> That just shows Resig is a transparent and disingenuous twit. He
> didn't even think to thank me for all of my contributions. The idea
> that you would use that to somehow support your... well, you don't
> really have any arguments, do you? :)

Hmmm. Also shows that he has no idea what his script does (or did).

"In jQuery 1.5.2, and older, in order to access a DOM property you
would have to do something like this:

var elem =3D $("#foo")[0];
if ( elem ) {
  index =3D elem.selectedIndex;
}"

Like hell. The original "attr" returned (mostly) property values in an
HTML DOM (and attribute values in an XML DOM). I (among others)
explained this to him years before he wrote this.

Too much. :(
0
Reply dmark.cinsoft (347) 9/19/2012 10:28:42 PM

On 9/19/2012 2:59 PM, David Mark wrote:
> On Sep 19, 5:26 pm, "S.T." <a...@anon.com> wrote:
>>> $(el).prop('value') == el.value;
>>> $(el).attr('value') != el.value;
>>
>> The .val() method should be used for getting and setting value. Read the
>> docs, man :)
>>
>>> Unfortunately for everybody
>>> that relies on jQuery for simplified DOM manipulation, they half-
>>> reverted these changes (almost immediately) as soon as I reviewed them
>>> here (literally the next day IIRC).
>>
>> The notion that they reverted anything because of you is laughable. :)
>
> Sorry, no. Not only did they split "attr" and "prop" as a direct
> result of both my near-constant and well-deserved criticism of "attr",

That's quite a leap of faith! Sadly, I doubt this is true :(

> but Resig even copied my Attributes primer to their repository for
> testing (but then you knew that). Not to mention that Resig
> participated in a thread back in the fall of 2007 where the "attr"
> problems were first outlined.
>
> I'm not revisiting that *again*; suffice to say that there were
> numerous, long-winded discussions related to that thread (and "attr"
> specifically) in the *jQuery group* for years to come. Matt Kruse
> initiated a couple of them. Resig also copied (almost verbatim) the
> "magic attributes flag" that I gave him in that thread. It was the
> cornerstone for their "breakthrough" 1.3 version (which ostensibly
> eliminated all browser sniffing). But then, you knew that too; so what
> is all of your noise in aid of?
>
> http://www.cinsoft.net/host.html
>
> Furthermore, someone called "Timmy" (last name escapes me) wrote a
> blog entry describing the split. I commented and told him exactly how
> he screwed it up and that he would either have to fix it or revert the
> whole mess. Clearly he chose the latter (the next day IIRC), after a
> few juvenile insults were tossed around, and then proceeded to delete
> all of my comments. :(
>
> https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/a195f1fff1975ca0/5cee91ec32a72bc2
>
> You know you've won an argument when the other side tries to hide all
> evidence that it ever took place. I suspect your comment is also along
> these lines (i.e. trying to obscure the obvious facts). You simply
> can't accept the fact that your chosen brand of browser scripts is so
> heavily influenced by my work. Get over it and perhaps re-think your
> whole view of the history behind these machinations.

Other than your insistence that this is true, there's nothing here that 
backs up your claims. They *did* revisit an ill-advised design decision 
of attempting to normalize attributes and properties into one function 
for ease of API. Your rants were the reason for that eventual decision? 
That seems very, very unlikely. :(

If it's credit you're after, and you seem to be complaining about that 
more and more, you should produce something people find useful. So they 
can credit you with it. You might have gotten some credit for helping in 
this case, but according to the thread you threatened legal action so 
they weren't able to use anything of yours that would have helped. So 
you didn't receive credit. Because you didn't actually help. That's how 
these things work. :(


0
Reply anon (312) 9/19/2012 10:30:17 PM

On Sep 19, 6:29=A0pm, "S.T." <a...@anon.com> wrote:
> On 9/19/2012 2:59 PM, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 19, 5:26 pm, "S.T." <a...@anon.com> wrote:
> >>> $(el).prop('value') =3D=3D el.value;
> >>> $(el).attr('value') !=3D el.value;
>
> >> The .val() method should be used for getting and setting value. Read t=
he
> >> docs, man :)
>
> >>> Unfortunately for everybody
> >>> that relies on jQuery for simplified DOM manipulation, they half-
> >>> reverted these changes (almost immediately) as soon as I reviewed the=
m
> >>> here (literally the next day IIRC).
>
> >> The notion that they reverted anything because of you is laughable. :)
>
> > Sorry, no. Not only did they split "attr" and "prop" as a direct
> > result of both my near-constant and well-deserved criticism of "attr",
>
> That's quite a leap of faith! Sadly, I doubt this is true :(

It's not a leap of faith; it's been quite well-documented (by me, Matt
Kruse, several other jQuery enthusiasts, as well as Resig himself).
All you have to do is follow my links and *read*.

And sadly, your doubts are not my concern.

>
>
>
>
>
>
>
>
>
> > but Resig even copied my Attributes primer to their repository for
> > testing (but then you knew that). Not to mention that Resig
> > participated in a thread back in the fall of 2007 where the "attr"
> > problems were first outlined.
>
> > I'm not revisiting that *again*; suffice to say that there were
> > numerous, long-winded discussions related to that thread (and "attr"
> > specifically) in the *jQuery group* for years to come. Matt Kruse
> > initiated a couple of them. Resig also copied (almost verbatim) the
> > "magic attributes flag" that I gave him in that thread. It was the
> > cornerstone for their "breakthrough" 1.3 version (which ostensibly
> > eliminated all browser sniffing). But then, you knew that too; so what
> > is all of your noise in aid of?
>
> >http://www.cinsoft.net/host.html
>
> > Furthermore, someone called "Timmy" (last name escapes me) wrote a
> > blog entry describing the split. I commented and told him exactly how
> > he screwed it up and that he would either have to fix it or revert the
> > whole mess. Clearly he chose the latter (the next day IIRC), after a
> > few juvenile insults were tossed around, and then proceeded to delete
> > all of my comments. :(
>
> >https://groups.google.com/group/comp.lang.javascript/browse_thread/th...
>
> > You know you've won an argument when the other side tries to hide all
> > evidence that it ever took place. I suspect your comment is also along
> > these lines (i.e. trying to obscure the obvious facts). You simply
> > can't accept the fact that your chosen brand of browser scripts is so
> > heavily influenced by my work. Get over it and perhaps re-think your
> > whole view of the history behind these machinations.
>
> Other than your insistence that this is true, there's nothing here that
> backs up your claims.

Except a seemingly endless "paper" trail. Again, *read* the
discussions, starting all the way back in 2007.

> They *did* revisit an ill-advised design decision
> of attempting to normalize attributes and properties into one function
> for ease of API.

Yes, four years later after numerous discussions that referenced my
articles criticizing this very design decision. Again, many of these
discussions took place in jQuery's own group. The fact that you refuse
to go back and look at them tells me you are just trying to obfuscate
the issue. Why is anyone's guess. My diagnosis is cognitive
dissonance. You might seek a professional opinion about that
though. ;)

> Your rants were the reason for that eventual decision?

Your characterization of my painfully detailed analyses of "attr" as
"rants" speaks volumes. Your brain just can't cope with reality (or
you simply don't understand the so-called rants at all).

> That seems very, very unlikely. :(

You seem very, very clueless about... well, everything. :(

>
> If it's credit you're after, and you seem to be complaining about that
> more and more, you should produce something people find useful.]

I am not after anything here, except for correcting your BS
assertions. Virtually everybody on the planet (save for you) is aware
of my contributions to jQuery, Dojo and many other such efforts. You
just seem to live in your own little world. :)

> So they
> can credit you with it. You might have gotten some credit for helping in
> this case, but according to the thread you threatened legal action so
> they weren't able to use anything of yours that would have helped.

You just don't get it. They copied my material without my permission.
They certainly *read* at least some of it before they decided it was
worth trying to lift. And this was *long* after the fact anyway. As
mentioned, the first review in 2007 is what brought the issue to their
attention.

> So
> you didn't receive credit. Because you didn't actually help. That's how
> these things work. :(

Again, I don't think you understand how *anything* works. Your whole
online existence seems to revolve around trying to discredit me. Think
about that. ;)
0
Reply dmark.cinsoft (347) 9/19/2012 11:01:39 PM

On Sep 19, 6:29=A0pm, "S.T." <a...@anon.com> wrote:
> On 9/19/2012 2:59 PM, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 19, 5:26 pm, "S.T." <a...@anon.com> wrote:
> >>> $(el).prop('value') =3D=3D el.value;
> >>> $(el).attr('value') !=3D el.value;
>
> >> The .val() method should be used for getting and setting value. Read t=
he
> >> docs, man :)

Missed this comment before. I suggest you read the ten tons of
comments on the previously cited jQuery blog post related to the
"value" attribute/property (and not one mention of "val"). Perhaps the
docs are unclear on this matter. At the very least, the jQuery
community is (predictably) quite confused about all of this stuff (as
are you).
0
Reply dmark.cinsoft (347) 9/19/2012 11:03:58 PM

On 9/19/2012 4:01 PM, David Mark wrote:

> Virtually everybody on the planet (save for you) is aware
> of my contributions to jQuery

Um, no. You seem to hypothesize that you've been a driving force behind 
changes to the most popular library out there but there are very few, if 
any, who would agree with you. Sorry bro.  :(

> Dojo

I recall reading your contributions to Dojo in the past, on their 
mailing list. Very amusing stuff. :)

Are we done yet?
0
Reply anon (312) 9/20/2012 12:09:44 AM

On Sep 19, 8:09=A0pm, "S.T." <a...@anon.com> wrote:
> On 9/19/2012 4:01 PM, David Mark wrote:
>
> > Virtually everybody on the planet (save for you) is aware
> > of my contributions to jQuery
>
> Um, no. You seem to hypothesize that you've been a driving force behind
> changes to the most popular library out there but there are very few, if
> any, who would agree with you. Sorry bro. =A0:(

There are very few that have a clue what goes on inside that script
and behind the scenes of its development. Certainly *you* are not on
that list. But, among those who bother to *read* the history, the
origin of the "attr"/"prop" split (and subsequent flailing rewrites)
is quite clear. Among those who don't, there's certainly a sneaking
suspicion (where there's smoke and all). But you alone remain
oblivious.

And no need to apologize. Your approval is hardly necessary.

>
> > Dojo
>
> I recall reading your contributions to Dojo in the past, on their
> mailing list. Very amusing stuff. :)

Indeed, you certainly are a die-hard fan of my works. If you
understood the discussions and their ramifications, you should have
found them amusing. They mangled attributes and properties in much the
same way as jQuery and also failed to fix them in a timely manner due
to a culture entrenched in guesswork and misunderstanding. They
couldn't even express what they thought their "attr" method was
supposed to do (suspect they copied it from jQuery or vice versa). Un-
declaring all of their globals to make their code "faster" and using
synchronous XHR to load scripts were also amusing bits.

You might also like this:

https://gist.github.com/2845842

Yes, that's right. The so-called "AMD" architecture is undisputedly
based on my rewrite of the Dojo loader. Go ahead, claim that you can't
see it. James Burke tried the same thing, right there in the thread
where he lifted it. He certainly couldn't fool me, but you seem
deluded enough to buy in to such obvious fantasy. :)

>
> Are we done yet?

I certainly hope so. :)
0
Reply dmark.cinsoft (347) 9/20/2012 12:23:37 AM

On Sep 19, 1:57=A0am, David Mark <dmark.cins...@gmail.com> wrote:
> Here they "grow" again:
>
> http://stackoverflow.com/questions/10978870/jquery-prop-vs-attr-clari...
>
> "Using 1.7.2 and 1.8pre, whether you call .prop() or attr(), jQuery
> will internally always actually use .prop for:
>
> async, autofocus, autoplay, checked, controls, defer, disabled,
> hidden, loop,
> multiple, open, readonly, required, scoped, selected"
>
> This is what's known as an "active" project. Basically, they fiddle
> around with the logic behind the "simple" API forever. You never know
> what to expect from one version to the next. This is largely caused by
> flailing around trying to make the results match their confused
> expectations. I call it a "never finished" project.
>
> Though I didn't see this specific misstep coming, I knew from reading
> the recently mentioned "attr vs. prop" discussion (for lack of a
> better word) on StackOverflow (for lack of a better site) that they
> were confused about how to handle boolean properties/attributes. I
> just had no idea *how* confused. Here they've lumped all booleans (or
> at least the ones they've heard of) into a single group for special
> treatment (apparently starting with version 1.7.2).
>
> The above is a partial list of attributes (left out ismap for one)
> that are reflected as boolean properties. Two of them should stand out
> as fundamentally different from the rest. The "checked" and "selected"
> attributes are reflected by DOM properties with the "default" prefix
> (e.g. "defaultChecked"). The reason for this is simple: user actions
> may change the "checked" and "selected" properties and the DOM must
> keep track of the default values of these attributes (e.g. to reset
> forms). This is all spelled out very clearly in the DOM
> specifications, which predate jQuery by several years (so much for
> moving forward).
>
> So, once again, in trying to dumb down interfaces that they themselves
> don't understand, they've just made things more complicated for their
> users. If they'd have bothered to *read* this example (as opposed to
> just copying it into their repository for testing), they'd have
> understood the basic concept of "attr" vs. "prop":
>
> http://www.cinsoft.net/attributes.html
>
> To be specific, they've created collisions where the DOM (and my
> example) specifically avoided them.
>
> Right:
>
> $(el).prop('checked') =3D=3D el.checked;
> $(el).attr('checked') =3D=3D el.defaultChecked;
>
> Wrong:
>
> $(el).prop('checked') =3D=3D el.checked;
> $(el).attr('checked') =3D=3D el.checked;
>

One other clarification to avoid confusion. The concept of right and
wrong (and "attr" vs. "prop") throughout is based on jQuery's
(somewhat ambiguously) stated design goals, not the design of the
functions in the Attributes primer. This is one reason why it was so
absurd for Resig to copy my functions into his repository for testing.
As I told him (or one of his buddies) at the time, they were not
*exactly* what he needed to make sense out of his "attr" method
(though the code certainly contained all of the answers).

In short, as stated at the top of the primer, my example functions,
which were written with testing in mind, are interested in the
document's canonical form, therefore they specifically exclude user
data.

This is also true of the getAttribute and getAttributeProperty
functions found in My Library. They both do basically the same thing,
with one retrieving (normalized) string and the other more convenient
property values and always by *attribute* name (e.g. "for" not
"htmlFor", "class" not "className"). User data is always excluded as
there are other functions for retrieving that (similar jQuery's "val"
method). There's no ambiguity or overlap between these functions, each
has a specific job to do and none of them have been modified in years.
Good thing as such functions are the foundation of any DOM
manipulation library, so changing them has a very good chance of
disrupting not only higher-level functions within the library (e.g.
queries) but calling applications.

On the other hand, if your code needs to reference a property value by
property name, simply reference it:

var checked =3D el.checked;
var value =3D el.value;
var defaultValue =3D el.defaultValue;

Easy, reliable, compatible in virtually every browser ever made and no
function call overhead. You can't beat properties (unless you view
them through a "magic" prism like jQuery).

Don't see any need to provide an API function to do that. Might be
handy to add one to the E and Q prototypes, but that's left as a
(trivial) exercise.
0
Reply dmark.cinsoft (347) 9/20/2012 3:13:00 AM

On Sep 19, 8:09=A0pm, "S.T." <a...@anon.com> wrote:
> On 9/19/2012 4:01 PM, David Mark wrote:
>
> > Virtually everybody on the planet (save for you) is aware
> > of my contributions to jQuery
>
> Um, no. You seem to hypothesize that you've been a driving force behind
> changes to the most popular library out there but there are very few, if
> any, who would agree with you. Sorry bro. =A0:(
>

Now that my "bro" has (hopefully) scuttled off, here are some links
that provide insight into the history of jQuery development, with
regard to attributes, properties, feature detection (and more!) :)

My proxy (Matt Kruse) makes yet another impassioned pitch for them to
pay attention to the difference between attributes and properties:

https://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd7=
14033

....that one references the Attributes primer and shows Resig clumsily
copying the code and then trying to test jQuery with it (despite it
being inappropriate for use with jQuery as is).

Bizarre SELECT hack:

https://groups.google.com/group/jquery-dev/browse_frm/thread/fe658871a8bff2=
08/bb0d17776314606a?lnk=3Dgst&q=3Dbroken+select#bb0d17776314606a

"After some discussion with colleagues, a better approach has been
identified." Uh, colleague (singular) as I recall. At least part of
that eventually made it into jQuery as a patch. I remember as my buddy
Matt begrudgingly gave me credit as an "official" jQuery contributor
at that point. :)

Here's their original reaction to the first review from back in 2007.
Yeah, they don't appear influenced at all. :)

https://groups.google.com/group/jquery-dev/browse_frm/thread/bc0ce94f8b9672=
24/92767115a8cf78a8?#92767115a8cf78a8

Towards the end:

"P.S. In his recent posts over on c.l.j he's actually been much more
down
to earth and given specific examples of what's wrong and even one
detailed description on his approach to one of the issues.
*ducks for cover*"

The "detailed description" he refers to is the very test that enabled
them to ditch a critical bit of browser sniffing and put them on the
road to (attempted) feature testing/detection. I know Resig had never
heard of an attribute reflection test at this time (neither had Peter
Michaux as I recall). In fact, this test is undisputedly my invention
as there's never been any evidence that such a test was used prior to
my introducing it in 2007. As a side note, it's a big part of
Modernizr (sp?) as well, but I'll give credit to their authors for
honestly acknowledging my influence (on Twitter IIRC). There'd sure be
no Modernizr without that pattern.

Hell, it's clear from his code (and confusion) that Resig didn't know
attributes from properties at all at that time. This is the now
infamous "magic flag" that he wanted so he could eliminate the browser
sniffing in the "attr" function. And yes, he copied it. It showed up a
year later, virtually verbatim, in version 1.3. He didn't read it
(along with dozens of his team members), discuss it in his forum,
forget all about it and then invent it himself a year later. ;)

That's just one of several discussions that occurred between members
of the jQuery team, in their own developer forum in the months that
followed the 2007 review. Not coincidentally, this is also about the
time My Library was first published, but I'm sure they simply ignored
it, just like the review. IIRC, Resig indicated he really wanted to
see "my perfect library" in the review thread. He saw such a thing as
a yeti. Five years later and the yeti has certainly been spotted,
alive and well. :)

http://www.youtube.com/watch?v=3D6RexQLrcqwc&feature=3Dplayer_detailpage#t=
=3D43s

The CLJ thread referenced throughout the jQuery developer discussion:

https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/4=
15949d1bcce6e6a/03c4d326340e7f7d?#03c4d326340e7f7d

Reaction from Richard Cornford regarding the 1.3 transformation that
followed a year later:

https://groups.google.com/group/comp.lang.javascript/msg/8ee3b684baaa0baa

One from CLJ that was referenced in one of the above-mentioned jQuery
forum posts:

https://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d2c0=
407a7fc2e33a/

Was a real pain digging these up (forgot they were in the jQuery *dev*
group, not the main one). As a side note, jQuery's new forum is broken
beyond belief in Chrome. Words can't express how broken; every click
(or navigation) is an adventure and many of the imported legacy posts
are full of broken markup. Another sound move on their part. :)

Now, if history holds, "S.T." will shut up at this point and then pop
up to voice his, uh "skepticism" a month from now as if he has a case
of amnesia. He's like some sort of obsessed stalker who wants to make
sure that his heroes gets credit that they clearly do not deserve.
Some life. :(
0
Reply dmark.cinsoft (347) 9/20/2012 5:17:44 AM

On 20/09/2012 10:09 AM, S.T. wrote:
> On 9/19/2012 4:01 PM, David Mark wrote:
>
>> Virtually everybody on the planet (save for you) is aware
>> of my contributions to jQuery
>
> Um, no. You seem to hypothesize that you've been a driving force behind
> changes to the most popular library out there but there are very few, if
> any, who would agree with you. Sorry bro.  :(
>
>> Dojo
>
> I recall reading your contributions to Dojo in the past, on their
> mailing list. Very amusing stuff. :)
>
> Are we done yet?

DM obviously understands js better than most. He posts links to 
discussions, code, and other references in support of his statements yet 
you reply with argumentum ad hominem. Do you believe your replies make 
you look a winner?

Andrew Poulos

0
Reply ap_prog (388) 9/20/2012 5:47:05 AM

On Sep 20, 1:47=A0am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> On 20/09/2012 10:09 AM, S.T. wrote:
>
> > On 9/19/2012 4:01 PM, David Mark wrote:
>
> >> Virtually everybody on the planet (save for you) is aware
> >> of my contributions to jQuery
>
> > Um, no. You seem to hypothesize that you've been a driving force behind
> > changes to the most popular library out there but there are very few, i=
f
> > any, who would agree with you. Sorry bro. =A0:(
>
> >> Dojo
>
> > I recall reading your contributions to Dojo in the past, on their
> > mailing list. Very amusing stuff. :)
>
> > Are we done yet?
>
> DM obviously understands js better than most. He posts links to
> discussions, code, and other references in support of his statements yet
> you reply with argumentum ad hominem.
>

Thanks for the kind words. I want to clarify one point though: lots of
people know JS better than I do (I just tend to stick with what I
know). Of course, history says I understand DOM scripting better than
most (certainly better than anybody associated with the jQuery
project). I ought to as I learned from Cornford's examples (which are
sadly not available on the Web today). It's interesting that many of
those examples were already fairly old in 2007.

It's just that the bloggers of the Ajax era completely ignored such
examples and set about reinventing the wheels, making all of the same
old mistakes from the turn of the century (e.g. browser sniffing).
They all but ignored (and often joked about) this newsgroup as some
sort of "irrelevant" antique. Clearly the joke was on them as the
answers they needed were here all along. :)

In five years of "campaigning" here (and elsewhere), I'm sure I have
influenced the development of a lot of "popular" libraries, though NIH
syndrome prevents most of the authors from acknowledging that
influence (they prefer to hurl insults like "troll"). Resig is one of
the most disingenuous of the lot and has even expressed that he
"hates" me. He won't even say my name (referring to me as "that guy"
who "attacked" him while he was "feeding the trolls"). What a complete
asshole. I'm quite happy to shred whatever is left of his reputation
(he's been a laughingstock among serious JS developers for years).
When you are a public figure, you have to expect public criticism. But
clowns like him think they are somehow immune.

Now, I know that their emotional reactions (or non-reactions as the
case may be) are due to the controversial nature of my posts. As I
stated back at the "beginning", I knew my somewhat caustic criticism
would piss of the self-proclaimed rock stars of the Ajax era. However,
as much of the information was old hat, I knew that the volume needed
to be turned way up for anyone to hear me over the bloggers. Most (if
not all) have gotten the message by now and the honest ones admit
that. Their fans are clueless, so instead of congratulating me on my
machinations moving browser scripting forward, they parrot their troll-
spotting idols. :(

> Do you believe your replies make
> you look a winner?

If so, he's even stupider than he sounds. But his psyche is his own
problem; I just try to correct his near-constant flow of
misinformation regarding jQuery, me, etc. He can spew his crap
elsewhere, but it will *never* fly here. Nothing more pathetic than an
anonymous jackass; it's as if he knows he is full of shit (and perhaps
he does).
0
Reply dmark.cinsoft (347) 9/20/2012 6:16:24 AM

On Wed, 19 Sep 2012 17:09:49 -0700, "S.T." <anon@anon.com> wrote:

>On 9/19/2012 4:01 PM, David Mark wrote:
>
>> Virtually everybody on the planet (save for you) is aware
>> of my contributions to jQuery
>
>Um, no. You seem to hypothesize that you've been a driving force behind 
>changes to the most popular library out there but there are very few, if 
>any, who would agree with you. Sorry bro.  :(
>
>> Dojo
>
>I recall reading your contributions to Dojo in the past, on their 
>mailing list. Very amusing stuff. :)
>
>Are we done yet?

     Could you point to a comp.lang.javascript post of yours where you
have been the slightest help at all?  If not, go away.

Sincerely,

Gene Wirchenko
0
Reply genew (1214) 9/20/2012 5:20:25 PM

On 9/19/2012 10:17 PM, David Mark wrote:
> Now, if history holds, "S.T." will shut up at this point and then pop
> up to voice his, uh "skepticism" a month from now as if he has a case
> of amnesia.

No such luck. :)

Your whole premise is ridiculous. You've spent an extraordinary amount 
of time pretending to prove a mirage.

jQuery's attr() and prop() methods are not constructed in the manner you 
would have - you make that clear every couple days. Virtually nothing in 
jQuery has been done in a manner you find acceptable. You've made that 
clear virtually daily, in one venue or another, for the past *five* years.

Yet now you claim that the jQuery team is secretly following your, 
err... 'suggestions'. This despite the fact for five years they've 
disregarded the overwhelming majority of things you've said, and those 
few instances where they've revisited things you've (correctly) 
screeched should be revisited, and should be revisited (incorrectly) 
immediately, these few instances occur literally years after the fact. 
And yet, somehow, you seem to really believe your input has a real 
bearing in their design process.

You don't think they're making these fixes because *it's how the DOM 
actually works* and low-priority bugs with backwards compatibility 
concerns to an a user base in the hundreds of thousands and tens of 
millions of websites can take time to fix. But rather you claim they're 
*really* making these changes because you're telling them too but they 
don't really want to though they know they should, so they hold off 
until you finally embarrass them into making the changes you're calling 
behind the scenes.

It's freaking crazy man.
0
Reply anon (312) 9/20/2012 5:41:24 PM

On Thursday, September 20, 2012 1:41:08 PM UTC-4, S.T. wrote:
> On 9/19/2012 10:17 PM, David Mark wrote:
>=20
> > Now, if history holds, "S.T." will shut up at this point and then pop
>=20
> > up to voice his, uh "skepticism" a month from now as if he has a case
>=20
> > of amnesia.
>=20
>=20
>=20
> No such luck. :)
>=20
>=20
>=20
> Your whole premise is ridiculous. You've spent an extraordinary amount=20
>=20
> of time pretending to prove a mirage.

If you say so.

>=20
>=20
>=20
> jQuery's attr() and prop() methods are not constructed in the manner you=
=20
>=20
> would have - you make that clear every couple days.

No, they clearly tried to take my advice, but predictably botched the job.

> Virtually nothing in=20
>=20
> jQuery has been done in a manner you find acceptable.

That's the first true statement you've made in this thread.

> You've made that=20
>=20
> clear virtually daily, in one venue or another, for the past *five* years=
..

Again, if you say so. :)

>=20
>=20
>=20
> Yet now you claim that the jQuery team is secretly following your,=20
>=20
> err... 'suggestions'.

It's clearly no secret (see links).

[snip redundant blithering]


>=20
>=20
>=20
> You don't think they're making these fixes because *it's how the DOM=20
>=20
> actually works*

WRT to "attr", it should be clear who showed them how the "DOM actually wor=
ks" (among other things).

> and low-priority bugs with backwards compatibility=20
>=20
> concerns to an a user base in the hundreds of thousands and tens of=20
>=20
> millions of websites can take time to fix.

You simply aren't paying attention. For one, "attr" is part of their founda=
tion and used by virtually every jQuery script out there. So not a low prio=
rity. And two, the extant "attr" is not consistent, even in the browsers th=
ey claim to support. And finally, as I've recommended repeatedly, they just=
 needed to deprecate (and eventually remove) that method. They could have d=
one that five years ago and certainly had serviceable methods by now. Unfor=
tunately, they aren't paying close attention either.

[more blithering]

>=20
>=20
>=20
> It's freaking crazy man.

Dave's not here, man. Go away. :)
0
Reply dmark.cinsoft (347) 9/20/2012 6:00:29 PM

On Thu, 20 Sep 2012 at 10:41:30, in comp.lang.javascript, S.T. wrote:
>On 9/19/2012 10:17 PM, David Mark wrote:

  <snip>
>Yet now you claim that the jQuery team is secretly following your,
>err... 'suggestions'. This despite the fact for five years they've
>disregarded the overwhelming majority of things you've said, and those
>few instances where they've revisited things you've (correctly)
>screeched should be revisited, and should be revisited (incorrectly)
>immediately, these few instances occur literally years after the fact.
>And yet, somehow, you seem to really believe your input has a real
>bearing in their design process.
  <snip>

Not only that, but when the JQuery people eventually admit that JQuery
is far too slow to load then *I* shall claim the credit for persuading
them.

Equally, when web designers admit that having different releases of
JQuery on the same web site is a maintenance disaster then I shall claim
the credit for making them aware of this.

  John
-- 
John Harris
0
Reply john2010 (326) 9/21/2012 8:19:00 AM

On Sep 21, 4:19=A0am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Thu, 20 Sep 2012 at 10:41:30, in comp.lang.javascript, S.T. wrote:
> >On 9/19/2012 10:17 PM, David Mark wrote:
>
> =A0 <snip>>Yet now you claim that the jQuery team is secretly following y=
our,
> >err... 'suggestions'. This despite the fact for five years they've
> >disregarded the overwhelming majority of things you've said, and those
> >few instances where they've revisited things you've (correctly)
> >screeched should be revisited, and should be revisited (incorrectly)
> >immediately, these few instances occur literally years after the fact.
> >And yet, somehow, you seem to really believe your input has a real
> >bearing in their design process.
>
> =A0 <snip>
>
> Not only that, but when the JQuery people eventually admit that JQuery
> is far too slow to load then *I* shall claim the credit for persuading
> them.

Have you mentioned that to them? You might have company there. :)

Anyway, I don't really persuade, I make the issues so public that they
have no choice but to confront them. Though I suppose the blatant
feature testing ripoffs were a matter of "persuasion" (followed by
plagiarism). That one didn't take "literally years" to happen. :(

>
> Equally, when web designers admit that having different releases of
> JQuery on the same web site is a maintenance disaster then I shall claim
> the credit for making them aware of this.
>

Hard to believe anyone would do that (though I've seen it on
occasion). Just goes to show that some designers are completely
oblivious to the ramifications of pasting in random scripts.
0
Reply dmark.cinsoft (347) 9/21/2012 1:29:12 PM

On Sep 21, 2:29=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 21, 4:19=A0am, John G Harris <j...@nospam.demon.co.uk> wrote:
> > Equally, when web designers admit that having different releases of
> > JQuery on the same web site is a maintenance disaster then I shall clai=
m
> > the credit for making them aware of this.
>
> Hard to believe anyone would do that (though I've seen it on
> occasion). Just goes to show that some designers are completely
> oblivious to the ramifications of pasting in random scripts.

I have experienced that also. It wasn't the nicest mess to clear up :(
0
Reply adambsilver (10) 9/21/2012 2:08:48 PM
comp.lang.javascript 37858 articles. 16 followers. Post

30 Replies
206 Views

Similar Articles

[PageSpeed] 2


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

Confused about properties, descriptors, and attributes...
I've been reading about Python Classes, and I'm a little confused about how Python stores the state of an object. I was hoping for some help. I realize that you can't create an empty place holder for a member variable of a Python object. It has to be given a value when defined, or set within a method. But what is the difference between an Attribute of a Class, a Descriptor in a Class, and a Property in a Class? If I had a Monster Class, and I wanted to give each Monster a member variable called ScaryFactor, how would I define it? Does a Property simply provide methods that acces...

Property or Attribute?
Howdy all! When do I call something a property and when do I call something an attribute? It has me a little confused at the moment! Any advice would be most appreciated! Rob :) Howdy David! > > When do I call something a property > > When its CSS. So I can say that the visibility property can be set to visible or invisible.. > > and when do I call something an attribute? > > When its HTML or XML. And I can talk about the SELECTED attribute of a CHECK BOX.. What about in JavaScript? Should I say a SELECT element has OPTION child elements or properties.. and...

Still confused
I'm not a db expert but have managed to get around Paradox over the years. I can't seem to get a handle on FMP 6. It seems different not in a bad way but it makes it hard for me to understand.... Any recommend books or how about the tutrial sogtware available on the net? Thanks Terry "The Book of FileMaker 6" by Chris Kubica ISBN 1-886411-81-6 which includes a reference CD. Best all encompassing book I've seen. If you can do Paradox, you can do more with FileMaker. Thanks. I really like the program. I'll check out the book Terry "cbvid" <cbvid@net...

XSLT: Confusion over adding attributes with xml:element and xml:attribute
Hi there. I am working with lom metadata and I am a little confused with how to form the following xml element: <lom xmlns="http://www.imsglobal.org/xsd/imsmd_v1p2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 imsmd_v1p2p2.xsd"/> I have the following so far: <xsl:element name="lom"> <xsl:attribute namespace="xmlns" name="xsi">http://www.w3.org/2001/XMLSchema-instance</xsl:attribute> <xsl:apply-templates/> </...

Property confusion
Hi ! I don't understand something: See that code: class A(object): __slots__=('x','a','__v') def __init__(self): self.__v=0 def g(self): print "g" return self.__v def s(self,v): self.__v=v print "s" GS=property(g,s) a=A() print a.g() a.s(1) print a.g() #print a.GS a.GS=2 print a.GS print a.g() It is working. But when we remove slots, it is missing: the a.GS is not used as property, it is access a local member. Why ? class A(object): def __init__(self): ...

Still the confusion is there ....
hi, can any one please let me know whats the clear and stratight difference between the most commonly used terms "SDK", "API", and "Library" ..... Regards, Omer "Madni" <omermadni@gmail.com> wrote in message news:1165379626.176777.268350@j44g2000cwa.googlegroups.com... > hi, > can any one please let me know whats the clear and stratight difference > between the most commonly used terms "SDK", "API", and "Library" ..... > Regards, > Omer SDK is "Software Development Kit". This is just somet...

Confusion is still there ....
hi, can any one please let me know whats the clear and stratight difference between the most commonly used terms "SDK", "API", and "Library" ..... Regards, Omer API- Application Programming Interface It's nothing but a windows functions acts beween Application n OS. SDK - Software Developement Kit It's set of Win32 API's used to develop Apps. Later MFC came into the picture where SDK API's are grouped and orgaised into classes. Library Dll is referred as library..as a short name. -Rajan Madni wrote: &g...

Newbie confusion: syntax check returns "unknown attribute" for a required element attribute
Hi all! I am currently studying HTML. I use SELFHTML 8.0 as my guide, and Quanta 3.1.2 as my web authoring tool (under SuSE Linux 8.2). Today I have done a little exercise that contains a small portion of javascript and a form in a single page, defined as DTD "HTML 4.01 Strict". I am interested in learning to produce my HTML as clean as possible, so I got curious about the syntax check that Quanta offers, and ran it against my little exercise. The outcome was rather confusing to me: "unknown attribute "TYPE" for element <script>" The lin...

Attributes VS Properties
This is probably stupid question (Thomas, you can skip it :) ), but I have to ask it ... :) I think I don't really understand attributes and properties ... and their difference, probably because their meaning is very similar (if not the same) when I translate them on my native language. In some way, I can understand difference in general, but can someone explain them to me in the world of HTML & JS ... what is attribute, what is property and what is(are) their difference(s)? I've found some online resources, but the explanation is very poor. :( I'm asking...

Attributes, properties and XHTML
Seems there is some confusion out there (okay a lot of confusion) regarding XHTML documents, properties and attributes. http://groups.google.com/group/comp.lang.javascript/msg/6bd058312099893a The root of the confusion is jQuery (of course.) Forgetting about that miserable, confusing script for a moment, if you are really crazy enough to server XHTML (as XHTML), know these generalizations: 1. XHTML DOM's expose the same properties as HTML DOM's (plus more) and they work in the same way. 2. The get/set/removeAttribute methods work the same as well 3. Just as get/set/removeAtttr...

Re: Property confusion
Peter wrote: >>>>> kepes.krisztian wrote: [Same old question under a new subject] If you don't receive an answer within a reasonable time span you should consider rephrasing the problem, not just the header. I tried the code you gave and could not perceive any difference in the output of the two snippets. Maybe you can post an interactive session with just the statements that produce different output? Or you rename one class, to B, say, and add an assertion you expect to succeed but which fails, e. g.: class A(object):...

class attribute confusion
Hi, i was having a problem with class attributes initiated outside of __init__. This code is a demonstration of what i mean: class A(): mylist = [] def __init__(self): self.mylist.append(1) pass class B(A): def __init__(self): A.__init__(self) self.mylist.append(2) v = A() print 'v:',v.mylist x = B() print 'x:',x.mylist y = B() print 'y:',y.mylist z = A() print 'z:',z.mylist print 'v:',v.mylist I would expect the following result: v: [1] x: [1, 2] y: [1, 2] z: [1] v...

structures still confusing
Hi Gurus, finally something, where I don't know, if it's odd idl syntax or not... something about structures. FUNCTION test_struct s = [{ m : [1L, 2L, 3L], n :1L }] FOR i = 1L, 2L DO BEGIN ; s = [s, { m : [1L, 2L, 3L], n : i }] ; ENDFOR return, s END this creates an array of structures: (X). s = test_struct() (X). help,/struct,s ** Structure <fa330>, 2 tags, length=16, data length=16, refs=1: M LONG Array[3] N LONG 1 (X). print, n_elements(s) 3...

Still a bit confused
A few people have been asking about variants of this recently, and I'm still not totally clear. A class Base declares, amongst other things, a method called func(). Because derived classes might replace this with their own implementation, func is declared as virtual in Base: // header class Base { public: virtual int func(int arg1); } Because not all derived classes will wish to provide their own implementation, Base provides a default one: int Base::func(int arg1) { ...... } This particular derived class in fact does not replace func(): class Derived : public Base { ...... } In...

property confusion #2
Could someone please explain to me why the two values at the bottom of this example are different? Python-3.3 if it makes any difference. Is this a difference in evaluation between a class attribute and an instance attribute? --rich class C: def __init__(self): self._x = None def getx(self): print('getx') return self._x def setx(self, value): print('setx') self._x = value def delx(self): print('delx') del self._x x = property(getx, setx, delx, "I...

Confusion about __call__ and attribute lookup
I am learning about metaclasses and there is something that confuses me. I understand that if I define a __call__ method for a class, then instances of the class become callable using function syntax: >>> class Foo(object): ... def __call__(self): ... print 'Called Foo' ... >>> f=Foo() >>> f() Called Foo To create a class instance, you call the class. This made me think that the class' class must define __call__, and indeed it does, and calling it as an unbound method also creates a class instance: >>> dir(type) [..., '__call...

attributes, properties, and accessors -- philosophy
The problem I have with properties is my typing. I'll end up assigning to an attribute, but get the spelling slightly wrong (capitalized, or missing an underscore -- non-obvious things when bug-hunting), so now I have an extra attribute which of course has zero effect on what I'm trying to do and I start getting wierd results like viewing deleted records when I *know* I set useDeleted = False... 30 minutes later I notice it was /supposed/ to be use_deleted. *sigh* So -- to keep myself out of trouble -- I have started coding such things as, for example: result = ta...

jQuery--still loopy after all these years
Was recently asked to review jQuery (yet again) as there is some myth going around that they've "finally got it right". Of course, as has been noted since its inception, there's no salvaging its inherently flawed design (conceived by a neophyte in 2006). The idea that it (or the like) will be "stable some day" has always been an excuse to put obviously bad code into production (i.e. take the money and run). /*! * jQuery JavaScript Library vPulled Live From Git * http://jquery.com/ * * Copyright 2010, John Resig * Dual licensed under the MIT or GP...

Defining a property with the DontEnum attribute
All -- I'm trying to solve a problem for which I think the solution will be to *cheat*; but I don't mind doing so for this case. The background is: Given an object constructor, and an instance SampleObj = function() { this.prop = 1; } obj = new SampleObj(); obj has one enumerable property: 'prop'; and several builtin, non-enumerable properties as well: 'toString', 'hasOwnProperty', 'propertyIsEnumerable', etc. If I redefined any of those, e.g: SampleObj.prototype.toString = function() {return '[SampleObj]'}; ...

I'm still confused...
How do neural networks work? Could someone please show me a simple example of a NN doing something like... representing an OR operator? Like this: 0,0,0 = 0 1,0,0 = 1 0,1,1 = 1 1,1,1 = 1 0,0,1 = 1 I am better at learning by example. My book search at local book stores has come up short, but I'll look for better ones eventually. On Fri, 23 Dec 2005 10:19:33 -0700, "Jordan Tiona" <torahteen@comcast.net> wrote: >How do neural networks work? Could someone please show me a simple example >of a NN doing something like... representing an OR operator? Like this: >...

Still confused about window adjust :-(
If I read the standard correctly (RFC 4254, section 5.2) the only data that counts for windowing purposes is the data string in SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets. However, the packet itself is of course bigger than that, for it includes the header (packet length, padding length, packet id and recipient channel fields, for SSH_MSG_CHANNEL_DATA packets) plus padding and HMAC. So imagine that we have an SSH_MSG_CHANNEL_DATA packet whose total length is L, whereas the length of the data string that it carries is D, with D < L. Let's assume that the cur...

plot markersize property confuses me
Hi, I would like to create a plot with a markersize between 1 and 2 but notice that the markersize only seems to adopt integer values even if I request noninteger values. Does anyone know how this works? Is there a way to get the 'inbetween' values I am looking for? Thanks, J % markersize 1 is too small (just a single point) plot(1:5,'o-','markersize',1) % markersize 2 is too big plot(1:5,'o-','markersize',2) % markersize 1.5 is the same as 2 plot(1:5,'o-','markersize',1.5) % markersize 1.49 is the same a...

Apple Mail still confused.
With 3 IMAP accounts and 3 POP accounts, Apple Mail still can't handle the load and either asks for passwords continually or can't connect to various servers. But hey, eye candy and feature creep is more important. On a more positive note, TB works just fine. In article <ju62ko$vug$3@speranza.aioe.org>, Nashton <nana@na.ca> wrote: > With 3 IMAP accounts and 3 POP accounts, Apple Mail still can't handle > the load and either asks for passwords continually or can't connect to > various servers. Of course it can't... LOL >...

confused about incompatible plot properties
I am new at Matlab. I am finding that when I use the plot() command with a list of properties following the x and y variables, some properties stop working once I add other properties. For example, let's say I start with the following line: plot(dataClust(clu1==i,xaxisIndex),dataClust(clu1==i,yaxisIndex),'MarkerFaceColor',plotcolor{i}) if I add the property 'Marker','*', MarkerFaceColor is now rejected. I have to add the 'Color' property. Also, now lines are drawn between the markers while they were not before, and I have to find a new property ...