Gutenberg: TinyMCE Core v4.6: add inline boundaries for links and code

[mtias]

Behaviour: moving cursor from the left towards a link should have two spaces, one where it goes to the edge of the link, and another where it goes inside the link but to the left of the first character within the link.

Example: https://cloudup.com/c49BKKIE7SW

[androb]

Thanks Matias, we're taking a look at this.

[spocke]

I've started working on this issue. I expect it to be finished before the end of this week.

[androb]

The video above has padding to the left and right of the hyperlink and Quip does not.

Do we believe that there should be padding?

[mtias]

Quip is better visually, this was mostly to illustrate how it works.

[jasmussen]

The video above has padding to the left and right of the hyperlink and Quip does not.
Do we believe that there should be padding?

The video above is from the UI prototype, where we built the feature for vanilla contentEditable.

Quip works great, in that in the stop immediately before the caret enters the link tag, the link looks like it usually does. Moving the caret one more stop to the right highlights the link with a boundary, implying you're now "inside the link tag".

Since we're essentially adding an arrow-key stop where none intuitively should exist, we need either the Quip-style highlight effect to visually imply what's happening, or extra padding on the side. I'm partial to the highlighting.

[spocke]

I have now merged the first version of the link/code boundary feature a demo can be found here: http://fiddle.tinymce.com/RKfaab

We will continue to work on this next week to fix a few more issues with it but so far the approach we took seem to be working pretty good.

[jasmussen]

I have now merged the first version of the link/code boundary feature a demo can be found here: http://fiddle.tinymce.com/RKfaab

Feels great! Looks good too! Nice work.

[anna-harrison]

Agreed - Nice job 👍
Question: should pressing space at the end of the link exit out of the link insertion mode? Right now, the only way to get out of the "inside link" mode is to press the right arrow key. Should ESC also exit out of the "inside link" mode?

[aduth]

Question: should pressing space at the end of the link exit out of the link insertion mode? Right now, the only way to get out of the "inside link" mode is to press the right arrow key. Should ESC also exit out of the "inside link" mode?

To me it seems as though pressing space within the link boundaries should not escape out of the linked text, since otherwise it would be difficult to add additional words to an existing link. Escape could be more reasonable, though what would happen when pressing escape while in the middle of linked text, not at the end?

[jasmussen]

Question: should pressing space at the end of the link exit out of the link insertion mode? Right now, the only way to get out of the "inside link" mode is to press the right arrow key. Should ESC also exit out of the "inside link" mode?

The benefit of the tweak to how links behave, with an extra arrow key stop before and after, is that it becomes clear to the user when you are extending the link, and when you are not. If space exits you out of this, it seems like you can't write anything but single words with no spaces in them, as you are typing inside a link.

Esc is a fine keyboard shortcut to keep in mind for _escaping out of modes_. But I'm not sure the link boundary feature counts as a "mode" — the caret would have to move out of the link as you press escape, which seems disruptive.

[jasmussen]

Feature is working great — we discovered over the weekend that it doesn't work on an iPad with a connected keyboard. Is it technically possible for us to make it work here? I do realize that WebKit is the new IE and this may be difficult.

CC: @spocke

[spocke]

I can investigate that but it might be that the iOS selection model doesn't support us mutating it once the keyboard is enabled.

[jasmussen]

I can investigate that but it might be that the iOS selection model doesn't support us mutating it once the keyboard is enabled.

Would love to see if this was possible. I'm getting signals that Quip might have solved this, but alas I can't test since I don't have a bluetooth keyboard.

[Afraithe]

Yeah we need to get a BT keyboard as well, and a more recent Android device. But our Brisbane team is well setup to test mobile once we get to building more on the mobile side of things.

[mtias]

I quickly tested trying to position the cursor before the "p" but within the link by tap-and-dragging and that didn't work either, so perhaps it's just a general mobile safari issue?

[spocke]

Added a related issue #207 to this one since the first deliverable is done and out there. I added the iOS testing to that one. I leave this one open as some form of master bug for this feature.

[spocke]

Looked into the bluetooth keyboard issue. I think it's impossible to solve since iOS isn't firing any events on the arrow keys tested keydown,keypress,keyup a bug report has been reported and is in Apples internal radar issue tracker: https://bugs.webkit.org/show_bug.cgi?id=149054 might also be solved if they ever support beforeinput event on iOS.

[mtias]

@spocke I think we can close this one and just open individual issues for other improvements.

[jasmussen]

Closing in favor of the other tasks.