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

[WordPress Trac]

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

Comment (by celloexpressions):

 Generally speaking, I am okay with breaking compatibility with things that
 aren't using the customizer API directly, but want to keep it as much as
 possible for anything following best practices and using specifically-
 blessed API features such as custom sections and panels.

 With that being said, skimming through the current patch, I don't think we
 need to be particularly worried about back-compat. The only PHP change is
 in `customize.php` and is only adding a class name to the root element. In
 terms of the JS side, custom sections and panels that generally follow the
 core UI should be using the core functions for expanding/collapsing rather
 than implementing their own versions, so the changes there should work for
 them. If we don't change anything in the markup for an individual section
 or panel, essentially, I think we'll be okay in terms of custom sections
 and panels, even if the css and js changes are extensive. When the JS
 functions are overridden by a custom section, the UI is typically
 different anyway.

 What's described above with the `Zerif` theme sounds like both generally a
 bad idea and something that a plugin could maybe do but a theme should not
 do. As a general rule themes should not do anything whatsoever to change
 the way the customizer UI works, only add their own
 panels/sections/controls as needed and build additional UI through custom
 object types when absolutely necessary. I'm totally fine with breaking
 things like that but we should make our best effort to inform anyone that
 may be affected. If this is a common issue (and even if it's only in a few
 themes), we should also probably have a broader discussion with the theme
 review team about what themes ''shouldn't'' be allowed to do with the
 customizer.

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