Allow to adjust the scrolling for some steps

[rmoncler-ctl]

The idea would be to have a new property to tell the tour that, "for this step, the scroll should continue for (or stop before) X units".
For example "addCustomScroll: 10px" or "addCustomScroll: -2em". The first one would make the scroll 10px longer than the expected scroll, the second one would make the scroll stop 2em before the end.

Two examples of problems that this could help solve :

1. If the height of the element to which the anchor is attached is too great, then the page scrolls until the top of the anchored element is aligned with the top of the visible part of the screen. The popup containing the title + description of the step is then outside the visible part of the page:
   

2. If I have a "sticky header", and displaying a certain step scrolls the page up, the target element may be behind the header, like this:
   
   instead of:
   

I'm not sure if this is the best solution, or if I'm taking the problem the right way, but I haven't found a solution for these kinds of UI problems yet.
If anyone have an idea on how to solve either of these, that would be great.

[hakimio]

If the height of the element to which the anchor is attached is too great, then the page scrolls until the top of the anchored element is aligned with the top of the visible part of the screen. The popup containing the title + description of the step is then outside the visible part of the page.

Does that happen on a mobile device where you have limited horizontal space?

To solve the second issue, you should try setting scroll-padding-top on your scrollable container.

Anyway, I don't have any plans to implement this functionality right now but feel free to create a PR and I'll take a look at it ASAP if you really need it.

EDIT: since this library is using scrollIntoView() built-in method, I don't think this functionality can be implemented in a simple way. And I don't think it's a good idea to do the scrolling twice - once with scrollIntoView() and once more to apply the scroll offset.

[hakimio]

A couple more thoughts on this topic:

• While scrollIntoView() scrolls correctly to reveal hidden element under your header when you set scroll-padding-top, curently scrollIntoView() is not called when the element is still within viewport boundaries, even if it's hidden behind another element. In addition to checking if the element is within viewport, we should also check if it's not hidden behind another element. I'll look into implementing this soon.
• To solve your first issue, you could add a div with absolute positioning and pointer-events: none inside your widget and then attach the tourAnchor to that element. Sth like the following should work for you:

.widget-tour-anchor {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    height: 50%;
}

[hakimio]

Released v10.4.0

[rmoncler-ctl]

Thanks a lot for all these ideas.

The first issue indeed happens on a mobile device. Your idea of a div with absolute positionning works quite well, but I'll still use a different solution because the UI feels like it is kind of broken (especially when scrolling down).
Instead, I will use a new anchor (on a smaller part of the widget) when the user is on a small device. When declaring this step, I use a condition checking the size of the device to choose between one anchor or the other.

Regarding the second issue, scroll-padding-top does not work in my case, but its counterpart scroll-margin-top actually does the job.

Thanks again, and I will definitely check the new features and improvements when upgrading the package ;-)