CTRL-V Still Pastes the Style

[co50]

I noticed in recent release notes that you fixed an issue where styles were being copy/pasted when they shouldn’t. I assumed this meant when using SHIFT-CTRL-V, because this was the case where in Pro 2.x using this shortcut would still paste underlying HTML (especially font sizes) sometimes even though it’s not supposed to.

I noticed when right clicking on Pro 3.x that there are options for Paste and Paste + Style. But these are incorrectly labeled .

On Pro 3.x, SHIFT-CTRL-V does not paste the style. It pastes the unformatted text, which is how every other desktop application treats it. So this is good.

CTRL-V pastes the whole thing, style and all.

You have these labeled the opposite of what they actually do.

[christopher]

Hi @co50,

I use Mac, so my experience may be different but here what I see using the Pro version 3.0.4:

When I use Cmd+V, it pastes the whole thing. When I use cmd+Shift+V, it pastes the only style, not paste + style.

So in order to use the paste style, you need to have another element added and use the shortcut on that element to apply the style.

I tested this on a Headline element. By that account, the labels are correct on the context menu. If you have another experience, I will appreciate it if you give us a quick screencast to check and to know the circumstances.

Thank you.

[co50]

Maybe it’s different on a Mac.

On Chrome + Windows 7, if I copy underlined (or bold, or large, or whatever) text and then I CTRL-V it into a Pro text element, I get the exact text as it was formatted at the source - underlined, bolded, large, small, whatever.

If I SHIFT-CTRL-V that same text it pastes just the text. No underline. No bold, no font size change. The text is styled in whatever way the area I’m pasting it into is. It does not retain styling from the source.

On Windows 7, CTRL-V is labeled as “Paste” and SHIFT-CTRL-V is labeled “Paste Style”. It does not paste the style though. It does the opposite.

Honestly, I couldn’t care less but just wanted you to know for when newbies come along and get confused. We know what the shortcuts actually do, but this will be confusing for those that do not.

[rad]

Hi @co50,

Please note that Copy and Pasting functionality is device and app’s feature, the builder only uses that same feature to extend its functionality. And it’s something we can’t override since all of that is limited to javascript capability imposed by browsers.

I have Mac, Windows 10, and Windows 7, so far I have no issues with copy and pasting. The Shift + Control + V is the standard way of pasting unformatted content. May I know which browser on Windows 7? That’s because Shift + Control + V is app-specific (like Word documents, chrome, firefox, and so on). Our builder only relies on the resources provided by active browser.

Thanks!

[co50]

Rad - yes, you are correct. Nothing you said it incorrect. But my original post was pointing out that when you right click in Pro, the context menu labels (YOUR menu) swap the functions of CTRL-V and SHIFT-CTRL-V.

[rad]

Hi @co50,

Ah, you mean you’re comparing the standard system’s copy and pasting feature with Pro’s context menu. They are completely different since elements aren’t HTML content. And that one on Pro’s context menu is correct for its purpose.

Since an element is not an HTML content, then in context menu CTRL V means whole, and SHIFT-CTRL-V means partial.

For example, since you’re expecting the Pro’s SHIFT CTRL V to work as to how you copy and pasting ad Word document (formatted and non-formatted), then how the Pro should paste a non-formatted element? It’s not possible since there is no non-formatted in Pro element, what you copy and pasting are data of those elements, style or not.

Hence in Pro context menu, CTRL V is simply replaced all (the whole element), and SHIFT CTRL V is simply partial paste (just settings of the element).

I was confused what was the issue because you said this

I noticed in recent release notes that you fixed an issue where styles were being copy/pasted when they shouldn’t. I assumed this meant when using SHIFT-CTRL-V, because this was the case where in Pro 2.x using this shortcut would still paste underlying HTML (especially font sizes) sometimes even though it’s not supposed to.

Pro’s context menu is never used for copy and pasting HTML content even on the older version. So I’m not sure what fix you’re referring to. Hence, I assumed that you’re not referring to the context menu, but the general copy and pasting shortcut when you’re editing the text element.

They are completely different feature, the labeling is correct to its intended feature since the data and element settings are not CSS styling.

And if we’ll do the Pro’s context menu SHIFT CTRL V as pasting an unformatted element, isn’t that just adding another empty or clean element? Instead, it’s purpose is partially paste the element state (like settings). Also, in standard copy pasting from, pasting a non-formatted content is also considered partial (since not the exact content is pasted). Hence, labeling might also connected, it just happen elements aren’t HTML, but structure and data, and it happens that those style are also the data which is considered content too.

I’ll forward this as all of that are just my personal opinion. Perhaps labels can be swapped due to style wording. I’ll also continue check this part If I SHIFT-CTRL-V that same text it pastes just the text, it’s something I can’t reproduce yet. Because I also assumed you’re pressing SHIFT CTRL V within the text editor, which will really just paste the text unformatted. That’s no longer connected to Pro context menu, but browser’s copy and paste feature. But again, if you’re referring to a copied element (not HTML codes or content) and pressed SHIFT CTRL V and it only pasted the content of that element, then I can’t reproduce it yet. Will further check.

Thanks!

[co50]

Wow - OK, so this is actually more of a mess than I thought. Looks like there are two different functions here and Pro just ignores one of them.

In a nutshell, when copying text from a 3rd party source (and BTW your customers are doing this waaaaaay more often than they’d copy Pro elements this way) to a Pro web page, the context-menu labels are reversed from what the keyboard shortcuts they display actually do, and these functions cannot even be selected. While we use keyboard shortcuts, plenty of novice users still paste via right mouse click. You’ve disabled this functionality for them.

When copying an element from Pro to another place in Pro, the right click context menu comes into play. And nobody really knows why since duplicating an element and moving it does the same thing and is arguably faster. In that instance, I guess, the labels are accurate. Though I couldn’t figure out what the heck Paste Style is supposed to do since I couldn’t get it to work after 5 tries on different elements. It did nothing.

Anyway, this thread was mainly intended to point out how convoluted the labels are and now the whole pasting element thing is even more confusing to me. I guess some could find a use for this, but duplicating an element seems to do the same thing, faster.

Duplicate method: Click element, click Duplicate, move it to preferred spot.

Copy/Paste method: Click element, CTRL-C or right click Copy, click an element in the column you want it to go, click column on top left side bar (since clicking the column directly in the editor isn’t always possible), CTRL-V or right-click Copy

Weird.

[alexander]

Hi @co50,

I think we could clear this up by disabling the builder’s right-click menu if you are using inline editing in the preview area. That might be what’s causing the confusion here since the menu appears but you can’t use any of those options while editing text inline. For now, something you can do is go under Preferences and disable the context menu. Or if you hold ctrl/cmd when right clicking it will ignore our version of the menu.

To clarify, our cmd+shift+v “Paste Style” action is not at all related to the native “paste without formatting” behavior. It is used to copy only styling (no content) between elements of the same type. Here’s an example of you can see this in action:

• Add two button elements in separate columns
• Change only the text on Button 1
• Change only background color on Button 2
• Duplicate Button 1 a few times.
• Right click and copy Button 2
• Right click one of the Button 1 elements and choose “Paste Style”. You should see the background color change, but not the text. This effectively mirrors the “Apply Preset” functionality with “Replace Content” unchecked.
• Now right click the column, row, or section where your several Button 1 elements reside. If you do “Paste Button Style” on one of those parent elements, it will apply your style to all the same elements. One example of when this might be useful is if you have some Columns and you want to quickly make the background color and border radius identical without using a preset and without changing it one by one.

You’re right, arguably you can duplicate and move the new element just as fast. Pasting just gives you another way to do that, and might be handy in places where you want to move something much farther away on the page. Another benefit is the ability to copy entire rows and columns. For example, right click and copy a Row, then right click and paste into another section. This is faster than having to switch to the Layout pane to drag the Row to its new home.

[co50]

I’m starting to usefulness of this, so I guess the main point - and you’re in agreement, is that the labeling and when the Pro-context-menu appears can be confusing. Whatever you can do to improve on that I’m sure would be helpful.

[christian]

Hey @co50,

Thanks for your feedback. To clarify, the confusion basically boils down to the activation of the Pro Context Menu when the Text Inline Mode is activated. Do you prefer to use the browser’s Context Menu when in Inline Mode?

The reason why I only see the confusion only in Inline Mode is that at this stage, the intent is usually to work just on the text and not the whole element.

In other areas, I see no confusion provided that the user is aware that Cornerstone / Pro has their Context Menu and Keyboard Shortcuts separate from the browser’s Context Menu and shortcuts.

Thanks.

[co50]

Basically, wherever the right click menu doesn’t actually work or make sense (like in inline editing), don’t show it.

I honestly use keyboard shortcuts exclusively, but I did catch the right click menu and thought it wasn’t labeled properly, which is why I brought this up. I did, however, try using the keyboard shortcuts assigned to your context menu, and they hardly ever work, so maybe just not including the shortcuts would further curb any confusion.

[christian]

Thank you for your feedback. I’ve now tested a page with lots of elements and the shortcuts work all the time. I’ll try some more tests and I’ll post the issue in our issue tracker once I have replicated.

In some elements like the Headline element, pasting in Inline Mode including HTML (ctrl + v) would not include the HTML because it’s not proper to do so. You should not be adding Block level HTML to a Headline. Adding of HTML for this case should be done manually in the HTML Editor.

Thanks.

[alexander]

Quick update: I just wanted to confirm that we’ve made this correction. In the next release the application context menu will not appear when right clicking if you are using the inline editor.