-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MouseEvent.screenX/Y coordinate space is not clear #150
Comments
Anyone knows the answer? |
I'm not an expert here but according to https://drafts.csswg.org/cssom-view/#dom-mouseevent-screenx, it seems that this should be in CSS pixels (since "Web-exposed Screen Area" is defined in CSS Pixels) though that's still an ED. That seems to match both Firefox and Chrome's implementations. In general, all coordinates I know of in the browser are in CSS pixels. Though for screenXY it does seem a bit awkward as the rest of the screen doesn't have browser zoom applied to it... |
Sorry, I have it backwards above - it appears that browser-zoom doesn't affect screenX/Y in practice so they're not in CSS pixels |
So I assume the goal was to have screenX/Y match the css pixels. Particularly both Chrome and Firefox do that when dsf changes but none of them do that when page zoom (i.e. browser zoom) changes. However, changing either dsf or page zoom in both browsers will change |
(It is Firefox, not FireFox ;) ) https://bugzilla.mozilla.org/show_bug.cgi?id=809788 has some background information. |
Looking at the history on that bug and roc's thread on www-style, it seems that we eventually aligned with Firefox on how I think the prevailing interpretation on the thread (which I agree with) is that ctrl+/- zoom and the zoom applied for high-dpi displays is effectively equivalent. Given that, I do think it's a bug that screenX/Y take into account one but not the other. I don't have a strong opinion on whether it should be in physical pixels or in CSS pixels but it seems like a bug that we're treating DSF differently from ctrl+/- zoom. |
I agree we want DSF and browser zoom treated the same. Assuming it's web compatible I'd prefer if |
Just to get everyone on board with this. @smaug----, @patrickkettner do you also agree having the screenX/Y in CSS pixels is okay (assuming there isn't many compat issues)? Particularly what I have in mind is changing the page zoom logic to also change screenX/Y range similar to what device scale factor does. |
It is now in CSS pixels, but sounds like your asking about zoom behavior. (Is dsf commonly used acronym?) |
If the property doesn't react to ctrl+/- zooming then it isn't in CSS pixels since that increases/decreases the size of a CSS pixel. Other properties like window.innerWidth do change as the user zooms in and out. DSF = device scale factor. It's the zoom applied by the browser to compensate for a high pixel density display (i.e. so that the UI doesn't look tiny). That's what we call it on Chrome, not sure what other browsers call it. We should be careful about compat impact but in this case, since we're already applying the DSF to these properties, content that will break wit this change would already have been broken on high density displays so I suspect regressions would be rare. Users could work-around by resetting zoom level so any issues would be low severity IMO. |
Are mouseevent.screenX/Y the only properties which don't scale? In general I do support the change, but I would assume some pages will be broken. Like, they could currently try to convert mouseevent.screenX/Y to something reasonable using other coordinates like clientX/Y and properties of screen object. |
Would someone research & post the current state of implementations? |
@EiraGe has created an extensive report on PointerLock coordinate space where we observe that all major browsers except Edge expose @smaug----, does it sound like an acceptable solution here? This is remotely related to this issue but we discussed it here: we also find in the above doc that we currently have no factors (in spec or in browsers) that allows conversion between DIPs and physical/CSS pixels. We will handle it separately, possibly through the PointerLock coordinate thread. (Note that |
Relevant table from @EiraGe's document:
(where With the recent announcement of Edge moving to adopt Chromium/Blink, I assume that Edge will soon be using DIPs as well. If so, then updating the spec to specifying |
@bokand @smaug---- @garykac @RByers @dtapuska @EiraGe
It is not very clear what the coordinate space of screenX/Y attributes is.
Is that the correct that is it in css pixels? In other words if screenX/Y of the events is increased by 1 does that mean it has moved 1 css px? So if I have a full screen browser and I set the left/top of a div to the screenX/Y of events should it follow the mouse pointer (as in this example)?
Note that I don't care about the offset as you can move the browser window in the screen. I care about the scale of each pixel.
The text was updated successfully, but these errors were encountered: