Path: csiph.com!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Cezary Tomczyk Newsgroups: comp.lang.javascript Subject: Re: Get inner text of HMTL element Date: Thu, 27 Feb 2014 21:41:31 +0100 Organization: A noiseless patient Spider Lines: 122 Message-ID: References: <5308ed02$0$9512$9b4e6d93@newsspool1.arcor-online.net> <1633562.pVBMJriu5e@PointedEars.de> <1780761.mlrEmVmIzg@PointedEars.de> <10325533.pBRRTmW78i@PointedEars.de> <2932926.BXQvjz4BgK@PointedEars.de> <1651063.34UYyxniXp@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 27 Feb 2014 20:41:28 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="0a21736184bec23e54222c2ddd6b9e0d"; logging-data="14775"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JurpxFBTS0S1ntB6KseIiHMrGiXMfRhs=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: <1651063.34UYyxniXp@PointedEars.de> Cancel-Lock: sha1:Im2mhzc+Kx4ju1jAbfeSFJ69yXI= Xref: csiph.com comp.lang.javascript:23354 Thomas 'PointedEars' Lahn wrote: > Cezary Tomczyk wrote: [...] >>> function _isObject (a) >>> { >>> var t = typeof a; >>> return t == "function" || t == "object" && a !== null; >> >> How about using toString() to get the type of object? >> >> Object.prototype.toString.call(a).match(/\s([a-zA-Z]+)/)[1].toLowerCase() > > There is jsx.object.getClass() which does something similar (more efficient, I'll take a look at above method. > less error-prone), but it is not a good idea to use it here: the [[Class]] > property of an ECMAScript value does not tell whether the value is a > primitive value or a reference to an object, and with host objects all bets > are off, even if one would be willing and able to invest the resources to > keep the list up-to-date. Thanks for explanation. [...] >> You probably referring to >> http://robertnyman.com/2005/12/21/what-is-typeof-unknown/#comment-8001, >> right? > > I would not refer to such nonsense. Just one sentence doesn't explain what is behind "nonsense". >>> last branch. Anyhow, there is no guarantee that if some arbitrary >>> element object has a “firstChild” or “nextSibling” property, the *target* >>> element object also has it. >>> >>> Do you see now why it is a bad idea to infer from one property to >>> another, even if the property names are the same and only the objects >>> differ? >> >> Then what options do I have? >> >> 1. Check, if firstChild and nextSibling is available on >> document.documentElement >> or >> 2. Check, if every element support firstChild and nextSibling? > > 3. Check if the *target* element supports “firstChild” and “nextSibling”. Ok > 4. Forget the whole idea. Except point no. 3. >>>>>> get_inner_text = function(node) { >>>>>> var txt = ''; >>>>>> >>>>>> node = node.firstChild; >>>>>> while (node) { >>>>>> if (node.nodeType === 3 || node.nodeType === 4) { >>>>> >>>>> I avoid strict comparison against property values of host objects. >>>>> There are too many unknowns. >>>> >>>> I've never had problems with that, but I am not claim that there is no >>>> problems. However, if you have a time then provide maybe some valuable >>>> source where I can read about above problems. Otherwise, skip it, in >>>> case of having no time. >>> >>> You are still operating in “Show me where it fails” mode in place of >>> logic. >> >> But "There are too many unknowns." doesn't teach me why. > > There is no indication that an interface’s *attribute* MUST be implemented > as a host object’s property using a *native* type or the *specified* type. > However, if it is to be useful, it must be implemented so that it allows > conversion to and from a native type. Hm, I am lost at that point. [...] >>> No, same problem: The feature test does not happen on the target object >>> because that object is not reliably accessible yet (if it even exists). >> >> So, the object itself must checked as well. It is in your above code, >> right? > > You can and should skip the first *bogus* test, and do *only* the *reliable* > test on the target object. This comes at a price, though: if you cannot > recognize the object (for example, through mapping), you will be forced to > do the same test for each object when it is accessed. AISB: Slower, but not > as error-prone as your/DM’s “one-size-fits-all” initialization or whatever > you/he call(s) it instead. How reliable test on the target object may look in my case? Asking to understand more deeply. >>>>> That aside, you should reconsider the actual probability that >>>>> Node::textContent (DOM Level 3) would not be implemented but >>>>> Document::createTreeWalker() (DOM Level 2 Traversal and Range) was. >>>> Hm, maybe it is worth it to remove textContent and focus only on >>>> createTreeWalker or normal recursive iteration? Less code to >>>> maintenance. >>> And much less efficient with regard to runtime and memory. You should as >>> yourself instead whether there is any actual *need* for tree-walking at >>> this point. >> >> Well, looking at >> https://developer.mozilla.org/en-US/docs/Web/API/Node.textContent looks >> like textContent is supported by major browsers. If I will drop IE8 >> support then I can focus only on textContent, I think. > > Never believe blindly in anything you read; be sceptical and *verify* it. Mostly I am doing in that way - verify it by myself. -- Cezary Tomczyk http://www.ctomczyk.pl/