Re: window.innerScreenX and window.innerScreenY

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.

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

> 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 Wednesday, 14 December 2016 16:04:29 UTC