On 2021/03/10 21:23, Xidorn Quan wrote:
On Wed, Mar 10, 2021, at 8:01 PM, Anne van Kesteren wrote:
That does seem unfortunate, but unless other browsers are interested
in picking this up, I think it will hurt us more to be different than
that it helps. I don't think we should make aligning with Chrome and
Safari conditional upon some new API.
I agree with this.
My main concern is that an event may be checked in multiple places, e.g. some
in web framework like React, some in the site itself, or maybe just inside code
owned by different teams. It would be pretty surprising if some of them checks
the `deltaMode` and then the behavior suddenly changes for other places trying
to read the value.
I would suggest that we bring this back to W3C to discuss with other vendors
regarding the current situation. If the web has been relying on delta being
always pixel, maybe we should make `deltaMode` always return `DOM_DELTA_PIXEL`,
and deltas always return pixel value.
If the raw value is still useful to authors, one possible solution is that we
expose a new `rawDeltaMode` and probably a new `getDeltaValue` method or so
which requires a delta mode to be provided, and in the case such mode matches
the raw delta mode, the raw value is returned without conversion. This way it
could be less likely to be misused.
WDYT?
Yes, I also think that the current behavior has the risk on web apps
which have multiple `wheel` event listeners. On the other hand, mainly
from my experience at aligning `keypress` event to Chrome, existing
behavior change is also really risky because a lot of web apps may check
UA name and OS instead of checking behavior. The hacky way guarantees
that the behavior does NOT change on web apps which handle `wheel` event
correctly.
--�
Masayuki Nakano <masay...@d-toybox.com>
Working on DOM, Events, editor and IME handling for Gecko
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
