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

Groups > comp.lang.javascript > #23363

Re: Get inner text of HMTL element

Show all headers | View raw

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.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 18:21 +0100
  Re: Get inner text of HMTL element Martin Honnen <mahotrash@yahoo.de> - 2014-02-22 19:31 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 20:51 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 21:11 +0100
        Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 21:37 +0100
          Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 22:05 +0100
            Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 23:38 +0100
              Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 10:43 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 14:50 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 15:48 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 21:01 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:34 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-27 21:41 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 22:32 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-28 13:44 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-28 16:54 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-03-04 20:51 +0100
                Re: Get inner text of HMTL element ompalompasales2@gmail.com - 2014-03-04 12:59 -0800
  Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 20:59 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 22:23 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 23:32 +0100
  Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-22 21:27 -0300
    Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 05:35 +0100
      Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-23 15:29 -0300
        Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 21:01 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 20:02 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 21:55 +0100
        Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 08:37 +0100
          Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:30 +0100
            Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 15:09 -0300
              Re: Get inner text of HMTL element Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 19:43 +0100
                Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 18:12 -0300
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:51 +0100
              Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-25 19:49 +0000
                Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 05:20 -0300
                Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-26 17:10 +0100
                OT - Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 15:48 -0300
                Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-26 22:43 +0100
                Re: OT - Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:00 +0000
                Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-28 10:50 +0100
                Re: OT - Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-27 10:57 +0100
                Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:46 +0000

csiph-web