Get the position of Window object

[jsiii]

I need to know coordinates of current window. I tried self.screenX (and Y). Although it is not in standards it works well in FF. But IE7 does not support it.

Is there another way how to get a position of a window in JS?

Thanks

[Thread1]

try screenLeft/screenTop for IE browser..


if (self.screenLeft != null) {
// IE
} else {
// FF and others?
}

[jsiii]

try screenLeft/screenTop for IE browser..

It works, thanks a lot :-)

Funny (or maybe sad) part of the story is that Microsoft Visual Studio's code autocomplete feature suggests screenX and screenY for window object. Yet, their own browser uses a different one :-/

[PeejAvery]

To simplify this, I would suggest ternary logic.

var winLeft = (self.screenLeft) ? self.screenLeft : self.screenX;

[andreasblixt]

Just an additional note... The order of the statements (self.screenLeft / self.screenX) is important for cross-browser compatability, because in Opera 7.5, both property sets are supported but one of them (screenX and screenY) has an incorrect value. So the order of the examples in this thread are "the way to go":

var x = self.screenLeft || self.screenX;
var y = self.screenTop || self.screenY;

|| means logical or, and since JavaScript has no defined data types, the first condition in the sequence that has a non-zero value (i.e. not undefined, null, 0, "", etc.) will be returned (in other programming languages you would perhaps expect this to only work with booleans).

Edit
I just realized that there is a rare, but possible bug/unexpected behavior that could occur with any of the solutions given so far. If self.screenLeft is 0, self.screenX will be used, even if it's undefined (except on Opera, in which case it will get an incorrect value - even worse!)

The solution to this is the following:
var x = self.screenX === undefined ? self.screenLeft : self.screenX;
var y = self.screenY === undefined ? self.screenTop : self.screenY;

=== performs a type-sensitive check, and will only return true if the two values are exactly the same (0 === '0' is false, 0 === 0 is true).

[Thread1]

Edit
I just realized that there is a rare, but possible bug/unexpected behavior that could occur with any of the solutions given so far. If self.screenLeft is 0, self.screenX will be used, even if it's undefined (except on Opera, in which case it will get an incorrect value - even worse!)

The solution to this is the following:
var x = self.screenX === undefined ? self.screenLeft : self.screenX;
var y = self.screenY === undefined ? self.screenTop : self.screenY;

=== performs a type-sensitive check, and will only return true if the two values are exactly the same (0 === '0' is false, 0 === 0 is true).


true. that is why i used the "!= null". :thumb:

[andreasblixt]

No, != null means the same as != '', != 0, != undefined, != 0.0 or != '0'. Even if you had used !== null, it would never be false, because the value will never be null. It will be an integer or undefined. Another way to perform the same check I did above is this:
var x = typeof(self.screenX) == 'undefined' ? self.screenLeft : self.screenX;
var y = typeof(self.screenY) == 'undefined' ? self.screenTop : self.screenY;
typeof(value) returns the type of the given value as a string.

[Thread1]

both the undefined and the null data type are the same when used with the standard equality operator (==), and will never be the same if to be compared with the strict one (===). and since we are only looking for an existence of a property here i think the condition that i posted is enough. however, plenty of ways can be used though just like you did. here is another one..


var x = ('screenLeft' in self) ? self.screenLeft : self.screenX;
var y = ('screenTop' in self) ? self.screenTop : self.screenY;

[andreasblixt]

Yes I just wrote in my post that undefined and null (and, more relevantly, 0) would be the same when using ==. That's the cause of the possible bug. That's why it shouldn't be used, and self.screenLeft === undefined ? self.screenX : self.screenLeft should be used. Or "screenLeft" in self ? self.screenLeft : self.screenX.

As for the reason you cannot use normal equality is because you wouldn't be able to see the difference between undefined and 0.

Furthermore, since null is equal to false, it would've made more sense (to me) to use if (!self.screenLeft), as null isn't a possible value for the variable (strictly speaking) and could be misleading.

[Thread1]

sorry but 0 is a value :confused: and should not be equal to the special undefined and null. there is no possible bug but a difference of course.


alert((undefined == null).toString()); // true
alert((0 == undefined).toString()); // false
alert((0 == null).toString()); // false


so i am still safe to write: :D


var x = (self.screenLeft != null) ? self.screenLeft : self.screenX;
or
var x = (self.screenLeft == null) ? self.screenX : self.screenLeft;

[andreasblixt]

Gosh, I was so certain that ""/false/0 would equal (==) null/undefined that I never tried it. Especially considering the fact that when performing an if check with no comparison operator at all they all result in false.

I guess it makes sense considering "" is a String object, false is a Boolean object and 0 is a Number object, while null is a null object reference, and undefined is simply nothing at all.

I'm sorry I didn't understand this earlier, but I'm glad I've learned something new, too. Especially something so fundamental to the language I most often script in (I almost feel stupid for not knowing this).

This means that all solutions except the one I made with the logical ors (because it tests if value is zero, null or undefined which causes the aforementioned bug) will work.

I'll still like to say that undefined makes more sense than null because the value isn't a null reference -- it's undefined. Actually, forget that, too, I just realized that using undefined in older browsers, funny as it may be, results in the error message "'undefined' is undefined." So I guess the only method left is comparing with null. Now the only improvement to your code that I can find is what PeejAvery suggested, using ternary operators:
var x = self.screenX != null ? self.screenX : self.screenLeft;
:p

[PeejAvery]

Gosh, I was so certain that ""/false/0 would equal (==) null/undefined that I never tried it. Especially considering the fact that when performing an if check with no comparison operator at all they all result in false.
JavaScript works with 6 different types of values. As you can see from the list below, null and undefined are in their own categories. They are not treated like any of the rest.

Integers
Strings
Booleans
Objects
null
undefined


Therefore, from this, Thread1 is correct.

0 != null != undefined


Now the only improvement to your code that I can find is what PeejAvery suggested, using ternary operators:
By this, you are referring to the original poster, jsiii, right?

[andreasblixt]

JavaScript works with 6 different types of values.
Actually, "integers" (they're actually called numbers and support floating point values as well), strings and booleans (and even functions) are all derivatives of objects. Undefined is not a value type at all (more like the opposite), and null is an object type, but it refers to nothing. That sums it up to one value type -- objects.

I think JavaScript has some kind of internal difference depending on how you initialize values (and looking at the typeof keyword), so one could argue that it does have more value types, namely the following:

string
number
boolean
object/null
function


alert(new Number(1) + 2); // 3
var s = new String("World");
alert("Hello ".concat(s)); // Hello World
alert(s instanceof Object); // true
alert(new Number(123) instanceof Object); // true
var f = new Function("alert('Hello World')");
f(); // Hello World
alert(f instanceof Object); // true

By this, you are referring to the original poster, jsiii, right?
No,
To simplify this, I would suggest ternary logic.

var winLeft = (self.screenLeft) ? self.screenLeft : self.screenX;
Except your code would exhibit the bug due to not including a comparison with null.

Edit
Maybe I misunderstood you. The solution was intended for the original poster, jsiii. The improvement was referring to Thread1's code.

[PeejAvery]

Edit
Maybe I misunderstood you. The solution was intended for the original poster, jsiii. The improvement was referring to Thread1's code.
Okay. Yes, you did misunderstand, but with this statement, you got it! Thanks for the clarification.

Yes, I meant numbers, not integers, but my mind was fried yesterday. Also, when I said about the six type values, I meant how to deal with them. But you understand what I meant.