Closed fyvfyv closed 2 years ago
@fyvfyv thanks for your patience! I've done a bit of tinkering, and I've potentially got an avenue we can explore that doesn't require constantly listening for mousemove
on the entire Quill root. There's a rough proof-of-concept here, where we toggle a class in JS on hover, but also allow clicking through to the underlying link.
The basic principles are:
mouseover
on the cursor only, which vastly restricts the number of events we're handlingmouseover
, then we apply pointer-events: none
(and any hover state we want) — this then lets us click the underlying element.mouseover
handlers on the document itself: when the mouse moves, we check if it's still intersecting the cursor. If it is, then we add another one-off handler. If it's not, then we remove the hover state and reset pointer-events
, which lets us pick up a hover again.This potentially handles a lot of events if a client makes extremely small movements within the cursor (thus staying in the manual mouseout check), but given that the cursor is so small, I think this is very unlikely.
What do you think?
@alecgibson Yeah, it might work. I'm trying to implement it in this repo and let's check
There is the issue with using CSS for opening/closing logic for flags. It's broken on touch devices (which don't trigger the
:hover
styling) (Issue #77). To fix it, we moved all the logic to JS:z-index
to «move» a cursor behind the text. It resolves the issue, when a cursor prevent clicking on the text (even if a user clicks exactly on cursor)mousemove
andtouchstart
with a callback, which shows/closes flags depends on a point positionTo achieve it there are added a couple of callbacks to update cursors position and store it in the quill-cursors module. It should be enough to cover all cases for touch and non-touch devices. Also, there is a small throttling for mousemove events to improve performance and decrease amount of callbacks executions