Add new section explaining coalesced and predicted events#364
Conversation
- provide a simple explanation of what these things actually *are* - shift the relevant examples into this new section and renumber the examples throughout the spec
for consistency, as "UA" appears only twice in the spec, and that use of "API" feels awkward
|
would appreciate a pair of eyes whenever your get a chance (as can't merge without one approving review) - this should be fairly non-controversial |
|
This is awesome! Thanks for taking care to add this. I have a few minor comments/questions, mostly around pulling some more text into your new section: A. In 5.1, the big text explanation right after B. The image about prediction needs to show the direction of drawing, otherwise it would be very confusing. Also, can we perhaps zoom in one part of the curve where we have two non-overlapping prediction-lines? ("Too many C. This is subjective, but in an introduction I prefer very focused code examples (no |
Yeah, I was considering this initially, but now wondering - should the new section here for coalesced/predicted events actually come under the (now renumbered) section 4 as a subsection, similar to 4.1.1 button states? and then yes, move the big text into it, here.
Agree about indication the movement direction that caused these points. Have to admit, because I was using https://patrickhlauke.github.io/touch/coalesced-predicted-events/ it ended up being surprisingly difficult to "swoosh" a good representative gesture. I might have to tweak my source script and possibly just zoom in on the end of the gesture (where the predictions become a bit clearer/better than the often quite random predictions that Chrome seems to give me during a drawing operation currently).
fair point yes, especially since we already stress the need for considering keyboard etc elsewhere. will tweak |
checking back on this, just to mention that in my demo, i don't actually draw any prediction lines per se, just the regular lines between confirmed and non-coalesced raw points. the predictions just show as dots (as otherwise i'd need to start tweaking my drawing logic to start looking at timestamps, and start drawing line segments from the last known good point to the next predicted point only, etc). I'll see if i can make it clearer though |
|
@mustaqahmed I chose a much cleaner example image for the predicted points and clarified in the caption what the movement that led to that line was. |
- move the extended existing explanations for coalesced and predicted events directly into the new section - split section into two subsections (one for coalesced events, one for predicted events) - tweak line lengths, unnecessary use of `code` and `var`
|
@mustaqahmed I've gone with your proposed idea of moving the content about coalesced and predicted events into the section (plus made a few tiny tweaks). Initially tried moving that whole section back up (to be a sibling section to "Button states", "Primary pointer", etc), but it felt odd / far too wordy / got in the way of getting to the actual list of "Pointer Event Types". I think this way here works ok. Going to set this back from draft to ready for QA |
mustaqahmed
left a comment
There was a problem hiding this comment.
This is very nice and organized now, thanks again! I never realized until now how the coalesced/predicted concepts were mingled with unrelated text before!!
I have one big suggestion only, about a new 10.3 below. The rest are minor comments.
c27d731 to
47d0fe2
Compare
mustaqahmed
left a comment
There was a problem hiding this comment.
LGTM. There are some unclear things from existing text but let's do it separately.
|
I believe that, at least in part, this PR also addresses #215 - please see if there's anything else that's missed out/unclear |
|
For the question relating to initialization (#364 (comment) and #364 (comment)), I opened a separate issue #374 |
…eaning "direct manipulation behavior"
f4b852d to
88ce9a0
Compare
* clearly list out properly what properties the coalesced/predicted events should have (more closely matching the suggested structure from #215) * remove the "Populating and maintaining the coalesced and predicted event lists" part, which is more confusing than anything if the various steps (with the dirty flag etc) are essentially just browser-internal flags, and where it doesn't really matter where/when the targets are changed as authors can't observe this change. leave it up to implementations how they want to do it. they can just decide wholesale to set the target to the event where the `getCoalescedEvents`/`getPredictedEvents` methods are being called on - see #364 (comment) Closes #370 #215
Closes #361 and #215
Preview | Diff