How can I read html data of other site (with javascript or etc)?
in [JavaScript]
|
Prev: FAQ Topic - Internationalisation and Multinationalisation in javascript. (2010-03-23)
Next: FAQ Topic - How do I format a Date object with javascript? (2010-03-28)
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 13:24 Sean Kinsey wrote: >> [Thomas 'PointedEars' Lahn wrote:] >> > [Sean Kinsey wrote:] >> > but I do know that those features _are_ indeed available in all the >> > target browsers (that being IE6/IE7). >> Whereas availability is well beside the point, though. > > Actually, when it comes to a pragmatic approach towards leveraging the > available features of a browser in order to gain new features, then it is > in fact the only point. No, further you need to make sure that an available feature under probable circumstances works as you expect. Since that is next to impossible, host object's properties, which by Specification exhibit undefined behavior, are to be avoided for storing data. And certainly doing otherwise is very far from being reliable. (I can see now that you not only misuse existing properties of host objects, but you also try to augment host objects with new properties, which is even worse than the former.) >> An assumption not supported by the available facts, of course. > > I have stated an assumption, you refer to facts. Where can I see these > facts? They come with experience for the most part. For example, you could, in the future, have a company as customer telling you that they would not update from IE 6/7 because the update would render their otherwise working software unusable. Then there is the fact not requiring as much experience that there is no IE 7+ for Windows 2000, and Windows XP, Windows Vista, or Windows 7 would not run on those machines even if their owners could afford or be willing to do the OS upgrade. > > >> It does not apply to the `name' property of iframe objects. > > > Earlier tests showed that it did (and there are many references to it > > > on the internet), but I'll retest as many things has changed in the > > > library since that piece of code was written. > > > > That fact has not changed since MSHTML 5.0, and has been discussed in > > particular by Richard Cornford here. > > I just did a new test, and based on this I have removed the before > mentioned code. I hope you have also removed the `id' attribute, replaced the ludicrous absolute positioning and added some *real* feature tests while you were at it. >> To use that metaphor, you know only a *subset* of *current* nails. > > Yes, and thats the 'nails' I target, and to be honest, the risk of IE6 > suddenly changing its behavior is minute, if not to say non-existent. It is a particularly silly approach on the World Wide Web, though, to target only one specific browser brand instead of *at least* one DOM implementation with all its non-dead past and backwards-compatible future versions. That said, you appear to be unaware that for IE 8 you are relying on a feature that originates from a *working* *draft* for a Specification, which is therefore in a constant state of flux and does not need to be supported (the same way) in the future. That is hardly raw material for production- quality code. >> >> > So in order to reach some goal (enabling cross domain messaging) I >> >> > am now _not_ allowed to use the only available techniques usable >> >> > for said goal? >> >> You are allowed to do anything stupid. Just do not expect it to work >> >> reliably, or promote it as such, and see yourself as having really >> >> understood what you are doing. >> > Well I do expect it to work reliably on all the target browser, >> There is your problem. > > A useless comment as my expectations are based on observable facts Your observations are not worth much, given that there is not only the theoretical possibility but also practical evidence of failure of this approach. >> > in fact, its an observable truth that it _does_ work in the target >> > browsers. >> How many combinations of data have you tested? > > All the relevant ones. Given that you do not know what data the user of your library is going to transfer with it, that is quite an overconfident response, but not an unusual one under these circumstances. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Sean Kinsey on 28 Mar 2010 13:45 On Mar 28, 7:24 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > >> [Thomas 'PointedEars' Lahn wrote:] > >> > [Sean Kinsey wrote:] > >> > but I do know that those features _are_ indeed available in all the > >> > target browsers (that being IE6/IE7). > >> Whereas availability is well beside the point, though. > > > Actually, when it comes to a pragmatic approach towards leveraging the > > available features of a browser in order to gain new features, then it is > > in fact the only point. > > No, further you need to make sure that an available feature under probable > circumstances works as you expect. Since that is next to impossible, host > object's properties, which by Specification exhibit undefined behavior, are > to be avoided for storing data. And certainly doing otherwise is very far > from being reliable. (I can see now that you not only misuse existing > properties of host objects, but you also try to augment host objects with > new properties, which is even worse than the former.) I'm guessing your referring to the loadFn property? That was a quick fix and I have a plan for removing it. > > >> An assumption not supported by the available facts, of course. > > > I have stated an assumption, you refer to facts. Where can I see these > > facts? > > They come with experience for the most part. For example, you could, in > the future, have a company as customer telling you that they would not > update from IE 6/7 because the update would render their otherwise working > software unusable. What is the relevance for the above statement? > > Then there is the fact not requiring as much experience that there is no IE > 7+ for Windows 2000, and Windows XP, Windows Vista, or Windows 7 would not > run on those machines even if their owners could afford or be willing to do > the OS upgrade. > And this? > > > >> It does not apply to the `name' property of iframe objects. > > > > Earlier tests showed that it did (and there are many references to it > > > > on the internet), but I'll retest as many things has changed in the > > > > library since that piece of code was written. > > > > That fact has not changed since MSHTML 5.0, and has been discussed in > > > particular by Richard Cornford here. > > > I just did a new test, and based on this I have removed the before > > mentioned code. > > I hope you have also removed the `id' attribute And why should I remove the id attribute when it is set so that the coder can more easily reference the iframe? > , replaced the ludicrous > absolute positioning Why is this ludicrous when the objective is to render the iframe off- screen? > and added some *real* feature tests while you were at > it. Again, I would really like it for you to actually stating the 'correct' approach as well as pointing out the 'wrong' one. > > >> To use that metaphor, you know only a *subset* of *current* nails. > > > Yes, and thats the 'nails' I target, and to be honest, the risk of IE6 > > suddenly changing its behavior is minute, if not to say non-existent. > > It is a particularly silly approach on the World Wide Web, though, to > target only one specific browser brand instead of *at least* one DOM > implementation with all its non-dead past and backwards-compatible future > versions. I don't target only one brand, so that line of arguments is void. > > That said, you appear to be unaware that for IE 8 you are relying on a > feature that originates from a *working* *draft* for a Specification, which > is therefore in a constant state of flux and does not need to be supported > (the same way) in the future. That is hardly raw material for production- > quality code. So, do you really think there is an inherent risk of IE8 suddenly dropping, or changing its implementation of postMessage? No, didn't think so.. > > >> >> > So in order to reach some goal (enabling cross domain messaging) I > >> >> > am now _not_ allowed to use the only available techniques usable > >> >> > for said goal? > >> >> You are allowed to do anything stupid. Just do not expect it to work > >> >> reliably, or promote it as such, and see yourself as having really > >> >> understood what you are doing. > >> > Well I do expect it to work reliably on all the target browser, > >> There is your problem. > > > A useless comment as my expectations are based on observable facts > > Your observations are not worth much, given that there is not only the > theoretical possibility but also practical evidence of failure of this > approach. > > >> > in fact, its an observable truth that it _does_ work in the target > >> > browsers. > >> How many combinations of data have you tested? > > > All the relevant ones. > > Given that you do not know what data the user of your library is going to > transfer with it, that is quite an overconfident response, but not an > unusual one under these circumstances. If you were referring to the payload data, then it does what it states, it transports string messages. And yes, it uses encoding where necessary. If it fails at transporting binary data then that is really not the libraries fault as that is not its intention - but the user can easily BASE64 encode/decode the message > > PointedEars > -- > var bugRiddenCrashPronePieceOfJunk = ( > navigator.userAgent.indexOf('MSIE 5') != -1 > && navigator.userAgent.indexOf('Mac') != -1 > ) // Plone, register_function.js:16
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 14:34 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Sean Kinsey wrote: >> >> [Thomas 'PointedEars' Lahn wrote:] >> >> > [Sean Kinsey wrote:] >> [...] you need to make sure that an available feature under >> probable circumstances works as you expect. Since that is next to >> impossible, host object's properties, which by Specification exhibit >> undefined behavior, are to be avoided for storing data. And certainly >> doing otherwise is very far from being reliable. (I can see now that >> you not only misuse existing properties of host objects, but you also >> try to augment host objects with new properties, which is even worse >> than the former.) > > I'm guessing your referring to the loadFn property? That was a quick > fix and I have a plan for removing it. I am referring to your misusing the `window.name' and `window.location.hash' properties. >> >> An assumption not supported by the available facts, of course. >> > I have stated an assumption, you refer to facts. Where can I see these >> > facts? >> They come with experience for the most part. For example, you could, in >> the future, have a company as customer telling you that they would not >> update from IE 6/7 because the update would render their otherwise >> working software unusable. > > What is the relevance for the above statement? (If you had quoted properly, you would have known.) You have stated the assumption that users would upgrade from IE 6/7. I have told you an example where they would not upgrade for a good reason. >> Then there is the fact not requiring as much experience that there is no >> IE 7+ for Windows 2000, and Windows XP, Windows Vista, or Windows 7 >> would not run on those machines even if their owners could afford or be >> willing to do the OS upgrade. > > And this? (Learn to quote.) Those people cannot be expected to upgrade to IE 8 either, so they would have to live with the side effects and error- proneness of the inappropriate alternatives you offer at the moment. For crying out loud, those people are the potential customers of your customers, and you are doing a bad job if you do not consider them. >> > > >> It does not apply to the `name' property of iframe objects. >> > > > Earlier tests showed that it did (and there are many references to >> > > > it on the internet), but I'll retest as many things has changed in >> > > > the library since that piece of code was written. >> > > That fact has not changed since MSHTML 5.0, and has been discussed >> > > in particular by Richard Cornford here. >> > I just did a new test, and based on this I have removed the before >> > mentioned code. >> I hope you have also removed the `id' attribute > > And why should I remove the id attribute when it is set so that the > coder can more easily reference the iframe? 1. IDs are not names; 2. IDs must be unique throughout the document, and they must in this case follow stricter naming rules than names; 3. The name suffices to refer to the iframe, with window.frames[...]; 4. createFrame() already returns the reference to the iframe object. >> , replaced the ludicrous absolute positioning > > Why is this ludicrous when the objective is to render the iframe off- > screen? Because that might not be achieved with a value of "-2000px" for the `left' style property, and there is a much better built-in way to hide an element (which is the *real* objective here). >> and added some *real* feature tests while you were at it. > > Again, I would really like it for you to actually stating the > 'correct' approach as well as pointing out the 'wrong' one. I could have said it has been discussed ad nauseam here, but that would not do it justice: Indeed, it is *being* discussed *constantly* here. Search the newsgroup's archives for "isMethod"/"isHostMethod". <FAQENTRY> I would like to refer you to the FAQ Notes, but they have not been updated accordingly yet (they still advocate deprecated type-converting tests as do most of the tutorials linked to from my primer). </FAQENTRY> Suffice it for me to say that `typeof' is the way to go. >> >> To use that metaphor, you know only a *subset* of *current* nails. >> > Yes, and thats the 'nails' I target, and to be honest, the risk of IE6 >> > suddenly changing its behavior is minute, if not to say non-existent. >> >> It is a particularly silly approach on the World Wide Web, though, to >> target only one specific browser brand instead of *at least* one DOM >> implementation with all its non-dead past and backwards-compatible >> future versions. > > I don't target only one brand, so that line of arguments is void. You have said that you are targeting "IE". How is that not targeting only one brand? >> That said, you appear to be unaware that for IE 8 you are relying on a >> feature that originates from a *working* *draft* for a Specification, >> which is therefore in a constant state of flux and does not need to be >> supported (the same way) in the future. That is hardly raw material for >> production- quality code. > > So, do you really think there is an inherent risk of IE8 suddenly > dropping, or changing its implementation of postMessage? > No, didn't think so.. Maybe not IE 8, but maybe 9, 10, ... >> >> > in fact, its an observable truth that it _does_ work in the target >> >> > browsers. >> >> How many combinations of data have you tested? >> > >> > All the relevant ones. >> Given that you do not know what data the user of your library is going >> to transfer with it, that is quite an overconfident response, but not an >> unusual one under these circumstances. > > If you were referring to the payload data, then it does what it > states, it transports string messages. Tell me something I don't know yet. > And yes, it uses encoding where necessary. Which only adds to the problem. > If it fails at transporting binary data then that is really not the > libraries fault as that is not its intention - but the user can easily > BASE64 encode/decode the message You miss the point. Start with: <http://support.microsoft.com/kb/208427/EN-US> And finally read <http://jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim> as common sense does not appear to suffice. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on 28 Mar 2010 14:45 Tim Streater wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >> Sean Kinsey wrote: >> > I have stated an assumption, you refer to facts. Where can I see these >> > facts? >> >> They come with experience for the most part. For example, you could, in >> the future, have a company as customer telling you that they would not >> update from IE 6/7 because the update would render their otherwise >> working software unusable. >> >> Then there is the fact not requiring as much experience that there is no >> IE 7+ for Windows 2000, and Windows XP, Windows Vista, or Windows 7 >> would not run on those machines even if their owners could afford or be >> willing to do the OS upgrade. > > Then there is the fact that there are plenty of us who avoid Windows > like the plague and therefore are not using *any* version of Exploder - > and never will. Yes, of course. Header's looking at you, kid ;-) PointedEars P.S.: <http://jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim> -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Sean Kinsey on 28 Mar 2010 15:04
On Mar 28, 8:34 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Sean Kinsey wrote: > >> >> [Thomas 'PointedEars' Lahn wrote:] > >> >> An assumption not supported by the available facts, of course. > >> > I have stated an assumption, you refer to facts. Where can I see these > >> > facts? > >> They come with experience for the most part. For example, you could, in > >> the future, have a company as customer telling you that they would not > >> update from IE 6/7 because the update would render their otherwise > >> working software unusable. > > > What is the relevance for the above statement? > > (If you had quoted properly, you would have known.) You have stated the > assumption that users would upgrade from IE 6/7. I have told you an > example where they would not upgrade for a good reason. No, I stated the opposite. > >> It is a particularly silly approach on the World Wide Web, though, to > >> target only one specific browser brand instead of *at least* one DOM > >> implementation with all its non-dead past and backwards-compatible > >> future versions. > > > I don't target only one brand, so that line of arguments is void. > > You have said that you are targeting "IE". How is that not targeting only > one brand? Yes, I said that, but I never stated that it was _limited_ to IE, only that the fallback stacks primarily support IE6/7 as the amount of users of IE6/7 constitutes the majority of the users who has a browser not supporting the primary stack. > > >> That said, you appear to be unaware that for IE 8 you are relying on a > >> feature that originates from a *working* *draft* for a Specification, > >> which is therefore in a constant state of flux and does not need to be > >> supported (the same way) in the future. That is hardly raw material for > >> production- quality code. > > > So, do you really think there is an inherent risk of IE8 suddenly > > dropping, or changing its implementation of postMessage? > > No, didn't think so.. > > Maybe not IE 8, but maybe 9, 10, ... And how is that relevant? Do you propose I build the library around non-existing standards? The library uses feature testing (and I'll correct that code), it does not at any point use agent sniffing. > > If you were referring to the payload data, then it does what it > > states, it transports string messages. > > Tell me something I don't know yet. > > > And yes, it uses encoding where necessary. > > Which only adds to the problem. > > > If it fails at transporting binary data then that is really not the > > libraries fault as that is not its intention - but the user can easily > > BASE64 encode/decode the message > > You miss the point. Start with: > > <http://support.microsoft.com/kb/208427/EN-US> The limit for use with hash fragments is actually 4050 or something, the limit you are referring to is the one used for the request to the server. Also, the library fragments and enqueues messages longer than the limit, and yes, all encoding is done prior to fragmenting. > > And finally read > <http://jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim> as common sense > does not appear to suffice. I'm new to usenet, so bear with me. I'll do my best. |