Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #23263
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: Get inner text of HMTL element |
| Date | 2014-02-24 21:01 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <leg8e4$q6d$1@dont-email.me> (permalink) |
| References | (5 earlier) <1780761.mlrEmVmIzg@PointedEars.de> <leb8sc$23n$5@dont-email.me> <10325533.pBRRTmW78i@PointedEars.de> <lecuah$mib$9@dont-email.me> <2932926.BXQvjz4BgK@PointedEars.de> |
Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
[...]
>>>> if (typeof document.getElementsByTagName('html')[0].textContent ===
>>>> 'string') {
>>>
>>> You should safely replace that with
>>>
>>> if (typeof document.documentElement != "undefined"
>>> && typeof document.documentElement.textContent == "string")
>>> {
>>
>> or
>>
>> if (document.documentElement !== undefined && typeof
>> document.documentElement.textContent === 'string') {
>
> I wrote “safely” for a reason. However,
Ok.
> if (typeof document.documentElement != "undefined"
> && document.documentElement !== null
> && typeof document.documentElement.textContent == "string")
> {
>
> should be even safer.
>
> Since this is a common task, it is useful to define a general method that
> takes an object reference and a list of property names as arguments, whereas
> the property names specify the “path” of a property such that the property’s
> value can be obtained by repeated property access along that list:
>
> /**
> * Determines if a value refers to an object.
> *
> * <p>Returns <code>true</code> if the value is a reference
> * to an object; <code>false</code> otherwise.</p>
> *
> * <p>An value "is an object" if it is a function or
> * <code>typeof "object"</code> but not <code>null</code>.
> *
> * @return {boolean}
> */
> 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()
> }
>
> return {
[...]
> getFeature: function (obj) {
> for (var i = 1, len = arguments.length; i < len; i++)
> {
> var arg = arguments[i];
> if (_isObject(obj) && typeof obj[arg] != "undefined" && obj[arg])
> {
> obj = obj[arg];
> }
> else
> {
> return void 0;
> }
> }
>
> return obj;
> }
> };
>
> See also: <http://PointedEars.de/wsvn/JSX/trunk/object.js>
Above idea looks good for me.
> A refined method would support specification of the property path as an
> Array of string values, and primitive false-values. I am working on it.
That would be nice.
>>>> get_inner_text = function(node) {
>>>> return node.textContent;
>>>> };
>>>> } else if (document.createTreeWalker) {
>>>
>>> Insufficient and error-prone feature test for a host object's method, see
>>> jsx.object.isHostMethod().
>>
>> Yes, I know isHostMethod, but still I am feeling that it's not enough.
>> Checking if host object is a function is one thing, but the second one
>> if it's native or not. Once I had a scenario where trim() method was
>> exists, but it was overwritten by some 3rd party library and this method
>> wasn't working well. I've just realized it after some investigation :-(
>>
>> However, last time I was thinking if it's strongly required every time
>> for every scenario. As I remember:
>>
>> 1. Some host objects in IE8 are as an "object", not a "function".
>> 2. There is type "unknown", but it's related to only one case.
>>
>> That's why I've been thinking that explicit conversion in that case is
>> relatively safe.
>
> Your logic is flawed. It had been unrecoverable exceptions being thrown
> upon type-converting tests of host object's methods in MSHTML that prompted
> my/the creation of isMethod(), later isHostMethod(), in the first place.
You probably referring to
http://robertnyman.com/2005/12/21/what-is-typeof-unknown/#comment-8001,
right?
>>>> get_inner_text = function(root) {
>>>> var w = document.createTreeWalker(root, 4, null, false),
>>>> result = '';
>>>> while (w.nextNode()) {
>>>> result += w.currentNode.data;
>>>> }
>>>> return result;
>>>> };
>>>>
>>>> } else {
>>>
>>> That the former two approaches fail does not mean that the third one must
>>> work.
>>
>> Hm, should I test if "firstChild" and "nextSibling" is supported before?
>> Or do something else?
>
> If you are to support “innerText” as well, *that* should be handled by the
I think I can skip innerText and support only textContent.
> 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?
>>>> 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.
>>>> node = node.nextSibling;
>>>> }
>>>> return txt;
>>>> };
>>>> }
>>>>
>>>> How about that?
>>>
>>> I do not think it is a good idea to infer from the existence of a
>>> property on one (host) object the existence of a property of the same
>>> name on another
>>
>> Hm, is it then better to do in that way?
>>
>> var get_inner_text = (function () {
>>
>> // here check what is available and return function
>>
>> }());
>
> 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?
>>> (host) object. Therefore, I prefer approaches that test the properties
>>> of the target object instead.
>>
>> By "test" you mean using isHostMethod, isHostObjectProperty and
>> isRealObjectProperty?
>
> Yes, but not in the DM way, because that is error-prone even though it might
> be faster.
Ok, I will compare DM and your version.
>>> 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.
--
Cezary Tomczyk
http://www.ctomczyk.pl/
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 18:21 +0100
Re: Get inner text of HMTL element Martin Honnen <mahotrash@yahoo.de> - 2014-02-22 19:31 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 20:51 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 21:11 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 21:37 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 22:05 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 23:38 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 10:43 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 14:50 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 15:48 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 21:01 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:34 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-27 21:41 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 22:32 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-28 13:44 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-28 16:54 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-03-04 20:51 +0100
Re: Get inner text of HMTL element ompalompasales2@gmail.com - 2014-03-04 12:59 -0800
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 20:59 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 22:23 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 23:32 +0100
Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-22 21:27 -0300
Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 05:35 +0100
Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-23 15:29 -0300
Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 21:01 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 20:02 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 21:55 +0100
Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 08:37 +0100
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:30 +0100
Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 15:09 -0300
Re: Get inner text of HMTL element Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 19:43 +0100
Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 18:12 -0300
Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:51 +0100
Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-25 19:49 +0000
Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 05:20 -0300
Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-26 17:10 +0100
OT - Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 15:48 -0300
Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-26 22:43 +0100
Re: OT - Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:00 +0000
Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-28 10:50 +0100
Re: OT - Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-27 10:57 +0100
Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:46 +0000
csiph-web