[wp-trac] [WordPress Trac] #49288: Metabox holders missing their border and "Drag boxes here" text

[WordPress Trac]

#49288: Metabox holders missing their border and "Drag boxes here" text
-------------------------------------+-------------------------------------
 Reporter:  xkon                     |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  highest omg bbq          |   Milestone:  5.5
Component:  Administration           |     Version:
 Severity:  blocker                  |  Resolution:
 Keywords:  has-patch has-           |     Focuses:  ui, accessibility,
  screenshots needs-testing needs-   |  administration
  backwards-compatibility            |
-------------------------------------+-------------------------------------

Comment (by afercia):

 @azaozz I'm all for reviewing better this change in the next release cycle
 if there are concerns for a broad impact on the plugins ecosystem. Your
 call :) Of course, I have no objections to a revert.

 However, for the future, this leads us to a question: to what extent is
 the HTML and CSS provided by core for specific pages really "supported"?
 I'd tend to think it is supported, ''to some extent'', for the specific
 layout provided by core for the specific kind of pages where it it's used.
 For example the legacy edit post page: any page that reuses that layout
 can use the HTML and CSS provided by core. Instead, I'm not sure that HTML
 and CSS can be "supported" when plugins reuse them in ''other pages'',
 like their settings pages. As I see it, core shouldn't support this usage
 as it's basically a "doing it wrong".

 In any case, plugins that "hack" (in the good sense) HTML and CSS used by
 core for layout, they do it at their own risk. There's no official
 support, nor an API, that "guarantee" core HTML and CSS won't ever change.
 Actually, they can change at any time and this isn't unprecedented in the
 WordPress history.


 Replying to [comment:57 azaozz]:
 >
 > This is incorrect. The `#post-body` ID is used in core as a container
 for the writing area

 Hm, isn't this what I said above? "...used in core to identify the edit
 pages of posts, comments, menu items..."


 > Looking a bit deeper, why were some of the (older) default styles
 removed? They seem unrelated to this ticket:
 https://core.trac.wordpress.org/changeset/48340/trunk/src/wp-
 admin/css/common.css. Looks like there are 32,700 plugins that may be
 reusing some of these:
 https://wpdirectory.net/search/01EE3GHZPD2KPSS1J24KGXE4CB. Was this
 unrelated change even tested in any way?

 This is documented in comment:18 on this ticket:
 > removes the CSS rulesets related to `.inner-sidebar` and `.has-right-
 sidebar` as **they're no longer used since WordPress 3.4**, see [20272] /
 #20015

 where the emphasis on **they're no longer used since WordPress 3.4** is
 mine :) Which leads us to one more question: how long core should keep
 supporting CSS that isn't used any longer in core? WordPress 3.4 was
 released on June 13, 2012, that's more than 8 years ago.


 > the fact that the committed code reverts previous (long time ago) fix

 I may have missed what this fix was. Asking genuinely, can you please
 clarify when you have a chance?

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