Why Does a Perspective Docked View Collapse on Dropdown Hover?

Here is what you see on the screen. The left docked nav expands on hover the way it should. You open a Dropdown inside it, such as a language selector, and move the cursor onto an option. The dock snaps back to 55 px while the option list is still open. Sometimes the list closes too, or it floats beside a collapsed bar.

The stylesheet that produces this behavior usually looks like this:

.docked-view-left {
  width: auto !important
}
.psc-nav {
  width: 55px;
  transition: width 0.3s ease-in-out;
}
.psc-nav:hover {
  width: 300px;
}

The CSS has no syntax error, so editing it will not fix the collapse. The problem is where the Dropdown's option list sits in the page.

Skip the Fixes That Waste Time

These are the usual attempts. None of them solves the collapse.

• Adding !important to the 300 px width. This is not a specificity problem. The :hover rule is no longer matching, so its priority does not matter.
• Lengthening the transition or adding a delay. This only slows the collapse. The dock still shrinks while the menu is open, just more slowly.
• Changing .docked-view-left width values. width: auto !important is what lets the inner container control the dock width. Leave it in place.
• Resizing the Dropdown or moving it inside the container. The option list renders in the same place no matter where the Dropdown sits in the view tree.
• Searching for a pure-CSS hover trick. :hover follows DOM ancestry. No selector on the nav container can match a pointer over an element that is not its descendant. Stop there and use events instead.

Understand Why :hover Lets Go

Start here. The Perspective Dropdown (Selection component) option list opens as a modal. It is rendered outside your nav container in the DOM and is not a child of the element with psc-nav.

The browser applies :hover to an element only while the pointer is over that element or one of its DOM descendants. When the cursor leaves the Dropdown field and moves onto the floating option list, the pointer is over an element that belongs somewhere else in the document. .psc-nav:hover stops matching, and the width transitions back to 55 px.

A Perspective component mouse event such as onMouseLeave behaves differently. It fires once, when the cursor leaves the component bounds. In practice, moving onto the Dropdown modal does not trigger it. That is why the class-swap method below keeps the dock open.

Replace :hover With Two Explicit Classes

Split the single hover rule into two named states. Keep the dock width override as it is.

.docked-view-left {
  width: auto !important
}
.psc-navReduced {
  width: 55px;
  transition: width 0.3s ease-in-out;
}
.psc-navExpanded {
  width: 300px;
  transition: width 0.3s ease-in-out;
}

• Put the transition on both classes. Then expanding and collapsing both animate, whichever class is being applied.
• Perspective adds the psc- prefix to style classes. In the stylesheet you write .psc-navExpanded. In the component property you write navExpanded.
• Delete the old .psc-nav:hover rule. If you leave it, it still fires on real hover and competes with the scripted state.

Wire the Mouse Events on the Nav Container

1. Open the docked view in the Designer and select the container that carries the nav style class. This is the element whose width the stylesheet controls.
2. Optional: add a custom property on the view, for example docked_status (boolean). Bind icon visibility, label text, or other cosmetic changes to it so they follow the dock state.
3. Right-click the container, choose Configure Events, and add a Script action under onMouseEnter:

   def runAction(self, event):
       self.props.style.classes = 'navExpanded'
       self.view.custom.docked_status = True

4. Add a Script action under onMouseLeave:

   def runAction(self, event):
       self.props.style.classes = 'navReduced'
       self.view.custom.docked_status = False

5. Set the container's initial props.style.classes to navReduced in the property editor. See the next section for why this step matters.
6. Save the project and open a fresh session. Designer preview does not always reproduce the Dropdown modal behavior exactly.

Avoid the Setup Pitfalls

• Initial class missing. If style.classes is empty at startup, neither width rule applies and the dock opens at its minimum width. It only corrects itself after the first mouse event. Set the starting class explicitly.
• Overwriting other classes. Assigning a string to self.props.style.classes replaces the whole value. If the container also uses classes such as a background theme class, write them all out, for example 'navExpanded navTheme'. Otherwise the first hover removes them.
• Events on the wrong element. Put the events on the same container that receives the class. If you attach them to a child, onMouseLeave fires when the cursor moves between children and the dock flickers.
• Gateway round trip. Component event scripts run on the Gateway, not in the browser. Each hover sends a message to the Gateway and waits for a property update. On a slow link, expect a short delay before the 0.3 s transition starts. That is normal behavior.
• Using the custom property as the source of truth. docked_status reports what the last event set. Bind cosmetic changes to it, but do not use it to decide which class to apply. Let the events set the class directly.

Fix a Pushed Dock That Covers the View

A second fault often shows up after the class swap works. The docked view's display is set to "pushed", but the expanded nav slides over the main content instead of moving it aside. Before you blame the dock configuration, check the style hierarchy.

Perspective applies styles in this order. Each later layer overrides the one before it:

Theming > Stylesheet > Named Styles > Inline Props

The stylesheet resource is inserted between the Gateway theme files and the project's Named Styles. A Named Style or an inline style property on the component beats your stylesheet rule. Your stylesheet beats the theme.

1. Check the nav container and the docked view root. Remove any Named Style or inline style props that set width, position, or overflow.
2. Open the page in a local browser session. Press Ctrl+Shift+I, or right-click and choose Inspect.
3. In the Elements panel, select the docked view element and then the main view container next to it.
4. Read the Styles pane. Rules that are overridden appear struck through. Note which rule wins and which source it comes from: theme file, stylesheet, Named Style, or inline.
5. Expand the nav and watch the main view container's offset (margin, padding, or left position) while the dock width changes. If the offset stays at the dock's configured size while the rendered width grows to 300 px, push mode is working. The push is sized from the dock configuration, and your CSS-driven width is simply wider than that configured size.
6. Decide from what you found. If a rule overrides you, remove it or move your rule to a higher layer. If the offset follows the configured size, either set the dock size to match the expanded width, or accept an overlay for the extra 245 px (300 minus 55).

width: auto !important on .docked-view-left is the first suspect here. It overrides the dock's own width handling, so the dock's rendered width and the width Perspective uses for pushing can differ.

Verify the Fix in a Live Session

1. Load the page fresh. The dock should render at 55 px immediately, with no flash at an undefined width.
2. Hover the nav. It should expand to 300 px over 0.3 s, and docked_status should read True. Check any bound cosmetic elements.
3. Open the Dropdown and move across every option, including the far edge of the list. The dock must stay at 300 px the whole time.
4. Select an option and move the cursor off both the list and the nav. The dock should collapse, and docked_status should return to False.
5. In DevTools, confirm that the container's class toggles between psc-navReduced and psc-navExpanded, and that no struck-through width rule remains.
6. If the dock is set to pushed, confirm the main content moves by the amount you expect at both widths.
7. Repeat the test from a remote client to see the delay users on slower links will get.

FAQ