(Duplicates #197)

We have a PR for this functionality, but we're generally wary of new configuration options. That said, I see this as a compelling reason to support this. I'll tag this as a core enhancement.

@kate2753: Can we think of any way to support this that isn't "yet another core configuration option"?

Ah! And I checked - but I probably I checked on issues and not on PR. The #197 is a different use case but it actually requires the same functionality so yes this is a duplicate. I will try to merge it and report back in #197.

As for the configuration option - I don't think that can be done reasonably without one. The only question is if it should be global or per tour. I vote for per tour...

We are allowing users to specify the target of the callout, as well as provide getTarget function implementation. Support for targeting various elements on the page would be more complete if we allowed users to specify the parent element of the callout.

I can't think of a way to support this without adding a new config option. We are deprecating several presentation config options in 0.3.0 release (#144). So the number of config options should still be reasonable.

Few issues that we might run into with this is - scrolling callout into the view and css styles applying cleanly to the callout. Having callout nested within other elements of the page may case some very broad app specific css rules to apply to the callout. We need to brainstorm on how we can mitigate that.
As for scrolling callout into the view, we would now have to worry about scrolling all scrollable parents of the callout, to make sure that callout is visible.

I can understand that there are several issues regarding the implementation
of this feature.

About the css pollution:
Current status: there are already issues with css pollution in the current
situation as is. Imagine rules like p {} or * {}.
Possible solutions:

1. web-components. Future based solution.
2. css-reset. Ugly pragmatic approach,
3. Ignore the situation (as is) and pass the burden to the integrator to
   sort it through (as everybody does).

About the scrolling into view you are of course right but at least it is an
obvious generalization of the current scheme and not death of a thousand
cuts as the css pollution problem.

thanks for considering the feature.

Vassilis

On Mon, Oct 5, 2015 at 9:38 PM, Kate Odnous [email protected]
wrote:

We are allowing users to specify the target of the callout, as well as
provide getTarget
1748222
function implementation. Support for targeting various elements on the page
would be more complete if we allowed users to specify the parent element of
the callout.

I can't think of a way to support this without adding a new config option.
We are deprecating several presentation config options in 0.3.0 release (
#144 #144). So the number
of config options should still be reasonable.

Few issues that we might run into with this is - scrolling callout into
the view and css styles applying cleanly to the callout. Having callout
nested within other elements of the page may case some very broad app
specific css rules to apply to the callout. We need to brainstorm on how we
can mitigate that.
As for scrolling callout into the view, we would now have to worry about
scrolling all scrollable parents of the callout, to make sure that callout
is visible.

—
Reply to this email directly or view it on GitHub
#206 (comment).

Vassilis Virvilis