[pmilla1606]

Well done! Moving the mouse to a child resets the position though. You may need some JS to do some fancy stuff like here: http://bjk5.com/post/44698559168/breaking-down-amazons-mega-...

Or to keep it JS free there might be a way to structure the HTML similar to: <Nav1><ChildNav1.../></Nav1>. Hover a :hover pseudo on <Nav1> will also fire when hovering over <ChildNav1 />.

[yscik]

Even the triangular cursor path thing could probably be done with just CSS, a short-lived extra element in the childnav that starts transforming away on hover, making the next nav item accessible if the intent turns out not to be to move to the submenu.

[chrismorgan]

The tricky thing is getting the triangle’s node to be the position of the cursor; you need it to start at the left of the menu item, then animate rightwards only while the cursor is hovering over it, stopping when it’s not—so that it will naturally come to rest. This is possible to express with animations (animation-play-state is key), except for the fact that :hover calculations are not done constantly in most browsers, but only when the user does something to trigger it, such as moving the cursor. And so basically the whole scheme falls apart: it will work just barely OK, but if you move your mouse just a bit too slowly, it’ll effectively stop working.

It’s still an interesting thought. If you’re interested and my explanation isn’t clear enough, I’ll put a simple proof-of-concept-and-why-it’s-sadly-not-really-enough together.

(OK, since then I’ve come up with an insane approach that relies upon this behaviour, and it might just work, though I’m concerned about how reliable it’ll be across browsers. If it does work, it will definitely be blog-post worthy.)

[ckluis]

Submit a PR.

[albanberg]

I noticed the same. If one clicks on the top folder on the left, the submenu holds open but it would be better to not need to do this.