Change #1036715 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] POC: Make paragraph spacing 0.5em top and 1em bottom by default, handle adjacent inline elements manually

https://gerrit.wikimedia.org/r/1036715

Just to double check, @JScherer-WMF these are the inline elements that were handled (ul, ol, table, dl, blockquote) to only have 0.5 top spacing when following a paragraph. Does this initial list of "inline elements" seem good to you? they can be adjusted in the future as well

i.e.

<p>paragraph</p>     
<--- 0.5em margin between paragraph and blockquote (not including spacing on the blockquote itself)
<blockquote>adjacent inline element</blockquote>
<--- 1em margin between paragraph and blockquote
<p>paragraph</p>

Change #1036715 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Make paragraph spacing 0.5em top and 1em bottom by default, handle adjacent inline elements manually

https://gerrit.wikimedia.org/r/1036715

Another problematic usecase we have on frwiki:

.col {
  margin-top: 0.3em;
  column-width: 30ex;
}
.col ul { margin-top: 0; }

<div class="col">
* list
* with
* several
* elements
* displayed
* in
* several
* columns
</div>

This example does not display consistently on Vector-2022 and Vector-legacy, since Vector-2022 already has margin-top: 0;

In T366389#9873928, @Pols12 wrote:

This example does not display consistently on Vector-2022 and Vector-legacy, since Vector-2022 already has margin-top: 0;

That will be removed after this patch goes live: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1036715/3/resources/skins.vector.styles/typography.less.

In T366389#9873593, @Edtadros wrote:

5. Verify the inline element spacing next to paragraphs.
6. ❓ AC2: Confirm that inline elements next to paragraphs have 0.5em of spacing.

@bwang, This doesn't look right. What should I be looking for here?

Ah, this is a poorly worded requirement. That's the source of the confusion. The requirement should read: "Paragraphs with floated elements beside them always have at least 0.5em vertical spacing."

The issue before was that floated elements "stole" the vertical spacing from the paragraphs within which they appear. @bwang and I decided that the paragraphs should always have at least 0.5em spacing. If a floated element interacts with the end of a paragraph, that means that the spacing might get slightly larger. The spacing between the floated elements themselves is not the primary focus of this patch. Moving this to ready for sign off.

If we discover new, unintended vertical spacing behaviours, we should note them as separate bugs.

Thanks again @Jack_who_built_the_house and @bwang for your collaboration on this!

Test Result - PROD

Status: ✅ PASS
Environment: PROD
OS: macOS Sonoma 14.5
Browser: Chrome 126
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Verify Paragraph and Inline Element Spacing in Vector 2022

1. Open the Vector 2022 skin.
2. Navigate to this patch demo page.
3. Verify the paragraph spacing.
4. ✅ AC1: Confirm that paragraphs have a margin-top of 0.5em and a margin-bottom of 1em.

5. Verify the inline element spacing next to paragraphs.
6. ✅ AC2: Confirm that inline elements next to paragraphs have 0.5em of spacing.

We have an issue because of that on frwiki: https://fr.wikipedia.org/wiki/Discussion_mod%C3%A8le:Infobox_V3/S%C3%A9parateur#Mod%C3%A8le_cass%C3%A9

p + table should be replaced with p:not(.mw-empty-elt) + table (and same with the other ones: p + ul, etc.)

Considering there is a mechanism to show such empty elements (wtf, just never outputting the markup of these elements would fix so many issues),
technically the code should be this monstrosity:

p:not(.mw-empty-elt) + table,
.mw-parser-output.mw-show-empty-elt p.mw-empty-elt + table,
body:not(.mw-hide-empty-elt) .mw-parser-output:not(.mw-hide-empty-elt) p.mw-empty-elt + table {
    /* layout "fix" here */
}

An alternative approach, that makes use of :has() and is much simpler:

p:has(+ ul, + ol, + table, + dl, + blockquote) {
    margin-bottom: 0.5em;
}

• Nicely works in case of nonvisible <p>.
• Doesn't use negative margins, which are source of so many troubles.
• Some browsers don't support :has() yet, but it would simply discard the rule, resulting in a slight margin excess.

Edit: I figured out a slightly faster selector: p:has(+ :is(ul, ol, table, dl, blockquote)). That's because for each <p> element, it will retrieve its next sibling only once, instead of retrieving the sibling five times.

As a bonus, :is() could be replaced with :where(), so that the whole selector has just the same specificity as p. Provided that it is applicable, this low-specificity selector would be more adequate, as it would be less conflicting with local styles.

For reference, when the current "-0.5em" tweak is removed, top margins (as of now) on Vector 2022:

• <ul> and <ol>: 0.3em
• <table>: 1em if having class "wikitable", else user agent (Chrome: 0)
• <dl>: 0.2em
• <blockquote>: user agent (Chrome: 1em)

Or… just stop outputting these empty elements, that are so dumb and bring nothing but problems.

I noticed a similar issue here: https://fr.wikipedia.org/wiki/Edna_O'Brien?oldid=217318314&useskin=vector-2022#Liens_externes

The content is too close to the bottom border of the « Liens externes » heading.

That's because the underlying template {{Liens}} may output empty list items (and that can't be changed, this has been already investigated). Note we already have had many troubles with this template because of these dumb .mw-empty-elt list items, see this discussion for instance.

Also, many articles are affected, as the template is used on about 480,000 pages.

Edit: The issue with this template isn't because of empty list items, but because it outputs a <nowiki /> at the beginning. Indeed, that template has to use workarounds for various issues related to newlines, see for instance 188332740 and 196601681.

But basically the issue remains the same, it's because of a .mw-empty-elt element at the beginning. In my messages just above I proposed two fixes: this one and this one.

Edit 2: I have added a local ugly workaround (diff), so the issue is no longer visible using the link from the top of this message.

Just to mention yet another issue I encountered because of these .mw-empty-elt…: 217576477, and I had to revert it: 217576519 (thus, the problem is not solved).

Edit: I didn't mean to use + (next-sibling) in this code, but ~ (subsequent-sibling) which would be a better pick here (as it would also allow empty items at intermediate positions, not only at end).

Edit 2: in addition to .liste-horizontale, that code could also be used elsewhere in the same file, for .fieldsetlike.

@Od1n this task is closed, and that’s not clear what you expect from your several messages. I think you should write a clear minimal wiki page as a test case to demonstrate the problematic differences between Vector-2022 and legacy Vector, then open a new task linking that test case.

@Od1n I filed T375548 with your suggestion, thanks for sharing that edge case and the solution proposal