W3C home > Mailing lists > Public > www-style@w3.org > December 2016

Re: window.innerScreenX and window.innerScreenY

From: Gérard Talbot <www-style@gtalbot.org>
Date: Thu, 15 Dec 2016 09:49:15 -0500
To: Jan Norden <jan.norden@gmail.com>
Cc: W3C www-style mailing list <www-style@w3.org>
Message-ID: <c4e269f4dd834881a740623c889e8c89@gtalbot.org>
Le 2016-12-14 11:03, Gérard Talbot a écrit :
> Le 2016-12-14 10:27, Jan Norden a écrit :
>> That is indeed a much better wording, though I think it is more 
>> appropriate
>> to add them before
>> https://drafts.csswg.org/cssom-view/#dom-window-innerwidth, in anaoigy 
>> with
>> https://drafts.csswg.org/cssom-view/#dom-window-screen
>> <https://drafts.csswg.org/cssom-view/#dom-window-screeny>x and
>> https://drafts.csswg.org/cssom-view/#dom-window-outerwidth .
>> Given that, what is the correct way to propose adding 
>> window.innerScreenX
>> and window.innerScreenY to the draft standard?
> You can do many things.
> 1- File a bug report in major mainstream browers who do not support
> none of screenLeft, screenTop, mozInnerscreenX, mozInnerScreenY. I see
> you did that already
> https://bugs.chromium.org/p/chromium/issues/detail?id=151983
> although it was closed with the main reason being that it is not a
> widely requested demand.
> 2- Once major mainstream browers support a proprietary, non-standard
> (vendor-prefixed or not) window pair of property, complaint gently but
> advocate relentlessly about
> non-standard, non-interoperable implementations in major mainstream 
> browsers.
> 3- Find the CSSOM View Module spec editor and try to get his attention
> and his support; right now, it's Simon Pieters.
> 4- Find the mailing list where the CSSOM View Module people discuss
> issues, matters, make propositions, debate how to improve things,
> etc...
> 5- Create a webpage exposing clearly and in a resounding manner the
> incompatibilities involved (a judicious live interactive DHTML example
> is best) and bring up (quote) related documentation. This is where I
> would focus on if I were you.
> 6- Find and list supporters of your proposal where they explain why
> they are bothered or constrained or restrained by current status.

Over at
chromium.org people asked you good, valid questions, you know.
"Security considerations wrt implementing this feature"
"what is the use-case you want this for?"
"help me understand why you want screen coordinates instead of top-level 
page coordinates"
"With respect to the security concern in #9, I think that's a legitimate 
There is already a lot of privacy advocates that believe that scripting 
is already giving away way too much recordable, monitorable information 
for tracking purposes (advertisment, hacking) or for illegal 

> 7- Find out why Mozilla developers created and implemented
> mozInnerscreenX, mozInnerScreenY

Found it!

Robert O'Callahan (:roc) 2009-03-31 17:07:17 PDT

My plan here is to add window.mozInnerScreenX/Y properties that return 
the screen coordinates of the top-left of the viewport. It should be 
trivial, I'll do it ASAP.
Bug 486200: Need API to compute screen coordinates of DOM elements

The interesting discussion I foresee surrounding your proposal is why 
Mozilla implemented window.mozInnerScreenX/Y properties 7½ years ago 
while Chromium project are definitely not ready to go ahead with 
implementing this.


>> And what is the process for getting such a proposal approved/rejected?
> Patience. Good planning.
> Gérard
>> 2016-12-14 16:09 GMT+01:00 Gérard Talbot <www-style@gtalbot.org>:
>>> Le 2016-12-13 08:46, Jan Norden a écrit :
>>>> There is currently no good way of translation a position in a 
>>>> browser to a
>>>> position on the screen.
>>> Jan,
>>> Let me rephrase what I believe you were trying to say here, like 
>>> this:
>>> there is currently no possible way of getting (retrieving) window's
>>> viewport (or client area) x and y coordinates of a browser in 
>>> relation to
>>> the (operating system) screen area.
>>> Our particular need is translating a gaze-position
>>>> (which we have in screen coordinates from our eyetracking hardware).
>>>> It is possible in Firefox, using the proprietary
>>>> mozInnerScreenX/mozInnerScreenY,
>>>> but not in general.
>>> window.screenX
>>> https://developer.mozilla.org/en/docs/Web/API/Window/screenX
>>> window.mozInnerScreenX
>>> https://developer.mozilla.org/en-US/docs/Web/API/Window/mozInnerScreenX
>>> window.screenY
>>> https://developer.mozilla.org/en/docs/Web/API/Window/screenY
>>> window.mozInnerScreenY
>>> https://developer.mozilla.org/en-US/docs/Web/API/Window/mozInnerScreenY
>>> I added the mozInnerScreenX and mozInnerScreenY properties into an 
>>> old
>>> webpage
>>> http://www.gtalbot.org/DHTMLSection/WindowEventsNS6.html
>>> and, as far as I can see, the mozInnerScreenX and mozInnerScreenY
>>> properties return the equivalent of IE's screenLeft and screenTop.
>>> "
>>> There is a major incompatibility between MSIE 5+ window.screenTop and 
>>> NS
>>> 6+ window.screenY. MSIE 5+ calculates the distance from the top of 
>>> the
>>> content area (client area) to the top side of the screen. NS 6+ 
>>> calculates
>>> the distance from the top of the browser's window to the top side of 
>>> the
>>> screen. There seems to be no way to figure out the height of chrome
>>> elements (menu bar, tools bar, address bar, links bar) present in the
>>> browser for MSIE 5+.
>>> "
>>> so, the addition of mozInnerScreenX and mozInnerScreenY properties 
>>> makes
>>> sense.
>>> http://www.gtalbot.org/DHTMLSection/ScreenXYComparedScreenLeftTop.html
>>> IE6, IE7, IE8 supported window.screenLeft and window.screenTop which 
>>> are,
>>> by definition, the equivalent of mozInnerScreenX and mozInnerScreenY. 
>>> I
>>> presumed here that window.screenLeft and window.screenTop are still
>>> supported by IE9, IE10, IE11.
>>> window.screenLeft
>>> "Retrieves the x-coordinate of the upper left-hand corner of the 
>>> window
>>> frame, relative to the upper left-hand corner of the screen."
>>> https://msdn.microsoft.com/en-us/library/ms534389(v=vs.85).aspx
>>> window.screenTop
>>> "Retrieves the y-coordinate of the upper left-hand corner of the 
>>> window
>>> frame, relative to the upper left-hand corner of the screen. "
>>> https://msdn.microsoft.com/en-us/library/ms534390(v=vs.85).aspx
>>> Returning now to your initial statement, I believe there is a way of
>>> getting window's viewport (or client area) position of a browser in
>>> relation to the (operating system) screen area in Gecko-based 
>>> browsers and
>>> in IE browsers. I do not know (I can not verify) if window.screenLeft 
>>> and
>>> window.screenTop are supported in Edge12+ browsers but typically 
>>> Microsoft
>>> does not remove proprietary attributes or properties of objects 
>>> unless
>>> there is already a web standard (and widespread-used) equivalent. So 
>>> I
>>> would presume that window.screenLeft and window.screenTop are 
>>> supported in
>>> Edge12+ browsers too.
>>> From a web standards point of view, best would be to have and to use 
>>> only
>>> 1 pair of property name (window.innerScreenX and window.innerScreenY, 
>>> no
>>> moz prefix), to have Microsoft to drop window.screenLeft and
>>> window.screenTop and to include such pair of property names in
>>> CSSOM View Module
>>> https://drafts.csswg.org/cssom-view/
>>> inside the §4. Extensions to the Window Interface, say, right after,
>>> https://drafts.csswg.org/cssom-view/#dom-window-screeny
>>> Gérard
Received on Thursday, 15 December 2016 14:49:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 December 2016 14:49:51 UTC