WordPress.org

Make WordPress Core

#34343 closed enhancement (fixed)

Customizer: Make panel headers sticky?

Reported by: pavelevap Owned by: westonruter
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: has-patch
Focuses: ui, javascript Cc:

Description

I have for example long menu and when I want to go back, I have to scroll to the top and then click arrow button. Panel headers should be sticky, I guess. See attached screenshot, there is no way to simply go back without scrolling to the top.

Attachments (5)

Customizer_Menu_headers.png (61.4 KB) - added by pavelevap 23 months ago.
34343_1.diff (7.4 KB) - added by delawski 12 months ago.
34343_2.diff (9.4 KB) - added by delawski 11 months ago.
34343_3.diff (9.4 KB) - added by delawski 11 months ago.
Updated patch (previous one had failing unit tests; merging master branch fixed the issues).
34343_4.diff (9.1 KB) - added by delawski 10 months ago.

Download all attachments as: .zip

Change History (38)

#1 @obenland
21 months ago

  • Version changed from trunk to 4.3

#2 follow-up: @celloexpressions
21 months ago

  • Focuses ui added
  • Type changed from defect (bug) to enhancement

This was one of the issues when the panel back buttons moved below the customizer close button instead of covering it. I'd like to see an approach for preserving at least the navigation, but it may take up too much space to make the whole section header sticky. Maybe scroll it into view when scrolling up but re-hide as soon as you scroll down? Is there a clean way to make just the navigation stick without keeping the whole header?

#3 in reply to: ↑ 2 @SergeyBiryukov
21 months ago

  • Keywords needs-patch added

Replying to celloexpressions:

Maybe scroll it into view when scrolling up but re-hide as soon as you scroll down?

Sounds good to me, would be consistent with comment:4:ticket:33165.

#4 @celloexpressions
16 months ago

#33315 was marked as a duplicate.

#5 @westonruter
12 months ago

Closely related to #34391

#6 @westonruter
12 months ago

This may be a duplicate of #35186.

#7 @celloexpressions
12 months ago

I would probably prefer this approach to moving the back buttons again; the current headers offer nice consistency when navigating around.

This ticket was mentioned in Slack in #core-customize by clorith. View the logs.


12 months ago

#9 @delawski
12 months ago

I'm working on this ticket now, but I cannot seem to assign it to myself.
@westonruter or @celloexpressions - could any one of you change the ownership of the ticket?

#10 @westonruter
12 months ago

  • Owner set to delawski
  • Status changed from new to assigned

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


12 months ago

#12 @delawski
12 months ago

  • Focuses javascript added
  • Keywords ux-feedback added

Today I've created all the 'mechanics' behind the sticky header feature.

At the first glance my solution may not seem obvious (i.e. using position: fixed). I have kept in mind updates that #34391 is going to introduce (hopefully in this release). Panels/sections are transitioned there using CSS transforms. They create new stacking contexts and paint layers, making it really hard to make use of position: fixed.

I still have to find best way to bind header positioning method to scroll event on the sidebar (scroll in current implementation of panels/sections is happening on either the sidebar or inner <ul>s; this will get simplified thanks to #34391).

Below you can see the actual effect of header toggling. I tried to make it as natural as possible, though I'm open to UX feedback.

https://cldup.com/PFnHjlutQV.gif

(Link to better quality video: https://cldup.com/yOM0Mr7GIO.mov)

Here is a PR with current WIP:

https://github.com/xwp/wordpress-develop/pull/155

Last edited 12 months ago by delawski (previous) (diff)

@delawski
12 months ago

#13 @delawski
12 months ago

  • Keywords has-patch added; needs-patch removed

I have moved the code responsible for 'sticking' the header out of panel/section class, and optimized the way sticky functionality is provided:

  • only a single expanded panel/section listens to the scroll event at a time;
  • it stops listening right after it is collapsed;
  • most calculations are moved out of the scroll event handler to prevent potential lags;
  • moreover, scroll event listener is throttled to further improve performance.

Because of the fact that this new feature is dependant on panel/section structure, I'd suggest merging it after #34391 (of course only if #34391 is going to be pulled into the master).

I've attached a diff file.

Also, a PR on GitHub is available:

https://github.com/xwp/wordpress-develop/pull/155

#14 @delawski
12 months ago

  • Keywords needs-patch added; has-patch removed

Okay, I've been to optimistic about my initial solution without usage of position: fixed. Just tested it on IE 10 and IE 9, and the header is flickering there while using position: fixed works great.

What has prevented me from using position: fixed is the fact that #34391 introduces deep changes to the panel/section layout and fixing anything there is not that simple as it might seem. However, this is a solution we have to look for, so I will postpone any development on this ticket until we get more clarity around #34391.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


12 months ago

This ticket was mentioned in Slack in #design by hugobaeta. View the logs.


11 months ago

#17 @celloexpressions
11 months ago

The design team approves of the approach in 12, so we should be good to go here once #34391 is fixed.

#18 @celloexpressions
11 months ago

  • Milestone changed from Awaiting Review to 4.7

Moving to 4.7 with the project that also includes #29158 and #34391, making the sliding panels experience better.

This ticket was mentioned in Slack in #core-customize by delawski. View the logs.


11 months ago

#20 @folletto
11 months ago

I feel it's important to mention that fixing the back button as per #35186 would solve the issue without any need of additional logic, and would be simpler overall (no scroll animation, always visible, solves the presence of two "back" buttons).

That said, this is already an improvement and there's agreement, so I think we can proceed with it, but I'd still move after to fix #35186 with the single back/close button, and remove the scrolling logic.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


11 months ago

This ticket was mentioned in Slack in #core-customize by delawski. View the logs.


11 months ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


11 months ago

This ticket was mentioned in Slack in #core-customize by delawski. View the logs.


11 months ago

@delawski
11 months ago

#25 @delawski
11 months ago

  • Keywords has-patch added; ux-feedback needs-patch removed

The patch is ready for review and testing. Here's the PR: https://github.com/xwp/wordpress-develop/pull/155

I have tested it in IE 9, 10, 11, Firefox and Chrome. It worked well in each case for me, but I'd really appreciate more testing.

The only downside of the patch is that it is infeasible to make the 'main' header element ('You are customizing...') sticky in current implementation. In opposite to all other headers, the 'main' header element (div#customize-info) is outside of the actual UL list containing links to top-level panels/sections (ul.customize-pane-parent). Because of that, it is CSS-transformed separately along with ul.customize-pane-parent. It would be suboptimal to write separate 'sticking/sliding' routines for this single element only.

Instead I'd suggest changing the 'main' panel markup so that the header div#customize-info is moved to the ul.customize-pane-parent to match other panes. I think that if the id and class are kept intact, the change wouldn't have a negative impact on the customizer sidebar. However, it should be described in a separate ticket and my patch doesn't account for that.

@delawski
11 months ago

Updated patch (previous one had failing unit tests; merging master branch fixed the issues).

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


10 months ago

#27 @celloexpressions
10 months ago

@delawski testing the patch, the sticky header comes into view too quickly when scrolling up. Can we make it scroll into view linearly as you scroll up, rather than jumping in?

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-customize by delawski. View the logs.


10 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


10 months ago

@delawski
10 months ago

#31 @delawski
10 months ago

@celloexpressions - Thanks for the testing. I have changed the behaviour of the sticky headers as you suggested. Right now on scrollTop the header won't slide down by itself. It will reveal itself as the user scrolls up gradually, as if it was hanged just above the visible area all the time.

https://core.trac.wordpress.org/attachment/ticket/34343/34343_4.diff

I have tested the patch with Chrome/OSX, Firefox/OSX/Win, Safari, IE11, IE10 and IE9. It worked as expected in all listed browsers.

If you feel the patch is not ready for 4.7, feel free to punt it and comment on what has to be done in the future in order for it to land in the trunk.

#32 @celloexpressions
10 months ago

  • Owner changed from delawski to westonruter
  • Status changed from assigned to reviewing

34343_4.diff looks good to me. Assigning to @westonruter for final review and commit.

Great work @delawski!

#33 @westonruter
10 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 38853:

Customize: Add sticky headers for panels and sections.

Includes autoprefixing of CSS.

Props delawski, celloexpressions.
See #35186.
Fixes #34343.

Note: See TracTickets for help on using tickets.