Keyboard events that remove something and turn non-plain text into plain text (e.g. Ctrl-\, Ctrl-M) should work by simply positioning the cursor on the text and pressing the keys; instead, VE requires the text to be selected, which is an unnecessary slowdown. (Compare with e.g. the gmail editor where moving on a link and pressing Ctrl-K removes the link instantly. Compare also with the VE GUI link dialog's remove button, which works in a similar fashion.)
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
What's your proposed alternative? If the document is (real-world examples like this exist quite often, especially on wikis, enough that this isn't a dismissible edge case sadly):
<p>Foo<b>b|ar<a href="./baz">ban<i>g</i></a></b></p>
… Maybe remove the <b> but not the <a> or <i>? Why?
<p>Foo<b>bar<a href="./baz">ban|<i>g</i></a></b></p>
… Maybe remove the <b> and <a> but not the <i>? Why? Will users be surprised?
Etc.
Comment Actions
For the particular case of link inspector, you can do Ctrl+K with the cursor anywhere within the link, then Delete and Enter. The interface doesn't look like the Enter will do anything (the button is disabled, and there's a red invalid indicator), but it works.
Comment Actions
Yeah, I see what you mean. In those cases IMO it is still fairly intuitive to just remove all formatting (as it would happen with text selected - ie. remove all tags that are overlapping the cursor), but things involving whitespace like foo<b> |bar</b> vs. foo <b>|bar</b> look impossible to handle in a non-confusing way.
Huh. Yeah, that works but is very unintuitive.
Comment Actions
All formatting where, though? In my first example it's relatively clear you're thinking of "just" the <b>, but in the second is the cursor next to an annotated <i> enough to cover that too? If not, why not? How does that work for user expectations for (say) Japanese?
Comment Actions
Unwind from the innermost element that the cursor is inside, to the outermost, for each remove style. In this case
<p>Foo<b>bar<a href="./baz">ban|<i>g</i></a></b></p>
the i-tag will newer be removed, as the cursor is not inside the element.
Comment Actions
Unfortunately closing this Phabricator task as no further information has been provided.
@Tgr: After you have provided the information asked for and if this still happens, please set the status of this task back to "Open" via the Add Action... → Change Status dropdown. Thanks!
Comment Actions
I think the most intuitive behavior would be to only remove the innermost element and only if it actually wraps the cursor. Also it probably shouldn't remove block formatting, especially paragraphs (the current selection-based mechanism doesn't do that either). So
- <p>Foo<b>b|ar<a href="./baz">ban<i>g</i></a></b></p> -> ⌃+M -> <p>Foob|ar<a href="./baz">ban<i>g</i></a></p> -> ⌃+M -> (no effect)
- <p>Foo<b>bar<a href="./baz">ban|<i>g</i></a></b></p> -> ⌃+M -> <p>Foo<b>barban|<i>g</i></b></p> -> ⌃+M -> (no effect)
Not affecting <p> tags matches current behavior, and merging paragraphs isn't a meaningful "remove formatting" action from the user's perspective anyway. Not affecting elements when the cursor is next to them but not inside them seems more intuitive to me, although I don't think it makes much difference either way. Only affecting one element at a time makes the behavior less surprising - if e.g. there's a quoted paragraph in italic, and a link in the middle, and the user presses ⌃+M inside the link, removing the italic as well will probably surprise them. Also removing both formattings with this behavior is easy, removing only the inner formatting would not be possible with the other behavior.