How can I read html data of other site (with javascript or etc)?

[Dr J R Stockton]

In comp.lang.javascript message <cc40922b-b288-4d2a-aad7-69268cc5892b@z3
g2000yqz.googlegroups.com>, Sat, 27 Mar 2010 16:41:41, johnwlockwood

also the FAQ for this group talks about cross domain scripting
http://jibbering.com/faq/#frameRef

That section starts "To reference another frame on the same domain".
That should be in <H4>, since otherwise it can be taken as applying to
the whole of 10.2. Then <H4>To communicate between frames on different
domains</H4>.

The first subsection needs a mention of accessing the content as text,
as in :

DIR = Fram.contentDocument.body
DIR = DIR.textContent || DIR.innerText // Is latter needed? Yes, IE8

 

[David Mark]

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

Be very careful with that word "pragmatic" as it is typically bandied
about by incompetents to justify their incompetent practices (see Dojo).

Can't tell from the quoting (or lack thereof), but how does IE6/7
represent all the target browsers? And what features are we talking about?

I have stated an assumption, you refer to facts. Where can I see these
facts?

Also be careful of demanding to see _anything_ in cross-browser
scripting, which is about understanding abstractions, _not_ about
observations. That's the old "show me where it fails" fallacy. The
ocean is much too large to go looking for dangers. Rest assured, they
are out there. And the easy way to look at it is that you cannot
observe browsers that do not yet exist (or ones you've never heard of).
There are no guarantees in this business. Changes are sometimes
required, but through understanding you can minimize their scope and
thus minimize headaches and wasted time for your users.

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.


I just did a new test, and based on this I have removed the before
mentioned code.

So now your users will have to download a new version. That could have
been avoided had you not relied on "pragmatic" programming by observation.

Ouch. I'm telling you, that moniker is not desirable in this industry.

I do apologize if it came across as an insult.


A useless comment as my expectations are based on observable facts

Programming by observation is the wrong approach. How many
configurations does one version of IE have? For instance, for _years_,
jQuery blew up immediately when ActiveX was disabled. Why? Resig had
never _seen_ a grin without a cat.

All the relevant ones.

See previous comment. Which of the umpteen million configurations of IE
do you consider relevant?

 

[Thomas 'PointedEars' Lahn]

[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 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 hardware and OS upgrade.

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.

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.

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.

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

 

[Thomas 'PointedEars' Lahn]

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

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.

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.

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.

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

 

[Sean Kinsey]

Can't tell from the quoting (or lack thereof), but how does IE6/7
represent all the target browsers?  And what features are we talking about?

The library has several 'transport stacks', one that uses postMessage,
one that uses window.name and one that uses FIM.
Most users that are stuck with IE6/7 are either unaware/incompetent,
or are unable to upgrade to a different browser.
Most users that are using other browsers are aware/competent and are
able to upgrade to modern versions,
all supporting the postMessage stack.
Also, most older browsers work similarly when it comes to the how the
name property is persisted across navigation, etc.

So now your users will have to download a new version.  That could have
been avoided had you not relied on "pragmatic" programming by observation..

Nope, cause that code doesn't change the behavior in any way, nor is
it 'wrong' in any way. Just unnecessary.

[Sean Kinsey wrote:]

A useless comment as my expectations are based on observable facts

Programming by observation is the wrong approach.  How many
configurations does one version of IE have?  For instance, for _years_,
jQuery blew up immediately when ActiveX was disabled.  Why?  Resig had
never _seen_ a grin without a cat.  

That is true. But observation is the only way to verify compliance.
And to be honest, I'd rather be the author of a library that works
(even if it 'misuses' the Fragment Identifier),
then one that doesn't (but follows every spec).

See previous comment.  Which of the umpteen million configurations of IE
do you consider relevant?

Most of the default ones.
And no, I dont' count 'javascript disabled' etc as one of those. My
library cannot perform magic so why try.


Why are you all busting my balls, pinpointing 'errors' etc. without
actually offering a 'better' way?
Why are you advocating that my code is 'wrong' when it uses the FIM or
window.name, when there is in fact no other
way to achieve cross-domain messaging (that is, in the browsers where
the use of these methods are necessary).

 

[Sean Kinsey]

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

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?

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.

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

Your observations are not worth much, given that there is not only the
theoretical possibility but also practical evidence of failure of this
approach.



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

 

[David Mark]

The library has several 'transport stacks', one that uses postMessage,
one that uses window.name and one that uses FIM.

Yes, I am familiar with such stacks. Dojo has something similar (which
is not a ringing endorsement).

Most users that are stuck with IE6/7 are either unaware/incompetent,
or are unable to upgrade to a different browser.

I'd be very careful of projecting incompetence onto your users. Users
don't need to know much of anything. Any design that assumes they know
more than how to use the basic features of the browser (or that they
even know what a browser is) is folly. And I don't follow what you are
saying about upgrading. Are you assuming that IE6/7 users will never
upgrade (or be upgraded?)

Most users that are using other browsers are aware/competent and are
able to upgrade to modern versions,
all supporting the postMessage stack.

That's a very _broad_ assumption. You should not design based on such
assumptions.

Also, most older browsers work similarly when it comes to the how the
name property is persisted across navigation, etc.

Most? Similarly? It sounds as if you have settled on a design that
sort of seems to work and will defend it to the end. That's not sound
browser scripting practice either.

Nope, cause that code doesn't change the behavior in any way, nor is
it 'wrong' in any way. Just unnecessary.

Due to unfortunate snipping in this thread, it is hard to tell what code
you are referring to.

[Sean Kinsey wrote:]

A useless comment as my expectations are based on observable facts

Programming by observation is the wrong approach. How many
configurations does one version of IE have? For instance, for _years_,
jQuery blew up immediately when ActiveX was disabled. Why? Resig had
never _seen_ a grin without a cat.

That is true. But observation is the only way to verify compliance.
And to be honest, I'd rather be the author of a library that works
(even if it 'misuses' the Fragment Identifier),
then one that doesn't (but follows every spec).

See previous comment. Which of the umpteen million configurations of IE
do you consider relevant?

Most of the default ones.

Oops. What makes you think that everyone uses IE in its default
configuration. Certainly many corporate users (for example) do not.

And no, I dont' count 'javascript disabled' etc as one of those. My
library cannot perform magic so why try.

Then you have only umpteen million minus one configurations to consider.
And make sure your _site_ does perform "magic" as many corporate
users, blind people, etc. disable JS (or have it disabled for them).

Why are you all busting my balls, pinpointing 'errors' etc. without
actually offering a 'better' way?

I can only speak for myself. You asked for feedback and you got it. I
haven't had a chance to go through all of your script, but the first
thing I noticed was an object inference based on attachEvent with an
unsafe host object property test and an explanation that didn't match up
with reality. Thomas has pointed that out, as well as other problems.
It's up to you to take (or leave) the advice. And get used to the
reality that there may not be better way for what you have decided to
do. That's why it pays to consider the relevant cross-browser
abstractions at the design stage. Observations should be used only
after the development to confirm (as best they can) that your design is
sound.

Why are you advocating that my code is 'wrong' when it uses the FIM or
window.name, when there is in fact no other
way to achieve cross-domain messaging (that is, in the browsers where
the use of these methods are necessary).

Aha!

 

[Tim Streater]

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

 

[Thomas 'PointedEars' Lahn]

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

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.

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.

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.

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

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.

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?

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

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

 

[Thomas 'PointedEars' Lahn]

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>

 

[David Mark]

The library has several 'transport stacks', one that uses postMessage,
one that uses window.name and one that uses FIM.

Yes, I am familiar with such stacks. Dojo has something similar (which
is not a ringing endorsement).

Most users that are stuck with IE6/7 are either unaware/incompetent,
or are unable to upgrade to a different browser.

I'd be very careful of projecting incompetence onto your users. Users
don't need to know much of anything. Any design that assumes they know
more than how to use the basic features of the browser (or that they
even know what a browser is) is folly. And I don't follow what you are
saying about upgrading. Are you assuming that IE6/7 users will never
upgrade (or be upgraded?)

Most users that are using other browsers are aware/competent and are
able to upgrade to modern versions,
all supporting the postMessage stack.

That's a very _broad_ assumption. You should not design based on such
assumptions.

Also, most older browsers work similarly when it comes to the how the
name property is persisted across navigation, etc.

Most? Similarly? It sounds as if you have settled on a design that
sort of seems to work and will defend it to the end. That's not sound
browser scripting practice either.

Nope, cause that code doesn't change the behavior in any way, nor is
it 'wrong' in any way. Just unnecessary.

Due to unfortunate snipping in this thread, it is hard to tell what code
you are referring to.

[Sean Kinsey wrote:]
A useless comment as my expectations are based on observable facts
Programming by observation is the wrong approach. How many
configurations does one version of IE have? For instance, for _years_,
jQuery blew up immediately when ActiveX was disabled. Why? Resig had
never _seen_ a grin without a cat.

That is true. But observation is the only way to verify compliance.
And to be honest, I'd rather be the author of a library that works
(even if it 'misuses' the Fragment Identifier),
then one that doesn't (but follows every spec).

See previous comment. Which of the umpteen million configurations of IE
do you consider relevant?

Most of the default ones.

Oops. What makes you think that everyone uses IE in its default
configuration. Certainly many corporate users (for example) do not.

And no, I dont' count 'javascript disabled' etc as one of those. My
library cannot perform magic so why try.

Then you have only umpteen million minus one configurations to consider.
And make sure your _site_ does perform "magic" as many corporate
users, blind people, etc. disable JS (or have it disabled for them).

Why are you all busting my balls, pinpointing 'errors' etc. without
actually offering a 'better' way?

I can only speak for myself. You asked for feedback and you got it. I
haven't had a chance to go through all of your script, but the first
thing I noticed was an object inference based on attachEvent with an
unsafe host object property test and an explanation that didn't match up
with reality. Thomas has pointed that out, as well as other problems.
It's up to you to take (or leave) the advice. And get used to the
reality that there may not be better way for what you have decided to
do. That's why it pays to consider the relevant cross-browser
abstractions at the design stage. Observations should be used only
after the development to confirm (as best they can) that your design is
sound.

Why are you advocating that my code is 'wrong' when it uses the FIM or
window.name, when there is in fact no other
way to achieve cross-domain messaging (that is, in the browsers where
the use of these methods are necessary).

Aha!

In the interest of saving time, perhaps I should elaborate on that
exclamation. If you had considered the cross-browser (including future
versions of the browsers you profess to support) implications at the
design stage, you would have realized that any such solution would be
impractical. In other words, you are attempting to create a canned
solution, packaged in a client-side script for a problem that is more
pragmatically addressed with techniques that cannot be packaged in such
a way. I know it is hard when you get all the way to the end of a
development and realize that your aim was off from the start, but that
appears to be the case here.

If you had not used misguided "pragmatic" techniques to try to push your
design through the proverbial brick wall, you would not have ended up
with such an unwanted epiphany. The somewhat hostile reaction is
typical of those (see Dojo) who don't want to hear that they wasted
their time (and the time of countless others) creating a solution that
can't measure up to the more practical alternatives. It usually
indicates either ignorance or huckstering on their part.

Many of the "major" libraries are full of such non-solutions. A typical
example is where browser sniffing is used to determine when to apply
proprietary IE styles, which is a job best left to IE's conditional
comments. What they end up with is a script that seems to work in a
handful of today's browsers (when scripting is enabled of course)
competing with an unscripted solution that is _guaranteed_ to work in
everything (past, present and future). Which would be the more
pragmatic approach? I ask because contributors to such projects often
use that word to describe what they are doing. Once educated, their
users tend to use other choice (and often obscene) words.

So don't feel bad. We've all gone through it. It's a steep (and often
unforgiving) learning curve. The trick is to avoid the Sisyphus act put
on by libraries like Dojo and jQuery. Their stuff keeps rolling back
down the hill and they just keep trying to put it back (all the while
telling themselves they are being "pragmatic" and acting in accordance
to the laws of some "real world" they imagine).

 

[Sean Kinsey]

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.

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.

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.

Tell me something I don't know yet.


Which only adds to the problem.


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.

 

[Thomas 'PointedEars' Lahn]

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.

(And I see what you mean now.) I am further referring to your attempt of
augmenting the host object referred to by `window' with new properties:

easyXDM.js line 95 (indentation minimized, comments wrapped):
| if (!config.local) {
| // If no local was set, and we are unable to find a suitable file,
| // then we resort to using the current window
| config.local = window;
| }
| }
|
| if (config.local === window) {
| // We are using the current window to listen to
| config.usePolling = true;
| config.useParent = true;

Since the current window object is not subject to the SOP, you should be
augmenting the global object (as referred to by `this' in the global
execution context) or, to minimize potential name collisions, a user-
defined native object instead.


PointedEars

 

[Sean Kinsey]

To wrap this up,
easyXDM is a library made to provide a means of transporting messages
between two Javascript programs residing in documents separated by the
Same-Origin policy.
It does this reliably for all browsers supporting the postMessage
interface, and all other browsers with similar traits as IE6/IE7.

It is NOT targeted exclusively at IE, nor at Windows.

If new standards etc are added to new browsers that solves this in a
better way then support for these will be added to new versions of
easyXDM.
Those of my 'costumers' that wish to support these will upgrade, those
who don't... well, they don't.

Building the library around features defined in the base spec is not a
viable option.
First of all, that would mean opting not to use newer and faster
features,
and secondly, no such features exist.

I appreciate all the feedback on issues as feature detection,
augmenting host objects etc, but I do not appreciate the way you seem
to want to undermine the considerable effort that has gone down to
reach the level of interoperability that it has.
If better solutions exist, let me know, then there is no use in me
continuing my effort.

Sean Kinsey

 

[Sean Kinsey]

Just looked at the web site and found it liberally sprinkled
with a picture of a JavaScript routine for String.prototype.trim
that embarrassingly uses two .replace calls where one would
suffice.

Hans-Georg

Nice one, attack the images I'm temporarily using on the website, and
a few .replace calls...
Real grown up...

 

[Thomas 'PointedEars' Lahn]

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.

No, you did not, and I misread anyway:

,-<|
| OK, fine, I'm not an expert on the spec, but I do know that those
| features _are_ indeed available in all the target browsers (that being
| IE6/IE7).
| And before you start on my potential lack of support for other
| browsers not implementing the newer postMessage interface; this is a
| choice made on the assumption that those using 'other' browsers than
| IE6/7 are capable people who do update their software.

But that is even worse because it assumes instead that

A) There are no other browsers that support this feature but IE 6/7.
B) People using "other" browsers are supposed to make updates.
C) This feature is necessarily available in the version of the "other"
browser that can be updated to.

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.

True, you did not state that. Unfortunately, that other assumption is only
equally unfounded.

And how is that relevant?

Software built today should still work tomorrow with little or no extra
effort. That is called responsible software development.

Do you propose I build the library around non-existing standards?

Why should I propose something that you have done already, which I have
explicitly recommended against?

The library uses feature testing (and I'll correct that code),

It currently uses object inference, and one can only hope that the new
version would not do that anymore.

it does not at any point use agent sniffing.

Are you expecting some kind of applause now? UA-sniffing is a technique
that was has been marked deprecated around 2000 CE. It is like your
telling me that you have not written this article on a typewriter.

The limit for use with hash fragments is actually 4050 or something,

That remains to be seen. In any case, there is a limit imposed when there
does not need to be one if you used the standards-compliant, reliable
approach.

the limit you are referring to is the one used for the request to the
server.

Not really.

Also, the library fragments and enqueues messages longer than the
limit, and yes, all encoding is done prior to fragmenting.

Are you saying you would not only change `window.name' or
`window.location.hash' once, but *several* times for sending the message?

And I thought it could not get any worse.


PointedEars

 

[Sean Kinsey]

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.

(And I see what you mean now.)  I am further referring to your attempt of
augmenting the host object referred to by `window' with new properties:

easyXDM.js line 95 (indentation minimized, comments wrapped):
|   if (!config.local) {
|     // If no local was set, and we are unable to find a suitable file,
|     // then we resort to using the current window
|     config.local = window;
|   }
| }
|                    
| if (config.local === window) {
|   // We are using the current window to listen to
|   config.usePolling = true;
|   config.useParent = true;

Since the current window object is not subject to the SOP, you should be
augmenting the global object (as referred to by `this' in the global
execution context) or, to minimize potential name collisions, a user-
defined native object instead.

And exactly where am I augmenting, no, attempting to augment the
window host object?

easyXDM does not augment ANY host objects, and the only global object
introduced is 'easyXDM'.

 

[David Mark]

To wrap this up,
easyXDM is a library made to provide a means of transporting messages
between two Javascript programs residing in documents separated by the
Same-Origin policy.

Which you should never need to do if you just consider more practical
designs (that, unfortunately for your endeavor, you cannot can.

It does this reliably for all browsers supporting the postMessage
interface, and all other browsers with similar traits as IE6/IE7.

So it is not an appropriate solution for a public-facing Website.

It is NOT targeted exclusively at IE, nor at Windows.

If new standards etc are added to new browsers that solves this in a
better way then support for these will be added to new versions of
easyXDM.
Those of my 'costumers' that wish to support these will upgrade, those
who don't... well, they don't.

Building the library around features defined in the base spec is not a
viable option.

Neither is building it around non-standard recommendations and hacks.

First of all, that would mean opting not to use newer and faster
features,
and secondly, no such features exist.
Huh?


I appreciate all the feedback on issues as feature detection,
augmenting host objects etc, but I do not appreciate the way you seem
to want to undermine the considerable effort that has gone down to
reach the level of interoperability that it has.

How is your wasted time (that you seek to pass on to others) the fault
of this newsgroup?

If better solutions exist, let me know, then there is no use in me
continuing my effort.

At least two solutions have already been proposed for _specific_
contexts. Seeking to can a general-purpose solution is usually bad news
and that has been the case with this project. I am truly sorry about
your luck, but don't blame the messenger(s).

 

[Sean Kinsey]

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

No, you did not, and I misread anyway:

,-<|
| OK, fine, I'm not an expert on the spec, but I do know that those
| features _are_ indeed available in all the target browsers (that being
| IE6/IE7).
| And before you start on my potential lack of support for other
| browsers not implementing the newer postMessage interface; this is a
| choice made on the assumption that those using 'other' browsers than
| IE6/7 are capable people who do update their software.

But that is even worse because it assumes instead that

A) There are no other browsers that support this feature but IE 6/7.
B) People using "other" browsers are supposed to make updates.
C) This feature is necessarily available in the version of the "other"
   browser that can be updated to.

All wrong. I only feature test. The library is agnostic to vendors,
brands and versions.
And by the way, the fallback method, FIM, is actually within the
standard.

Are you saying you would not only change `window.name' or
`window.location.hash' once, but *several* times for sending the message?

window.name, no, and not window.location.hash either actually I set
the full URL, I do not access the .hash property because I know this
not to be standard.
And seriously, it actually sounds like your saying that 'if you cannot
pass the message by changing the hash only once, then it should't be
done at all'.
Seriously..

 

[Thomas 'PointedEars' Lahn]

To wrap this up,

You have a peculiar way of saying "to bury all valid counter-arguments made
before below a load of advertisement nonsense".

easyXDM is a library made to provide a means of transporting messages
between two Javascript programs residing in documents separated by the
Same-Origin policy.

We know what it *advertises* to do, thank you very much.

It does this reliably for all browsers supporting the postMessage
interface, and all other browsers with similar traits as IE6/IE7.

By definition it cannot.

It is NOT targeted exclusively at IE, nor at Windows.
Good.

If new standards etc are added to new browsers that solves this in a
better way then support for these will be added to new versions of
easyXDM.

Existing standards solve this problem completely already.

Those of my 'costumers' that wish to support these will upgrade, those
who don't... well, they don't.

You do not seem to understand that your customers are not concerned when it
comes to compatibility of a script library, but the customers of your
customers, i.e. the visitors of their Web sites. IOW, the worm must be
tasty for the fish, not the fisherman.

Building the library around features defined in the base spec is not a
viable option.

Yes, it is. It has been done before.

First of all, that would mean opting not to use newer and faster
features,

No, it would not.

and secondly, no such features exist.

You are mistaken.

I appreciate all the feedback on issues as feature detection,
augmenting host objects etc, but I do not appreciate the way you seem
to want to undermine the considerable effort that has gone down to
reach the level of interoperability that it has.

I hate to break it to you, stupid, but for the most part you have wasted
your time with this. Like David said, it happens to the best of us.

If better solutions exist, let me know, then there is no use in me
continuing my effort.

For crying out loud, a much better approach has been proposed here already.


PointedEars