Offer a "selection-change" event?

[TooTallNate]

When looking at the code for the scribe-plugin-toolbar, it seemed obvious to me that a selection-change event generated from the Scribe instance would be highly useful to lots of plugins.

How hard would it be to implement this? I could perhaps take a stab at it if you'd like.

[samvasko]

Hard as usual, but it doable. there is selectionchange that does not work in FF and has no spec. But should be working fine on IE/Blink/Webkit.

So maybe checking for document.onselectionchange and falling back to those 4 events would do the trick!

[OliverJAsh]

This would definitely be useful, as a replacement for wherever we listen to mouseup/keyup.

[OliverJAsh]

I guess your custom event would use mouseup/keyup behind-the-scenes. That’s easy. But detecting when the selection has actually changed inside those events would be a little bit tricky, perhaps. I guess you could compare the start{Container,Offset} and end{Container,Offset} with each mouseup/keyup. Unless you have other ideas?

[TooTallNate]

Also consider using a polyfill: https://github.com/2is10/selectionchange-polyfill

[OliverJAsh]

+1 to using a polyfill, if the edge cases are considered acceptable (and it’s not a regression from what we currently have).

Oliver Joseph Ash Software Engineer

On 13 June 2014 18:12, Nathan Rajlich notifications@github.com wrote:

Also consider using a polyfil: https://github.com/2is10/selectionchange-polyfill

— Reply to this email directly or view it on GitHub https://github.com/guardian/scribe/issues/193#issuecomment-46036319.

---

Visit theguardian.com. On your mobile and tablet, download the Guardian iPhone and Android apps theguardian.com/guardianapp and our tablet editions theguardian.com/editions. Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered in England Number 908396

[OliverJAsh]

On second thoughts, it’s not a standardised event, it just happens that browsers are reverse engineering each other (once again). In that case I think I would prefer not to polyfill it, but I still like the idea of having an event…

[deuill]

I've implemented Scribe for some internal WYSIWYG functionality, where using straight <buttons> (which don't hijack selection state) was not possible, as we needed dropdowns and special character selection and what-not.

So, I made a plugin that stores the selection state, which can then be recalled just before calling a command by executing it. It's hack-ish, but it works.

https://gist.github.com/thoughtmonster/01e95eb4859a74c4e165

Doing window.getSelection() and document.createRange() is required for Chrome, which doesn't work with a new scribe.api.Selection, but otherwise it's pretty straightforward.

Comparing the values between events is just a couple of lines of code, but I think there should be some way where selections aren't as sensitive as they are now, and should work with any element.

[mitar]

@ thoughtmonster: I think what you are describing is related to ticket #129. I implemented something similar to what you are describing, but using rangy.

[hgl]

It would be tremendous helpful if scribe polyfills this event, because currently it kinda breaks this event.

The culprit is the undo manager (if i'm not wrong), which is constantly inserting markers around selection range, which in turn, triggers selectionchange events. On digging deeper, it's actually that selection.placeMarkers() changes selection directly.

So, for example, every time a character is typed in, multiple selectionchange events are fired.

For a vanilla contenteditable element, this event is fired only once when a character is typed in.

[hmgibson23]

Yes the selection is slightly broken at the moment. I think we need to have a further discussion about how to fix it @theefer @rrees

[mindplay-dk]

This issue has been open for going-on two years. Any progress?

I was poking through every scribe plug-in I could find on Github yesterday, and at least three times, I saw people listening for a list of mouse and keyboard events trying to track the selection.

Is this really very hard to implement? Listen for mouse-up/key-up/focus/blur events, check if the selection has changed and broadcast the event.

As @OliverJAsh pointed out, this is not a standard event - I would suggest a consistent implementation that uses the standard events to generate a standards-like event; in case it does get standardized some day.

To implement this, you have to write the code that uses standard events either way, so there's no reason to write extra code to support the non-standard event - that only complicates rather than simplifies.

[rrees]

There's not a huge internal driver for this so I think we'd welcome a community contribution that had general support.