#50836 closed defect (bug) (wontfix)
Using tags in metaboxes makes them float
Reported by: | mnelson4 | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.5 |
Component: | Administration | Keywords: | has-patch close |
Focuses: | css, administration | Cc: |
Description
WP 5.5 made some CSS changes that makes our plugin's (YARPP) metabox text get placed in an unexpectedly different way than before.
Inside the metabox's header the plugin has been adding <small>
tags, and now all that content gets aligned to the far right right of the metabox, while the rest of it is still aligned left, which results in this:
Whereas on WP 5.4 and earlier it looked more like this:
We can workaround it, but I thought I should mention this as other plugin authors might experience the same issue, and fix in core might be better.
Attachments (3)
Change History (19)
#1
@
4 years ago
- Component changed from General to Administration
- Milestone changed from Awaiting Review to 5.5
@
4 years ago
Administration: Use flex-start
value for justify-content
property to ensure Dashboard Widgets are not misaligned.
#3
@
4 years ago
Thanks for the quickfix! In our case it's not quite perfect: there's now no space between the text and the text inside the small
tags. See https://i.imgur.com/VdW7xAA.png
#4
follow-up:
↓ 6
@
4 years ago
Thanks for the feedback. I'm unsure whether it's better to add some spacing or to let plugin authors add the HTML space (of some custom CSS) by themselves.
#5
@
4 years ago
- Milestone changed from 5.5 to 5.5.1
Since this seems to be limited to custom metaboxes, let's push this to 5.5.1 since we are deep in the RC process.
#6
in reply to:
↑ 4
@
4 years ago
We can also use one CSS rule like below.
.postbox-header .hndle > small { padding-left: 3px; }
Replying to audrasjb:
Thanks for the feedback. I'm unsure whether it's better to add some spacing or to let plugin authors add the HTML space (of some custom CSS) by themselves.
#7
follow-up:
↓ 14
@
4 years ago
@mukesh27 <small>
is just an example from their plugin, but it can be a span, or any other HTML tag. We don't want to fix core for this plugin, but for any HTML bit of code added there ;-)
#8
@
4 years ago
@audrasjb so in this case plugin developer need to implement custom CSS in there plugin to add space or we can add .postbox-header .hndle > *
for all HTML element.
#10
@
4 years ago
Thanks @mukesh27 and @audrasjb for the suggestions on core fixes; and @SergeyBiryukov and @whyisjake for triaging etc.
FYI for our plugin we’re just removing the small
tags in the latest update. It was an overdue change anyway for us.
I’m fine with closing this ticket, unless you want it open in case others face similar issues.
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
4 years ago
#14
in reply to:
↑ 7
;
follow-up:
↓ 15
@
4 years ago
- Keywords close added
Replying to audrasjb:
<small>
is just an example from their plugin, but it can be a span, or any other HTML tag. We don't want to fix core for this plugin, but for any HTML bit of code added there ;-)
I'd argue that I'm not sure core should allow to "add any HTML" within the meta box headings. Headings are of fundamental importance for accessibility and altering the HTML provided by core may lead to a decreased level of accessibility. In this specific case, based on comment:10, seems there's nothing to fix now, as the redundant HTML tag was removed by the plugin (thanks for that!).
I noticed other plugins alter these headings in more harmful ways e.g. injecting form elements inside the heading. I think core should not support and not even allow these kind of hacks of the UI. Planning to propose this item for the next weekly accessibility meeting agenda.
#15
in reply to:
↑ 14
@
4 years ago
Replying to afercia:
I'd argue that I'm not sure core should allow to "add any HTML" within the meta box headings.
I agree, however, I don't know if preventing that is feasible. I don't know how these plugins are adding the HTML, but I'd assume its by accessing the global $wp_meta_boxes
.
Because that is a global variable, there's no reasonable way from preventing any plugin from changing. To prevent changing of headers would require a major change to how meta boxes logic works. That's not out of the question, but it would be a large undertaking for the purpose of... preventing plugins from changing core?
#16
@
4 years ago
- Milestone 5.5.1 deleted
- Resolution set to wontfix
- Status changed from reviewing to closed
Since there is no consensus on moving forward, the issue for the plugin in question is now fixed, and there are currently no other similar reports, I think this can be closed for now per comment:14.
Feel free to reopen if any new considerations come up.
Thanks for the ticket! As noted in comment:3:ticket:50788, this appears to be a side effect of using CSS flexbox on the heading for edit-box links, same as in #50788:
Moving to the milestone for visibility.