michfreak

Dude, you clearly don't read much of what Stan Lee writes and says. It's one of his top 10 words.

I just want to personally thank you for continuing to make Americone Dream. One scoop of that with strawberry in a waffle cone is my absolutely favorite ice cream combo in the world.

Like, the movie, the play? Are you a hardcore singing-Christian Bale fan? Or just an aficionado of Tony-nominated musicals?

Who is your favorite camper from Whispering Rock?

In most programming languages (and many logical languages), = means you're assigning something to something else. So saying "thing = bowtie" is semantically similar to saying out loud "This thing is now a bowtie". Similarly, == means you are checking if something is something else. Saying "thing == bowtie" is semantically similar to asking "Is this thing a bowtie?" Finally, === is a bit more programmer-y, if you will, where the two things you are comparing are also checked to make sure that they are also the same substance. For instance, I could probably convince you that a painting of a bowtie is the same as a bowtie for the purposes of looking at them: "painting of bowtie == bowtie". But a painting of a bowtie, while similar to a bowtie, is not exactly like a bowtie, so saying "painting of a bowtie === bowtie" would not check out.

Phew.

In the situation above, there is a programmatic object named a "window", which describes exactly what you probably think it is: a browser window in IE. Objects in most programming languages can have "properties" or "methods" attached, notated with dots. For example, if I have a bowtie this might be notated with tie.type === 'bow', describing the "type" property with what type of tie it is. I could also run tie.knot (where "knot" is a method) and it would tie the bowtie in a knot.

Presumably in this case, window has a method or property named "frames" that describes what kind of frames the window has in it (where frames are sections of the browser marked out to show different things). However, because the window object itself is a list of frames, asking for window.frames just ends up returning the window object again, proven with the fact that window === window.frame. Things like this happen sometimes in order to maintain compatibility with old software; for example, even though the window object was later upgraded to act as a framelist on its own, older scripts might expect the framelist to be stored in window.frame.

Let me know if that's confusing or if I'm completely wrong anywhere. I'm not familiar with IE's specific framework (heh heh), so I'm guessing when it comes to frames.