Editing the link text is unintuitive

[mitar]

In our user testing we noticed that current editing of existing link text is unintuitive. We noticed that if user creates a link with URL and default text is link itself, they want to edit it. What they do is often click on the end of the URL in rich text editor, delete the link text and then start typing new text, expecting it to be the previously made link, just with new text. But Scribe does not behave like that, when link text is deleted, link is removed immediately and new text is not a link.

I would suggest a special case here. If link is deleted it should stay in the content if user does not move focus/cursor somewhere else. Only if after deletion users moves focus/cursor somewhere else, link is deleted. Otherwise new text become new link text for previous link.

The only issue is if link is the last thing in the editor, then deleting the link and starting typing again will still be "inside link". The solution would probably be that user moves a bit around, or that if user click at the end again (not really moving cursor, but reaffirming it) link state would also be removed.

[OliverJAsh]

I have a feeling this is the native behaviour, provided by the browser – we will have to create an isolated case to test that hypothesis.

If that is indeed the case, then I’m not sure what we can do to patch the behaviour without completely reinventing contenteditable (this is the approach Google Docs has taken and would amount to a completely different project). Is the behaviour the same in Firefox and Chrome? I think our only hope would be to file issues against those browsers.

[mitar]

Sadly, it seems the same in all browsers.

I think it could be doable. You track when link is deleted and you reintroduce it if cursor is not moved before pressing next key.

[OliverJAsh]

Sounds fiddly but not more so than any of the patches we currently have – fancy giving it a go?

[mitar]

Hmm. :-) Can you maybe point me where would be the best place to add this?

[OliverJAsh]

Somewhere in here, as a Scribe plugin? https://github.com/guardian/scribe/tree/master/src/plugins/core/patches

[mitar]

So where could I hook into every change which is made? And know also the position of the cursor? And when that position changes?

[OliverJAsh]

To do what you describe, you would listen to the mouseup and keyup events on the Scribe element. In your event handler you can use the native Selection API.

[mitar]

What about input event (to catch copy-pasting)? I hoped Scribe unified all that.

Will look into it.

[OliverJAsh]

See #193 for a discussion about the proposed selectionchange event.

I’m unsure whether input is needed as well as mouseup and keyup. Never thought of that! I assume a paste would also trigger one of mouseup/keyup, but if that happens before the paste or after, I’m unsure. It probably happens before, in which case we should update the toolbar plugin to use the input event: https://github.com/guardian/scribe-plugin-toolbar/blob/32253dd5a60893341144b5d1811c2ad7b8b7274e/src/scribe-plugin-toolbar.js#L30-L36

[mitar]

On pasting something in, you want input. If you press ctrl-v, keyup is not triggered I think because browser handles the key stroke combination.

The issue with input event is that it is not available in all browser versions. Is relatively new. So editors like Scribe should abstract this somehow and use input if it is available, otherwise failback to others.

[OliverJAsh]

The browser support for input is fine given what we are currently supporting: https://developer.mozilla.org/en-US/docs/Web/Reference/Events/input#Browser_compatibility

[mitar]

You are not supporting IE?

[OliverJAsh]

I’ve never tested Scribe in IE. I assume it doesn't work at all:

It has been tested in Firefox >= 21, Chrome >= 27, and Safari 7.

– https://github.com/guardian/scribe#browser-support

Re. #151

Have you tried it?

[mitar]

Oh, I completely missed that. I hoped IE is supported and I do not have to care about that. Shouldn't this be the point of such editors as Scribe, to be a layer between incompatibilities? So that you can easily develop plugins and it just works?

No, I am not using IE and do not have it myself. :-)

[OliverJAsh]

We’re using standard compliant APIs (where they exist). Our target is browsers that adhere to the standards.

Theoretically, Scribe should work in any browser with the Selection API, the Range API, and support for most of the non-standardised list of commands that appears in this MDN article.

– https://github.com/guardian/scribe#browser-support

I don't know what the status of IE is in terms of support for the Selection and Range APIs. If it has support, it might work. This PR claims to have Scribe working in IE11 (and soon IE10), but I don't know whether or not all/any of the integration tests pass.

I would love to have more information on this front but I don't. I was hoping the community would come forward and provide it in this issue: #151

[mitar]

Yes. I am just saying that you could add input event support to the list in #151.

[OliverJAsh]

The point of Scribe is to polyfill browser inconsistencies in browsers that do have the Selection and Range APIs – it’s goal is not to polyfill the Selection and Range APIs or browsers without them. Ideally, these polyfills could be written as individual projects, in which case you would simply load in the polyfill before Scribe.

Many other popular editors (TinyMCE et al.) go down the route of “polyfilling” these missing APIs internally, which has resulted in pretty poor code.

[OliverJAsh]

@mitar Added, thanks.