Allow selectively skipping elements so that the "driver-fix-stacking" class won't get applied about driver.js HOT 6 CLOSED

Thank you for looking into this @josias-r. The SVG approach does seem interesting. The initial implementation of driver.js was similar to what you proposed -- we used to draw a canvas covering the full page and were cutting the portion above the highlighted element but the approach was discarded due to browser compatibility and performance issues.

I just got some time and have started working on the rewrite. I will look into what you have done with the fork :)

from driver.js.

Thanks @josias-r — I just released v1.0 of driver.js which has been rewritten from the ground up using the SVG mechanism as your boarding.js. Please have a look at the docs and do let me know if you face any issues.

Once again, thank you for your contribution 🙏

from driver.js.

For the moment, I wrote a react-hook for our codebase to do exactly that. It simply watches an element for class changes and if it is the driver-dont-fix-stacking class, it will immediately remove it again:

import { useEffect, useRef } from "react";
// import { CLASS_FIX_STACKING_CONTEXT } from "driver.js/src/common/constants"; // not property exported, but this is where it comes from
const CLASS_FIX_STACKING_CONTEXT = "driver-fix-stacking";

function useDriverJSIgnoreStackFix<TElement extends HTMLElement>() {
  const elementRef = useRef<TElement>(null);
  useEffect(() => {
    const observer = new MutationObserver((mutations) => {
      mutations.forEach((mutation) => {
        if (
          mutation.type !== "attributes" &&
          mutation.attributeName !== "class"
        )
          return;
      });

      if (elementRef.current?.classList.contains(CLASS_FIX_STACKING_CONTEXT)) {
        // removing class immediately again
        elementRef.current.classList.remove(CLASS_FIX_STACKING_CONTEXT);
      }
    });

    if (elementRef.current) {
      observer.observe(elementRef.current, {
        attributes: true,
        attributeFilter: ["class"],
      });
    } else {
      console.warn(
        "Element that was supposed to be watched has not been assigend yet"
      );
    }

    return () => {
      observer.disconnect();
    };
  }, []);
  return elementRef;
}

export default useDriverJSIgnoreStackFix;

You can use it like this:

function MyComponent() {
   const ignoreDriverStackFixRef = useDriverJSIgnoreStackFix<HTMLDivElement>();

   return <div className="myClassesThatWouldTriggerStackFixClass" ref={ignoreDriverStackFixRef}>children</div>
}

from driver.js.

After more extensive usage testing (we are just now working on a prototype in our application that makes use of this library), I realised that there is a more fundamental flaw of how this library handles highlighting of elements.

The reason driver-dont-fix-stacking is necessary in the first place, is because the library wants to force a zIndex on the element that should be highlighted. It needs to do that, so it can put that element-to-highlight on a higher index then the overlay that appears.

Now the issue is, that this might work fine for many simple websites. But for more complex websites or web-apps. There's a high chance the complex layout just relies on zIndex (for example modals/dialogs that open, etc.).

So what would be the solution? Actually the solution would be to work without touch the stack context at all and leaving everything as it is.
This would mean though, that you cannot make use of the "overlay" anymore, as it would block clicking the element.

Therefore we are now experimenting in a custom solution where the highlight works using an SVG where there is an actual rectangle cropped out. So far the results seem to be very pleasing.

This means we can patch out all of the stack-context classes that driver.js applies to the elements like so:

document
  .querySelectorAll(
    ".driver-fix-stacking,.driver-highlighted-element,.driver-position-relative"
  )
  .forEach((node) => {
    node.classList.remove("driver-fix-stacking");
    node.classList.remove("driver-highlighted-element");
    node.classList.remove("driver-position-relative");
  });

@kamranahmedse Did you every think of going into that direction? Our results so far seem to be promising and we don't see a big issue with this. If you like the idea I can also work on a PR to get this into driver.js.
If no other issues start appearing, this approach seems much more stable, as driver.js can really "highlight" an element without having to hack the elements zIndex to the top and potentially breaking layouts.

from driver.js.

@kamranahmedse That’s great, I’m open for any exchange 🙌🏼

My fork has turned into a total rewrite as I have discovered other issues when working with interactive applications that mount elements dynamically.

I believe the two libraries now have different use cases in mind:

Mine is designed to be compatible with any kind of interactive web application where elements may be mounted at any time and modals and other elements with different z-indexes can be rendered anywhere. On the other hand, DriverJS in its current state is more suitable for simple websites where there is not much interactivity or dynamic rendering.

There are trade-offs for both approaches

from driver.js.

@kamranahmedse Interesting! I'm currently off from my computer for a few months, but glad my rewrite was an inspiration 😀

I will check it out again at some point

from driver.js.