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

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

Get inner text of HMTL element

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

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#23200 — Get inner text of HMTL element

To get inner text of HTML element I've been using:

function get_inner_text(node) {
     if (node.nodeType === 3) {
         return node.data;
     }

     var txt = '';

     node = node.firstChild;
     while (node) {
         txt += get_inner_text(node);
         node = node.nextSibling;
     }
     return txt.replace(/\s+/g, ' ');
}

However, I am thinking about simplifying it and instead of:

var str = get_inner_text(elm); // elm represent reference to the HTML 
element

I would use now:

var str = elm.textContent || elm.data || elm.innerText;

Is it a good approach? Any suggestions?

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [next] | [standalone]

#23201

Cezary Tomczyk wrote:


> I would use now:
>
> var str = elm.textContent || elm.data || elm.innerText;
>
> Is it a good approach?

No, with a browser implementing the W3C DOM Level 3 textContent property 
and an empty element "elm" and no support for the other properties you 
would get the value undefined, see http://jsfiddle.net/55euf/, instead 
of the empty string.

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

#23203

On 2014-02-22 19:31, Martin Honnen wrote:
> Cezary Tomczyk wrote:
>
>
>> I would use now:
>>
>> var str = elm.textContent || elm.data || elm.innerText;
>>
>> Is it a good approach?
>
> No, with a browser implementing the W3C DOM Level 3 textContent property
> and an empty element "elm" and no support for the other properties you
> would get the value undefined, see http://jsfiddle.net/55euf/, instead
> of the empty string.

I've updated the code. How about that?

http://jsfiddle.net/55euf/1/

P.S. I should write first unit tests for it and probably this would 
catch scenario which you've described.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#23205

Cezary Tomczyk wrote:

> On 2014-02-22 19:31, Martin Honnen wrote:
>> Cezary Tomczyk wrote:
>>> I would use now:
>>>
>>> var str = elm.textContent || elm.data || elm.innerText;
>>>
>>> Is it a good approach?
>>
>> No, with a browser implementing the W3C DOM Level 3 textContent property
>> and an empty element "elm" and no support for the other properties you
>> would get the value undefined, see http://jsfiddle.net/55euf/, instead
>> of the empty string.
> 
> I've updated the code. How about that?
> 
> http://jsfiddle.net/55euf/1/

How about posting it?
 
> P.S. I should write first unit tests for it and probably this would
> catch scenario which you've described.

You do not need a unit test for this, only deeper and clear thinking.
What is the result of

  "" || void 0 || void 0

?

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23207

W dniu 2014-02-22 21:11, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> On 2014-02-22 19:31, Martin Honnen wrote:
>>> Cezary Tomczyk wrote:
>>>> I would use now:
>>>>
>>>> var str = elm.textContent || elm.data || elm.innerText;
>>>>
>>>> Is it a good approach?
>>>
>>> No, with a browser implementing the W3C DOM Level 3 textContent property
>>> and an empty element "elm" and no support for the other properties you
>>> would get the value undefined, see http://jsfiddle.net/55euf/, instead
>>> of the empty string.
>>
>> I've updated the code. How about that?
>>
>> http://jsfiddle.net/55euf/1/
>
> How about posting it?

No problem. Here we go:

function get_inner_text(elm) {
     var txt = '';
     if (elm && elm.childNodes && elm.childNodes.length > 0) {
         txt = elm.data || elm.textContent || elm.innerText;
     }
     return txt;
}

>> P.S. I should write first unit tests for it and probably this would
>> catch scenario which you've described.
>
> You do not need a unit test for this, only deeper and clear thinking.
> What is the result of
>
>    "" || void 0 || void 0
>
> ?

"" is converted to "false" boolean
void 0 is evaluated to "undefined" and then to "false" boolean

Because all of them are converted to "false" boolean then "undefined" by 
default is returned.

How about that?

function get_inner_text(elm) {
     var txt = (elm.data || elm.textContent || elm.innerText);
     if (!txt) {
         txt = '';
     }
     return txt;
}

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#23208

Cezary Tomczyk wrote:

> W dniu 2014-02-22 21:11, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> On 2014-02-22 19:31, Martin Honnen wrote:
>>>> Cezary Tomczyk wrote:
>>>>> I would use now:
>>>>>
>>>>> var str = elm.textContent || elm.data || elm.innerText;
>>>>>
>>>>> Is it a good approach?
>>>>
>>>> No, with a browser implementing the W3C DOM Level 3 textContent
>>>> property and an empty element "elm" and no support for the other
>>>> properties you would get the value undefined, see
>>>> http://jsfiddle.net/55euf/, instead of the empty string.
>>>
>>> I've updated the code. How about that?
>>>
>>> http://jsfiddle.net/55euf/1/
>>
>> How about posting it?
> 
> No problem. Here we go:
> 
> function get_inner_text(elm) {
>      var txt = '';
>      if (elm && elm.childNodes && elm.childNodes.length > 0) {
>          txt = elm.data || elm.textContent || elm.innerText;
>      }
>      return txt;
> }

Better (but unnecessarily inefficient: consider the “firstChild” property), 
but see below.
 
>>> P.S. I should write first unit tests for it and probably this would
>>> catch scenario which you've described.
>>
>> You do not need a unit test for this, only deeper and clear thinking.
>> What is the result of
>>
>>    "" || void 0 || void 0
>>
>> ?
> 
> "" is converted to "false" boolean
> void 0 is evaluated to "undefined" and then to "false" boolean
> 
> Because all of them are converted to "false" boolean then "undefined" by
> default is returned.
> 
> How about that?

The final operand¹ is not converted, and no operand is actually converted 
(instead of just internally for the purpose of determining shortcut 
evaluation).  And nothing is *returned*.  Otherwise you have described it 
correctly.
 
> function get_inner_text(elm) {
>      var txt = (elm.data || elm.textContent || elm.innerText);
>      if (!txt) {
>          txt = '';
>      }
>      return txt;
> }

Much the same could be achieved with

  var text = elm.data || elm.textContent || elm.innerText || "";

and it would still be wrong.

For a start, one wonders how you got the idea that an *element* object had a 
(built-in, standards-compliant) “data” property to yield the text content of 
the represented element.

_______
¹ Colloquially speaking; actually, we are looking at only one “||” operation 
  whose first operand is the result of another one: “a || b || c” is parsed
  like “(a || b) || c” due to the production
  
  | LogicalORExpression(NoIn) :
  |   LogicalANDExpression(NoIn)
  |   LogicalORExpression || LogicalANDExpression(NoIn)

  <http://ecma-international.org/ecma-262/5.1/#sec-11.11>
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23211

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
[...]
>> function get_inner_text(elm) {
>>       var txt = '';
>>       if (elm && elm.childNodes && elm.childNodes.length > 0) {
>>           txt = elm.data || elm.textContent || elm.innerText;
>>       }
>>       return txt;
>> }
>
> Better (but unnecessarily inefficient: consider the “firstChild” property),
> but see below.

True. I've rewritten it to:

function get_inner_text(elm) {
     var txt = '';
     if (elm && elm.firstChild) {
         txt = elm.textContent || elm.innerText;
     }
     return txt;
}

There is no "elm.data". I've explained it below.

[...]
>>> What is the result of
>>>
>>>     "" || void 0 || void 0
>>>
>>> ?
>>
>> "" is converted to "false" boolean
>> void 0 is evaluated to "undefined" and then to "false" boolean
>>
>> Because all of them are converted to "false" boolean then "undefined" by
>> default is returned.
>>
>> How about that?
>
> The final operand¹ is not converted, and no operand is actually converted
> (instead of just internally for the purpose of determining shortcut
> evaluation).  And nothing is *returned*.  Otherwise you have described it
> correctly.

Right. I was thinking about default return value when function has no 
defined "return" statement. But in this case there is no function at all.

>> function get_inner_text(elm) {
>>       var txt = (elm.data || elm.textContent || elm.innerText);
>>       if (!txt) {
>>           txt = '';
>>       }
>>       return txt;
>> }
>
> Much the same could be achieved with
>
>    var text = elm.data || elm.textContent || elm.innerText || "";
>
> and it would still be wrong.

:-( There is no "elm.data".

> For a start, one wonders how you got the idea that an *element* object had a
> (built-in, standards-compliant) “data” property to yield the text content of
> the represented element.

I have no idea how it happened. I've already worked with the property 
"data", but I forgot that it apply only to TextNode object 
(http://msdn.microsoft.com/en-us/library/ie/cc304097%28v=vs.85%29.aspx).

After longer research, experimenting and reading 
(http://www.kellegous.com/j/2013/02/27/innertext-vs-textcontent/) I 
think I can build something like this:

var get_inner_text;

if (typeof document.getElementsByTagName('html')[0].textContent === 
'string') {
     get_inner_text = function(node) {
         return node.textContent;
     };
} else if (document.createTreeWalker) {

     get_inner_text = function(root) {
         var w = document.createTreeWalker(root, 4, null, false),
             result = '';
          while (w.nextNode()) {
              result += w.currentNode.data;
          }
          return result;
     };

} else {

     get_inner_text = function(node) {
         var txt = '';

         node = node.firstChild;
         while (node) {
             if (node.nodeType === 3 || node.nodeType === 4) {
                 txt += node.data;
             } else if (node.nodeType === 1){
                 txt += get_inner_text(node);
             }
             node = node.nextSibling;
         }
         return txt;
     };
}

How about that?

> _______
> ¹ Colloquially speaking; actually, we are looking at only one “||” operation
>    whose first operand is the result of another one: “a || b || c” is parsed
>    like “(a || b) || c” due to the production
>
>    | LogicalORExpression(NoIn) :
>    |   LogicalANDExpression(NoIn)
>    |   LogicalORExpression || LogicalANDExpression(NoIn)
>
>    <http://ecma-international.org/ecma-262/5.1/#sec-11.11>

Thanks.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#23215

Cezary Tomczyk wrote:

> [...]
> After longer research, experimenting and reading
> (http://www.kellegous.com/j/2013/02/27/innertext-vs-textcontent/) I
> think I can build something like this:
> 
> var get_inner_text;
> 
> if (typeof document.getElementsByTagName('html')[0].textContent ===
> 'string') {

You should safely replace that with

  if (typeof document.documentElement != "undefined"
      && typeof document.documentElement.textContent == "string")
  {

>      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().
 
>      get_inner_text = function(root) {
>          var w = document.createTreeWalker(root, 4, null, false),
>              result = '';
>           while (w.nextNode()) {
>               result += w.currentNode.data;

See below.

>           }
>           return result;
>      };
> 
> } else {

That the former two approaches fail does not mean that the third one must 
work.
 
>      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.

>                  txt += node.data;
>              } else if (node.nodeType === 1){
>                  txt += get_inner_text(node);
>              }

You should join an Array of string values instead.  Also note that a stack 
overflow could prevent you from providing an adequate result (but the 
iterative approach is not as elegant and may fail as well, only later).

>              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 
(host) object.  Therefore, I prefer approaches that test the properties of 
the target object instead.

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.
MDN says (unverified):

                   Node::textContent  document.createTreeWalker()¹
------------------------------------------------------------------
Chrome             1+                 1.0
Firefox (Gecko)    (Yes)              2.0 (1.8.1)
Internet Explorer  9                  9.0
Opera              (Yes)              9.0
Safari             (Yes)              3.0
------------------------------------------------------------------
______
¹ Basic support, respectively.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23217

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> [...]
>> After longer research, experimenting and reading
>> (http://www.kellegous.com/j/2013/02/27/innertext-vs-textcontent/) I
>> think I can build something like this:
>>
>> var get_inner_text;
>>
>> 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') {

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

>>       get_inner_text = function(root) {
>>           var w = document.createTreeWalker(root, 4, null, false),
>>               result = '';
>>            while (w.nextNode()) {
>>                result += w.currentNode.data;
>
> See below.
>
>>            }
>>            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?

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

>>                   txt += node.data;
>>               } else if (node.nodeType === 1){
>>                   txt += get_inner_text(node);
>>               }
>
> You should join an Array of string values instead.  Also note that a stack
> overflow could prevent you from providing an adequate result (but the
> iterative approach is not as elegant and may fail as well, only later).

Let me try to rewrite it using Array.

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

}());

> (host) object.  Therefore, I prefer approaches that test the properties of
> the target object instead.

By "test" you mean using isHostMethod, isHostObjectProperty and 
isRealObjectProperty?

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

[...]

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#23228

Cezary Tomczyk wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> [...]
>>> After longer research, experimenting and reading
>>> (http://www.kellegous.com/j/2013/02/27/innertext-vs-textcontent/) I
>>> think I can build something like this:
>>>
>>> var get_inner_text;
>>>
>>> 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,

  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;
  }

  return {
    /**
     * Returns a feature of an object
     *
     * @param {Object} obj
     *   Object which provides the feature
     * @params {string}
     *   Property names on the feature path, including the property
     *   for the feature itself.  For example, use
     *   <code>jsx.object.getFeature("foo", "bar", "baz")</code> for
     *   safe access to <code>foo.bar.baz</code>.
     * @return {any}
     *   <code>undefined</code> if <var>obj</var> does not have such
     *   a feature.  Note that features whose value can be
     *   <code>undefined</code> cannot be detected with this method.
     */
    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>

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.

>>>       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.
 
>>>       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 
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?
 
>>>       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.
 
>>>               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).
 
>> (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.
 
>> 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.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23263

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/

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

#23265

Cezary Tomczyk wrote:

> Thomas 'PointedEars' Lahn wrote:
>>    /**
>>     * 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()

There is jsx.object.getClass() which does something similar (more efficient, 
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.
 
>> 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.

The former is implemented now, but it needs to be (unit-)tested before it 
can be merged to the live branch.  Check the trunk on my WebSVN (or read 
<news:26292757.AuDnbMLnkA@PointedEars.de> p.)

>>>>>        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?

I would not refer to such 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”.

4. Forget the whole idea.
 
>>>>>        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.
 
>>>>>                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?

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

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#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/

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

#23355

Cezary Tomczyk wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
> [...]
>>> 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".

What do you mean by that?
 
>>>> 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.

What do you mean by that?

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

What did you not understand?
 
> [...]
>>>> 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.

In your case, AFAICS the target object is an arbitrary element object and, 
because of recursion, each of its descendant node objects.  So you will have 
to test each of those objects at least once.  (Of course, if “textContent” 
is supported on the element object of your initial serialization call, you 
can return its value and are done.  No iteration and recursion necessary 
then.)

You could assume that in a consistent DOM implementation if the node type 
and/or the element type were the same as before, they would support the same 
properties, and you could skip the feature test based on previous knowledge.  
Also, if an element had an ID, you could store feature test results by ID.  
But there is no guarantee that this works (it certainly does not need to 
work if the document is modified between calls).  And it requires *more* 
tests at runtime (you need to test more properties than before), a *larger* 
effective scope chain or argument list (a recursively called function has no 
access to the local context of its caller) and/or *more* memory (the 
information for the lookup needs to be stored).  So you better forget that 
idea of “optimization”.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23362

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>> [...]
>>>> 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".
>
> What do you mean by that?

I mean that saying like "I would not refer to such nonsense." doesn't 
bring any value. Instead of that I would expect: "Specified comment is 
"nonsense" because of ... [and here are arguments]".

>>>>> 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.
>
> What do you mean by that?

"Forget the whole idea." - I thought that point no. 3 is the right thing 
to do and "whole idea" is not applicable for that point.

>>>>>>>>          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.
>
> What did you not understand?

I had a bit of homework and explore the knowledge. So, here what I 
understood now: "interface’s *attribute*" represent 
https://developer.mozilla.org/en-US/docs/Web/API/Attr. However, looks 
like "nodeType" property, at least in Gecko implementation, is 
deprecated (I see it in section "Deprecated properties and methods").

So, I should use 
https://developer.mozilla.org/en-US/docs/Web/API/Element.getAttributeNode to 
check if property exists and then decide to use its value? Or do 
something else?


>> [...]
>>>>> 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.
>
> In your case, AFAICS the target object is an arbitrary element object and,
> because of recursion, each of its descendant node objects.  So you will have
> to test each of those objects at least once.  (Of course, if “textContent”
> is supported on the element object of your initial serialization call, you
> can return its value and are done.  No iteration and recursion necessary
> then.)

Is then sufficient to check property only once on the root element of 
the document? Just what you wrote in previous message(s).

if (typeof document.documentElement != "undefined"
       && typeof document.documentElement.textContent == "string")
   {[...]

Of course, then I need to assume that other elements support textContent 
as well as Element 
(https://developer.mozilla.org/en-US/docs/DOM/element) that is the root 
element of the document.

> You could assume that in a consistent DOM implementation if the node type
> and/or the element type were the same as before, they would support the same
> properties, and you could skip the feature test based on previous knowledge.
> Also, if an element had an ID, you could store feature test results by ID.
> But there is no guarantee that this works (it certainly does not need to
> work if the document is modified between calls).  And it requires *more*
> tests at runtime (you need to test more properties than before), a *larger*
> effective scope chain or argument list (a recursively called function has no
> access to the local context of its caller) and/or *more* memory (the
> information for the lookup needs to be stored).  So you better forget that
> idea of “optimization”.

Ok, I've already forgot about above optimization. :-)

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
If anyone can suggest me some good NNTP server other than 
news.eternal-september.org then it would be nice. Thanks.

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

#23363

Cezary Tomczyk wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Cezary Tomczyk wrote:
>>> [...]
>>>>> 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".
>>
>> What do you mean by that?
> 
> I mean that saying like "I would not refer to such nonsense." doesn't
> bring any value. Instead of that I would expect: "Specified comment is
> "nonsense" because of ... [and here are arguments]".

It would be easier to say which statements in it are _not_ nonsense, as 
there are fewer of them.

Tom Trenka states there:
| Internet Explorer displays “unknown” when the object in question is on the
| other side of a COM+ bridge.

Internet Explorer displays “unknown” if the result of the “typeof” operation 
is displayed in this case.  It (or rather, the JScript engine) throws an 
(AFAIK unrecoverable) exception on any other access.

That “the object is on the other side of a COM+ bridge” may or may not be 
true.  Certainly it does not have to be COM+ object; a COM object suffices 
as this was the case before there was COM+.  (isMethod() came about *before* 
2003 CE, so before COM+.)

<http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx>
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>

| You may not know this or realize this, but MS’s XMLHTTP object is part of
| a different COM+ object that implements IUnknown;

“MS’s XMLHTTP object” is _not_ part of another object.

In the form referred by the result of the expression

  new ActiveXObject("Microsoft.XMLHTTP")

it is a so-called “(OLE) Automation object” (an ActiveX object, now a 
special COM object) whose server name is “Microsoft” and type name is 
“XMLHTTP”.

<http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.84).aspx>
<http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.94).aspx>
<http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>

| when you call methods on it, you’re doing so over a COM bridge

True as of the date of the cited comment when there was no native 
XMLHttpRequest:

<http://msdn.microsoft.com/en-us/library/ms535874(v=vs.85).aspx>

(It should be noted that you find “XMLHttpRequest” in Microsoft's “Internet 
Explorer API Reference” but not in their “JavaScript Reference”.  One must 
conclude that it is referring to a host object, not a native JScript object 
as it is often claimed.)

| and not calling native JavaScript.

Nothing is called when using “typeof”.  (When you see someone naming read 
access or mere evaluation of an expression a “call”, and the thing being 
read or evaluated “called”, this is one sure sign of wannabe talk.)

Internet Explorer as of the date of the cited comment supported JScript (it 
still does, it is just named differently now, mainly for marketing reasons).

<http://msdn.microsoft.com/en-us/library/hbxc2t98(v=vs.84).aspx>

| Basically that’s MS’s answer if you try to test or access something that’s
| not a true part of the JScript engine.

(Whether the statement that some object in *userland*¹ would be part of a 
script engine makes any sense is questionable already.  I am assuming he 
meant “part of the JScript *language*” here.)

*No* DOM object, in general *no* host object, is part of JScript (the 
language, not an engine), not only COM(+) objects.  (That differentiates 
*host* objects from *native* objects.)

In particular, Microsoft’s XMLHTTP object, whatever the version, is not 
provided by jscript.dll, but by mshtml.dll [“new 
ActiveXObject("Microsoft.XMLHTTP") or “new XMLHttpRequest”] or msxml2.dll 
[new ActiveXObject("Msxml2.XMLHTTP")].

| Before you complain about it further, bear in mind that MSXML was designed
| to be used from any MS platform,

True.  However, MSXML does not have to be used.

| including VB and C++;

Microsoft Visual Basic and (Microsoft Visual) C++ are programming languages, 
not (computing) platforms.  (x86 is a platform.)

<http://en.wikipedia.org/wiki/Computing_platform>

| there are methods and properties on XMLHTTP that are useless in scripting
| and even cause some confusion (such as the much maligned onreadystate,

There is no “onreadystate”; there is an “onreadystatechange” property on XHR 
objects.

<http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>
<http://msdn.microsoft.com/en-us/library/ie/dd576252(v=vs.85).aspx>

| which makes plenty of sense once you realize that MSXMLHTTP, when used
| from C++ and VB, give you full interactive access to the internal IStream
| via the responseStream property.)

This statement does not make any sense.  He claims that “there are methods 
and properties that are useless in *scripting* …” and that this makes sense 
because “MSXMLHTTP, when used from C++ and VB [*not* from scripting], gives 
you full interactive access …“?

It is necessary to make sure that the value of the “readyState” property has 
reached the value of 4 (“DONE”) before one accesses the “responseText” or 
“responseXML” properties.  It is not clear what Tom Trenka meant here, but 
if he means “readyState” (instead of “onreadystate” which does not exist), 
he is simply talking nonsense.

There is/was a “responseStream” property in the IXMLHttpRequest interface, 
but whether it is/was available to userland I do not know.  (The latest Wine 
upgrade broke my capability of running IE 6.)  I assume it was not available 
because of the return type; the returned (referred) value would have to 
implement IStream.

<http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>	
<http://msdn.microsoft.com/en-us/library/ie/hh772830(v=vs.85).aspx>

At least Robert Nyman subsequently pointed out – in a way – that Tom 
Trenka’s logic must be flawed.  (You need to read more carefully.)
 
>>>>>> […]  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.
>> What do you mean by that?
> 
> "Forget the whole idea." - I thought that point no. 3 is the right thing
> to do and "whole idea" is not applicable for that point.

I understood your 1. and 2. to be alternatives, mutually exclusive; so 3. 
and 4. are alternatives I suggested, equally mutually exclusive and 
excluding 1. and 2.
 
>>>>>>>> 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.
>> What did you not understand?
> 
> I had a bit of homework and explore the knowledge. So, here what I
> understood now: "interface’s *attribute*" represent
> https://developer.mozilla.org/en-US/docs/Web/API/Attr.

No, that has nothing to do with it.  Instead:

The W3C/WHATWG DOM specifies interfaces (APIs) with attributes and methods:

<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html>

Those interfaces are implemented in a programming language (usually, C or 
C++).  The implementations are exposed (via language binding) by host 
environments (like Web browsers) to (here) ECMAScript-based programming 
languages as (here) properties and methods of objects:

<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ecma-script-binding.html>

We only know that the type of an attribute of an interface must be 
convertible to a native ECMAScript type.  Otherwise the implementation of 
the interface would be useless to userland code.

We do not know, for example, if the implementor heeded the specification and 
implemented the “tabIndex” attribute of the HTMLInputElement interface as a 
property that stores a number value; it makes as much sense to use a string 
value (even more sense, considering IEEE-754 precision and *really* large 
documents).  This has happened with style properties in the past and it may 
happen again.  (If that reads like paranoia, consider the current
non-concept of a “Living Standard”.)

<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>

> However, looks like "nodeType" property, at least in Gecko implementation,
> is deprecated (I see it in section "Deprecated properties and methods").

You need to read more carefully:

,----
| Warning: In DOM Core 1, 2 and 3, Attr inherited from Node. This is no 
| longer the case in DOM4. In order to bring the implementation of Attr up 
| to specification, work is underway to change it to no longer inherit from 
| Node. You should not be using any Node properties or methods on Attr 
| objects. Starting in Gecko 7.0 (Firefox 7.0 / Thunderbird 7.0 / SeaMonkey 
| 2.4), the ones that are going to be removed output warning messages to the 
| console. You should revise your code accordingly. See Deprecated 
| properties and methods for a complete list.
`----
 
> So, I should use
> https://developer.mozilla.org/en-US/docs/Web/API/Element.getAttributeNode
> to check if property exists and then decide to use its value?

No.

> Or do something else?

Yes.
 
>>>> 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.
>>
>> In your case, AFAICS the target object is an arbitrary element object
>> and, because of recursion, each of its descendant node objects.  So you
>> will have to test each of those objects at least once.  (Of course, if
>> “textContent” is supported on the element object of your initial
>> serialization call, you can return its value and are done.  No iteration
>> and recursion necessary then.)
> 
> Is then sufficient to check property only once on the root element of
> the document?

In general, no.

> Just what you wrote in previous message(s).
> 
> if (typeof document.documentElement != "undefined"
>        && typeof document.documentElement.textContent == "string")
>    {[...]

Just to refine your error-prone code.
 
> Of course, then I need to assume that other elements support textContent
> as well as Element
            ^the?
> (https://developer.mozilla.org/en-US/docs/DOM/element) that is the root
> element of the document.

Yes, depending on whether you omitted the definite article above and I 
understand you correctly.

______
¹ For lack of a better term.  With “userland” I do not mean only “outside
  the kernel” of the operating system, as it is commonly understood, but
  also outside the language implementation as provided by the runtime
  environment.  Or, if you consider the features provided by the script
  engine (the language implementation) your kernel – the core of the
  language –, the part that the user of the script engine cannot change,
  outside of *that* kernel.
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23396

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>> [...]
>>>>>> 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".
>>>
>>> What do you mean by that?
>>
>> I mean that saying like "I would not refer to such nonsense." doesn't
>> bring any value. Instead of that I would expect: "Specified comment is
>> "nonsense" because of ... [and here are arguments]".
>
> It would be easier to say which statements in it are _not_ nonsense, as
> there are fewer of them.

Ok.

> Tom Trenka states there:
> | Internet Explorer displays “unknown” when the object in question is on the
> | other side of a COM+ bridge.
>
> Internet Explorer displays “unknown” if the result of the “typeof” operation
> is displayed in this case.  It (or rather, the JScript engine) throws an
> (AFAIK unrecoverable) exception on any other access.
>
> That “the object is on the other side of a COM+ bridge” may or may not be
> true.  Certainly it does not have to be COM+ object; a COM object suffices
> as this was the case before there was COM+.  (isMethod() came about *before*
> 2003 CE, so before COM+.)
>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
>
> | You may not know this or realize this, but MS’s XMLHTTP object is part of
> | a different COM+ object that implements IUnknown;
>
> “MS’s XMLHTTP object” is _not_ part of another object.
>
> In the form referred by the result of the expression
>
>    new ActiveXObject("Microsoft.XMLHTTP")
>
> it is a so-called “(OLE) Automation object” (an ActiveX object, now a
> special COM object) whose server name is “Microsoft” and type name is
> “XMLHTTP”.
>
> <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.84).aspx>
> <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.94).aspx>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
>
> | when you call methods on it, you’re doing so over a COM bridge
>
> True as of the date of the cited comment when there was no native
> XMLHttpRequest:
>
> <http://msdn.microsoft.com/en-us/library/ms535874(v=vs.85).aspx>
>
> (It should be noted that you find “XMLHttpRequest” in Microsoft's “Internet
> Explorer API Reference” but not in their “JavaScript Reference”.  One must
> conclude that it is referring to a host object, not a native JScript object
> as it is often claimed.)
>
> | and not calling native JavaScript.
>
> Nothing is called when using “typeof”.  (When you see someone naming read
> access or mere evaluation of an expression a “call”, and the thing being
> read or evaluated “called”, this is one sure sign of wannabe talk.)
>
> Internet Explorer as of the date of the cited comment supported JScript (it
> still does, it is just named differently now, mainly for marketing reasons).
>
> <http://msdn.microsoft.com/en-us/library/hbxc2t98(v=vs.84).aspx>
>
> | Basically that’s MS’s answer if you try to test or access something that’s
> | not a true part of the JScript engine.
>
> (Whether the statement that some object in *userland*¹ would be part of a
> script engine makes any sense is questionable already.  I am assuming he
> meant “part of the JScript *language*” here.)
>
> *No* DOM object, in general *no* host object, is part of JScript (the
> language, not an engine), not only COM(+) objects.  (That differentiates
> *host* objects from *native* objects.)
>
> In particular, Microsoft’s XMLHTTP object, whatever the version, is not
> provided by jscript.dll, but by mshtml.dll [“new
> ActiveXObject("Microsoft.XMLHTTP") or “new XMLHttpRequest”] or msxml2.dll
> [new ActiveXObject("Msxml2.XMLHTTP")].
>
> | Before you complain about it further, bear in mind that MSXML was designed
> | to be used from any MS platform,
>
> True.  However, MSXML does not have to be used.
>
> | including VB and C++;
>
> Microsoft Visual Basic and (Microsoft Visual) C++ are programming languages,
> not (computing) platforms.  (x86 is a platform.)
>
> <http://en.wikipedia.org/wiki/Computing_platform>
>
> | there are methods and properties on XMLHTTP that are useless in scripting
> | and even cause some confusion (such as the much maligned onreadystate,
>
> There is no “onreadystate”; there is an “onreadystatechange” property on XHR
> objects.
>
> <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>
> <http://msdn.microsoft.com/en-us/library/ie/dd576252(v=vs.85).aspx>
>
> | which makes plenty of sense once you realize that MSXMLHTTP, when used
> | from C++ and VB, give you full interactive access to the internal IStream
> | via the responseStream property.)
>
> This statement does not make any sense.  He claims that “there are methods
> and properties that are useless in *scripting* …” and that this makes sense
> because “MSXMLHTTP, when used from C++ and VB [*not* from scripting], gives
> you full interactive access …“?
>
> It is necessary to make sure that the value of the “readyState” property has
> reached the value of 4 (“DONE”) before one accesses the “responseText” or
> “responseXML” properties.  It is not clear what Tom Trenka meant here, but
> if he means “readyState” (instead of “onreadystate” which does not exist),
> he is simply talking nonsense.
>
> There is/was a “responseStream” property in the IXMLHttpRequest interface,
> but whether it is/was available to userland I do not know.  (The latest Wine
> upgrade broke my capability of running IE 6.)  I assume it was not available
> because of the return type; the returned (referred) value would have to
> implement IStream.
>
> <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>	
> <http://msdn.microsoft.com/en-us/library/ie/hh772830(v=vs.85).aspx>

Thank you very much for above explanation.

> At least Robert Nyman subsequently pointed out – in a way – that Tom
> Trenka’s logic must be flawed.  (You need to read more carefully.)

I was reading whole article few weeks before I've posted the link. 
Probably I have overlook something, but will try to read more carefully 
next time.

>>>>>>> […]  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.
>>> What do you mean by that?
>>
>> "Forget the whole idea." - I thought that point no. 3 is the right thing
>> to do and "whole idea" is not applicable for that point.
>
> I understood your 1. and 2. to be alternatives, mutually exclusive; so 3.
> and 4. are alternatives I suggested, equally mutually exclusive and
> excluding 1. and 2.

1. I will more closely again at JSX how it's done there.
2. Solution no. 3 - I am fine with that.

>>>>>>>>> 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.
>>> What did you not understand?
>>
>> I had a bit of homework and explore the knowledge. So, here what I
>> understood now: "interface’s *attribute*" represent
>> https://developer.mozilla.org/en-US/docs/Web/API/Attr.
>
> No, that has nothing to do with it.  Instead:
>
> The W3C/WHATWG DOM specifies interfaces (APIs) with attributes and methods:
>
> <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html>
>
> Those interfaces are implemented in a programming language (usually, C or
> C++).  The implementations are exposed (via language binding) by host
> environments (like Web browsers) to (here) ECMAScript-based programming
> languages as (here) properties and methods of objects:
>
> <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ecma-script-binding.html>
>
> We only know that the type of an attribute of an interface must be
> convertible to a native ECMAScript type.  Otherwise the implementation of
> the interface would be useless to userland code.
>
> We do not know, for example, if the implementor heeded the specification and
> implemented the “tabIndex” attribute of the HTMLInputElement interface as a
> property that stores a number value; it makes as much sense to use a string
> value (even more sense, considering IEEE-754 precision and *really* large
> documents).  This has happened with style properties in the past and it may
> happen again.  (If that reads like paranoia, consider the current
> non-concept of a “Living Standard”.)
>
> <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>

Again, thank you for above explanation.

>> However, looks like "nodeType" property, at least in Gecko implementation,
>> is deprecated (I see it in section "Deprecated properties and methods").
>
> You need to read more carefully:

Even, if I am reading carefully it doesn't means that's everything is 
clear for me for the first time. Documentation may not be clear, for 
example. ;-)

> ,----
> | Warning: In DOM Core 1, 2 and 3, Attr inherited from Node. This is no
> | longer the case in DOM4. In order to bring the implementation of Attr up
> | to specification, work is underway to change it to no longer inherit from
> | Node. You should not be using any Node properties or methods on Attr
> | objects. Starting in Gecko 7.0 (Firefox 7.0 / Thunderbird 7.0 / SeaMonkey
> | 2.4), the ones that are going to be removed output warning messages to the
> | console. You should revise your code accordingly. See Deprecated
> | properties and methods for a complete list.
> `----
>
>> So, I should use
>> https://developer.mozilla.org/en-US/docs/Web/API/Element.getAttributeNode
>> to check if property exists and then decide to use its value?
>
> No.
>
>> Or do something else?
>
> Yes.
>
>>>>> 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.
>>>
>>> In your case, AFAICS the target object is an arbitrary element object
>>> and, because of recursion, each of its descendant node objects.  So you
>>> will have to test each of those objects at least once.  (Of course, if
>>> “textContent” is supported on the element object of your initial
>>> serialization call, you can return its value and are done.  No iteration
>>> and recursion necessary then.)
>>
>> Is then sufficient to check property only once on the root element of
>> the document?
>
> In general, no.
>
>> Just what you wrote in previous message(s).
>>
>> if (typeof document.documentElement != "undefined"
>>         && typeof document.documentElement.textContent == "string")
>>     {[...]
>
> Just to refine your error-prone code.

Ok, will refine my code based on how it's done in JSX. At least I'll try.

>> Of course, then I need to assume that other elements support textContent
>> as well as Element
>              ^the?

Yes, the.

>> (https://developer.mozilla.org/en-US/docs/DOM/element) that is the root
>> element of the document.
>
> Yes, depending on whether you omitted the definite article above and I
> understand you correctly.

Thank you helping me and sorry for some delay in response.

> ______
> ¹ For lack of a better term.  With “userland” I do not mean only “outside
>    the kernel” of the operating system, as it is commonly understood, but
>    also outside the language implementation as provided by the runtime
>    environment.  Or, if you consider the features provided by the script
>    engine (the language implementation) your kernel – the core of the
>    language –, the part that the user of the script engine cannot change,
>    outside of *that* kernel.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

#23400

Order  Online Overnight, Ketamine Online Pharmacy, Order Ketamine Cod Overnight Delivery. 
Buy Ketamine Online Cod Only, Buy Ketamine Cod, Buy Ketamine Online With Mastercard. 
Buy Ketamine Online Cod, Order Ketamine Online, Legal Buy Ketamine Online 
(c)2012-2013. Top Pharmacy List! Best Prices Online! 
Buy Ketamine(R) Online! ENTER HERE! 
********************************************** 
. 
> http://ed.bestonlinefinn.net/?q=Ketamine < - BUY Ketamine(R) ONLINE, CLICK HERE! 
. 
. 
********************************************** 
. 
> http://us.bestonlinefinn.net/?q=Ketamine < - BUY Ketamine(R) ONLINE, CLICK HERE! 
. 
. 
********************************************** 
Buy Ketamine(R) Online Without A Prescription 

On Tuesday, March 4, 2014 8:51:36 PM UTC+1, Cezary Tomczyk wrote:
> Thomas 'PointedEars' Lahn wrote:
> 
> > Cezary Tomczyk wrote:
> 
> >
> 
> >> Thomas 'PointedEars' Lahn wrote:
> 
> >>> Cezary Tomczyk wrote:
> 
> >>>> Thomas 'PointedEars' Lahn wrote:
> 
> >>>>> Cezary Tomczyk wrote:
> 
> >>>> [...]
> 
> >>>>>> 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".
> 
> >>>
> 
> >>> What do you mean by that?
> 
> >>
> 
> >> I mean that saying like "I would not refer to such nonsense." doesn't
> 
> >> bring any value. Instead of that I would expect: "Specified comment is
> 
> >> "nonsense" because of ... [and here are arguments]".
> 
> >
> 
> > It would be easier to say which statements in it are _not_ nonsense, as
> 
> > there are fewer of them.
> 
> 
> 
> Ok.
> 
> 
> 
> > Tom Trenka states there:
> 
> > | Internet Explorer displays "unknown" when the object in question is on the
> 
> > | other side of a COM+ bridge.
> 
> >
> 
> > Internet Explorer displays "unknown" if the result of the "typeof" operation
> 
> > is displayed in this case.  It (or rather, the JScript engine) throws an
> 
> > (AFAIK unrecoverable) exception on any other access.
> 
> >
> 
> > That "the object is on the other side of a COM+ bridge" may or may not be
> 
> > true.  Certainly it does not have to be COM+ object; a COM object suffices
> 
> > as this was the case before there was COM+.  (isMethod() came about *before*
> 
> > 2003 CE, so before COM+.)
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx>
> 
> > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
> 
> >
> 
> > | You may not know this or realize this, but MS's XMLHTTP object is part of
> 
> > | a different COM+ object that implements IUnknown;
> 
> >
> 
> > "MS's XMLHTTP object" is _not_ part of another object.
> 
> >
> 
> > In the form referred by the result of the expression
> 
> >
> 
> >    new ActiveXObject("Microsoft.XMLHTTP")
> 
> >
> 
> > it is a so-called "(OLE) Automation object" (an ActiveX object, now a
> 
> > special COM object) whose server name is "Microsoft" and type name is
> 
> > "XMLHTTP".
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.84).aspx>
> 
> > <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.94).aspx>
> 
> > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
> 
> >
> 
> > | when you call methods on it, you're doing so over a COM bridge
> 
> >
> 
> > True as of the date of the cited comment when there was no native
> 
> > XMLHttpRequest:
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/ms535874(v=vs.85).aspx>
> 
> >
> 
> > (It should be noted that you find "XMLHttpRequest" in Microsoft's "Internet
> 
> > Explorer API Reference" but not in their "JavaScript Reference".  One must
> 
> > conclude that it is referring to a host object, not a native JScript object
> 
> > as it is often claimed.)
> 
> >
> 
> > | and not calling native JavaScript.
> 
> >
> 
> > Nothing is called when using "typeof".  (When you see someone naming read
> 
> > access or mere evaluation of an expression a "call", and the thing being
> 
> > read or evaluated "called", this is one sure sign of wannabe talk.)
> 
> >
> 
> > Internet Explorer as of the date of the cited comment supported JScript (it
> 
> > still does, it is just named differently now, mainly for marketing reasons).
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/hbxc2t98(v=vs.84).aspx>
> 
> >
> 
> > | Basically that's MS's answer if you try to test or access something that's
> 
> > | not a true part of the JScript engine.
> 
> >
> 
> > (Whether the statement that some object in *userland*¹ would be part of a
> 
> > script engine makes any sense is questionable already.  I am assuming he
> 
> > meant "part of the JScript *language*" here.)
> 
> >
> 
> > *No* DOM object, in general *no* host object, is part of JScript (the
> 
> > language, not an engine), not only COM(+) objects.  (That differentiates
> 
> > *host* objects from *native* objects.)
> 
> >
> 
> > In particular, Microsoft's XMLHTTP object, whatever the version, is not
> 
> > provided by jscript.dll, but by mshtml.dll ["new
> 
> > ActiveXObject("Microsoft.XMLHTTP") or "new XMLHttpRequest"] or msxml2.dll
> 
> > [new ActiveXObject("Msxml2.XMLHTTP")].
> 
> >
> 
> > | Before you complain about it further, bear in mind that MSXML was designed
> 
> > | to be used from any MS platform,
> 
> >
> 
> > True.  However, MSXML does not have to be used.
> 
> >
> 
> > | including VB and C++;
> 
> >
> 
> > Microsoft Visual Basic and (Microsoft Visual) C++ are programming languages,
> 
> > not (computing) platforms.  (x86 is a platform.)
> 
> >
> 
> > <http://en.wikipedia.org/wiki/Computing_platform>
> 
> >
> 
> > | there are methods and properties on XMLHTTP that are useless in scripting
> 
> > | and even cause some confusion (such as the much maligned onreadystate,
> 
> >
> 
> > There is no "onreadystate"; there is an "onreadystatechange" property on XHR
> 
> > objects.
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>
> 
> > <http://msdn.microsoft.com/en-us/library/ie/dd576252(v=vs.85).aspx>
> 
> >
> 
> > | which makes plenty of sense once you realize that MSXMLHTTP, when used
> 
> > | from C++ and VB, give you full interactive access to the internal IStream
> 
> > | via the responseStream property.)
> 
> >
> 
> > This statement does not make any sense.  He claims that "there are methods
> 
> > and properties that are useless in *scripting* ..." and that this makes sense
> 
> > because "MSXMLHTTP, when used from C++ and VB [*not* from scripting], gives
> 
> > you full interactive access ..."?
> 
> >
> 
> > It is necessary to make sure that the value of the "readyState" property has
> 
> > reached the value of 4 ("DONE") before one accesses the "responseText" or
> 
> > "responseXML" properties.  It is not clear what Tom Trenka meant here, but
> 
> > if he means "readyState" (instead of "onreadystate" which does not exist),
> 
> > he is simply talking nonsense.
> 
> >
> 
> > There is/was a "responseStream" property in the IXMLHttpRequest interface,
> 
> > but whether it is/was available to userland I do not know.  (The latest Wine
> 
> > upgrade broke my capability of running IE 6.)  I assume it was not available
> 
> > because of the return type; the returned (referred) value would have to
> 
> > implement IStream.
> 
> >
> 
> > <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>	
> 
> > <http://msdn.microsoft.com/en-us/library/ie/hh772830(v=vs.85).aspx>
> 
> 
> 
> Thank you very much for above explanation.
> 
> 
> 
> > At least Robert Nyman subsequently pointed out - in a way - that Tom
> 
> > Trenka's logic must be flawed.  (You need to read more carefully.)
> 
> 
> 
> I was reading whole article few weeks before I've posted the link. 
> 
> Probably I have overlook something, but will try to read more carefully 
> 
> next time.
> 
> 
> 
> >>>>>>> [...]  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.
> 
> >>> What do you mean by that?
> 
> >>
> 
> >> "Forget the whole idea." - I thought that point no. 3 is the right thing
> 
> >> to do and "whole idea" is not applicable for that point.
> 
> >
> 
> > I understood your 1. and 2. to be alternatives, mutually exclusive; so 3.
> 
> > and 4. are alternatives I suggested, equally mutually exclusive and
> 
> > excluding 1. and 2.
> 
> 
> 
> 1. I will more closely again at JSX how it's done there.
> 
> 2. Solution no. 3 - I am fine with that.
> 
> 
> 
> >>>>>>>>> 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.
> 
> >>> What did you not understand?
> 
> >>
> 
> >> I had a bit of homework and explore the knowledge. So, here what I
> 
> >> understood now: "interface's *attribute*" represent
> 
> >> https://developer.mozilla.org/en-US/docs/Web/API/Attr.
> 
> >
> 
> > No, that has nothing to do with it.  Instead:
> 
> >
> 
> > The W3C/WHATWG DOM specifies interfaces (APIs) with attributes and methods:
> 
> >
> 
> > <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html>
> 
> >
> 
> > Those interfaces are implemented in a programming language (usually, C or
> 
> > C++).  The implementations are exposed (via language binding) by host
> 
> > environments (like Web browsers) to (here) ECMAScript-based programming
> 
> > languages as (here) properties and methods of objects:
> 
> >
> 
> > <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ecma-script-binding.html>
> 
> >
> 
> > We only know that the type of an attribute of an interface must be
> 
> > convertible to a native ECMAScript type.  Otherwise the implementation of
> 
> > the interface would be useless to userland code.
> 
> >
> 
> > We do not know, for example, if the implementor heeded the specification and
> 
> > implemented the "tabIndex" attribute of the HTMLInputElement interface as a
> 
> > property that stores a number value; it makes as much sense to use a string
> 
> > value (even more sense, considering IEEE-754 precision and *really* large
> 
> > documents).  This has happened with style properties in the past and it may
> 
> > happen again.  (If that reads like paranoia, consider the current
> 
> > non-concept of a "Living Standard".)
> 
> >
> 
> > <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>
> 
> 
> 
> Again, thank you for above explanation.
> 
> 
> 
> >> However, looks like "nodeType" property, at least in Gecko implementation,
> 
> >> is deprecated (I see it in section "Deprecated properties and methods").
> 
> >
> 
> > You need to read more carefully:
> 
> 
> 
> Even, if I am reading carefully it doesn't means that's everything is 
> 
> clear for me for the first time. Documentation may not be clear, for 
> 
> example. ;-)
> 
> 
> 
> > ,----
> 
> > | Warning: In DOM Core 1, 2 and 3, Attr inherited from Node. This is no
> 
> > | longer the case in DOM4. In order to bring the implementation of Attr up
> 
> > | to specification, work is underway to change it to no longer inherit from
> 
> > | Node. You should not be using any Node properties or methods on Attr
> 
> > | objects. Starting in Gecko 7.0 (Firefox 7.0 / Thunderbird 7.0 / SeaMonkey
> 
> > | 2.4), the ones that are going to be removed output warning messages to the
> 
> > | console. You should revise your code accordingly. See Deprecated
> 
> > | properties and methods for a complete list.
> 
> > `----
> 
> >
> 
> >> So, I should use
> 
> >> https://developer.mozilla.org/en-US/docs/Web/API/Element.getAttributeNode
> 
> >> to check if property exists and then decide to use its value?
> 
> >
> 
> > No.
> 
> >
> 
> >> Or do something else?
> 
> >
> 
> > Yes.
> 
> >
> 
> >>>>> 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.
> 
> >>>
> 
> >>> In your case, AFAICS the target object is an arbitrary element object
> 
> >>> and, because of recursion, each of its descendant node objects.  So you
> 
> >>> will have to test each of those objects at least once.  (Of course, if
> 
> >>> "textContent" is supported on the element object of your initial
> 
> >>> serialization call, you can return its value and are done.  No iteration
> 
> >>> and recursion necessary then.)
> 
> >>
> 
> >> Is then sufficient to check property only once on the root element of
> 
> >> the document?
> 
> >
> 
> > In general, no.
> 
> >
> 
> >> Just what you wrote in previous message(s).
> 
> >>
> 
> >> if (typeof document.documentElement != "undefined"
> 
> >>         && typeof document.documentElement.textContent == "string")
> 
> >>     {[...]
> 
> >
> 
> > Just to refine your error-prone code.
> 
> 
> 
> Ok, will refine my code based on how it's done in JSX. At least I'll try.
> 
> 
> 
> >> Of course, then I need to assume that other elements support textContent
> 
> >> as well as Element
> 
> >              ^the?
> 
> 
> 
> Yes, the.
> 
> 
> 
> >> (https://developer.mozilla.org/en-US/docs/DOM/element) that is the root
> 
> >> element of the document.
> 
> >
> 
> > Yes, depending on whether you omitted the definite article above and I
> 
> > understand you correctly.
> 
> 
> 
> Thank you helping me and sorry for some delay in response.
> 
> 
> 
> > ______
> 
> > ¹ For lack of a better term.  With "userland" I do not mean only "outside
> 
> >    the kernel" of the operating system, as it is commonly understood, but
> 
> >    also outside the language implementation as provided by the runtime
> 
> >    environment.  Or, if you consider the features provided by the script
> 
> >    engine (the language implementation) your kernel - the core of the
> 
> >    language -, the part that the user of the script engine cannot change,
> 
> >    outside of *that* kernel.
> 
> 
> 
> -- 
> 
> Cezary Tomczyk
> 
> http://www.ctomczyk.pl/

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

#23204

Cezary Tomczyk wrote:

> To get inner text of HTML element I've been using:
> 
> function get_inner_text(node) {
>      if (node.nodeType === 3) {
>          return node.data;
>      }
> 
>      var txt = '';
> 
>      node = node.firstChild;
>      while (node) {
>          txt += get_inner_text(node);
>          node = node.nextSibling;
>      }
>      return txt.replace(/\s+/g, ' ');
              ^^^^^^^^^^^^^^^^^^^^^^^^
This is _not_ equivalent to node.textContent, see
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent>.

> }
> 
> However, I am thinking about simplifying it and instead of:
> 
> var str = get_inner_text(elm); // elm represent reference to the HTML
> element
> 
> I would use now:
> 
> var str = elm.textContent || elm.data || elm.innerText;
> 
> Is it a good approach?

No.

> Any suggestions?

Yes.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#23209

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> To get inner text of HTML element I've been using:
>>
>> function get_inner_text(node) {
>>       if (node.nodeType === 3) {
>>           return node.data;
>>       }
>>
>>       var txt = '';
>>
>>       node = node.firstChild;
>>       while (node) {
>>           txt += get_inner_text(node);
>>           node = node.nextSibling;
>>       }
>>       return txt.replace(/\s+/g, ' ');
>                ^^^^^^^^^^^^^^^^^^^^^^^^
> This is _not_ equivalent to node.textContent, see
> <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent>.

I see. In documentation I've read that "No whitespace normalization is 
performed and the returned string does not contain the white spaces in 
element content[...]."

As for "whitespace normalization" I found that it's about "(spaces, 
tabs, and blank lines)" (http://www.w3.org/TR/REC-xml/#sec-white-space). 
However, "blank lines" means "new line" using \r\n or \r or \n, right?

Also, how "whitespace normalization" should work? E.g. replacing "   " 
to " "? Any suggestions? In the meantime I am doing some research around 
that.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web