Skip to content

Conversation

@lolbinarycat
Copy link
Contributor

@lolbinarycat lolbinarycat commented Dec 7, 2025

I believe the reason we were doing this before was that write_html_fmt adds a \n after each <p> element.

I have worked around this by making white-space:pre-wrap apply only to the contents of each paragraph, so the inserted whitespace between paragraphs is not included.

Perhaps a better solution would be getting rid of pre-wrap entirely, and instead inserting
events in place of newlines, but that would be a significantly larger change.

fixes #149732

r? @GuillaumeGomez

@rustbot
Copy link
Collaborator

rustbot commented Dec 7, 2025

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @lolbinarycat

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Dec 7, 2025
@rust-log-analyzer

This comment has been minimized.

@lolbinarycat lolbinarycat force-pushed the rustdoc-stab-no-strip-p-149732 branch from 15636e0 to ba1a361 Compare December 11, 2025 20:06
I believe the reason we were doing this before was that
write_html_fmt adds a \n after each <p> element.
I have worked around this by making white-space:pre-wrap apply
only to the contents of each paragraph, so the inserted whitespace
between paragraphs is not included.

Perhaps a better solution would be getting rid of pre-wrap entirely,
and instead inserting <br> events in place of newlines, but that
would be a significantly larger change.
@GuillaumeGomez
Copy link
Member

Wouldn't it be simpler to replace \n with <br>?

@lolbinarycat
Copy link
Contributor Author

lolbinarycat commented Dec 12, 2025

@GuillaumeGomez do you mean pre-parsing? that wouldn't work bc we disable inline html support for depreciation notes.

honestly i'm tempted to say we should just completely break this over an edition, making it use normal markdown handling and telling people to escape their html tags and use <br> and non-breaking spaces if they want the old behavior. unsure if we would want to do that in addition to or instead of making this change.

@GuillaumeGomez
Copy link
Member

Yeah, that would make more sense.

@lolbinarycat
Copy link
Contributor Author

I think I'll just go ahead and implement that change for EditionFuture, then add a class for the legacy word wrap behavior. Hopefully when edition 2027 is being drafted up someone greps for EditionFuture and finds that? I guess we could add the maybe-future-edition label to the issue to make it easier to find?

Some might find it odd to make edition changes this far in advance, but I think it's a good idea in order to avoid crunch time.

@GuillaumeGomez
Copy link
Member

I think so too. Although I wonder if we really need to put it behind an edition change. Might be worth discussing with the team, don't you think? Eventually that will allow you to have less work to do. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Newlines in deprecation warning are handled strangely - double newlines are stripped completely

4 participants