You could just create an invisible :hover::before on the <a> tag that renders an invisible triangle that overlaps the neighbors. Since it's still part of the <a> tag, as long as you're hovering over it, you won't activate other menu entries. You could even animate the triangle's size (or existence), shrinking it over time to mimic Amazon or Mac OS behavior. Set z-indices correctly so the right-hand panel is on top, and you're off to the races.

You'd want to use clip-path which isn't supported that well yet, but it does let you define non-rectangular hover regions. But there is still a problems with this approach.

It's subtle, but if you look at the Bloomberg implementation, if you move the pointer to the left at any point, it abandons the behaviour and highlights the menu item below the pointer -- even if the pointer is still inside the conceptual triangle region.

So I think you can get pretty close to a CSS-only solution in modern browsers, but the the small touches that make it feel great would still probably require writing some JavaScript.

You can also use a very acute 3D perspective transform to create almost any quadrilateral shape, so the support can be a bunch better.

What the parent is describing isn't a shape at all, though. The behaviour is different depending on the direction the cursor is moving.

Built a quick demo that shows that (a) you can mostly do it with HTML/CSS and (b) the experience isn't great:

https://codepen.io/andy-ingram/pen/MXPqZN?editors=1100

That is cool.

The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.

Jake Smith • 5 years ago This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.

Bruce "Tog" Tognazzini Jake Smith • 5 years ago Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.

Josh Davenport Jake Smith • 5 years ago I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu...........Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac"

markr_7 • 5 years ago Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.

> This is solved by tracking the mouse movement and holding the current menu open if the movement is at a specific angle

Was it Amazon that first used this trick on their giant dropdown menus? I remember reading an article about their implementation but do not recall if they were the first or merely the most visible.

Here's an article that reverse engineers Amazon's implementation; http://bjk5.com/post/44698559168/breaking-down-amazons-mega-... - not the first implementation by a long shot, as pointed out elsewhere in this thread, but perhaps the first implementation for the web.

This seems like something that would be obvious to a seasoned interactive programmer(video games, animated UX, etc) or somebody in that mindset. I would be extremely surprised if some form of this technique doesn't have prior art going way back.

No. Mac OS had it.

Correct. I first used a Mac with System 6 somewhere around 1991-1992. I remember using other GUIs (maybe windows 3.1 or X) and being frustrated by the menus, then realizing that the Mac had this diagonal most movement detection and that's what made their menus so much easier to use. Apple figured this out 30 years ago.

You're right -- in fact it was at least 31 years ago!

I just posted a comment about this with a link to the 1987 Apple Human Interface Guidelines and page snapshots explaining the design.

https://news.ycombinator.com/item?id=17404345

pp. 87: Hierarchical Menus: https://i.imgur.com/RrEDo3m.png

pp. 88: Figure 3-42: Dragging diagonally to a submenu item: https://i.imgur.com/a0gNWHh.png

I also linked to an article showing how to solve the problem with CSS and without JavaScript!

https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...

Hopefully the author of this article (dosy) can use the css :hover delay technique to make his menus even better than Bloomberg's, without requiring any JavaScript!

Subtle but important details like that easily get lost and forgotten, because it seemed important enough to write down in 1987, but now it's built into macOS and nobody can change it.

It's hard for most people to notice, because the whole point is to invisibly work behind-the-scenes to make selecting from submenus easier without distracting you!

So Apple doesn't mention it any more in their "modern" UI guidelines, since they don't expect macOS application developers to reimplement menus from scratch. But that's what web developers do all the time, so it's important to document and preserve details like this!

I highly recommend reading the original 1987 Apple Human Interface Guidelines to any serious user interface designer! It's quite dated, but so is the Mona Lisa!

https://archive.org/details/applehumaninterf00appl

I just added triangular hover regions based on the comments. Debug outlines showing the open paths to the submenus: https://vgy.me/nBfeiA.gif

Nicely done!

Bruce Tognazzini invented the technique, and wrote about it in his "A Quiz Designed to Give You Fitts" on Ask Tog:

Question 6

What is the bottleneck in hierarchical menus and what techniques could make that bottleneck less of a problem?

The bottleneck is the passage between the first-level menu and the second-level menu. Users first slide the mouse pointer down to the category menu item. Then, they must carefully slide the mouse directly across (horizontally) in order to move the pointer into the secondary menu.

The engineer who originally designed hierarchicals apparently had his forearm mounted on a track so that he could move it perfectly in a horizontal direction without any vertical component. Most of us, however, have our forarms mounted on a pivot we like to call our elbow. That means that moving our hand describes an arc, rather than a straight line. Demanding that pivoted people move a mouse pointer along in a straight line horizontally is just wrong. We are naturally going to slip downward even as we try to slide sideways. When we are not allowed to slip downward, the menu we're after is going to slam shut just before we get there.

The Windows folks tried to overcome the pivot problem with a hack: If they see the user move down into range of the next item on the primary menu, they don't instantly close the second-level menu. Instead, they leave it open for around a half second, so, if users are really quick, they can be inaccurate but still get into the second-level menu before it slams shut. Unfortunately, people's reactions to heightened chance of error is to slow down, rather than speed up, a well-established phenomenon. Therefore, few users will ever figure out that moving faster could solve their problem. Microsoft's solution is exactly wrong.

When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu. As long as the user's pointer was moving a few pixels over for every one down, on average, the menu stayed open, no matter how slow they moved. (Cancelling was still really easy; just deliberately move up or down.) Apple hierarchicals were still less efficient than single level menus, because of the added target, but at least they were less challenging than the average video game.

Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac, in designing the hierarchical menu interface for OSX. Today's Mac hierarchicals are just as difficult to use as those of Windows.

Fitts' law is not just about target size and distance; it's also about the number of targets. The more targets, all else being equal, the longer the task will take. Hierarchicals automatically add one extra target. Making it difficult to enter a second-level menu adds an additional target, the second-level menu itself.

With my hierarchicals on the pre-OSX Macs, in most cases, the user did not even have to think about targetting the second-level menu. The menu opened, and the user simply aimed for the desired item. The only time the user had to consider the second-level menu separately was when there were so many items in the menu that the one the user was after was way up or way down the list, out of range of the allowable pivot for entry. Even then, users would typically arc along a more radical curve to reach their items in a single motion, rather than breaking things down into the jerky Etch-A-Sketch types of moves users typically make with today's hierarchicals.

When designing a user's required motions, reduce the number of motions needed along with both distance and required precision for each motion, then consider how your proposed scheme maps onto a human's ability to make those motions.