-
Notifications
You must be signed in to change notification settings - Fork 133
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
Allow doubles for ProgressEvent's loaded and total #394
base: main
Are you sure you want to change the base?
Conversation
I'll double check, in principle it seems fine. @smaug----? |
Closes #15. Depends on whatwg/xhr#394.
This allows specifications to use ProgressEvents while not necessarily giving away the exact number of bytes, while maintaining a granularity greater than just 1 part in 100. See discussion in webmachinelearning/writing-assistance-apis#15 for the concrete use case.
48e8e0d
to
5b4e883
Compare
Should be fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you could ping me once Chromium has successfully shipped this I'd appreciate this and I'll be sure to align WebKit at that point.
Awesome. I'm hoping to delegate the implementation and tests to someone else so it might be a week or so, but once we have tests up I'll update this thread with a link to them and open other-browser bugs. And I'll ping again once we have it shipped. |
Closes #15. Depends on whatwg/xhr#394.
Closes #15. Depends on whatwg/xhr#394.
Closes #15. Depends on whatwg/xhr#394.
Bug with a patch https://bugzilla.mozilla.org/show_bug.cgi?id=1943649 (webidl codegen for events is nice in this case) |
This allows specifications to use ProgressEvents while not necessarily giving away the exact number of bytes, for example by using numbers between 0 and 1. See discussion in webmachinelearning/writing-assistance-apis#15 for the concrete use case.
ProgressEvent
behavior changes: fractions are preserved, and negatives are now passed through as-is instead of subtracted from 2^64.(See WHATWG Working Mode: Changes for more details.)
I wanted to get this PR up to judge implementer interest. It would be a decent bit cleaner if we all agreed this was reasonable and merged the change now, instead of having to float a patch in the relevant specs and thus causing all the databases to have two definitions of
ProgressEvent
.Preview | Diff