FAQ Topic - How do I access a frame's content? (2009-10-25)
in [JavaScript]
|
Prev: Implicit object constructor misinterpretation
Next: Creating an Object that extends Array functionality
From: Thomas 'PointedEars' Lahn on 29 Oct 2009 19:07 Garrett Smith wrote: > Dr J R Stockton wrote: >> In comp.lang.javascript message <hca8q9$4j1$1(a)news.eternal- >> september.org>, Wed, 28 Oct 2009 12:16:06, Garrett Smith >> <dhtmlkitchen(a)gmail.com> posted: >>> As I explained, the innerText/textContent is not related to the frame; >>> it is related to elements. An entry on getting frame's >>> innerText/textContent implies that a frame has a property >>> innerText/textContent. That would be false. >> >> In a FAQ, answers should be classified according to the nature of the >> question, not according to the nature of the answer. >> >> A common reasoning for questioning is that the answer is not where the >> questioner thought to look. >> >> In ordinary English, a frame, or at least an iframe, does commonly have >> an innerText or textProperty property; but it is kept by one of its >> descendants. > > The IFRAME element and the frame (as in frames[0] or > anIframe.contentWindow), are different. > > It is important to be clear on the distinction. These are technical > terms, not ordinary English terms. Don't be ridiculous. The standards-compliant `textContent' property of the object referred to by the standards-compliant `contentDocument' property of an `iframe' element object (which is the same as the object referred to by the `document' property of the object referred to by the proprietary `contentWindow' property of an `iframe' element object) undoubtedly provides access to the `iframe''s content. >> Ask the average elderly person whether they have grandchildren. >> Commonly the answer will be "Yes"; it will not be "No; but I have >> children who have children". > > So what? So you are being deliberately obtuse. >> Anyway, the FAQ said "9.2 How do I access a frame's content?", rightly >> omitting any reference to the structure within the frame. >> > The "content" would be in the document. And if the document would be a plain text document, the `textContent' property of wrapping document element object would yield exactly its content. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Dr J R Stockton on 29 Oct 2009 15:48 In comp.lang.javascript message <hccj1f$6u8$1(a)news.eternal- september.org>, Thu, 29 Oct 2009 10:22:40, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Is this the issue I evaded? > >As I stated, textContent is not related to the frame; stating >otherwise, >as the proposal for section (9.2) "9.2 How do I access a frame's >content?" would be misleading (counterproductive to FAQ goals). If a user's browser shows an iframe element (called Fram), into which a typical Web page has been loaded (e.g. by Fram.src=WebPage.htm), the user sees something matching the meaning of the word "frame" on the OED; and it contains visible material, some of which matches "text" in the OED. The frame therefore contains text, and it is reasonable to ask "How do I access a frame's content?", and therefore to have that as a FAQ section Subject. Text, in the OED sense, is commonly an important part of a frame's content, and so the answer should include how to read it. The fact that the frame element does not contain directly a method or property that directly yields the text is irrelevant. For the question, the answer should address accessing the "JavaScript" content AND the "HTML" content AND the "style" content. Since all that is easy to do once one knows how, much of the answer can readily be given as a series of examples with a little comment : for the frame Fram - COD = Fram.contentDocument // Text : BOD = COD.body TXT = BOD.textContent || BOD.innerText // latter is needed for MSIE // HTML : HTM = BOD.innerHTML // ?? // Accoutrements : ANK = COD.anchors ; LNK = COD.links ; // etc. // JavaScript : COW = Fram.contentWindow VAR = COW.moo // Fram's JavaScript's var moo Those are probably about right, but not directly tested; and a couple of DOM methods could be shown. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: Dr J R Stockton on 29 Oct 2009 16:10 In comp.lang.javascript message <e317ec92-048b-4d6d-be38-ce3e14a5933a(a)j4 g2000yqe.googlegroups.com>, Wed, 28 Oct 2009 17:30:34, VK <schools_ring(a)yahoo.com> posted: >Dr J R Stockton wrote: >> >> In effect, I want to read the file, HTML or TXT, as it exists on disc. > >VK wrote: >> >You cannot do it for the reason explained at >> >http://groups.google.com/group/comp.lang.javascript/msg/d9f3f6724bada573 > >Dr J R Stockton wrote: >> Unconvincing, because I *am* doing it, > >You don't, it is your delusion. > >> to the extent that is essential >> for the task. �If you consider under what circumstances what can work, >> you should be able to deduce how and why I am doing it. > >I don't know how and why are you doing it, but it was stated that "I >want to read the file, HTML or TXT, as it exists on disc." As long as >you are not using AJAX calls - and you don't - you are not able and >you are not reading any files "HTML or TXT, as it exists on disc" - >however wide the definition "as it exists on disc" would be taken. Give or take irrelevant questions of character coding and newline representation, I have been getting, by using innerHTML and by using innerText, a string which agrees visually with the content of a TXT file on disc, as would be shown by Notepad. I still WANT to read a HTML file correspondingly, seeing the source lines as per Notepad; but I don't really NEED to, since what I can get suffices for that part of the desired work that is NECESSARY. >As much as I can understand you request, you want to get the textual >data from the loaded document in full and without omission which is >doable but it is a completely different task. Yes, that is what I still WANT. But it is more than, in the case of an HTML page, I really NEED. Therefore progress is being made. Associated query : I have read a TXT file from disc, getting a matching string. It consists of many lines containing words separated by punctuation. They all start with the same sequence of words and punctuation (improbably, zero length), but after that there is always non-zero length. No two lines completely agree. What is the nicest way of determining the common part AND obtaining in sequence strings for the varying parts? Think of it as like a representation of a directory tree. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: Garrett Smith on 30 Oct 2009 02:11 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hca8q9$4j1$1(a)news.eternal- >>> september.org>, Wed, 28 Oct 2009 12:16:06, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>>> As I explained, the innerText/textContent is not related to the frame; >>>> it is related to elements. An entry on getting frame's >>>> innerText/textContent implies that a frame has a property >>>> innerText/textContent. That would be false. >>> In a FAQ, answers should be classified according to the nature of the >>> question, not according to the nature of the answer. >>> >>> A common reasoning for questioning is that the answer is not where the >>> questioner thought to look. >>> >>> In ordinary English, a frame, or at least an iframe, does commonly have >>> an innerText or textProperty property; but it is kept by one of its >>> descendants. >> The IFRAME element and the frame (as in frames[0] or >> anIframe.contentWindow), are different. >> >> It is important to be clear on the distinction. These are technical >> terms, not ordinary English terms. > > Don't be ridiculous. The standards-compliant `textContent' property of the > object referred to by the standards-compliant `contentDocument' property of > an `iframe' element object (which is the same as the object referred to by > the `document' property of the object referred to by the proprietary > `contentWindow' property of an `iframe' element object) undoubtedly provides > access to the `iframe''s content. > The iframe contents could be an image, an HTML document with a Flash movie, javascript, a canvas. The IFRAME content, in those cases, is what? frame.contentWindow.document.textContent? Wow. You're so smart. In contrast, there is a node that has a textContent or innerText property. That node may have a document, which may have a parentWindow, and the |parent| of that parentWindow may be including that resource via an IFRAME or FRAME element. >>> Ask the average elderly person whether they have grandchildren. >>> Commonly the answer will be "Yes"; it will not be "No; but I have >>> children who have children". >> So what? > > So you are being deliberately obtuse. No, I am correct. As long as I have something to say about it, the entry will correctly explain how to access the window object of the IFRAME. | A frame's content window can be found from the frames collection. And from there, the window has a document, which has a |getElementById|, a |forms| property, etc. All standard fare, basic stuff. > >>> Anyway, the FAQ said "9.2 How do I access a frame's content?", rightly >>> omitting any reference to the structure within the frame. >>> >> The "content" would be in the document. > > And if the document would be a plain text document, the `textContent' > property of wrapping document element object would yield exactly its > content. > DOM properties on elements in a plain text document? Browsers do create HTML documents for text/plain documents and give a quirks mode dom. It isn't standard, though, is it? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 30 Oct 2009 16:05
In comp.lang.javascript message <1486365.uhbGJ8BuQJ(a)PointedEars.de>, Thu, 29 Oct 2009 19:50:30, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> posted: >Dr J R Stockton wrote: > >> Thomas 'PointedEars' Lahn posted: >>> Dr J R Stockton wrote: >>>> Thomas 'PointedEars' Lahn posted: >>>>> Dr J R Stockton wrote: >>>>>> I want to read as on disc, certainly; but my needs are substantially >>>>>> satisfied for TXT files by what innerText and innerHTML show, and for >>>>>> HTML files by what is actually revealed. >>>>>> >>>>>> It's annoying that Firefox seems to lack innerText of iframe content, >>>>> >>>>> It implements the `textContent' property instead, like any other >>>>> browser >>>>> standards-compliant in that regard. (Discussed here ad nauseam). >>>> >>>> I see. Then why did you not suggest that <FAQENTRY> it should be >>>> included in the frame-content section (9.2) of the FAQ? >>> >>>Because I do not think it is a frequently asked question. >> >> Then why did you not suggest that the section be removed? > >Because I was not aware of its existence to date (obviously I never had a >problem that required searching the comp.lang.javascript FAQ for it), There have been sections in the FAQ on frames for *at least* four years (w.e.f. Thursday next); Google and Wayback will show many instances. You very frequently advise people, in a peremptory manner, to search the archives before posting. You will have seen posted here, in FAQ sections and elsewhere, injunctions to read the FAQ. The FAQ begins with an index to its sections and subsections, naming their Subjects. Those subsections will have been posted to the newsgroup on a regular basis by Bart. Therefore, you should have KNOWN that the FAQ contained material on frames; and, in any case, you should have suspected it. Hypocrite. >>>> It's still annoying that one major browser lacks what others have (even >>>> if out of fashion), especially if the functionality is present. >>> >>>Which browser would that be? >> >> With a little more - with any - humility and/or common sense, you would >> read what you quote both before and after composing a reply. The answer >> to that question is plainly visible above, currently at the >>>> level. > >I have asked before because that implication of yours would be incorrect. >Firefox/Gecko does not lack what others have; IE/MSHTML does lack it. While >probably not in number of installations, `textContent' is the standards- >compliant approach which is supported by more current layout engines than >`innerText' is or is going to be. Firefox apparently lacks what the most-used browser (MSIE), and three other major PC browsers, have - innerText of iframe content. It is of course also a pity that IE lacks textContent - however, it is unreasonable to expect (except in Nelson's context) Microsoft to heed international standards. >>> SOP? >> OAF. > >Sorry, I am not familiar with that acronym, and it is not listed on ><http://www.merlyn.demon.co.uk/acronyms.htm#Acro> or in the usual places. Indeed not. You are incorrect in assuming it there to be an acronym. It is a well-known long-established English word, derived from the Norse : according to Google, the Norwegians and Icelanders still use it. You have just proved it apt. (As an acronym, it can be found at <http://www.acronymfinder.com/OAF.html>, with 14 meanings.) It's a good idea to read the newsgroup c.l.j and its FAQ. See below. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3 news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>. <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links. |