Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!news.internetdienste.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Content-Type: text/plain; charset="UTF-8"
Message-ID: <4411003.FLlSE2plY9@PointedEars.de>
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Reply-To: Thomas 'PointedEars' Lahn <cljs@PointedEars.de>
Organization: PointedEars Software (PES)
Date: Sat, 21 Apr 2012 20:46:53 +0200
User-Agent: KNode/4.4.11
Content-Transfer-Encoding: 8Bit
Subject: Re: jquery ,get the id of the input in order to delete input row?
Newsgroups: comp.lang.javascript
References: <94ebf0a1-856f-4357-b689-2622f641bb10@h10g2000pbi.googlegroups.com> <jmup6f$ihr$1@dont-email.me>
Followup-To: comp.lang.javascript
MIME-Version: 1.0
Lines: 135
NNTP-Posting-Date: 21 Apr 2012 20:46:54 CEST
NNTP-Posting-Host: cefd6089.newsspool4.arcor-online.net
X-Trace: DXC=W2Q:<?CKAlX@@RW1FjIB5S4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[EUNnbbFTL3RDZm8W4\YJN\J`:FmdeL>KPfQ>EOE\[m`[G8E?GZPWfBZ
X-Complaints-To: usenet-abuse@arcor.de
Xref: csiph.com comp.lang.javascript:13510

Matt McDonald wrote:

> On 12-04-20 12:39 PM, JRough wrote:
>> $(function() {
>>                          $(".btnDelete").click(function() {
>>                          // get the id here
>>                          var $id =this.id;
>>
>>                           // POST...
>>
>>                          return false;
>>                          });
>>                      });
> 
> Though using jQuery is in itself inadvisable, I'd like to
> point out some flaws with the preceding snippet:
> 
> 1. Class "selectors" such as ".btnDelete" are tar pits
> speed-wise. Sizzle will recur the entire document tree
> looking for results; most often, that's undesirable. Hooking
> onto a common ancestor element via `document.getElementById`
> or other methods (such as `HTMLCollection`s) is much more
> reliable.

ACK.

> 2. Your "to-do" list is semantically invalid. `<ul>` elements
> *should* have strictly `<li>` elements as direct children[0].

(tl;dr the OP's code – who, I must say, is notorious in comp.ALL for their 
inability to write a proper program in any language and take given advice to 
heart –, so I am only commenting on what you wrote here.)

Loosely speaking, that would be *syntactically* invalid (semantics considers 
*meaning*) and *MUST* instead.  However, you need to differentiate between 
children and child elements.  You are talking about child elements.  
Children can be text nodes too, which, in a strict sense, made even the so 
corrected statement wrong (or at least imprecise, as there are circumstances 
where `ul' element nodes really should have only `li' element nodes as child 
nodes).

> I'd suggest encapsulating these "list items" (read: form controls)

List items are _not_ form controls.  They may contain form controls, though 
[1],

> in a form.

… and then it makes sense to have them as descendants (not: children) of a 
`form' _element_ [2], …

> Furthermore, hook onto that form and use a property
> such as `onclick`; this will facilitate event delegation
> (one event handler instead of an infinite amount). Using a form
> along with simple event delegation would be both semantically
> valid and grant massive speed gains

(again, _syntax_)

… so as to facilitate accessibility with the `onsubmit' event handler 
attribute [3] which cannot always be achieved with the `onclick' event 
handler attribute. 

> 4. I'd recommend avoiding the shorthand "document ready"
> hack (i.e. `$(function () { [code] });`). This pattern
> essentially involves passing a function to the jQuery
> "constructor"/god function. A massive jQuery object is
> returned (which "wraps" `document`)[1].

This "hack" is well-documented, though. [4]  ISTM that it is preferred to 
all other jQuery-based approaches as it involves the least number of 
property lookups (CMIIW).

Objects are not returned, references to objects are.  Therefore it does not 
matter how (seemingly) large the object is whose reference is returned by a 
function, as long as the object is not created by that function, and 
especially if that object can be subject to garbage collection immediately 
after the function returned, as it is the case here.

What evidence do you have that an object is created on that call that is 
"massive"?

> The "document ready" non-problem can be avoided by placing `<script>` tags
> at the end of the `<body>` element right before its closing tag
> (e.g. `<script [...]></script></body>`).

There is insufficient evidence for that.  Code that relies on the document 
tree having been built should be run by the standard `load' event listener 
[5, 6] (since the DOMContentLoaded event is not ubiquitous by comparison 
[6]).  But jQuery interferes with that. [4]

> By taking that advice, you'll have weaned yourself off of
> jQuery and (should) be in complete control over your code.

That much is certain (if we ignore the OP's Usenet record).

> Another option would be to simply use
> `<button [...] type="button">`, which makes more sense
> outside of a form element as it does not alter a
> form upon "activation".

But its functionality also is not available without scripting.  Consider a 
`form' element with <button … type="submit">…</button> instead then (and 
note that the `button' element type has a *non-EMPTY* content model). [7]

> ¹ I use the term "implementer" instead of "developer" as there
> is very little "development" taking place when leaning on jQuery
> to solve one's problems.

IMHO this does not fit [8]; "user" would be more appropriate term here, in 
this case in several regards [9].


PointedEars
___________
[1] <http://www.w3.org/TR/1999/REC-
html401-19991224/struct/lists.html#h-10.2>
[2] <http://www.w3.org/TR/1999/REC-
html401-19991224/interact/forms.html#edef-FORM>
[3] <http://www.w3.org/TR/1999/REC-
html401-19991224/interact/scripts.html#adef-onsubmit>
[4] <http://api.jquery.com/ready/>
[5] <http://www.w3.org/TR/2000/REC-DOM-Level-2-
Events-20001113/events.html#Events-eventgroupings-htmlevents>
[6] 
<https://developer.mozilla.org/en/DOM/DOM_event_reference/DOMContentLoaded>
[7] <http://www.w3.org/TR/1999/REC-
html401-19991224/interact/forms.html#edef-BUTTON>
[8] <http://www.thefreedictionary.com/implementor>
[9] <http://www.thefreedictionary.com/user>
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16