Open jouni opened 6 years ago
Probably does not give much value over what we have.
The downsides are:
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>
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
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.
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
insidevaadin-context-menu
and nolisten-on
attribute is defined, use theparentNode
as the context.Example:
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.