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

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

Using getElementsByName on a DIV ?

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

Contents

  Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-25 19:37 +0200
    Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-25 20:57 +0200
      Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-25 20:10 +0100
        Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-25 21:42 +0200
          Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-25 23:07 +0100
            Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 09:32 +0200
              Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-26 11:28 +0100
                Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 14:52 +0200
                  Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-26 14:40 +0100
                    Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 18:37 +0200
                      Re: Using getElementsByName on a DIV ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-04-26 19:12 +0200
                        Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 20:44 +0200
                      Re: Using getElementsByName on a DIV ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 19:17 +0200
                      Re: Using getElementsByName on a DIV ? Stefan Weiss <krewecherl@gmail.com> - 2016-04-26 19:56 +0200
                        Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 22:11 +0200
                      Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-26 19:40 +0100
                        Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 21:43 +0200
                          Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-27 00:14 +0100
                            Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-27 11:05 +0200
                              Re: Using getElementsByName on a DIV ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-28 01:10 +0100
                                Re: Using getElementsByName on a DIV ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-05-05 00:46 +0200
                                  Re: Using getElementsByName on a DIV ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-05-06 12:56 +0200
                                    Re: Using getElementsByName on a DIV ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-05-06 05:14 -0700
                                Re: Using getElementsByName on a DIV ? John Harris <niam@jghnorth.org.uk.invalid> - 2016-05-05 14:36 +0100
                      Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 20:38 +0200
          Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 08:57 +0200
    Re: Using getElementsByName on a DIV ? Stefan Weiss <krewecherl@gmail.com> - 2016-04-25 23:41 +0200
      Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 08:59 +0200
    Re: Using getElementsByName on a DIV ? JJ <jj4public@vfemail.net> - 2016-04-26 19:03 +0700
      Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-26 14:56 +0200
      Re: Using getElementsByName on a DIV ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 20:13 +0200
        Re: Using getElementsByName on a DIV ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-26 20:19 +0200
    Re: Using getElementsByName on a DIV ? Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> - 2016-04-26 23:30 +0100
      Re: Using getElementsByName on a DIV ? "R.Wieser" <address@not.available> - 2016-04-27 09:29 +0200
      Re: Using getElementsByName on a DIV ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-04-27 10:34 +0200
      Re: Using getElementsByName on a DIV ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-05-04 19:04 -0700

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

#30393

Ben Bacarisse wrote:

> "R.Wieser" <address@not.available> writes:
   ^^         ^^^^^^^^^^^^^^^^^^^^^
WTF is this?  YTF are you people even talking to this guy?

> <snip>
>> Do I *really* need to spoon-feed the/a problem like in the below ?
> 
> No, you really have to provide an example document along with the code
> that doesn't work.
> 
>> [javascript]
>> Ancestor = this.parentNode;
>> aDescendants = Ancestor.getElementsByTagName("IMG");
>> // aDescendants = Ancestor.getElementsByName("foobar");
>> // aDescendants = Ancestor.getElementsByClassName("foobar");
>> // oDescendant = Ancestor.getElementByID("foobar");
                             ^^^^^^^^^^^^^^
>> [/javascript]
>>
>> I thought that should have been clear from my problem description.   But
>> I guess I expected too much ...

Enough niceties extended to the OP.  It takes a sharp axe to split a tough 
log¹:

This is not a free customer support forum; you are not a customer, and we 
are not the customer support team that needs to cater to your every whim in 
order to avoid losing you.  This is a technical newsgroup on software 
development for (aspiring) software developers.  Do your own homework and 
RTFFAQ, RTFM, STFW.  Or FOAD, luser.

> […]
> One thing is sure: if aDescendants is an element (as seems likely, but
> without a full example that's just a guess) the calls to
> getElementsByName and to getElementByID won't work.  These are methods
> that are part of the document interface, not the element interface.

getElementsByName() is a method of the *Document* (HTML5+) and 
*HTMLDocument* (W3C DOM Level 2 HTML, for [X]HTML < 5) interfaces only.

<http://www.w3.org/TR/2014/REC-html5-20141028/dom.html#the-document-object>

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26809268>
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-011100101>
<https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-745549614>
<https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-745549614>

There is no getElementByID() method in the W3C DOM, which is probably the 
reason why the call fails.  getElementById(), however (note the letter 
case), is and has always been a method of the *Document* interface.

<https://www.w3.org/TR/2015/REC-dom-20151119/#interface-nonelementparentnode>

<https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#i-Document>
<https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#i-Document>

  [“Note: The getElementById() method is not on elements for compatibility 
   with older versions of jQuery. …” – WTF?]

___________
¹  Thanks to the people at dict.leo.org for the approximate translation of 
   the German original, „Auf einen groben Klotz gehört ein grober Keil“.
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30401

Thomas 'PointedEars' Lahn wrote:

> <https://www.w3.org/TR/2015/REC-dom-20151119/#interface-nonelementparentnode>
> 
>   [“Note: The getElementById() method is not on elements for compatibility 
>    with older versions of jQuery. …” – WTF?]

Ouch!

-- 
Christoph M. Becker

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

#30405

On Friday, May 6, 2016 at 5:56:44 AM UTC-5, Christoph M. Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
> 
> > <https://www.w3.org/TR/2015/REC-dom-20151119/#interface-nonelementparentnode>
> > 
> >   ["Note: The getElementById() method is not on elements for compatibility 
> >    with older versions of jQuery. ..." - WTF?]
> 
> Ouch!

Exactly...

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

#30398

On Thu, 05 May 2016 00:41:41 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Ben Bacarisse wrote:
>
>> "R.Wieser" <address@not.available> writes:
>   ^^         ^^^^^^^^^^^^^^^^^^^^^
>WTF is this?  YTF are you people even talking to this guy?
  <snip>

WTF is this? 

"you people" think that communicating is more interesting than
identifying.

  John

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

#30349

Stefan,

>   The DOM does not have an abstraction »the
> getElementsBy* ones«. Instead it uses »interfaces«.

Did I say anything to the contrary ?

And I'm sorry, but without mentioning what, according to you, *both* use
("document" as well as "elements" therein) that explanation there is rather
useless to me.

>   So if someone is still using a 2015 browser today (it's
>   April!), he will do this consciously and will know that
>   sites will usually *not* work and will not blame the site
>   author for this

I guess you have never used a browser older than you underwear ?   You
should definitily try it sometimes, you might be surprised how many websites
have absolutily no problem with displaying all the information they have in
such, no doubt declared "obsolete" by you, browsers.

In other words: Go take a hike with your "must always be the
latest-of-the-latest" attitude.

But, thanks for reminding me.   Did you know that the getElementsByName
method doesn't, on mozilla's website, specify a minimum browser, of any kind
?    And for getElementsByTagName it just specifies "(Yes)".

getElementsByClassName specifies a minimum version of 3.0 .   I take it that
must mean of before stone-age for you.

That leaves getElementsByID.   I made a mistake, and took the "ByName",
"ByTagName", "ByClassName" and "ByID" as being of the same "getElementsBy"
family (as I mentioned at least once).   It isn't.   Its written without
that "s", and returns a single element.   Its also the only one which does
seem to work on the document, but not on an element.

I think I now have all of the info I need, thanks to you.

But if you do not mind, lets please take a bit different method next time.
:-)

Regards,
Rudy Wieser


-- Origional message:
Stefan Ram <ram@zedat.fu-berlin.de> schreef in berichtnieuws
interfaces-20160426175707@ram.dialup.fu-berlin.de...
> "R.Wieser" <address@not.available> writes:
> >... and seemingly a number of the same ones, like the getElementsBy*
ones --
> >which is what we where talking about.
>
>   The DOM does not have an abstraction »the getElementsBy*
>   ones«. Instead it uses »interfaces«. Certain DOM element
>   types implement certain interfaces and certain interfaces
>   inherit from other interfaces.
>
>   For another example, we could talk about »the a* types«.
>   These are »a«, »abbr«, »acronym«, and »address«. But this
>   abstraction will not often be helpful. Instead one talks
>   about »inline types« and »block types« for example, which
>   are more useful abstractions.
>
>   Browsers often get updated automatically today. When someone
>   still has a browser from 2015, all sites will display
>   warnings like »Your historical browser is putting the life
>   of your family at risk, you need to update   N O W ! !«.
>   So if someone is still using a 2015 browser today (it's
>   April!), he will do this consciously and will know that
>   sites will usually *not* work and will not blame the site
>   author for this. But you are free to use (read) any
>   historic DOM specification, like DOM level 3 or DOM level 2.
>   They are still available for readers AFAIK.
>

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

#30330

Stefan,

>   I was talking about »getElementsByTagName« not
>   »getElementsByName« since an img element is determined by
>   its element /type/ »img« and not by a name attribute.

I was assuming that the "getElementsBy*" commands where a family-group (all
working the same), allowing us to find an elements in different ways.

The responses (yours, ben's) seem to indicate otherwise ...

Regards
Rudy Wieser


-- Origional message:
Stefan Ram <ram@zedat.fu-berlin.de> schreef in berichtnieuws
type-name-20160425210603@ram.dialup.fu-berlin.de...
> "R.Wieser" <address@not.available> writes:
> >Well.   The FF Javascript Console told me that
"Ancestor.getElementsByName
> >is not a function" (the "Ancestor" variable contains a "parentNode"
result).
>
>   I was talking about »getElementsByTagName« not
>   »getElementsByName« since an img element is determined by
>   its element /type/ »img« and not by a name attribute.
>
>   (»Tag name« is a misnomer for »type name«.)
>

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

#30320

R.Wieser wrote:
> Now I think of it, I've got pretty-much the same question in regard to
> finding an "ancestor" element:  I've written some code which moves up the
> DOM tree until it finds the sought for element, but maybe there is a
> simpler, single command available for that too.

Since this part of your question hasn't been addressed yet: a manual loop,
moving up the tree and checking each ancestor separately, is the best
solution in your case. There is a new(ish) and very convenient method that
can directly find the closest ancestor matching a given query selector, but
it's not well supported yet:

https://developer.mozilla.org/en-US/docs/Web/API/Element/closest
https://dom.spec.whatwg.org/#dom-element-closest


- stefan

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

#30331

Stefan,

> There is a new(ish) and very convenient method that can
> directly find the closest ancestor matching a given query
> selector, but it's not well supported yet:

Yeah, while googling I've stumbled over the command too.   But exactly its
"new(ish)" character is what made me decide not to use it.

Thanks for mentioning the command though.

Regard,
Rudy Wieser


-- Origional message:
Stefan Weiss <krewecherl@gmail.com> schreef in berichtnieuws
nfm2tc$346$1@news.albasani.net...
> R.Wieser wrote:
> > Now I think of it, I've got pretty-much the same question in regard to
> > finding an "ancestor" element:  I've written some code which moves up
the
> > DOM tree until it finds the sought for element, but maybe there is a
> > simpler, single command available for that too.
>
> Since this part of your question hasn't been addressed yet: a manual loop,
> moving up the tree and checking each ancestor separately, is the best
> solution in your case. There is a new(ish) and very convenient method that
> can directly find the closest ancestor matching a given query selector,
but
> it's not well supported yet:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Element/closest
> https://dom.spec.whatwg.org/#dom-element-closest
>
>
> - stefan

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

#30333

On Mon, 25 Apr 2016 19:37:21 +0200, R.Wieser wrote:
> Hello all,
> 
> I need to find an IMG element in a DIV.   I have written some code to do
> just that, but suddenly thought of using getElementsByName on the DIV node.
> Alas, that does not seem to work.
> 
> #1: can I use getElementsBy* to find sub-elements of a DIV (or other
> grouping element) at all ?
> 
> #2: if the answer to #1 is "no", is there another command that will do it ?
> A google search did not turn up anything in that regard.
> 
> Mind you, I've already written a solution.  I'm just wondering if my
> multi-line recursive function could be replaced by a simpler, single
> command.
> 
> Now I think of it, I've got pretty-much the same question in regard to
> finding an "ancestor" element:  I've written some code which moves up the
> DOM tree until it finds the sought for element, but maybe there is a
> simpler, single command available for that too.

Is querySelector() not applicable?

e.g.: find the IMG element whose direct parent is a DIV element that has
"data-name" attribute value of "container".

  var img = document.querySelector('DIV[data-name]="container" > IMG');

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

#30336

JJ,

> Is querySelector() not applicable?

Possibly, but as far as I got it that one is rather new.   I would not want
the a bit older browsers to feel like they are left out in the cold. :-)

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
hdhaf5igcona$.109xfx7v3a5gl$.dlg@40tude.net...
> On Mon, 25 Apr 2016 19:37:21 +0200, R.Wieser wrote:
> > Hello all,
> >
> > I need to find an IMG element in a DIV.   I have written some code to do
> > just that, but suddenly thought of using getElementsByName on the DIV
node.
> > Alas, that does not seem to work.
> >
> > #1: can I use getElementsBy* to find sub-elements of a DIV (or other
> > grouping element) at all ?
> >
> > #2: if the answer to #1 is "no", is there another command that will do
it ?
> > A google search did not turn up anything in that regard.
> >
> > Mind you, I've already written a solution.  I'm just wondering if my
> > multi-line recursive function could be replaced by a simpler, single
> > command.
> >
> > Now I think of it, I've got pretty-much the same question in regard to
> > finding an "ancestor" element:  I've written some code which moves up
the
> > DOM tree until it finds the sought for element, but maybe there is a
> > simpler, single command available for that too.
>
> Is querySelector() not applicable?
>
> e.g.: find the IMG element whose direct parent is a DIV element that has
> "data-name" attribute value of "container".
>
>   var img = document.querySelector('DIV[data-name]="container" > IMG');

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

#30346

JJ wrote:

> On Mon, 25 Apr 2016 19:37:21 +0200, R.Wieser wrote:
>> Now I think of it, I've got pretty-much the same question in regard to
>> finding an "ancestor" element:  I've written some code which moves up the
>> DOM tree until it finds the sought for element, but maybe there is a
>> simpler, single command available for that too.
> 
> Is querySelector() not applicable?
> 
> e.g.: find the IMG element whose direct parent is a DIV element that has
> "data-name" attribute value of "container".
> 
>   var img = document.querySelector('DIV[data-name]="container" > IMG');
                                                   ^^^^^^^^^^^^^
Please test examples before you post them, or say explicitly that you have 
not tested them.  This is not a valid CSS selector.

You probably meant

  var img = document.querySelector('div[data-name="container"] > img');

but in order to satisfy the “ancestor” requiredment, it would have to be

  var img = document.querySelector('div[data-name="container"] img');

We have discussed the drawbacks of d.qS(A) here already: there is always a 
backwards compatibility problem.  XPath or a custom selector engine like 
jQuery’s Sizzle would help, but in the case of a parent element it is so 
much easier and more compatible to search for all “img” elements with 
document.getElementsByTagName(), and use Array methods on the resulting 
NodeList to filter out those whose parent element is either not a “div” 
element or does not have a “data-name” attribute with the specified:

  var img = [].slice.call(document.getElementsByTagName("img") || [])
    .filter(function (img) {
      var parentNode = img.parentNode;

      return parentNode.tagName.toLowerCase() === "div"
        && parentNode.getAttribute("data-name") === "container";
    });

The “ancestor” requirement would require a loop.  It should therefore be 
tested which of those approaches are the most compatible ones and which are 
the most efficient ones.  With feature testing, all of them can be 
supported.

[Where Array.prototype.filter() of ES 5 is not available, you can easily 
emulate it to sufficient standards compliance:

  if (typeof Array.prototype.filter != "function")
  {
    Array.prototype.filter = function (filter, thisValue) {
      if (arguments.length < 2) thisVal = this;
      var a = [];

      for (var i = 0, len = this.length; i < len; ++i)
      {
        var value = this[i];
        if ((i in this) && filter.call(thisValue, value, i, this))
        {
          a.push(value);
        }
      }

      return a;
    });
  }

or, if order does not matter,

  if (typeof Array.prototype.filter != "function")
  {
    Array.prototype.filter = function (filter, thisValue) {
      if (arguments.length < 2) thisVal = this;
      var a = [];

      for (var i in this)
      {
        var value = this[i];
        if (((i >>> 0) === i) && filter.call(thisValue, value, i, this))
        {
          a.push(value);
        }
      }

      return a;
    });
  }

I find it interesting to note that the second variant could be more 
efficient with sparse arrays and still maintain index order if one would 
sort the resulting array by index and map the result to a value array.

Always filter for-in loops on Array instances afterwards, and as a general 
rule, on all Array instances and instances of derived object types.]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30347

Thomas 'PointedEars' Lahn wrote:

>   if (typeof Array.prototype.filter != "function")
>   {
>     Array.prototype.filter = function (filter, thisValue) {
>       if (arguments.length < 2) thisVal = this;
>       var a = [];
> 
>       for (var i in this)
>       {
>         var value = this[i];

          i = +i;

(conversion to Number) is mandatory if strict comparison is used below.  
Otherwise the following is never going to be executed as property names are 
of type String.

>         if (((i >>> 0) === i) && filter.call(thisValue, value, i, this))
>         {
>           a.push(value);
>         }
>       }

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#30353

In comp.lang.javascript message <571e5590$0$5835$e4fe514c@news.xs4all.nl
>, Mon, 25 Apr 2016 19:37:21, R.Wieser <address@not.available> posted:

>Now I think of it, I've got pretty-much the same question in regard to
>finding an "ancestor" element:  I've written some code which moves up the
>DOM tree until it finds the sought for element, but maybe there is a
>simpler, single command available for that too.

One should consider how often, and how quickly, this needs to be done.

If it is only needed a few times, and the DOM tree is not vast, you
might as well just scan the whole DOM tree on every occasion until the
desired point is found.

If it is to be done sufficiently frequently on an unchanging tree, it
seems to me likely that it would be worth-while to scan the whole DOM
tree initially, building a parallel tree or list or array containing
only the elements which might be wanted; and scan only that when an
element is wanted.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#30357

J R,

> If it is to be done sufficiently frequently on an unchanging
> tree, it seems to me likely that it would be worth-while to
> scan the whole DOM tree initially

Yes, that also came to my mind.  I already decided that I will try to write
such a version after I've wrapped up writing (simplifying) the current one.
If for nothing else than to see how the implementations compare to each
other.

Regards,
Rudy Wieser


-- Origional message:
Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> schreef in
berichtnieuws JpqLf9bYw+HXFw8E@invalid.uk.co.demon.merlyn.invalid...
> In comp.lang.javascript message <571e5590$0$5835$e4fe514c@news.xs4all.nl
> >, Mon, 25 Apr 2016 19:37:21, R.Wieser <address@not.available> posted:
>
> >Now I think of it, I've got pretty-much the same question in regard to
> >finding an "ancestor" element:  I've written some code which moves up the
> >DOM tree until it finds the sought for element, but maybe there is a
> >simpler, single command available for that too.
>
> One should consider how often, and how quickly, this needs to be done.
>
> If it is only needed a few times, and the DOM tree is not vast, you
> might as well just scan the whole DOM tree on every occasion until the
> desired point is found.
>
> If it is to be done sufficiently frequently on an unchanging tree, it
> seems to me likely that it would be worth-while to scan the whole DOM
> tree initially, building a parallel tree or list or array containing
> only the elements which might be wanted; and scan only that when an
> element is wanted.
>
> --
>  (c) John Stockton, Surrey, UK.  Ź@merlyn.demon.co.uk   Turnpike v6.05
MIME.
>  Merlyn Web Site <                       > - FAQish topics, acronyms, &
links.

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

#30358

Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> wrote on 27 Apr 2016 
in comp.lang.javascript:

> In comp.lang.javascript message <571e5590$0$5835$e4fe514c@news.xs4all.nl
>>, Mon, 25 Apr 2016 19:37:21, R.Wieser <address@not.available> posted:
> 
>>Now I think of it, I've got pretty-much the same question in regard to
>>finding an "ancestor" element:  I've written some code which moves up the
>>DOM tree until it finds the sought for element, but maybe there is a
>>simpler, single command available for that too.
> 
> One should consider how often, and how quickly, this needs to be done.
> 
> If it is only needed a few times, and the DOM tree is not vast, you
> might as well just scan the whole DOM tree on every occasion until the
> desired point is found.
> 
> If it is to be done sufficiently frequently on an unchanging tree, it
> seems to me likely that it would be worth-while to scan the whole DOM
> tree initially, building a parallel tree or list or array containing
> only the elements which might be wanted; and scan only that when an
> element is wanted.

You are absolutely right, John.

However, perhaps 'we' sometimes forget that to the younger ones,
programme-efficiency is not so much factual execution efficiency 
as imagined programming ease. 

The whole JQuery worship is based on such fallacy.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#30394

On Tuesday, April 26, 2016 at 5:47:45 PM UTC-5, Dr J R Stockton wrote:
> In comp.lang.javascript message <...>, Mon, 25 Apr 2016 19:37:21, R.Wieser <...> posted:
> 
> >Now I think of it, I've got pretty-much the same question in regard to
> >finding an "ancestor" element:  I've written some code which moves up the
> >DOM tree until it finds the sought for element, but maybe there is a
> >simpler, single command available for that too.
> 
> One should consider how often, and how quickly, this needs to be done.
> 
> If it is only needed a few times, and the DOM tree is not vast, you
> might as well just scan the whole DOM tree on every occasion until the
> desired point is found.
> 
> If it is to be done sufficiently frequently on an unchanging tree, it
> seems to me likely that it would be worth-while to scan the whole DOM
> tree initially, building a parallel tree or list or array containing
> only the elements which might be wanted; and scan only that when an
> element is wanted.

Luckily there's a method for that these days (though not quite standard yet):

someElement.closest('...myCssSelector...')

<https://developer.mozilla.org/en-US/docs/Web/API/Element/closest>
<http://caniuse.com/#feat=element-closest>
<https://github.com/jonathantneal/closest/blob/master/closest.js>

[toc] | [prev] | [standalone]

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

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

csiph-web