Interaction

Navigation

The nav is assembled from real elements, and the breakpoint is the CSS.

A navigation in sitereal is not one element with a settings panel behind it. It is a group of ordinary elements, assembled — which is why you can restyle any part of it without asking us for a setting.

Inserting one

Insert Nav and you get the whole assembled menu: a bar, a list, items, links, a dropdown with a trigger and a submenu, a mobile toggle with a burger, a panel, a close button, a scrim and a skip link. Every one of them is a real child node you can select, move, delete or restyle.

The other fifteen nav elements are in the insert menu on their own, for when you want to add one more link or a second dropdown to a menu you already have.

No part wears a class

A nav part is styled by what it is:

[builder-data-element="nav-link"] {
  display: flex;
  align-items: center;
  gap: 0.4rem;
  padding: 0.5rem 0.75rem;
}

A class we invented for you — .nav__link — would be a name in your markup you never chose, that you could rename out from under its own rule, and that a dozen siblings would have to agree with. The attribute is the one thing about a part that is not yours to get wrong, so it is what the look hangs off.

Add a class when you want this menu to differ from the site's. It then wins as the selector, exactly like an id, and it is a name you meant.

Each part brings one starter rule, written into your own stylesheet the first time it is inserted. There is no nav.css and no --nav-* token layer: the whole look is editable like anything else you wrote.

Two attributes, two contracts

nav.js does the behaviour and the accessibility wiring: it pairs each trigger with a real id/aria-controls, keeps aria-expanded honest, traps focus only while a panel is modal, closes on Escape, locks scroll, and marks the current page with aria-current.

The settings a menu has

Select any part of a menu and the Element panel shows the menu's own settings — read for whichever nav and dropdown the part sits inside, so a link four levels down answers the same as the bar. Nothing is stored: each setting rewrites real CSS or a real attribute.

Collapse

Moves the media query the parts share — the toggle's, which is the breakpoint by definition — across the menu's own rules and nothing else.

A tablet tweak you wrote on the links is a different query and is left alone.

Menu: flyout or mega

Flyout is a list under the trigger. Mega menu wraps the submenu in a nav-mega — a real element whose own rule is the panel. The two things a panel makes true of its neighbours (the item stops positioning it, and the flyout inside it stops being a flyout) are written in the panel's own rule, not in theirs, so a menu built before mega panels existed can still grow one.

Folding back unwraps that column, and is refused rather than made lossy once the panel holds more than one.

Opens on

Hover and click, unless you say otherwise.

• Click takes the hover out — for a panel too big to open in passing.
• Hover takes the click out — clicking a menu the pointer is still inside would shut it under the cursor.

Neither can be the whole story, so a hover dropdown still opens on a tap, in the mobile menu, and on Enter / ArrowDown. A dropdown you cannot open is not a setting.

Hangs from

Start (and it flips itself at the screen edge), Centre, or End. Setting it also calls off the script's measured flip, because you have said where it goes.

Show it open

A canvas-only preview. It stamps the real data-nav-open, so what you style is the menu as it truly opens, in your own rules. It is never saved into a page.

The breakpoint is the CSS

There is no breakpoint setting anywhere. The menu is mobile exactly when the CSS has made the toggle visible — so moving the media query is the whole of moving the breakpoint.