Re: window.innerScreenX and window.innerScreenY

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
https://bugs.chromium.org/p/chromium/issues/detail?id=151983
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 
concern"
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 
surveillance.


> 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
https://bugzilla.mozilla.org/show_bug.cgi?id=486200#c1

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.

Gérard

>> 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