[wp-trac] [WordPress Trac] #34391: Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks)

WordPress Trac noreply at wordpress.org
Sun Nov 1 07:37:23 UTC 2015


#34391: Harden panel/section UI code by removing contents from being logically
nested (read: goodbye margin-top hacks)
-------------------------+--------------------------------------------
 Reporter:  westonruter  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Customize    |     Version:  4.0
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, accessibility, javascript
-------------------------+--------------------------------------------
Description changed by westonruter:

Old description:

> The UI concept of sliding panels were introduced to Customizer in 4.0
> with the introduction of the “Panel”, a grouping of sections (see
> #27406). In 4.2 the panel UI paradigm was extended to Sections (groups of
> controls), which were originally represented as accordions in the
> Customizer UI (see #31336).
>
> To accomplish the sliding panel UI paradigm in the Customizer while
> retaining the existing nested DOM structure in a large multidimensional
> unordered list (panels containing sections containing controls), there
> have been a lot of headaches trying to get the panels positioned properly
> with hacks using `margin-top`, and maintaining this when panels/sections
> change their active state. (Eliminating the recalculation of the `margin-
> top` will also improve DOM performance.) Several  bugs have ensued,
> including:
>
> * #33567: Panel margin-top glitches when widget areas added
> * #34344: Expanded section margin-top glitches when other section is
> deactivated
> * #33220: Customizer: layout issues with autofocus'd sections on small
> screens
>
> It seems clear that another approach is needed to reduce the complexity
> and improve the robustness of the Customizer UI.
>
> I'd like to propose that the root “panel” of the Customizer (the links to
> the panels and panel-less sections) is logically independent in the DOM
> from the panels and sections it links to, and likewise for the links to
> sections within a panel to be disconnected in the DOM from the container
> elements for the sections they link to. By keeping these separate, we
> won't have to do any more `margin-top` hacks: the panel/section to be
> shown simply needs to be positioned to the top of the Customizer pane.
> This will mean accessibility hacks which set the root of the Customizer
> to `visibility:hidden` but a nested child element to `visibility:visible`
> won't be needed anymore (see #33258). To maintain the accessibility
> benefit that comes “for free“ with the current nested hierarchical
> unordered list, we can implement [http://www.w3.org/TR/wai-
> aria/states_and_properties#aria-owns aria-owns] to relate the
> panel/section links with the panel/section containers they link to.

New description:

 The UI concept of sliding panels were introduced to Customizer in 4.0 with
 the introduction of the “Panel”, a grouping of sections (see #27406). In
 4.2 the panel UI paradigm was extended to Sections (groups of controls),
 which were originally represented as accordions in the Customizer UI (see
 #31336).

 To accomplish the sliding panel UI paradigm in the Customizer while
 retaining the existing nested DOM structure in a large multidimensional
 unordered list (panels containing sections containing controls), there
 have been a lot of headaches trying to get the panels positioned properly
 with hacks using `margin-top`, and maintaining this when panels/sections
 change their active state. (Eliminating the recalculation of the `margin-
 top` will also improve DOM performance.) Several  bugs have ensued,
 including:

 * #33567: Panel margin-top glitches when widget areas added
 * #34344: Expanded section margin-top glitches when other section is
 deactivated
 * #33220: Customizer: layout issues with autofocus'd sections on small
 screens
 * #34529: Customizer: wp.customizer.section(xxx).focus() resizing issue
 (WP 4.4 Beta 2)

 It seems clear that another approach is needed to reduce the complexity
 and improve the robustness of the Customizer UI.

 I'd like to propose that the root “panel” of the Customizer (the links to
 the panels and panel-less sections) is logically independent in the DOM
 from the panels and sections it links to, and likewise for the links to
 sections within a panel to be disconnected in the DOM from the container
 elements for the sections they link to. By keeping these separate, we
 won't have to do any more `margin-top` hacks: the panel/section to be
 shown simply needs to be positioned to the top of the Customizer pane.
 This will mean accessibility hacks which set the root of the Customizer to
 `visibility:hidden` but a nested child element to `visibility:visible`
 won't be needed anymore (see #33258). To maintain the accessibility
 benefit that comes “for free“ with the current nested hierarchical
 unordered list, we can implement [http://www.w3.org/TR/wai-
 aria/states_and_properties#aria-owns aria-owns] to relate the
 panel/section links with the panel/section containers they link to.

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34391#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list