Show triangle on the "Details" disclosure element in all cases

[JohnTitor]

Re-submission of #82805, fixes the style issue by applying the same margin as <p>.

Before

After

r? @GuillaumeGomez

[rust-highfive]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez

[GuillaumeGomez]

Thanks! What would be nice would be to have a GUI test for it, but not sure if it's actually possible...

Any idea @jsha? If not possible, then let's simply r+ it.

[jsha]

This strikes me as possibly the wrong fix. I think what's going on is that we have some CSS that hides the triangle for rustdoc's built-in toggles, since we want to use a ::before pseudo-element with content: [+] for that. But I guess that CSS is also hiding the triangle for <details> tags written in Markdown by the doc author. Can we make rustdoc's own CSS rules more specific to .rustdoc-toggle so it doesn't interfere with user-authored HTML?

[JohnTitor]

This strikes me as possibly the wrong fix. I think what's going on is that we have some CSS that hides the triangle for rustdoc's built-in toggles, since we want to use a ::before pseudo-element with content: [+] for that. But I guess that CSS is also hiding the triangle for <details> tags written in Markdown by the doc author.

That's a good point, pushed another fix.

Can we make rustdoc's own CSS rules more specific to .rustdoc-toggle so it doesn't interfere with user-authored HTML?

I'm not familiar with rustdoc's CSS but I think the below should've worked here:

rust/src/librustdoc/html/static/rustdoc.css

Lines 1453 to 1455 in 50a9081

	details.rustdoc-toggle > summary, details.undocumented > summary {
	list-style: none;
	}

But it does hide the normal summary's triangles, any idea?

[jsha]

Okay, I looked into this and it turns out the issue is actually a bug in the very old version of normalize.css we use (3.0.0, from 2014). In #82313 I tried to update to the latest, 8.0.1. But it was reverted in #82549 because of these regressions:

#82548
#82542

See these demos that show it is a problem with normalize.css:

https://jsbin.com/jorowazuli/edit?html,output

https://jsbin.com/kecozayaka/edit?html,output

The right path forward is to figure out why upgrading normalize.css caused those regressions, fix the issues, and then do the upgrade. Alternately, we may conclude that we no longer need normalize.css, which would be an even nicer outcome.

[JohnTitor]

Thanks for investigating! Hmm, but given that we should take a look at it carefully and reviewing will taker a longer time not to regress anymore, I think this PR is still worth landing as a stopgap, no?
Though, I'm happy to work on upgrading normalize.css if you could provide some help, or I'm also happy if you would work on it.

[jsha]

You're right, it does make sense to land this as a stopgap. The current version looks good but I want to make sure we know to remove it after normalize.css is either upgraded or removed. Can you add a comment that says "Remove after normalize.css is either upgraded or removed (#86629)"?

[JohnTitor]

Sure, added.

[jsha]

@bors r+

[bors]

📌 Commit 14413ad has been approved by jsha

[bors]

⌛ Testing commit 14413ad with merge 3e9d7ec...

[bors]

☀️ Test successful - checks-actions
Approved by: jsha
Pushing 3e9d7ec to master...