search

LinkedInAttic / hopscotch

A framework to make it easy for developers to add product tours to their pages.
Apache License 2.0
4.2k stars 664 forks source link

Fullscreen div: Parent of hopscotch other than the body #206

Open vasvir opened 9 years ago

vasvir commented 9 years ago

Hi,

This is an enhancement request and not a bug report. Please let me know if I should post this to a more appropriate forum.

I have a HTML widget that can go fullscreen such as the video widget. The widget employs some hopscotch tours that are not visible in fullscreen mode since only the direct elements of the fullscreen div are visible.

The perfect enhancement would be to be able to specify per tour the parent of the hopscotch dialog

The second option (not so cool but I could live with) would be able to specify the parent at the global Hopscotch level for all tours in the page.

Thanks for your work in Hopscotch. Vassilis Virvilis

timlindvall commented 9 years ago

(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"?

vasvir commented 9 years ago

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...

kate2753 commented 9 years ago

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.

vasvir commented 9 years ago

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 notifications@github.com wrote:

We are allowing users to specify the target of the callout, as well as provide getTarget https://github.com/linkedin/hopscotch/commit/174822290db393a4636e33f33362187d592a99cc 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 https://github.com/linkedin/hopscotch/issues/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 https://github.com/linkedin/hopscotch/issues/206#issuecomment-145626026.

Vassilis Virvilis