WordPress.org

Make WordPress Core

Opened 3 months ago

Closed 2 months ago

Last modified 2 months ago

#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:

https://user-images.githubusercontent.com/1766382/88839120-6c8e1200-d18f-11ea-9483-e3a05c16eb7f.png

Whereas on WP 5.4 and earlier it looked more like this:

https://user-images.githubusercontent.com/1766382/88839166-862f5980-d18f-11ea-9c17-b24aeee65907.png

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)

50836.diff (436 bytes) - added by audrasjb 3 months ago.
Administration: Use flex-start value for justify-content property to ensure Dashboard Widgets are not misaligned.
Capture d’écran 2020-08-03 à 22.02.46.png (23.8 KB) - added by audrasjb 3 months ago.
Before the patch
Capture d’écran 2020-08-03 à 22.02.18.png (23.6 KB) - added by audrasjb 3 months ago.
After the patch

Download all attachments as: .zip

Change History (19)

#1 @SergeyBiryukov
3 months ago

  • Component changed from General to Administration
  • Milestone changed from Awaiting Review to 5.5

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:

.postbox-header .hndle {
	flex-grow: 1;
	/* Handle the alignment for the configurable dashboard widgets "Configure" edit-box link. */
	display: flex;
	justify-content: space-between;
	align-items: center;
}

Moving to the milestone for visibility.

@audrasjb
3 months ago

Administration: Use flex-start value for justify-content property to ensure Dashboard Widgets are not misaligned.

#2 @audrasjb
3 months ago

  • Keywords has-patch added

50836.diff fixes the issue on my side.

#3 @mnelson4
3 months 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: @audrasjb
3 months 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 @whyisjake
3 months 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 @mukesh27
3 months 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: @audrasjb
3 months 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 ;-)

Last edited 3 months ago by audrasjb (previous) (diff)

#8 @mukesh27
3 months 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.

#9 @SergeyBiryukov
3 months ago

Related: #50839, appears to be another manifestation of the same issue.

#10 @mnelson4
3 months 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.

#11 @desrosj
2 months ago

  • Version changed from trunk to 5.5

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


2 months ago

#13 @SergeyBiryukov
2 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#14 in reply to: ↑ 7 ; follow-up: @afercia
2 months 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 @khag7
2 months 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 @SergeyBiryukov
2 months 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.

Feel free to reopen if any new considerations come up.

Version 0, edited 2 months ago by SergeyBiryukov (next)
Note: See TracTickets for help on using tickets.