Remove long_to_double from MouseEvent API#11317
Conversation
|
These entries are very poorly described, but are about this change I think: (The versions don't match, so I'm not sure...) https://chromestatus.com/feature/6169687914184704 is a similar change. |
|
I'm now realizing that I was seriously confusing |
|
Yeah, I think a single subfeature per interface where some members changed from always integer to sometimes floating point would be good. "fractional coordinates" is actually a pretty good description I think. I see that https://chromestatus.com/feature/6169687914184704 says:
If that's still true, then these entries on |
|
This all originates from the wiki table: I'm pretty sure that the single "MouseEvent.screenX, MouseEvent.screenY, MouseEvent.clientX, and MouseEvent.Y are double instead of long." feature there was based on https://chromestatus.com/feature/6169687914184704 and was then turned into multiple features when it was ported to BCD in #1883. I've just tested in Chrome 91 to confirm that A further nail in the coffin is that the spec uses |
|
@ddbeck let me know if you need any more info for the release notes here, or if it seems suspect when you try to explain it. |
|
Note also that the real change/feature is already represented here: |
|
And I've sent #11327 to link bugs for that entry. |
* Bump version to v3.3.10 * Add release note for #10958 * Add release note for #11061 * Add release note for #11062 * Add release note for #11266 * Add release note for #11276 * Add release note for #11307 * Add release note for #11317 * Add release note for #11323 * Add release note for #11328 * Add release note for #11334 * Fix formatting * Set release date * Add stats
This PR removes the various
long_to_doubleentries from the MouseEvent API. Overall, the difference between alongand adoubleis more floating point accuracy, but I can't imagine a scenario where a web developer will require such high levels of precision, not to mention this is near impossible to test, and only really observable in the WebIDL.