[cssom-view] window.innerScreenX windows.innerScreenY

[JanNorden]

For the browser as such it is possible to obtain both the dimensions and the positon on the (operating system) screen area:

https://drafts.csswg.org/cssom-view/#dom-window-outerwidth
https://drafts.csswg.org/cssom-view/#dom-window-outerheight
https://drafts.csswg.org/cssom-view/#dom-window-screenx
https://drafts.csswg.org/cssom-view/#dom-window-screenx

However, for the viewport it is only possible to obtain the dimensions, not the position:

https://drafts.csswg.org/cssom-view/#dom-window-innerwidth
https://drafts.csswg.org/cssom-view/#dom-window-innerheight

The fact that the position is not available makes it impossible to translate coordinates on the screen to coordinates in the viewport.

I therefore propose the addition of corresponding innerScreenX and innerScreenY properties.

Since this translation is already performed by e.g. window.onMouseMove(), implementing the properties should not present any new technical or conceptual challenges.

The need arises when you get (OS) screen coordinates from some non-mouse source (in our particular case an gaze-tracking device), and want to relate them to the corresponding position in the displayed document.

There are non-standard implementations, e.g. mozInnerScreenX https://developer.mozilla.org/en-US/docs/Web/API/Window/mozInnerScreenX.

A previous request for another vendor-specific implementation was declined awaiting standardization https://bugs.chromium.org/p/chromium/issues/detail?id=151983 .

[pbi-qfs]

@frivoal Which kind of help is wanted for the proposal?

[xckai]

Same question, there is no "bridge" between HTML element's CSS position and system virtual screen position in chrome.
In some scenery ,such as web automation, get HTML element's system virtual screen position is very usefull.

[muodov]

Just stumbled upon this problem, I described my use case here

@frivoal could you point in the direction of how to push this forward? Should I try to write some prose draft, or start with seeking implementers' attention first? 🙏🏻

[ArkadiuszMichalski]

Lack of this solution is extremely irritating, and from what I can see it takes years. I have had the same problem again #5814. What can we do to push it a little bit forward?

[muodov]

Note that in IE11 window.screenTop and window.screenLeft seem to be doing exactly this.

However, in modern engines (as well as the spec), those are just aliases to screenX/screenY, e.g. these commits (1, 2) in Blink/WebKit.

[xfq]

I think you can draft some text to explain:

• the expected behavior and some example code
• some of the use cases it solves, with some examples
• the alternatives which have already been considered and why they were not chosen
• potential privacy implications (if any)

The initial draft doesn't have to be super formal, and can be used to gather implementers' interest and guide spec writing.

[muodov]

@xfq Thank you for these pointers, it clarifies the process a bit :) I'll sketch something out

[caoimhinsmo]

I have been tearing my hair out looking for this feature too and eventually my searches led me to here. Specifically, I just want to be able to open a popup window (using window.open and hence using OS coordinates) above a particular empty box in the underlying document (hence identified by particular CSS coordinates) so that it will not block anything important from view. I am amazed that such a commonplace requirement is so complicated to implement. I need this for Multidict, a facility which I wrote at multidict.net which lets the user swop easily between various online dictionaries, putting the dictionary results in an iframe. More and more dictionaries though are setting HTTP SAMEORIGIN which prevents their results from appearing an iframe, so for these dictionaries I need to send the results to a popup window appearing above the div which would normally hold the iframe.

[andreineculau]

FWIW this is the best guessing game that I know of https://github.com/rokmoln/browser-coords

[Somnium7]

Are there any plans for this? We need this too. Still can't be reliably detected in 2024...