[context-menu] Allow the parent node to act as the menu context

[jouni]

The current API allows the developer to either wrap content that acts as the context, or define a listen-on attribute to point to another element on the page that acts as the context.

I propose we add one more way of defining the context, and that is to use the parentNode as the default context.

So, if there’s only the menu template inside vaadin-context-menu and no listen-on attribute is defined, use the parentNode as the context.

Example:

<div>
  This element will have a context menu.

  <vaadin-context-menu>
    <template>
      <vaadin-list-box>
        ...
      </vaadin-list-box>
    </template>
  </vaadin-context-menu>
</div>

This covers mostly the same use cases as the listen-on attribute, but it’s easier/safer to use as you don’t have to provide a hardcoded id for the context.

[platosha]

Probably does not give much value over what we have.

The downsides are:

• One more special mode to implement
• Adding listeners outside breaks encapsulation
• Unclear listener element when parent is a shadow root

While the use case is very similar to what is already supported without breaking encapsulation:

<vaadin-context-menu>
  <template>
    <vaadin-list-box>
      ...
    </vaadin-list-box>
  </template>

  <div>This element will have a context menu.</div>
</vaadin-context-menu>

[jouni]

The reason to support this is that the parent element would be allowed to be the one that affects the layout, and not the context menu wrapper. Having the wrapper requires conscious thinking about layout styles.

I used this approach for the tooltip element prototype: https://github.com/jouni/j-elements/blob/polymer2/j-tooltip.html#L87-L93

[jouni]

At least for me, having the menu inside the context it is applied to maps more easily as our current wrapper model. It’s always felt a little “off” to me.