Great job mimicking the menu with just pure CSS! You even got the fade/slide down effect mostly there.

From a UX perspective there's a reason they used Javascript. For example, if you hover over "Politics" and want to click on "2018 Women Candidates" naturally you move your mouse at an angle. Which causes you to lose the menu when it mouses over "Technology". This is solved by tracking the mouse movement and holding the current menu open if the movement is at a specific angle

I'd like to read your write up if you do it :)

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.

Any specific reason why you haven't used the old "Son of Suckerfish" approach? [0] It would have solved the "stay open on hover" problem and made for much cleaner, more semantically meaningful and accessible html IMHO.

Still, really glad to see people trying and succeeding in doing simple web stuff without the need for unnecessary javascript. Good job!

[0] http://www.htmldog.com/articles/suckerfish/dropdowns/

Wow, blast from the past. Still remember implementing that on some of my first websites.

What exactly does "semantically meaningful and accessible html" mean?

Hopefully "semantically meaningful" is pretty self-explanatory, it just means using HTML elements in an organized and structured way (like not using a span when you should use a paragraph). "Accessible" means usable by screen readers and potentially other accessibility tools for people with low vision or other disabilities.

As an example: Consider using a <div class=“paragraph”> vs using <p>. The <p> tag is semantic and meaningful, whereas the <div> means nothing. A screen reader (or other markup interpreters) can’t tell what a <div> means

Good point. Perhaps, I would think, Bloomberg's menu does this and he can just "borrow" their semantic + A11Y-centric markup?

Exactly my thoughts. Kids these days :))

The menu is functionally completely broken. Because panel visibility is determined purely by :hover or :focus, as soon as you try to click on an item in the panel, that focus is lost and the panel disappears, taking your attempted click with it.

There are only three approaches that you can reasonably use here (they can be combined, too):

① Labels, which allow some rather nifty structure-breaking tricks on :hover;

② Change the .bmenu > a things from links (because you can’t nest links), and put the panel contents inside that node, then use :hover;

③ Use radio buttons and :checked.

Nice try but it works fine in all browsers for me.

It's getting truncated for me in Chrome.

> The menu is functionally completely broken.

Works fine for me on Firefox Nightly.

It got fixed a while after my comment, in one of the many commits with the message “ok” (!) at https://github.com/dosyago-coder-0/mimic-bloomberg-menu-no-j....

(Author: commit messages are a nice thing and worth putting at least some effort into.)

When you hover over an item in the main list, then move your mouse to the right, does the sub-menu stay the same or revert to the sub-menu for the first entry? (EDIT: Looks like that bug has been fixed. Earlier this morning, it would revert to the first sub-menu, now it works as expected)

Cool stuff, You should check it out: https://careers.bloomberg.com/job/detail/57675

Obviously you can develop things however you want, but IMO, not using a descriptive message in your commits (like repeatedly naming them "ok") is a pretty bad habit.

Firstly, job well done. Secondly, what is the motivation of going pure CSS aside from the challenge of it?

I once prefered Pure CSS stuff until I learned Javascript myself. Now I've come to loathe that approach on complex menus and widgets.

Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful (reacting to an active category or something indicated by the url or querystrings, etc.

Again, good job though if it's just for the lulz.

It seems to me, many web developers today don't even realize, that creating features without js and enriching the experience from that baseline, not only enhances performance and accessibility, but in the end is often not more work and might even lead to cleaner, leaner code. I guess in the end it just comes down to which tools one learned first and based on that which approach one takes to solve the problem at hand.

I can only encourage everyone that thinks js is the catch-all solution to dive a bit deeper into html&css and try out alternate solutions. It's worth it for the knowledge gain in itself but offers many other benefits.

css is often the slowest part of a webapp. complex css like this is not necessarily better accessibility-wise than javascipt

Why complex? Sure, this example is somewhat complex, but it does not need to be. Structure the menu in nested ul's, add simple hover css and don't use "display: none;" but rather "position: absolute; left: -999em;" and you get simple css and a good html structure that a screen reader for example can read easily and which also is clear to read if you turn css off entirely.

Of course, small hover menus offer their own accessibility challenges, but they don't depend on the way they are implemented but rather the choice of UX. And no reason why you could not improve this simple css menu with some js to make it more user friendly (like turning hover into clicks etc.)

Do you have some proof to back this? CSS matching is incredibly fast.

For one, many people prefer to browse websites with javascript turned off. Aside from performance benefits, you turn off user tracking, flashy ads, autoplay videos, annoying popovers, etc.

MANY people? Source?

zero people block JS: false

only one person blocks JS: false

therefore many block JS

"Many" is not synonymous with "multiple".

I would expect that the percentage of people who browse without javascript on is incredibly small. The absolute number might be largish, and I guess in that context is could be considered "many."

Still, the vast majority use javascript.

Haven't you studied cardinality? You don't have One to Multiple relationships, you have One to Many /s

Between zero or all, could be many or some.

Or perhaps "few".

Most "stateful" functionality (including all you mentioned) can still be done with a CSS driven drop down menu.

Could this be handled by a templating engine like handlebars?

> Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful

You shouldn't need to refactor anything done in HTML or CSS to add JS-driven statefulness. This is what's great about using JS: it's power allows it to wrap/augment existing functionality quite flexibly.

Any chance of making it click-based? For example, once I open it, I'd rather click on Markets than hover to change the right side.

Also, and I realize this was just for fun, making it responsive would be a nice touch. For example, force the right col under col 1 and col 2 below a certain width. That's easy and I think more people are likely to find the example more useful.

Otherwise, sweet! Good stuff. Thanks for sharing.

@dosy great work.

If I was a bit more skilled I'd try and help you out on mobile compatibility.

Thanks!

I'd want to read it!

your html is over 400 lines. this is why you need JS man :)

Yeah, with JS it could be 800 lines :)