screen{X,Y,Left,Top} use window location, not viewport

[eeminionn]

Summary

Addresses #45048: No Browser Implements screenX, screenY according to the spec

Changed files

• files/en-us/web/api/window/screenx/index.md

Validation

• git diff --check: passed

Fixes #45048

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Preview URLs (5 pages)

• /en-US/docs/Web/API/Window/screenLeft
• /en-US/docs/Web/API/Window/screenTop
• /en-US/docs/Web/API/Window/screenX
• /en-US/docs/Web/API/Window/screenY
• /en-US/docs/Web/API/Window

Flaws (2)

Note! 4 documents with no flaws that don't need to be listed. 🎉

Found an unexpected or unresolvable flaw? Please report it here.

URL: /en-US/docs/Web/API/Window
Title: Window
Flaw count: 2

• macros:
  • Macro domxref produces link /en-US/docs/Web/API/HTMLElement/invalid_event which is a redirect
  • Macro domxref produces link /en-US/docs/Web/API/Element/select_event which is a redirect

External URLs (3)

URL: /en-US/docs/Web/API/Window/screenLeft
Title: Window: screenLeft property

• https://mdn.github.io/dom-examples/screenleft-screentop/ (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/API/Window/screenTop
Title: Window: screenTop property

• https://mdn.github.io/dom-examples/screenleft-screentop/ (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/API/Window/screenX
Title: Window: screenX property

• https://mdn.github.io/dom-examples/screenleft-screentop/ (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2026-09-02 01:05:23)

[Josh-Cena]

cc @greggman

[greggman]

lgtm. FYI screenY has the same issue with showing and hiding things like bookmark bars.

[Josh-Cena]

Wait—@greggman do you know where in the spec does it say this property is based on the content (viewport, I assume)? The spec says:

The screenX and screenLeft attributes must return the x-coordinate, relative to the origin of the Web-exposed screen area, of the left of the client window as number of CSS pixels, or zero if there is no such thing.

Weirdly, it never gave a definition for client window; but its only other appearance is in outerHeight/outerWidth, which is already documented on MDN as including the browser UI.

So perhaps this is just a content bug, and we should replace everything that says "viewport" (which means innerWidth) to "window" (which means outerWidth)?

[greggman]

maybe. It's a pretty ridiculous API. It had a purpose. Browsers apparently broke it and never bothered to make it useful again. I'd suggest removing the sample since it doesn't actually work.

[Josh-Cena]

idk, it looks pretty useful to me 🤷 This example also works for me. The circle moves as you drag the browser window across the device screen. Sure, it's offset by showing/hiding toolbars/sidebars, but I don't think that subtracts from its usefulness in most cases.

[Josh-Cena]

There's a bug in this demo that prevents the correct screenLeft screenTop from being read if the screen initially starts with screenLeft=0. I'll fix that.

[greggman]

I’m curious what you think the use case is? To me the use case is to align with something relative to the screen. The center or one of the edges. It does’t work for that. Worse, if you’re a vertical tab user and you have the auto hide feature (common), it breaks even more

[Josh-Cena]

mdn/dom-examples#393 should fix the bug in the demo.

[Josh-Cena]

I’m curious what you think the use case is? To me the use case is to align with something relative to the screen. The center or one of the edges. It does’t work for that. Worse, if you’re a vertical tab user and you have the auto hide feature (common), it breaks even more

Well I can't speak for vertical tabs. But there's only an unobservable dimension change if the browser chrome dynamically changes. In the remaining cases, this demo works as intended.

MDN is not in a good position to discuss whether a feature is "useful" anyway; we can only document what it does and you as a reader can figure out whether it fits your particular use case. If you think there's an unimplementable UX involving dynamic browser UI, you could raise the issue with CSSWG to have additional ways to measure, say, the viewport's position within the window. That would definitely be helpful for this demo, which, per the note I added, suffers exactly from this lack.

[greggman]

that is not really my point though. The demo does not do what it claims to do

What it claims to do

In this example we are using Window.screenLeft/Window.screenTop plus Window.requestAnimationFrame() to constantly redraw the circle in the same physical position on the screen

It does not keep the circle in the same physical position on the screen. And further, every browser puts the circle in a different place.

chrome

Screen.Recording.2026-09-02.at.12.41.01.mp4

firefox

Screen.Recording.2026-09-02.at.12.43.28.mp4

safari

Screen.Recording.2026-09-02.at.12.44.09.mp4

[Josh-Cena]

Yes, as I said, no behavior can be said about when the browser UI changes dynamically. I already added the following disclaimer:

This example compensates for changes in the browser window's position, but not for changes in the viewport's position within the window. Showing or hiding a toolbar or sidebar can therefore shift the circle on the screen.

This demo is only for when the browser UI stays constant. As I also said, I believe true fixed screen position is unattainable unless you can query the viewport's location within the window, and if that's what you'd like to see, it would be very helpful to ask in CSSWG.

[greggman]

no behavior can be said about when the browser UI changes dynamically

Even if the UI doesn't change dynamically. Set one window to have its tabs visible and another not. Then run such a demo in 2 windows. The 2 windows will not align.

They used to, example from 2011 (video is newer, demo was written in 2011)

https://www.youtube.com/watch?v=ef20wKxt5aY