-
Notifications
You must be signed in to change notification settings - Fork 33
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
should altitudeAngle default to 0 or pi/2 when not supported? #320
Comments
Just to add one additional point. When the device doesn't support this stylus angle we set tiltX/Y to zero. Meaning we indicate the pen is straight. If we set altitude/azimuth to 0 as well it shows that the pen is parallel to the surface. Then these two coordinate system at least in the case of the device not supporting them are going to differ and show two different states of the pen. |
ah, good catch. this could at least be used as a sensible justification beyond "just because we don't like it / think it makes sense" in TE vs PE |
Decided on today's call https://lists.w3.org/Archives/Public/public-pointer-events/2020AprJun/0050.html that it does make sense to go for a value of We should consider adding a prominent warning there in the spec so authors don't miss this divergence from Touch Events. |
Addressed in #323 |
splitting this off from #316 (comment)
in short: in Touch Events, if the current touch is not from a stylus that supports altitudeAngle/azimuthAngle, both values are
0
. the theoretical case of a stylus lying completely flat/horizontal on the screen does not seem to actually happen - the stylus tip does not touch the digitizer in that scenario. so0
seems a safe assumption for "not a stylus, or a stylus that doesn't support position/attitude information". presumably web apps that deal with stylus using Touch Events use this assumption today as well.for pointer events, currently we also used
0
as default value. now, a more logical/safe approach may well be to say that the default should be either PI/2 (perpendicular stylus), or to provide a clear NaN or similar that signals it's not supported at all.personally, i think it would be confusing if PE's
altitudeAngle
differed this dramatically from TE'saltitudeAngle
. but i can see the argument about authors simply wanting to plug a property into their code and have it default to something sensible.would appreciate further thoughts/opinions on this.
The text was updated successfully, but these errors were encountered: