Sensor page: Stop side-panels using vertical space when closed#2033
Sensor page: Stop side-panels using vertical space when closed#2033
Conversation
Signed-off-by: Nicolas Höning <nicolas@seita.nl>
nhoening
changed the title
|
@copilot pleease continue work in this PR and work on the first three TODO items in feat/options-on-sensor-page-use-less-vertical-space-when-closed. |
- TODO 1: Add CSS variables for z-index (--z-index-sidepanel, --z-index-sidepanel-label, --z-index-sidepanel-content) for a single global stacking index - TODO 2: Rename classes throughout: sidepanels→sidepanel (wrapper), left-sidepanel-label→sidepanel-label, sidepanel+left-sidepanel→sidepanel-content in all HTML templates (sensors, accounts, assets) and base.html JS - TODO 3: Move chart-type-picker and delete button outside the .sidepanel wrapper in sensors/index.html so they appear below the sidepanel tabs rather than interleaved - Remove old commented-out CSS block and clean up CSS (fix // comments to /* */, remove nth-child hacks, use height:60px per container instead) Agent-Logs-Url: https://github.com/FlexMeasures/flexmeasures/sessions/484168a2-b80f-49f1-99a2-016408ad5c2a Co-authored-by: nhoening <1042336+nhoening@users.noreply.github.com>
Done in commit 2899726. Here's what was addressed: TODO 1 – Fix z-index, use one global stacking index: Added CSS custom properties ( TODO 2 – Better class names: Renamed throughout all templates, CSS, and the JS in
TODO 3 – Accommodate chart dropdown and delete button: In Also cleaned up the CSS: removed the old commented-out block, replaced nth-child top-offset hacks with a simple |
|
@copilot the z-index issue is still not working well in practice. .sidepanel-content is above its own .sidepanel-label and .sidepanel-container, but not above the other .sidepanel-containers. Here is a possible explanantion: This behavior usually happens when stacking contexts are created unintentionally, or when z-index values are scoped to different containers. Here’s why it might be happening and how to fix it: Why This Happens: Stacking Contexts: If a parent element (e.g., .sidepanel-container) has properties like opacity, transform, filter, or position: fixed/sticky, it creates a new stacking context. This means z-index values inside it are relative to that container, not the entire page. z-index Scoping: Even if .sidepanel has a higher z-index than .left-sidepanel-label, if the label belongs to a different container with a higher z-index, it will appear on top. One possible solution: If possible, place all elements inside a single parent container with position: relative. This ensures their z-index values are compared within the same stacking context. |
Move z-index from .sidepanel-container to .sidepanel so all containers share a single stacking context. Previously each .sidepanel-container had position+z-index which created its own isolated stacking context, causing .sidepanel-content (z-index:100) inside container N to be covered by later containers whose z-index was evaluated in the same parent context. Now .sidepanel is the stacking context, containers have no z-index (so they don't isolate their children), and the open sidepanel-content (z-index:100) correctly paints above all other containers in the shared context. Agent-Logs-Url: https://github.com/FlexMeasures/flexmeasures/sessions/4f095d33-daeb-4c8b-8d5e-dd641de3aa4c Co-authored-by: nhoening <1042336+nhoening@users.noreply.github.com>
Fixed in commit a6042c0. The root cause was exactly as described: The fix moves the
|
Signed-off-by: F.N. Claessen <claessen@seita.nl>
There was a problem hiding this comment.
Copilot seems to be still lacking a way to reliably check the UX quality of its own work.
A few regressions I saw:
- Gap between panel items [I fixed this]
- Sliding animanition has now become a hard appear/disappear
- "Last 7 days" and "Today and tomorrow" buttons fade lingers
|
Well, the UI specialist is being added in #1985, but I don't know how much that guy will add. |
@copilot can you look into the two open items here? @Flix6x I also saw there were still some layout issues. I just wasn't in a hurry with it. |
Replaces height+opacity approach with transform: translateX which: 1. Fixes the hard appear/disappear regression - height:0→auto cannot be animated by CSS; transform IS animatable, giving smooth slide 2. Fixes button fade lingers - removing opacity transition means litepicker preset buttons no longer have their hover-state CSS transitions layered over a parent opacity fade Hidden state: transform: translateX(-106%) with visibility: hidden delayed by 0.3s (waits for slide-out animation to complete before hiding from a11y) Shown state: visibility flips visible immediately, then transform slides in Agent-Logs-Url: https://github.com/FlexMeasures/flexmeasures/sessions/8ef4d9f6-dc4a-4ef2-bf72-46bba0b79a8b Co-authored-by: nhoening <1042336+nhoening@users.noreply.github.com>
Fixed in commit f3630cb. Both issues had the same root cause — the height+opacity animation approach I introduced: Sliding animation → hard appear/disappear: CSS cannot animate Button fade lingers: Removing |
I know, but this kind of UI stuff is what I consider a fun activity when I have some time off. 🤭 |
|
My main issues are resolved now. I really like that the sensor page no longer scrolls vertically anymore on a desktop screen. My remaining list can be considered off scope:
|
sidepanels→sidepanel,left-sidepanel-label→sidepanel-label,sidepanel left-sidepanel→sidepanel-contentin all templates + CSS + JSsensors/index.html— moved them outside the.sidepanelwrapper, below the sidepanel tabs.sidepanel-containerto.sidepanelso open panel content is never covered by subsequent closed containerstransform: translateXslide (height→auto cannot be animated)