Customizer panels should have the same priority hierarchy as Sections

[mattwiebe]

WP_Customize_Panel is subclassed from WP_Customize_Section and have the same hierarchy in the Customizer as a top-level item. However, upon rendering, first the Panels are rendered, then the Sections. This makes the priority property deceptive and makes it impossible to move em-paneled sections beneath any possibly-more-important plain sections.

I could help with a patch for this if folks agree that this is a good idea.

[celloexpressions]

#27406 is still open so that we can decide whether or not to do this (and specifically, see #27406 comment:48). I'm still against it for UX purposes, and I don't think the implementation would be as clean, but I may be in the minority there. You probably understand the implications of the subclassing approach here better than most; in terms of API, sections and panels are treated as fairly distinct entities with add_panel vs add_section, get_panel, remove_panel, etc. that make the separate sorting of sections and panels clearer. I think if we'd gone with add_section with a parent parameter instead of the panel terminology, your point would be more significant.

If we don't end up doing this in 4.0 but want to consider it again in the future, we can re-open this ticket, but let's keep the discussion there for now. I think a proof-of-concept patch could be useful in making a final decision here.

[nacin]

I'm going to re-open this so we have a specific ticket (#27406 is getting big, and it's good to keep discrete things separate). I think the current API is deceptive and the current UX is also poor. Widgets should not be at the top, that's wrong.

I absolutely agree that panels and sections should be sorted together. I don't see why Widgets is at the top, either — it shouldn't be first.

[celloexpressions]

Biggest UX thing for me is that we need to do something about the tiny arrow indicators for sliding down/right if we even want to consider this. Some things sliding down and others sliding sideways and switching contexts seemingly at random results in incredibly confusing UX, and it's nearly impossible to tell which direction the arrow points if they aren't grouped by direction (and it's not great anyway).

I have a feeling, for some reason, that people will use panels more appropriately (and generally try to keep their interfaces simpler/easier to use) if they're all at the top, as that implies their importance and pushes traditional sections lower. Also, a reminder for everyone that panels do support priority, and are sorted by their priorities. Once there are more core (and plugin) panels, the grouping at the top will make more sense. I've been using the Customizer with both Widgets and Menus panels since this was introduced, and that may be influencing my opinion here. But since there will inevitably be more core panels in the future, any proposed changes/implementations here need to be tested with multiple panels. Making a decision here based solely on the placement of Widgets would be a big mistake.

@nacin do you have a why for "widgets shouldn't be at the top, that's wrong"? Besides the current implementation, Widgets are currently at the top because they're the most likely to be edited the most frequently. Users rarely change things like site title/tagline, colors, header/background, static front page, etc. after initial setup, but they're likely to tweak Widgets much more frequently. If they're near the top, users don't need to search long for them when they visit the Customizer for the first time in a while looking to make a change there. In the context of panels generally, the argument is that panels should generally be used for things that require an entrely separate context, and one that would be used more frequently than standard sections. Eventually, everything that's currently in a top-level section could potentially be moved to a "theme options" panel, so we should consider that possibility as well.

A big reason to have kept this on #27406 is that the path to the implementation we currently have is documented there. Other than comments specific to the sorting issue, we went with an API that specifically makes panels and sections distinct objects, like sections and controls are. That WP_Customize_Panel extends WP_Customize_Section is an implementation detail, IMO. And rather than mixing sortings, I would be interested in UI changes that give panels hierarchy with respect to top-level sections, as they're fundamentally different things.

Dump of relevant comments from #27406 to attempt to de-fragment the discussion:
celloexpressions:

We can (and should consider) group top-level-sections and pages together for sorting by priority in the page approach; and could look into a WP_Customize_Group class that WP_Customize_Section and WP_Customize_Page both extend (@westonruter's idea).

Note: the "page" approach is what made it into core; in the other approach, sections had parent sections that were still sections.

Should all panels be listed before top-level sections, or should they have mixed sorting? I think it's better to keep them separate, as the small arrow indicators are more effective when grouped, and users are probably more likely to need to use a panel then a top-level section when entering the Customizer at any given time (if Widgets and Menus are panels, for example).

ethitter:

Sections already support priority. Since a Panel is an extension of the WP_Customize_Section class, shouldn't it respect priority?

helen:

Not sure about grouping panels vs. sections - I can see how it would make sense to group them together, but the ordering feels wrong with Widgets at the top.

celloexpressions:

Sorting/priorities: in the current implementation, all panels are displayed by their priorities and then all sections are displayed by their priorities. Until there are more panels in core, that does mean that widgets will often be alone at the top (pending theme/plugin panels). We certainly could do mixed priorities, although that would be a bit less elegant, as we may need two copies of everything in WP_Customize_Manager (panels, sections, and the combined array, perhaps groups). I think we should think about this from a UI/UX perspective and get some feedback. For me, having the panels at the top makes sense because the types of things that'll go in panels will generally be more-commonly-used (ie, users change their widgets more frequently than their site title/tagline, header/background, colors, static front page, etc.). Could probably get some stats from .com to back that up (even though their customizer UI is fairly different).

Only remaining item here, barring any bugs, is whether panels and top-level sections should have independent or mixed sortings. The current, separate approach is a cleaner implementation and asserts than panels contain more-commonly-used controls. It also makes it easier, as a user, to distinguish between panels that will completely change the Customizer's context and sections, which simply open inline. I imagine that would create a really strange user experience, unless there is a more obvious visual distinction between panels and top-level sections. Eventually, I could see a time when we may force all sections to be contained in a panel (placing unspecified ones into a generic panel), so we may want to consider that as well.

[celloexpressions]

Example of visual hierarchy distinction between top-level sections and panels. Needs design work, obviously. Another option might be to do #28504 (icons) only for panels - thus providing a strong visual distinction between sections and panels.

[mattwiebe]

Putting Panels at the top is only punting on the already-existing UI problems here and hoping that nobody will use a short enough screen and/or register enough panels to create the unsolved problem. That's maybe tolerable if the plan is to tackle this properly in 4.1 but that feels pretty questionable.

Look at a common UI pattern like a dropdown menu, which interleaves top level and secondary-level items in the same hierarchy:

Or a settings screen in iOS:

Things are sorted by their importance in their context, not according to the type of thing that they are.

Some things sliding down and others sliding sideways and switching contexts seemingly at random results in incredibly confusing UX, and it's nearly impossible to tell which direction the arrow points if they aren't grouped by direction (and it's not great anyway).

Has this been tested? I don't think that's actually going to be a problem. Sure, maybe this needs to be designed better (icons, better indication of expected behaviour), but I'm seeing assumptions that may not bear out.

[celloexpressions]

Screen capture (low framerate) demonstrating interactions with panels mixed with sections.

[celloexpressions]

Screen capture (low framerate) demonstrating interactions with all panels at the top.

[celloexpressions]

Replying to mattwiebe:

Putting Panels at the top is only punting on the already-existing UI problems here and hoping that nobody will use a short enough screen and/or register enough panels to create the unsolved problem. That's maybe tolerable if the plan is to tackle this properly in 4.1 but that feels pretty questionable.

Could you elaborate on the existing UI problems you see here? If the issue is too many sections/hard to find certain sections, I wouldn't say that panels relate to the issue, as they serve to provide different contexts (for example that could eventually be deep-linked) rather than purely adding hierarchy to sections. Something like #28504 would help a lot for that too.

Look at a common UI pattern like a dropdown menu, which interleaves top level and secondary-level items in the same hierarchy:
Things are sorted by their importance in their context, not according to the type of thing that they are.

I wouldn't compare this to a dropdown menu. That's a hierarchy of actions, whereas in the Customizer we have a hierarchy of control containers. The iOS settings look like they're a hybrid between containers and controls, rather than control containers and super-containers, but are a closer comparison.

Some things sliding down and others sliding sideways and switching contexts seemingly at random results in incredibly confusing UX, and it's nearly impossible to tell which direction the arrow points if they aren't grouped by direction (and it's not great anyway).

Has this been tested? I don't think that's actually going to be a problem. Sure, maybe this needs to be designed better (icons, better indication of expected behaviour), but I'm seeing assumptions that may not bear out.

See screen captures above. I find it much less intuitive, even confusing. Could also do some user tests. Again, having more than one panel for testing purposes is important.

Regardless of what we do here, we should assign a priority to widgets based on a hierarchy of potential future core panels so that plugin panels can prioritize accordingly.

[celloexpressions]

Icons might help (see #28504).

[celloexpressions]

Alternate arrow styling is considerably worse.

[celloexpressions]

More equivalent vertical arrow padding.

[celloexpressions]

No icons, alternate arrows with differing spacing.

[celloexpressions]

Per IRC chat during the bug scrub this morning, we're going to do some user testing to get an unbiased feel for how panels and top-level sections should interact.

After looking at a bunch of different UI approaches (screenshots above and on #28504), we're going to try the following scenarios:

• Baseline: current trunk setup with all panels at the top, existing UI.
• Icons: add icons to panels, but not sections (per #28504), use 28504.panels.diff for testing.
• Mixed sorting, new arrows but existing spacing and no icons. 28979.DEMO.diff​ for testing.

Testing should be done with a theme with multiple widget areas (like Twenty Fourteen), the ​Menu Customizer plugin, and settings-customizer.php​, which adds a settings panel. I'll add priorities to the different panels in the hacky-mixed-sorting patch.

[celloexpressions]

"Settings Customizer" plugin shell that adds a Settings panel with several sections to the Customizer, for testing purposes.

[celloexpressions]

Hacky patch to implement mixed sorting and an alternate arrow style.

[folletto]

@nacin: I think the current API is deceptive and the current UX is also poor

I can't help much on the API side, but I can give an hand on the UX side. This is a very important piece of UI so I hope a different perspective might help the discussion. :)

@celloexpressions: Some things sliding down and others sliding sideways and switching contexts seemingly at random results in incredibly confusing UX

I agree that this is the most important issue to address. :)

I tried then to think about the issue, and here are two ideas. Notice that I sidestep what is probably an API issue in order to point to what could be an ideal state of things, so we might review that. But I feel it's important to get that view first.

Concept Slide-All:

Concept Slide-Groups:

The rationale behind these proposals are:

1. The main issue with that UI is the mix of slides and accordion. Accordion are usually relatively bad by themselves because they mix navigation and content (they can be used, but they need to be use very accurately), and they slide the navigation up and down to arbitrary positions. So the first advice would be to convert everything to sliders. I'm aware this is added dev cost, but this is really one solution that would really solve the UX issue.
2. Bonus: sliders are also ideal on mobile, and will feel natural in that context. This doesn't just include the standard iOS drilldown, but also Android (see the recent guideline on Lists for Material Design where the accordion is shown only as pure navigation).
3. Introducing titles in-between will also help in achieve a functional grouping that will help understanding the various options with small visual impact.
4. The grouping will also allow for an in-between solution if it's not possible to switch everything to sliders: just group the various elements, and create a single bucket for the sliders.

I hope this is doable... and it helps the discussion. :)

P.S.: this might be OT on this ticket (should I open a new one?), but would be absolutely great if the "You are customizing" click would lead to the themes switch page instead of just showing you a theme screenshot, which... given the site is on the right, feels redundant... :)

[celloexpressions]

Latest/best concept so far for distinguishing panels and adding a bit more contrast.

[celloexpressions]

Dump of CSS used for the recent set of iterations linked in IRC (headers added between each one, somewhat corresponding to screenshot filenames).

[celloexpressions]

We've agreed that a two-toned approach to panel headings, with the alternate arrow icon, seems to work best, regardless of the sorting. The contrast & visual hierarchy leaves a lot to be desired, but we'll resolve that in a future release via #29158.

I would be okay with mixed sorting if we did something like my most recent screenshot (with that order - widgets should be before static front page and before the current navigation section (moved into the menus panel with the Menu Customizer plugin), as widgets are before menus in the admin menu. If we decide to go this route I can patch it, but it will be a fairly involved patch.

However, my preference is still for separate sorting with panels at the top. One new issue I see with mixed sorting is that panel headings look kind of like top-level-section group headings, visually (like in @folletto's concept).

[celloexpressions]

Replying to folletto:

P.S.: this might be OT on this ticket (should I open a new one?), but would be absolutely great if the "You are customizing" click would lead to the themes switch page instead of just showing you a theme screenshot, which... given the site is on the right, feels redundant... :)

That was #26890, and then with #28550, we no longer even mention the current theme when not doing a theme preview. Given that it would be incredibly useful to make a close connection between themes and theme options/customization, I think we'll probably just wait to get theme-switching into the Customizer at this point. That would mean a "Theme: [theme name]" panel at the top that slides backwards to imply a layer of hierarchy above the top-level controls; I've written a ​UI proposal for that and we're hoping to get a feature-plugin team working on that once some of the API infrastructure to allow something like that is in place.

[folletto]

Ok, I guess this ticket is for visual styling as well. Is there already a ticket to address the overall design of accordions/slide-ins? :)

Replying to celloexpressions:

Replying to folletto:

P.S.: this might be OT on this ticket (should I open a new one?), but would be absolutely great if the "You are customizing" click would lead to the themes switch page instead of just showing you a theme screenshot, which... given the site is on the right, feels redundant... :)

That was #26890, and then with #28550, we no longer even mention the current theme when not doing a theme preview. Given that it would be incredibly useful to make a close connection between themes and theme options/customization, I think we'll probably just wait to get theme-switching into the Customizer at this point. That would mean a "Theme: [theme name]" panel at the top that slides backwards to imply a layer of hierarchy above the top-level controls; I've written a ​UI proposal for that and we're hoping to get a feature-plugin team working on that once some of the API infrastructure to allow something like that is in place.

The proposal you make is very similar to a design concept I was working on too, even if the "slide back" actually triggered a full screen view (from the left slides in a full page that covers everything, which is in practice the 3.9 theme browser), the reason is that it would be too constrained to fit inside a small column (even if, that would be exactly how it would behave on mobile).
But apart from that, I agree 100% that it should be the hierarchy to imply there.

We could still add an intermediate step: it could be simply a link back (click, open Themes panel in the admin area), and we can work on the better interaction (sliding panels, API, etc) at a later stage. ;)

So... worth a new ticket? ;)

[celloexpressions]

Replying to folletto:

Ok, I guess this ticket is for visual styling as well. Is there already a ticket to address the overall design of accordions/slide-ins? :)

I think that would be here. I do like the idea of everything side-sliding, as things are organized in a more intuitive hierarchy that is a more common UI pattern. But in practice it introduces a lot of extra mouse/finger movement (especially for finding the back button) and cognitive load with the entire context shift for every section. Existing sections are designed with the expectation of being displayed in an accordion, and users expect that, so I'm not sure that we could change it at this point even if we resolved issues like the back button (touch swiping works great for touch devices here). Sliding down vs. sideways for sections vs. panels also gives them functional hierarchy, which is good, whereas everything sliding would imply more of a parent/child setup, which we moved away from with the implementation in #27406 (API-wise).

The proposal you make is very similar to a design concept I was working on too, even if the "slide back" actually triggered a full screen view (from the left slides in a full page that covers everything, which is in practice the 3.9 theme browser), the reason is that it would be too constrained to fit inside a small column (even if, that would be exactly how it would behave on mobile).
But apart from that, I agree 100% that it should be the hierarchy to imply there.

We could still add an intermediate step: it could be simply a link back (click, open Themes panel in the admin area), and we can work on the better interaction (sliding panels, API, etc) at a later stage. ;)

So... worth a new ticket? ;)

Great idea! We could even slide in themes.php in a full-screen iframe from the left of the screen, and then trigger a new full pageload to get out of the iframe as soon as the user navigates somewhere (such as, most commonly, to customize a new theme). If you want to make a new ticket, or even re-open #26890 with a comment, I can throw together a rough patch as I have an idea for how we could accomplish that from a technical perspective. Now that we have an AYS for unsaved changes, linking away from the Customizer isn't a huge deal. If the Customizer was opened from themes.php, we would already have that page's DOM loaded thanks to customize-loader, so it would just be a matter of changing the animation that closes the Customizer iframe. Not the ideal experience that doing it all in the customizer would be, but a good approach while we build up the API, and at least we can start to make the themes vs. theme/site options relationship clearer. If we get a few people working on it, could probably get that into 4.1.

[folletto]

Replying to celloexpressions:

But in practice it introduces a lot of extra mouse/finger movement (especially for finding the back button) and cognitive load with the entire context shift for every section. Existing sections are designed with the expectation of being displayed in an accordion, and users expect that, so I'm not sure that we could change it at this point even if we resolved issues like the back button (touch swiping works great for touch devices here). Sliding down vs. sideways for sections vs. panels also gives them functional hierarchy, which is good, whereas everything sliding would imply more of a parent/child setup, which we moved away from with the implementation in #27406 (API-wise).

I feel this is a mix of a few different arguments coming also from the ticket you link... let me try to disassemble it. :)

The most important point imho is that the cognitive load of slide-ins is lower than accordions, not higher, this for a moltitude of reasons:

1. The number of clicks is identical
2. The positioning is preserved both in the navigation AND in the customization panel: fixed positioning helps people with spatial memory to recall items, creating visual trust.
3. Slide-ins separate also clearly navigation from content. It won't be a mix of navigation and content, like the accordion (note that this isn't something new, many accordion solutions ask for a uniform set of content, like all menu, instead of mixed one. The same recent Google Material Design manual outlines accordions for menus only).
4. Moving sections rely on our spatial memory overall, while things that fold/unfold will keep moving the whole page up and down: I click an accordion, content appears in between, suddenly the "next" item is way below, moving it as a target.
5. It's easier to scan a pure list of items, instead with an open accordion the menu is disrupted.
6. An open slide-in is clearly just that, thus helping the user to focus on that content, instead of having first to separate it from the context. It's a cleaner solution.
7. Not to mention the potentially improved elegance of keyboard navigation... (left-right-esc). ;)

This doesn't mean that accordions are bad overall, clearly, however they must be very carefully isolated from context, and used where possible not as navigation but as exploration (i.e. not menu-with-content, but already descripting items with "more"). ;)

I'd note also in regard of #27406 that slide-ins are a better solution regardless of their use as a multi-layer hierarchy, or not. In other terms: if we could instantly convert all the accordions to slide-ins right now, it would still be an improvement even without implementing a multi-layer structure (even if I'd personally find it the natural step forward).
I've seen your work there... I think it was the right direction... and reading the thread does look to me that there was agreement on that being a better solution, no? :)

Plus, all of this, good for desktop, would be just bliss on mobile. ;)

Great idea! We could even slide in themes.php in a full-screen iframe from the left of the screen, and then trigger a new full pageload to get out of the iframe as soon as the user navigates somewhere (such as, most commonly, to customize a new theme). If you want to make a new ticket, or even re-open #26890 with a comment, I can throw together a rough patch as I have an idea for how we could accomplish that from a technical perspective. Now that we have an AYS for unsaved changes, linking away from the Customizer isn't a huge deal. If the Customizer was opened from themes.php, we would already have that page's DOM loaded thanks to customize-loader, so it would just be a matter of changing the animation that closes the Customizer iframe. Not the ideal experience that doing it all in the customizer would be, but a good approach while we build up the API, and at least we can start to make the themes vs. theme/site options relationship clearer. If we get a few people working on it, could probably get that into 4.1.

Sounds great!
Reopened #26890... let's see... ;)

[celloexpressions]

Lots of great points here. I think the biggest thing is separating navigation from content; that would facilitate changes like what I proposed in #29158 to make the Customizer feel more like wp-admin. My remaining concern would be wasted vertical space within Customizer sections that only have one or two controls, but that's something that developers could adapt to.

Unfortunately, we're far too late to consider any structural changes like dropping the accordion for 4.0. We're already planning on re-doing the Customizer on mobile in 4.1 (see #28784); I think it would be good to experiment with switching the accordion behavior to sliding as part of that effort. If that goes well, we could make that change for desktop users as well. Could you either comment on #28784 so that we remember to experiment with this there, or make a new ticket for experimenting with doing it everywhere? We'll definitely need to do user testing to confirm the UX theory, but it makes a lot of sense in theory.

For this ticket - let's focus on design tweaks to help distinguish panels, first, and then making a final decision about panel / top-level-section sorting and act accordingly. Let's split any other details out to their own appropriately prioritized tickets (see #29172 and #29174 so far). Keeping the minor design tweaks here since it directly relates to whether or not mixed sorting would work.

Next step is to convert the appropriate part of my CSS dump into a more refined patch to implement customize-panels-3-c.png​. And if any designers have suggestions to improve the color selections without getting crazy, we can do those here too.

[folletto]

Ok, message received. I'm out of this ticket. ;)

[celloexpressions]

With forthcoming patch, using line-arrows and a two-toned header for panels to distinguish them from top-level sections. Cleans up exact color selections and border styling from earlier mockups.

[celloexpressions]

Implement design tweaks to distinguish panels from top-level sections, and adjust hover/focus states accordingly.

[celloexpressions]

28979.design.diff​ should be good to go to resolve the design-related issues here; if any other designer have tweaks or suggestions please say so. I've revised the color selections and border styling from the earlier mockups to make things feel more polished.

Once this (or a variant) is committed, we can revisit mixed sorting now that the visual design issues and panel/section distinction is resolved.

[helen]

In 29470:

Clearer visual differentiation between panels and sections in the customizer. props celloexpressions. see #28979.

[helen]

Per the original goal of the ticket, and feedback from various entities, let's mix them together, please.

[helen]

28979.diff​ is based on the demo diff, with widgets at the bottom (priority 140). It doesn't seem hacky to me.

[celloexpressions]

28979.diff​ is a good start, but I think we should definitely change how the subclassing works - making both WP_Customize_Section and WP_Customize_Panel extend WP_Customize_Container. That clarifies the purpose of each class and is something we had considered doing anyway - but got lost in the shuffle (@westonruter suggested initially in June). Otherwise, for example, we have things like WP_Customize_Panel::controls, which even though they aren't used seems wrong. I can put that together pretty quickly tomorrow morning. I do think that our UI changes resolve many of my concerns with mixed sorting.

In terms of sorting, I think that Widgets would make the most sense being before Static Front page, after header & background image, as that's one option that's very rarely going to change and is independent of many preview contexts (we should make it contextual once we have contextual sections), whereas Widgets are likely to be used/changed more frequently and are directly related to the preview. Generally speaking, I like the order in customize-panels-two-tone-mixed.png​ if those sections & panels were to exist on a given site based on the plugins & theme (that's Twenty Eleven) being used. Switching the default priority to be at the bottom (proposed 160 in #29172) would mean that there would often be a section after static front page (pending the particular set of plugins/theme), but by default it would just be static front page after Widgets. So it may be better to put widgets at 140 until we have another core panel, but my preference would be at 110 (before static front page).

[celloexpressions]

We need to tweak the colors more; didn't realize you left the focus/active change out of the commit. I think that that part of the patch is very necessary, but if we don't do it, the darker color of the two-tone (and the corresponding border colors) needs to be lighter on both normal and (especially) focus/hover states.

But the bigger problem is that the focus/hover/open/active color for sections (I think #eee is really the only option given the current design) matches the off-white color from the two-toned panels (for which #f5f5f5 works, unless we don't change the other color, in which case we need to make it even lighter). The whole point here is for them to be different; they start to run together when you actually play around with it without the rest of the patch there. So we need to either lighten the offset color even more, or, do what's in 28979.design.diff​, or something more extreme (but we already tried a bunch of variants of that).

Not sure if only committing part of the patch was intentional, but there are some places where color changes but not background color changes were made, etc. so something odd happened there.

---

Also re: why we really should make the more fundamental changes along with mixed sorting, WP_Customize_Panel::panels is a thing...

[celloexpressions]

Customizer Panels are not Sections; Panels and Sections are both containers for entirely different types of objects. We should be consistent with that fact internally. Not sure how to patch this exactly, but wp-includes/class-wp-customize-section.php should be renamed to class-wp-customize-container.php, with the contents as indicated in the patch (actual diff is not as big). Also merges support for mixed priorities by default. Needs thorough review (but a proper diff first would be good).

[celloexpressions]

Straight diff on class-wp-customize-section.php, which I'm guessing needs to be applied before renaming the file.

[celloexpressions]

I feel pretty good about 28979.2.diff​ / 28979.2.class-wp-customize-section.diff​. As I said before, it's pretty involved. But if containers are going to be a thing, they should be an actual thing. Panels are not sections, sections and panels are both containers; since we're mixing sorting this distinction needs to be clear internally. This needs thorough review from westonruter, etc.

The only residual awkwardness that this leaves is the customize_render_section actions, but we can't really change those. Will need extensive testing because the Customizer (CSS especially) was not designed with nested accordion sections (need to probably add some more >s).

Re: design it still feels really wrong, but #eee (matching header/footer actions) seems to work the best without changing things around completely. We should probably lighten the offset panel-arrow background hover-state even with this change, as it's a bit too contrasty with everything else. #fff to #f5f5f5 is 10 shades for the contrast in the standard state, we should use #e5e5e5 instead of #ddd for the background and then change the borders to #ddd for the hover/focus state to match (since that'll be against #eee).

[celloexpressions]

Punt WP_Customize_Container to future release and mark WP_Customize_Panel as final in the meantime to avoid potential BC issues. Implement mixed sorting and introduce a containers array in WP_Customize_Manager.

[celloexpressions]

#29197 for WP_Customize_Container. @westonruter agrees that we can wait for it (and should do it in the future), but since we need to close off the Panels API in the meantime (subclassing is an important part of the way all Customizer objects work), we'll definitely want to make sure it happens early in 4.1.

28979.3.diff​ should be good to go; note the css tweak that caused issues for panels that were at the bottom. I don't think there're any other css issues related to panels not being on top, but we'll see if anything pops up.

[helen]

nacin will handle final review and commit.

[celloexpressions]

Remove the changes to class-wp-customize-section.php.

[nacin]

In 29488:

Customizer: Mixed priority sorting for panels and top-level sections.

props celloexpressions.
fixes #28979.

[mattwiebe]

ya'll are awesome. :)