I understand that links are currently not click-able in Touch UI when in Edit Mode.
I have a situation where I am trying to improve the experience for my authors.
We have tabs on the pages that authors are editing. The tabs change what content is shown on the page. Currently the author has to click on the preview mode, then they can switch tabs, then they have to go back to edit mode, click the component, and then click the wrench.
The solution I want is to enable specific links, or even non-external page links on a page. I can see the need for this for in-page navigation, or enabling functionality in Tabs or Sliders.
I identified that touch ui places a overlay ontop of the page, that prevents interaction from bubbling to the iframe below with the content. Instead all components get a overlay rendered inside the overlay container, which represents there interaction point. I also identified that components get this extra overlay for interaction by the CQ element that is created automatically.
While this is clever, it is also heavy handed and prevents previous functionality from working.
For example, I can create a edit button, that calls the same properties as the edit toolbar button, but because of the overlay, the component gets selected first. So even if I try to improve the experience by removing 1 extra click for the author, the UI prevents that from working.
So my question is this in summary.
1. I need a solution for enabling certain iterations from being stopped by the touch UI overlay while in Edit Mode.
2. Alternatively, if I could put interaction in the page that can be done without opening up a component Edit dialog or toolbar, or going to preview mode. For example, a direct link to open a components dialog. Is there a API for this instead that lets us build the interaction out of Coral UI instead of placing it in the template for the page.
In my situation, these pages are only edited by a Author, and create data for nodes that populate other pages. These are never exposed to an end user. Hence why these requests may sound very author focused, it is because there is no consumer viewing these pages.
Your assumption is correct, and this is also documented.
Reason for that choice was not to interfere with the customer page's DOM anymore, like it was done in Classic UI. I agree his also has the drawback you mentioned.
In 6.1, we're introducing a keyboard shortcut to easily switch between the current editing mode (edit, target, etc.) and preview, and the layout of the header bar is also allowing to save one click, since the preview option is no more under the menu.
Regarding 6.0, you mention:
For example, a direct link to open a components dialog
What do you mean exactly? A link global to the page? For this we have an extension point.
One solution I see for the issue could be to create a toolbar button that would display a popover with the list of tabs, which can be selected, and that action would trigger the same action as if you'd click the tab in preview mode.