A simple animated menu with progressive enhancement
Keep navigation usable first, then add restrained transitions without carrying an old MooTools animation dependency into a new site.
Navigation should be the least surprising part of a website. A menu that works only on hover or after an animation finishes can prevent someone from reaching the content entirely.
The historical tutorial targeted MooTools 1.2. This rewrite explains a native approach for a new site; consult the exact version’s documentation when maintaining an existing plugin.
Keep destinations as links
Use a nav landmark and a list of anchors for destinations. If a section needs to expand, use a separate button to control its submenu. Do not turn the parent link into an ambiguous control that both navigates and opens something.
const button = document.querySelector('[data-menu-toggle]');
const panel = document.getElementById(button.getAttribute('aria-controls'));
button.addEventListener('click', () => {
const open = button.getAttribute('aria-expanded') !== 'true';
button.setAttribute('aria-expanded', String(open));
panel.hidden = !open;
});The example requires a button with aria-controls pointing to a real panel ID and an initial aria-expanded value matching the panel’s visibility. Keep the links visible before enhancement if the design allows it.
Add motion after behavior works
Small opacity or transform transitions can communicate the change without delaying it. Honor reduced-motion preferences. Never leave visually hidden links reachable by keyboard: use a visibility mechanism that matches the intended interaction state.
Test like a visitor
Navigate with Tab, Shift+Tab, Enter, and touch. Resize while the menu is open. Enlarge text and test a long translated label. For ordinary site navigation, avoid ARIA application-menu roles unless you implement their full keyboard model. The WAI disclosure navigation example explains the distinction.