Copy plain text variant of blocks #41366
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
draganescu
added
[Type] Enhancement
|
Size Change: +77 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
|
cc @mcsf who has thought about these mechanics before |
mcsf
reviewed
May 27, 2022
There was a problem hiding this comment.
The value in this change is clear, but we need to identify the use cases for stripped and unstripped content copying, so as to minimise the disruption for users who have come to expect this behaviour. :)
Btw, I quickly wrote and uploaded a "clipboard debugger" to dive into this topic: http://mcsf-clipboard-data.surge.sh/ . This works as expected in Firefox, but I see strange data in Safari, which I suspect to be due to some policy of per-domain clipboard isolation or similar.
So, coming back to identifying use cases, we have:
- Select a range of blocks and copy with Meta+C — handled by CopyHandler
- Select a range of rich text within a single block and copy with Meta+C — handled by useCopyHandler
- Click the Copy All Content button in the More menu — handled by CopyContentMenuItem
- Select a block and click the Copy button in the block's dropdown menu — handled by CopyMenuItem
- (anything else that I'm forgetting?)
The first two cases are those in which multiple types of data are added to the clipboard (text/plain, text/html, and some special rich-text-related types), while in cases 3 and 4 we only set text/plain with serialised block markup.
Case 1 is the one that this PR is changing. Note that, in case 2, the plain-text payload was already free of the HTML-comment block demarcations, so this PR can be said to make copying more consistent across the editor.
@draganescu: Can we list pros and cons of stripping content down to the visible plain text?
| event.clipboardData.setData( 'text/plain', serialized ); | ||
| event.clipboardData.setData( | ||
| 'text/plain', | ||
| stripHTML( serialized ) |
There was a problem hiding this comment.
If we go forward with this, we'll want to clean up line breaks:
Suggested change
| stripHTML( serialized ) | |
| stripHTML( serialized ).replace( /\n\n+/g, '\n\n' ) |
I'm trying to decide whether this belongs inside stripHTML; it's a question of whether it can break any expectations within Gutenberg Core, and — although it's an explicitly __unstable API — any expectations with third parties.
|
Years ago, in a discussion in this repo around copying and pasting, someone suggested some sort of just-in-time UI, like a popover around the cursor, asking the user what they would like to copy or paste: the plain text, the rich text, or the markup. I don't really know how I would find that thread nowadays; I don't think that anything came of it, but I think there's an opportunity for better clipboard ergonomics. In my mind, it's similar to this URL-opening tool called Choosy, but reacting to Meta+C or Meta+V: open-link-with-choosy.mp4 |
Me! Ulysses does something similar. |
|
Wow, we're handling the clipboard in so many places 😁 !
Pros
Cons
MS Word has the Paste Special command which opens an ancient popup window allowing the user to select what to paste (HTML, formatted, unformatted).
To make things consistent I think we should: (a) make the behavior of:
... be consistent in putting visible text in (b) rename the more menu's "Copy All Content" to "Copy Block Content" and override |
|
I think your arguments and proposals are fair, @draganescu. I'd like an extra opinion, perhaps from @ellatrix? |
|
This is fine with me. Ideally, the plain text type should be plain text, the HTML type should be just HTML without block demarkations, and we should use a custom type for the proper serialised output with the block demarkations. I'm pretty sure there's at least one existing issue that can be closed by this PR? |
|
@mcsf @ellatrix so what's next for this? Can it be merged like this, or should I build the following: (a) make the behavior of: ... be consistent in putting visible text in text/plain and html + block markup in text/html, plus the formatted rich text. (b) rename the more menu's "Copy All Content" to "Copy Block Content" and override text/plain with block markup and HTML in this special situation, which would be a shortcut to switching to code view and copying all visible text from there. ... on top of this? |
Not sure what you mean here. |
|
If I understood Ella correctly, the part about allowing users to copy HTML stripped of block demarcations into |
|
Some complexity here :)
|
|
@mcsf for consistency the following have been added:
|
mcsf
approved these changes
Jun 13, 2022
packages/block-editor/src/components/block-settings-menu/block-settings-dropdown.js
Outdated
Show resolved
Hide resolved
|
:D |
What, it doesn't run? Pff, minor detail! 😅 |
…ck markup is copied as well
Co-authored-by: Miguel Fonseca <[email protected]>
draganescu
force-pushed
the
try/better-text-copy
branch
from
6af62cc to
89006fd
Compare
|
FYI: I worried that this change might break the possibility to copy multiple blocks / nested blocks to save them in a .html file for including as a pattern in a theme. But using the "Copy Block" menu button and pasting it into VSCode or Windows Notepad also pastes the block markup - so everything's fine 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR strips the HTML from copied block markup for the text/plain version of the clipboard.
Why?
Pasting into plain text editors should only paste the text we see on screen not the whole underlying
markup.
This is an improvement in the experience of writing in a different app rather than in the
WordPress editor itself, and then bringing over the content. Since one could move text content back
and forth a few times, pasting block markup is annoying if not even prone to introducing problems.
How?
By fixing what seems to be a problem anyway: stripping HTML out of serialized data in the copy
handler before placing it in the
text/plainversion.Testing Instructions
Make plain text before pasting)
Screenshots or screencast
Before
paste-plain-before.mp4
After
paste-plain-after.mp4