This PR introduces an on-close delay for (sub-)menus, which prevents the menu from closing too early in case the user moves out their mouse cursor from the respective menu item.
I’ve described some subtle problems and corner-cases below. Let me know how the current timing parameters feel for you, so that we can tweak them if need be.
I don’t think we need -webkit and friends anymore for compatibility. It seems that the transition directive should be supported for long enough by now.
I moved the comment about the “System” menu down one line, just above the respective <li> element. I think it should have been there in the first place.
Delaying the transition
I slightly delayed the fade-out in the initial part of the transition, otherwise the menu would start to disappear immediately. This would feel a bit weird, because if you move the mouse cursor back quickly, the menu seems to fade in again out of nowhere. The initial delaying alleviates this effect.
The video below demonstrates the feeling with the default, linear transition, i.e., without a cubic-bezier easing function. (Alternatively, we could also use a linear easing function, but that still has poorer browser support right now, since it’s newer.)
I tried to find a good compromise between keeping the menu open long enough so that it prevents the accidental closing scenario, yet still quick enough so that it doesn’t feel sluggish and sticky.
The video below demonstrates the feeling when the transition duration is too long.
Chrome and Firefox seem to prevent transitions on page load automatically. Safari (and maybe other browser too) don’t do this, however, so you would see the menus briefly flickering when loading the page. Therefore, we have to workaround that with a CSS/JS hack.
I was only able to test on MacOS with Chrome, Firefox and Safari. Unfortunately, there is always a slight risk with these kind of hacks that browsers do weird things. This hack technique doesn’t seem uncommon at least.
The video below demonstrates how it looks without such a workaround (in Safari).
Resolves https://github.com/tiny-pilot/tinypilot/issues/1725.
This PR introduces an on-close delay for (sub-)menus, which prevents the menu from closing too early in case the user moves out their mouse cursor from the respective menu item.
I’ve described some subtle problems and corner-cases below. Let me know how the current timing parameters feel for you, so that we can tweak them if need be.
Now
https://github.com/tiny-pilot/tinypilot/assets/83721279/6a30adc2-b75d-4f82-a2ca-d078b5378a21
Before
https://github.com/tiny-pilot/tinypilot/assets/83721279/98e2cf31-c25e-4aa6-bb96-06a866617be2
(Photo of TinyPilot user, captured throughout this screen recording)
Notes
-webkitand friends anymore for compatibility. It seems that thetransitiondirective should be supported for long enough by now.<li>element. I think it should have been there in the first place.Delaying the transition
I slightly delayed the fade-out in the initial part of the transition, otherwise the menu would start to disappear immediately. This would feel a bit weird, because if you move the mouse cursor back quickly, the menu seems to fade in again out of nowhere. The initial delaying alleviates this effect.
The video below demonstrates the feeling with the default, linear transition, i.e., without a
cubic-beziereasing function. (Alternatively, we could also use alineareasing function, but that still has poorer browser support right now, since it’s newer.)By the way, see this tool for a visualisation what
cubic-bezier(0.5, 0, 1, 0.25)looks like mathematically.https://github.com/tiny-pilot/tinypilot/assets/83721279/6b419939-e462-4d3d-a1af-17347f04f3f9
Transition duration
I tried to find a good compromise between keeping the menu open long enough so that it prevents the accidental closing scenario, yet still quick enough so that it doesn’t feel sluggish and sticky.
The video below demonstrates the feeling when the transition duration is too long.
https://github.com/tiny-pilot/tinypilot/assets/83721279/ce2e7b81-b88e-4b5f-806f-156ed15b7d9f
Flicker prevention
Chrome and Firefox seem to prevent transitions on page load automatically. Safari (and maybe other browser too) don’t do this, however, so you would see the menus briefly flickering when loading the page. Therefore, we have to workaround that with a CSS/JS hack.
I was only able to test on MacOS with Chrome, Firefox and Safari. Unfortunately, there is always a slight risk with these kind of hacks that browsers do weird things. This hack technique doesn’t seem uncommon at least.
The video below demonstrates how it looks without such a workaround (in Safari).
https://github.com/tiny-pilot/tinypilot/assets/83721279/22535fd5-d5f0-4db0-b444-3052b3ad9fe0