Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #13471 > unrolled thread

jquery ,get the id of the input in order to delete input row?

Back to article view | Back to comp.lang.javascript

Contents

  jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-20 11:39 -0700
    Re: jquery ,get the id of the input in order to delete input row? Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-21 01:23 +0000
      Re: jquery ,get the id of the input in order to delete input row? Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-21 02:18 +0000
        Re: jquery ,get the id of the input in order to delete input row? Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-21 07:31 +0200
          Re: jquery ,get the id of the input in order to delete input row? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-04-21 06:09 +0000
            Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-22 09:52 -0700
              Re: jquery ,get the id of the input in order to delete input row? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-04-23 10:32 +0000
            Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-22 12:53 -0700
            Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-22 13:03 -0700
            Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-05-04 13:16 -0700
        Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-22 09:50 -0700
          Re: jquery ,get the id of the input in order to delete input row? Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-23 02:10 +0000
          Re: jquery ,get the id of the input in order to delete input row? John G Harris <john@nospam.demon.co.uk> - 2012-04-23 15:10 +0100
            Re: jquery ,get the id of the input in order to delete input row? Barry Margolin <barmar@alum.mit.edu> - 2012-04-25 21:39 -0400
              Re: jquery ,get the id of the input in order to delete input row? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-26 04:35 +0200
                Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 15:49 +1000
                  ECMAScript Support Matrix (was: jquery ,get the id of the input in order to delete input row?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-26 10:01 +0200
                    Re: ECMAScript Support Matrix Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 18:41 +1000
                      Re: ECMAScript Support Matrix Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-26 11:06 +0200
                        Re: ECMAScript Support Matrix Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 20:41 +1000
              Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 12:38 +1000
                Re: jquery ,get the id of the input in order to delete input row? Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-04-26 09:01 +0300
                  Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 16:16 +1000
                    Re: jquery ,get the id of the input in order to delete input row? Barry Margolin <barmar@alum.mit.edu> - 2012-04-26 06:52 -0400
                      Re: jquery ,get the id of the input in order to delete input row? John G Harris <john@nospam.demon.co.uk> - 2012-04-26 16:30 +0100
                Re: jquery ,get the id of the input in order to delete input row? Barry Margolin <barmar@alum.mit.edu> - 2012-04-26 06:30 -0400
                  Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-26 20:44 +1000
                    Re: jquery ,get the id of the input in order to delete input row? Barry Margolin <barmar@alum.mit.edu> - 2012-04-26 08:34 -0400
                      Re: jquery ,get the id of the input in order to delete input row? John G Harris <john@nospam.demon.co.uk> - 2012-04-26 16:49 +0100
                      Re: jquery ,get the id of the input in order to delete input row? Gregor Kofler <usenet@gregorkofler.com> - 2012-04-26 18:08 +0200
                        Re: jquery ,get the id of the input in order to delete input row? Scott Sauyet <scott.sauyet@gmail.com> - 2012-04-27 13:29 -0700
                          Re: jquery ,get the id of the input in order to delete input row? Gregor Kofler <usenet@gregorkofler.com> - 2012-04-28 00:15 +0200
                        Re: jquery ,get the id of the input in order to delete input row? Dr J R Stockton <reply1217@merlyn.demon.co.uk.not.invalid> - 2012-04-27 21:41 +0100
                      Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-27 07:55 +1000
                      Re: jquery ,get the id of the input in order to delete input row? Matt McDonald <matt@fortybelow.ca> - 2012-04-26 22:23 -0600
                        Re: jquery ,get the id of the input in order to delete input row? Gregor Kofler <usenet@gregorkofler.com> - 2012-04-27 11:40 +0200
                        Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-27 20:05 +1000
                          Re: jquery ,get the id of the input in order to delete input row? "S.T." <anon@anon.com> - 2012-04-27 14:32 -0700
                            Re: jquery ,get the id of the input in order to delete input row? Andrew Poulos <ap_prog@hotmail.com> - 2012-04-28 16:03 +1000
                              Re: jquery ,get the id of the input in order to delete input row? David Mark <dmark.cinsoft@gmail.com> - 2012-07-05 19:52 -0700
                                Re: jquery ,get the id of the input in order to delete input row? David Mark <dmark.cinsoft@gmail.com> - 2012-07-06 00:53 -0700
                                Re: jquery ,get the id of the input in order to delete input row? "S.T." <anon@anon.com> - 2012-07-10 13:53 -0700
                                  Re: jquery ,get the id of the input in order to delete input row? Matt McDonald <matt@fortybelow.ca> - 2012-07-10 18:32 -0600
                                    Re: jquery ,get the id of the input in order to delete input row? "S.T." <anon@anon.com> - 2012-07-11 10:51 -0700
                            Re: jquery ,get the id of the input in order to delete input row? Gregor Kofler <usenet@gregorkofler.com> - 2012-04-28 17:41 +0200
                              Re: jquery ,get the id of the input in order to delete input row? "S.T." <anon@anon.com> - 2012-04-28 13:15 -0700
                                Re: jquery ,get the id of the input in order to delete input row? Gregor Kofler <usenet@gregorkofler.com> - 2012-04-28 22:45 +0200
      Re: jquery ,get the id of the input in order to delete input row? Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-21 14:28 +0000
        Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-29 15:02 -0700
      Re: jquery ,get the id of the input in order to delete input row? JRough <janis.rough@gmail.com> - 2012-04-22 12:34 -0700
    Re: jquery ,get the id of the input in order to delete input row? Matt McDonald <matt@fortybelow.ca> - 2012-04-21 11:02 -0600
      Re: jquery ,get the id of the input in order to delete input row? Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-21 17:12 +0000
        Re: jquery ,get the id of the input in order to delete input row? Matt McDonald <matt@fortybelow.ca> - 2012-04-21 11:37 -0600
          Re: jquery ,get the id of the input in order to delete input row? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-21 20:59 +0200
      Re: jquery ,get the id of the input in order to delete input row? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-21 20:46 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#14897

On Thursday, July 5, 2012 10:52:23 PM UTC-4, David Mark wrote:

> If they do "work", they do so very slowly.  Best not to send them.

I should add that it doesn't really matter if jQuery UI demos appear to "work" in a handful of mobile devices as developers in their right mind wouldn't send all of that crap to a phone (and since you don't know in advance if it is a phone...)

And the punchline is that one of the many files included with that distribution is a "CSS Reset".  For the uninitiated, imagine a painted wall missing a few flecks and randomly flinging buckets of paint everywhere to cover these imperfections.  In short, they try to stamp out all of the agent and user style preferences.  Virtually anybody can write widgets that at least look similar in such flattened environments, but it just isn't practical to indiscriminately nuke every default style (and then presumably attempt to put them all back "better").  Absurdly, this is a very popular "best practice" among Web developers going back several years (but it's exponentially more absurd today).

Of course, there's a reason that agents provide their own defaults.  The people that write the browsers and manufacture the devices think long and hard to come up with appropriate "baseline" styles and users have their own reasons for fiddling with them.  Then along comes jQuery UI (or Dojo or YUI or whatever) and all of those considerations go out the window in the name of creating demos that look "exactly the same" in "all browsers".  Tada!  :(

The reality these days is you often need multiple style sheets (controlled by media queries) to accommodate the wide variety of user agent/device/configuration combinations.  Widgets like date pickers, auto-completes, etc. may turn out to be useless (at best) in some devices.  Anything that replaces a SELECT with an enhanced text input is going to be a downgrade on the tiny screens.  Best to avoid such things completely unless you know exactly what you are doing.  They need to either work competently or get out of the way; the problems come when they work halfway and break what they were meant to enhance.

As for the script end of it, anything that constantly breaks down (e.g. jQuery *, Dojo, Ext JS, etc.) in the face of new environments, no matter how "pretty" or involved their widgets may be, is junk.  Anything that makes you choose between a "standard" and "touch" version is out of the question as well.  And anything that is not *cross-browser* isn't worth considering in the first place.  Just start reading the script(s) until you hit the first bogus, observation-based assumption about host objects or major language-related red flag (it never takes long) and then throw them away.  Why buy trouble (pretty or not?)

Finally, if you like the shiny widgets (and who doesn't?!), save their graphics.  If the client is sure they want something that looks like slider XYZ, it's because they like the graphics (and are likely oblivious to the dubious nature of the accompanying scripts and style sheets).

[toc] | [prev] | [next] | [standalone]

#15008

On 7/5/2012 7:52 PM, David Mark wrote:
> On Saturday, April 28, 2012 2:03:58 AM UTC-4, Andrew Poulos wrote:
>> On 28/04/2012 7:32 AM, S.T. wrote:
>>> On 4/27/2012 3:05 AM, Andrew Poulos wrote:
>>
>>> If you're going to do any "fancy" type UI you have to test and adjust
>>> for new browsers, period. Those guys didn't - can't blame jQuery on
>>> that. You simply can't put up scripts that do a bunch of crap to the DOM
>>> and forget about it, just assuming it will continue work. That applies
>>> whether using a library or not.
>>>
>>> Take Chrome for Android, for instance. Try it on the vxweb.net library
>>> site seen around here and the calendar widget doesn't work correctly and
>>> the Dual Select widget is completely busted, that's out of about five
>>
>> Though it does work fine in IE 9.
>>
>>> demos I tried. Try it on David Mark's library and, even given the simple
>>> nature of the few demos on his site, failures abound.
>
> Pfft. He knows damned well that the fixed positioning in a couple of the more over-the-top examples don't translate well to the small screen.

a. The failures and issues on Chrome for Android extended beyond janky 
position:fixed stuff.
b. 8" 1280x800 isn't really that small a screen.
c. Your "over-the-top examples" are quite primitive.

>
> Funny, I can replicate a whole Explorer-shell like interface by pushing buttons.  Sidebars, toast popups, dialogs, etc.

You can't replicate it reliably cross-browser. Seen that first-hand.

 > It's had audio long before HTML5 (and of course those demos do 
nothing on Androids).

Well there's an in-demand feature. Make sure to add a <blink> tag 
emulator as well. And some MIDI background music for when my sites go 
out for Halloween dressed as MySpace circa 2002.

>>
>> I think you're exaggerating.
>
> Or very confused about the nature of these things.  He (she?) always looks at widget demos to determine whether a JS library "works". :(

You have no other demos to work with. I'd love to see some decent-sized 
web app UI powered by My Library. Sadly, none exists to see how it 
performs in various environments. All I'm left with are a couple sparse 
widgety-type examples.

>>
>> While the jquery demos I looked at "worked" I wouldn't say they worked well.
>
> Nothing with jQuery works well on battery-powered mobile devices.  It's just too damned slow and bloated for those sorts of environments.  That's why they finally threw in the towel on IE 8- (and compatibility modes).

Haven't seen performance issues with jQuery on mobile. Even on a 2nd 
generation iPhone (2008'ish) or 2009'ish Android running 2.2. jQuery UI 
is bloaty on desktops already, and though it's not ideal for mobile, 
still works well enough in the short-term. Just barely though.

>>
>>> If those two can't reliably put out a future'ish proof UI widgets, and
>>> given their knowledge of JS exceeds mine by a factor of 10 or so, I'm
>>> fairly certain the solution to my needs is *not* writing these UI
>>> elements myself. Safe to say I'll use a library and stay up to date on
>>> the site. And if I can't stay up to date for some reason, I probably
>>> won't incorporate "widgets" or other complicated JS.
>
> As if there is any way for this developer to know when he needs to "stay up to date". :)

It's not too hard. An inherent advantage of a large community.

>>>
>>> And with no offense to Gregor (but fine if it offends David Mark - he's
>>> an asshat), if I'm going to use a library I'll lean towards one with a
>>
>> Why is it bad to a hat on an ass?
>
> I don't know where that word comes from either.

http://www.urbandictionary.com/define.php?term=ass-hat

>>
>> Good luck.
>>
>>> As a footnote, ran through the jQueryUI demos with Chrome for Android
>>> and didn't notice any failures. Not saying none exist, but didn't see any.
>
> Well, if they didn't see any "failures", that's good enough for me. :)

I will credit My Library for failing in exceedingly obvious ways.

[toc] | [prev] | [next] | [standalone]

#15013

On 12-07-10 02:53 PM, S.T. wrote:

> Haven't seen performance issues with jQuery on mobile. Even on a 2nd
> generation iPhone (2008'ish) or 2009'ish Android running 2.2.

Browse a jQuerified site with no default mobile interface like
GitHub or Reddit on a mobile device. Then disable JavaScript,
and try again. I cut load time in half on an iPod Touch by doing
just that (20s to 10s for GitHub). Furthermore, try interacting
with those pages over an extended period. Watch the device's
battery life drain alarmingly quickly.

The jQuery API is simply too slow for any sane (mobile) user.
Its poor design and mountains of misconceptions enable developers
to write poor, incorrect code in record time.

250kB of mandatory code (obfuscated or not) is a big issue.
That's approaching the Sencha (ExtJS) echelon of insanity.
Tossing that to a mobile device to chew on is lunacy.
Requiring that API on top of another giant wall of text
(jQuery Mobile) is homicidal towards mobile devices.

Keep in mind that obfuscated scripts (gZip et al.) need to
be decoded by the browser (as per HTTP/1.1) just to run.
GZipping isn't free.

Just for the record, pasting the latest "production" version
of jQuery into a text editor and saving it yields a 94kB file,
and not the "32kB" marketed (since the browser is required to
perform the compression). Pull off the GZip robe, and a
disturbingly obese script remains.

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#15019

On 7/10/2012 5:32 PM, Matt McDonald wrote:
> On 12-07-10 02:53 PM, S.T. wrote:
>
>> Haven't seen performance issues with jQuery on mobile. Even on a 2nd
>> generation iPhone (2008'ish) or 2009'ish Android running 2.2.
>
> Browse a jQuerified site with no default mobile interface like
> GitHub or Reddit on a mobile device. Then disable JavaScript,
> and try again. I cut load time in half on an iPod Touch by doing
> just that (20s to 10s for GitHub). Furthermore, try interacting
> with those pages over an extended period. Watch the device's
> battery life drain alarmingly quickly.

You sure it's jQuery and not just what JS functionality they're doing, 
native code or not?

I see no effectively no difference on Reddit with or w/o JS enabled. 
Github is slower, that appears to be the result of some painfully slow 
XHR responses related to logging browser/user info 
(http://i.imgur.com/Jalmg.png) This slowdown seems more server-side.

Tried a test page with <span lang='test'>OK</span> x 500

Cleared cache. Called in newest jQuery off Google's CDN. At the top of 
the doc, using jQuery $(document).ready(), I added some grossly 
inefficient code:

​$("span[lang='test']").css("color","yellow");
$("span[lang='test']").click(function () {alert("ok");});
$("span[lang='test']").css("background-color","black");​

Load time difference was barely perceptible.

With a more efficient:

var spans = $("span");
spans
     .css({"color":"yellow","background-color":"black"})
     .click(function(){alert("ok");})​

... I saw no visible difference.

That's not to say I believe jQuery is entirely efficient, particularly 
in the mobile setting. Clearly there's a ton of overhead relating to 
IE6/7 and hordes of unused methods in any given project that could be 
trimmed to make a much leaner script. But in real-world usage I simply 
don't see the effects of jQuery's bloat. At least with what I typically 
browse on and have on me at the moment, a relatively high-end phone.

I see lots of slowdowns in mobile relating to heavy XHR, operations that 
cause canvas repaints and so on but that's not jQuery specific.

[toc] | [prev] | [next] | [standalone]

#13672

Am 2012-04-27 23:32, S.T. meinte:

> Take Chrome for Android, for instance. Try it on the vxweb.net library
> site seen around here and the calendar widget doesn't work correctly and
> the Dual Select widget is completely busted

Are we talking about *Chrome* for Android (which is beta, and which I 
haven't tested so far, since Google Play doesn't list it on my mobile 
device)?

If not: With the Android browser the calendar widget works well - it 
seems that the "click" areas of the widget are somewhat off. The Dual 
Select widget *might* work, too, but the Android browser has its fair 
share of CSS issues, since it doesn't even display the un-"enhanced" 
select element properly. Well, the Android browser doesn't pass the 
ACID2 test either.

> If those two can't reliably put out a future'ish proof UI widgets, and
> given their knowledge of JS exceeds mine by a factor of 10 or so, I'm
> fairly certain the solution to my needs is *not* writing these UI
> elements myself. Safe to say I'll use a library and stay up to date on
> the site. And if I can't stay up to date for some reason, I probably
> won't incorporate "widgets" or other complicated JS.
>
> And with no offense to Gregor

None taken.

> (but fine if it offends David Mark - he's
> an asshat), if I'm going to use a library I'll lean towards one with a
> massive user base that's able to find and fix these odd bugs quickly, or
> at least have obscure issues documented somewhere on the web.
>
> As a footnote, ran through the jQueryUI demos with Chrome for Android
> and didn't notice any failures. Not saying none exist, but didn't see any.

I'm actually quite pleased with my scripts - they have then swallowed 
IE9 without further complications, and on the mobile platforms the main 
problems stem from the different form of user interaction (and a 
complete change of UI paradigm *is* impossible to anticipate). For 
example the slider widget can be "clicked" into positions, but not 
dragged. And the tree widget always seems to capture the click event on 
the wrong level (doesn't occur with Opera Mobile). After all, all those 
libraries now have special "touch" editions.

Gregor

[toc] | [prev] | [next] | [standalone]

#13675

On 4/28/2012 8:41 AM, Gregor Kofler wrote:
> Am 2012-04-27 23:32, S.T. meinte:
>
>> Take Chrome for Android, for instance. Try it on the vxweb.net library
>> site seen around here and the calendar widget doesn't work correctly and
>> the Dual Select widget is completely busted
>
> Are we talking about *Chrome* for Android (which is beta, and which I
> haven't tested so far, since Google Play doesn't list it on my mobile
> device)?

Yeah, the Android version. Only runs on Android 4.0, which is maybe 2% 
of the Android base, so it's a pretty small pool right now. But updates 
are now rolling and Google's coming out with their own sub-$250 budget 
tablet in the next few months. Safe to say Chrome will be it's default 
so it could see a rapid user base. Something to keep an eye on, 
especially as IMHO Chrome is light year's ahead of most Android stock 
browsers and a few legs up on Opera/Dolphin/Firefox for Android.

Beta with Google is tricky to interpret. Gmail was in beta for five 
years and had 150 million users when they finally dropped the beta tag. 
What exists now may well be indicative of what Google pushes out to 
users for years.

> If not: With the Android browser the calendar widget works well - it
> seems that the "click" areas of the widget are somewhat off. The Dual
> Select widget *might* work, too, but the Android browser has its fair
> share of CSS issues, since it doesn't even display the un-"enhanced"
> select element properly. Well, the Android browser doesn't pass the
> ACID2 test either.

Here's screen caps if it helps.
- First is opening a calendar (fine)
- Second is what happens if clicking to change month and half the time a 
date, though sometimes selecting a date works. Just overlays a 
semi-transparent block and nothing occurs.
- Final is what the dual select looks like.
http://imgur.com/a/OmRiY

Calendar layout gets jacked up in IE9 in compatibility mode if you care 
(personally I don't fault any library/widget/etc that has issues in 
compatibility/transitional and don't think developers need waste their 
time)

>
> I'm actually quite pleased with my scripts - they have then swallowed
> IE9 without further complications, and on the mobile platforms the main
> problems stem from the different form of user interaction (and a
> complete change of UI paradigm *is* impossible to anticipate). For
> example the slider widget can be "clicked" into positions, but not
> dragged. And the tree widget always seems to capture the click event on
> the wrong level (doesn't occur with Opera Mobile). After all, all those
> libraries now have special "touch" editions.

Certainly not trying to disparage your library. Context it was brought 
up in is it's unreasonable to expect current libraries and UI widgets to 
handle any and all future browsers without issue. Only person I've ever 
heard claim something along those line was, well... not hard to guess 
who makes the biggest (and unsubstantiated) claims like that.

[toc] | [prev] | [next] | [standalone]

#13679

Am 2012-04-28 22:15, S.T. meinte:

> Here's screen caps if it helps.
> - First is opening a calendar (fine)
> - Second is what happens if clicking to change month and half the time a
> date, though sometimes selecting a date works. Just overlays a
> semi-transparent block and nothing occurs.
> - Final is what the dual select looks like.
> http://imgur.com/a/OmRiY

The dual select is particularly odd - seems as if the size attribute 
gets completely ignored. The "before" select comes with this markup and 
is not "tainted" via JS:

<select name="myOrdinarySelect" class="ml" size="10" multiple="multiple">
...

> Calendar layout gets jacked up in IE9 in compatibility mode if you care
> (personally I don't fault any library/widget/etc that has issues in
> compatibility/transitional and don't think developers need waste their
> time)

Could be. For one I don't care too much about the more obscure modes IE 
offers (I even don't care for quirks mode, since my pages never come in 
this mode), and I suppose this would be a CSS issue, and not a JS problem.

Gregor

[toc] | [prev] | [next] | [standalone]

#13479

On Sat, 21 Apr 2012 01:23:12 +0000, Denis McMahon wrote:

As usual, when looking over the code after it posted, I realised a couple 
of things that could have been done a bit better ...

> function deleteRow(button){
> var row,rows,rownum,elems,elnum,loop;
> rows=document.getElementById(containerId).getElementsByTagName(rowTag);
> rownum=rows.length;
> loop=true;
> while(rownum--){
> row=rows.item(rownum);
> elems=row.getElementsByTagName("*");

/*

The above line could probably be replaced with:

elems=row.getElementsByTagName("input");

which would probably make the code a bit more efficient, assuming the 
control we're looking for is specified with <input type="button" 
value="Delete" onclick="deleteRow(this);"> or the equivalent thereof.

*/

> elnum=elems.length;
> while(elnum--){
> if(elems.item(elnum)==button){
> loop=false;
> break;
> }
> }
> if(!loop)break;
> }

/* Here it should probably have something more like: */

if (!loop) {
> // "row" is the dom element of the row you wish to delete 
> // "elems" is elements within row
}
else {
// didn't find a row containing button in container
}

> }

I noticed that I wasn't trapping the situation where the button element 
was not found within any of the rows in the collection inside container. 
Fortunately the flag used for the 2nd level break out of the while loop 
can also be used to detect successful location of the row being sought.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#13697

On Apr 21, 7:28 am, Denis McMahon <denismfmcma...@gmail.com> wrote:
> On Sat, 21 Apr 2012 01:23:12 +0000, Denis McMahon wrote:
>
> As usual, when looking over the code after it posted, I realised a couple
> of things that could have been done a bit better ...
>
> > function deleteRow(button){
> > var row,rows,rownum,elems,elnum,loop;
> > rows=document.getElementById(containerId).getElementsByTagName(rowTag);
> > rownum=rows.length;
> > loop=true;
> > while(rownum--){
> > row=rows.item(rownum);
> > elems=row.getElementsByTagName("*");
>
> /*
>
> The above line could probably be replaced with:
>
> elems=row.getElementsByTagName("input");
>
> which would probably make the code a bit more efficient, assuming the
> control we're looking for is specified with <input type="button"
> value="Delete" onclick="deleteRow(this);"> or the equivalent thereof.
>
> */
>
> > elnum=elems.length;
> > while(elnum--){
> > if(elems.item(elnum)==button){
> > loop=false;
> > break;
> > }
> > }
> > if(!loop)break;
> > }
>
> /* Here it should probably have something more like: */
>
> if (!loop) {> // "row" is the dom element of the row you wish to delete
> > // "elems" is elements within row
> }
>
> else {
> // didn't find a row containing button in container
>
> }
> > }
>
> I noticed that I wasn't trapping the situation where the button element
> was not found within any of the rows in the collection inside container.
> Fortunately the flag used for the 2nd level break out of the while loop
> can also be used to detect successful location of the row being sought.
>
> Rgds
>
> Denis McMahon

Is this what you meant to say?
function deleteRow(button){

                var row,rows,rownum,elems,elnum,loop;
                rows=document.getElementById('todo-
list').getElementsByTagName('input').type('li');
                rownum=rows.length;
                loop=true;
                    while(rownum--){
                    row=rows.item(rownum);
 
elems=row.getElementsByTagName('input').type('li');
                    elnum=elems.length;
                        while(elnum--){
                        if(elems.item(elnum)==button){
                            loop=false;
                            break;
                            }
                        }
                        if(!loop){
                           return;
                        } else{
                           deleteRow();


                        }
                    };
 The last element on the row is a </li>, the delete button is right
before that.  So this line should not  be button
if(elems.item(elnum)==button){

[toc] | [prev] | [next] | [standalone]

#13531

On Apr 20, 6:23 pm, Denis McMahon <denismfmcma...@gmail.com> wrote:
> On Fri, 20 Apr 2012 11:39:19 -0700, JRough wrote:
> > ...  How to select which id has the button
> > delete clicked and remove that row ?
>
> Assuming you add a delete button on each row, you could assign the
> button's onclick to be something like "deleteRow(this)", and then in
> deleteRow(button) find the row that contains the specified button and
> delete that row.
>
> Presumably your "rows" are defined by a collection of "row" elements
> inside some "container" element? Either as table rows within a table, or
> paragraphs within a div, or elements within a list etc. Presumably you
> can give the container an id, and each row is encapsulated in an element
> of the same type, so you can do something like:
>
> function deleteRow(button){
> var row,rows,rownum,elems,elnum,loop;
> rows=document.getElementById(containerId).getElementsByTagName(rowTag);
> rownum=rows.length;
> loop=true;
> while(rownum--){
> row=rows.item(rownum);
> elems=row.getElementsByTagName("*");
> elnum=elems.length;
> while(elnum--){
> if(elems.item(elnum)==button){
> loop=false;
> break;}
> }
> if(!loop)break;
> }
>
> // "row" is the dom element of the row you wish to delete
> // "elems" is elements within row
>
> }
>
> Note - untested code intended to demonstrate the concept, not intended
> for deployment. Use at your own risk. User accepts all responsibility for
> debugging any typos, logic errors, or just plain dumb mistakes.
>
> Rgds
>
> Denis McMahon

thnx,  first I have to delete it from the DOM then I have to delete it
from the database.  Tnx, I am now clear on that.  And thx for the
concept of how to identify the row,  loop and adding a temporary
identification number in the loop and also the THIS identifies the
clicked button.  thanks again.

[toc] | [prev] | [next] | [standalone]

#13493

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.

2. Your "to-do" list is semantically invalid. `<ul>` elements
*should* have strictly `<li>` elements as direct children[0]. I'd
suggest encapsulating these "list items" (read: form controls)
in a form. 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
(by leaving jQuery in the dust).

3. The usage of `$` to prefix a variable name is a convention
used by jQuery *implementers*¹ to denote a "cached" jQuery
object (e.g. `var $dumb = $(".dumb");`). Simply accessing
the `id` property of an element has nothing to do with jQuery. 
Therefore, the "need" to prefix "$id" with "$"
is nonexistent.

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]. 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>`).

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

>   <section class="main">&nbsp
>       <input id="toggle-all" type="checkbox">
>        <label for="toggle-all">Mark all as complete</label>
>
> <input type="checkbox" id="task" />  User Input to do item<input
> type="button" value="Delete" id="btnDelete />
>
>     </section>

Once again, you are doing yourself a disservice by using form
controls outside of a form element. Controls such as
`<input [..] type="text">` are much easier to select from
inside of a form via the `HTMLFormElement::elements`
HTMLCollection[2]. If you do not wish for the form to be
"submittable", I'd suggest adding an attribute along the lines
of `onsubmit="return false;"`. This will displease the
"Unobtrusive Javascript [sic]" zealots, but is easy to
implement. Of course, that same property can be accessed
via the DOM as well if one desires "spotless" markup.

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

[0]: http://www.w3.org/TR/html401/struct/lists.html#edef-LI
[1]: http://pastebin.com/NzS78ijd
[2]: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-76728479

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

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#13496

On Sat, 21 Apr 2012 11:02:08 -0600, Matt McDonald wrote:

> 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>`).

>>   <section class="main">&nbsp
>>       <input id="toggle-all" type="checkbox">
>>        <label for="toggle-all">Mark all as complete</label>
>> <input type="checkbox" id="task" />  User Input to do item<input
>> type="button" value="Delete" id="btnDelete />

OP used xhtml style markup. Leaving aside whether anyone should be 
generating new pages in xhtml nowadays, does xhtml allow script elements 
in the document body?

Surely the proper way to signal "document loaded" is to define an onload 
event handler for the body element?

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#13500

On 12-04-21 11:12 AM, Denis McMahon wrote:

> OP used xhtml style markup. Leaving aside whether anyone should be
> generating new pages in xhtml nowadays, does xhtml allow script elements
> in the document body?

The doctype being used is the HTML 5 doctype, which allows both
X(HT)ML[0]¹ and HTML syntax[1].

> Surely the proper way to signal "document loaded" is to define an onload
> event handler for the body element?

The `onload` attribute of the `<body>` element listens for the
`load` event[2]. This is the same event that the `onload` property
of the `window` object listens for. As has been observed, this
approach leaves the author (and user) hostage to images, that
when sufficiently large, take a long time to load. Here's what [2]
has written regarding the `load` event:

 > A user agent must dispatch this event when the DOM
 > implementation finishes loading the resource
 > (such as the document) **and any dependent resources
 > (such as images, style sheets, or scripts)**. Dependent
 > resources that fail to load must not prevent this event from
 > firing if the resource that loaded them is still accessible via
 > the DOM. If this event type is dispatched, implementations are
 > required to dispatch this event at least on the Document node.

[0]: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-13
[1]: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-12
[2]: http://www.w3.org/TR/DOM-Level-3-Events/#event-type-load

¹ hat-tip to Thomas Lahn for the notation

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#13513

Matt McDonald wrote:

> On 12-04-21 11:12 AM, Denis McMahon wrote:
>> OP used xhtml style markup. Leaving aside whether anyone should be
>> generating new pages in xhtml nowadays, does xhtml allow script elements
>> in the document body?
> 
> The doctype being used is the HTML 5 doctype, which allows both
> X(HT)ML[0]¹ and HTML syntax[1].
> 
> […]
> ¹ hat-tip to Thomas Lahn for the notation

Thanks, but HTML5 will perhaps not allow XML syntax as it is not perhaps 
going to be¹ SGML-based.  An "XHTML syntax of HTML5" has been specified, but 
it has very little to do with XML or XHTML.  IMHO, HTML5 is a caricature of 
XHTML.
 
>> Surely the proper way to signal "document loaded" is to define an onload
>> event handler for the body element?
> 
> The `onload` attribute of the `<body>` element listens for the
> `load` event[2]. This is the same event that the `onload` property
> of the `window` object listens for. As has been observed, this
> approach leaves the author (and user) hostage to images, that
> when sufficiently large, take a long time to load. Here's what [2]
> has written regarding the `load` event:
> 
>  > A user agent must dispatch this event when the DOM
>  > implementation finishes loading the resource
>  > (such as the document) **and any dependent resources
>  > (such as images, style sheets, or scripts)**. Dependent
>  > resources that fail to load must not prevent this event from
>  > firing if the resource that loaded them is still accessible via
>  > the DOM. If this event type is dispatched, implementations are
>  > required to dispatch this event at least on the Document node.
> 
> [0]:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-13
> [1]:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/#auto-toc-12
> [2]: http://www.w3.org/TR/DOM-Level-3-Events/#event-type-load

But this is not always implemented so.  Furthermore, jQuery interferes with 
it.  The sad truth is that once you are using jQuery, you are condemned to 
use $(…) even for the equivalent of the `load' event listener.  BTDT.

Ceterum censeo jQuerynem esse delendam.²


PointedEars
___________
¹ remember that HTML5 is likely to become the longest lasting Working Draft 
  in W3C history
² CMIIW
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.javascript

csiph-web