Make contextual links less intrusive to front end templates

PoC: https://www.drupal.org/sandbox/vaplas/contextual_outside.

Problem/Motivation

When the links are inside of context, it leads to a number of problems:

Problem 1. Unpleasant html

For example:

---

Possible html for such block:

<div class="animals">
  <div class="animal">🦊</div>
  .....
</div>

<style>
.animals { display: flex; }
.animal { /* cool border */ }
</style>

---

What Drupal does (not show a lot other wrappers, which can be remove via templates):

<div class="animals" [contextual-region-1]>
  <div class="contextual-links" [contextual-id-1]></div>
  <div class="wrapper">
    <div class="animal" [contextual-region-2]>
      <div class="contextual-links" [contextual-id-2]></div>
      <div class="wrapper">🦊</div>
    </div>
    .....
  </div>
</div>

---

Contextual links - it's great. And it's great that they are separated from the content (because their mix - leads to terrible results). But what do we pay for using them?

1. Money, time, and health to port the layout from the non-drupal-world (and updates after each changes).
2. Potential flaws after port (which we can not immediately notice).
3. Overall complexity of the layout.
4. Negative mood from such a boring work.

Problem 2. Tag limitation.

It is impossible to wrap item by tags like a, img, iframe, video, .... Either you need to complicate the html/css again, even to output simple image item, or item that is link.

Few issues about this:

• #2430901: Contextual links not working when wrapped in an <a> element
• and like an attempt to prevent negative results #2898875: Contextual links should not be added inside another link

But so many cases, where the item is full link (<a>), or cannot have any child (<img>).

Problem 3. Conflicts of styles.

I remember the issue (#2773431: Please make Contextual link 8 independent on block <a> color) where I was trying to explain, that using #id and !important in css rules is a bad practice. But you know, even correct styles can be problem for contextual links.

Example, this rule not contains any #id

.path-frontpage .main-content .region-content .node--type-article a {
  font-size: 2em;
}

But it has a higher priority than rule from contextual module, like:

.free-contextual-link.contextual .contextual-links a {
  font-size: small;
}

Also what about parameters that are not specified in the css rules of contextual module, and therefore can be redefined by any custom rules.

Proposed resolution

Move contextual links out of context.

So, what will change after the patch?

After the patch, the example from problem1 will take the following form:

<div class="animals" [contextual-region-1]>
  <div class="wrapper">
    <div class="animal" [contextual-region-2]>
      <div class="wrapper">🦊</div>
    </div>
    .....
  </div>
</div>

.....

<div class="contextual-links" [contextual-id-1]></div>
<div class="contextual-links" [contextual-id-2]></div>

Therefore, after manually changing the templates, it will take the following form:

<div class="animals" [contextual-region-1]>
    <div class="animal" [contextual-region-2]>🦊</div>
    .....
</div>
.....

<div class="contextual-links" [contextual-id-1]></div>
<div class="contextual-links" [contextual-id-2]></div>

🎉

What about Backwards Compatibility?

No problems. Just make it optional:

• Checkbox1: Enable new regim. Works only if html does not contain "traditional" contextual links. For example, after removing {{ title_suffix }}, or unset contextual_links via hook_preprocess.
• Checkbox2: Aggressive mode. Used when enabled new regim (checkbox1 checked). Removes all links via contextual_preprocess. It is convenient if you do not want to change templates, but want to switch to the outside contextual links.

Hard JS dependency?

Yes. But contextual module is already in hard dependence from JS, and does not work without it.
Of course, we will need to work out positioning and hovering. Since now it can not rely on the nesting css-rules. But I am sure, that by joint efforts we will be able to achieve results no worse, or even better, than current.

What about Quickedit and other

Perhaps more work is needed to enable quickedit for wrapper like <a>. Maybe via preventing links behavior, while the quickedit mode on. Or via side panel, as Settings Tray does.In any case, even the basic set of contextual links ('edit', 'delete', 'translate') will be more useful than nothing.

Remaining tasks

User interface changes

API changes

Data model changes