Shoud I add changelog_unreleased/markdown/15081.md?

Can you send a separate PR for this first?

Don't trim spaces other than ASCII whitespace at the beginning or end of paragraphs

And we can use this module to do the html trim.

@fisker In CommonMark spec, the form feed \f (U+000C) is in the same category as the full-width space (and other spaces in Zs).

https://spec.commonmark.org/0.30/#unicode-whitespace-character

Either way, it is destined to be removed at the stage where the converted HTML is processed, so it may as well be removed at the stage of conversion in Prettier.

https://codepen.io/tats-u/pen/bGQjrvM

I'll reuse that code.

Trailing form feeds don't seem always to be removed.

Interesting, https://bugs.webkit.org/show_bug.cgi?id=13159 seems we already made mistake in HTML/Handlebars printer.

Anyway, I think we should reuse htmlWhitespaceUtils, but consider remove \f in future if it really matters.

@fisker Your change has just been applied.

I found an interesting description in https://drafts.csswg.org/css-text-3/#line-break-transform

Then any remaining segment break (\n) is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

NOTE: Historically, HTML and CSS have unconditionally converted segment breaks to spaces, which has prevented content authored in languages such as Chinese from being able to break lines within the source. Thus UA heuristics need to be conservative about where they discard segment breaks even as they strive to improve support for such languages.

What sucks is not the HTML or CSS specs but browsers' implementations.
I have to modify the change log and comments in the source code.

@fisker I'll change the behavior.

I looked into the detailed behavior of Firefox.

Table: Is a newline between the followings converted to a space in Firefox?

A newline between [Chinese & Japanese & CJK punctuations] should not be converted to a space.
Once it is removed, these

漢字
だよ
。

↓ OK

漢字だよ。

↓ STOP!

漢字
だよ。

This will improve the compatibility with the conventional behavior to some extend and reduce browser-defined behaviors.

A space around Chinese (& Japanese) is going not to be converted to a newline. It's not compatible with Firefox.

A newline between [Chinese & Japanese & CJK punctuations] should not be converted to a space.

Didn't get it.

[Chinese & Japanese & CJK punctuations]

These seem to be treated as a single group in Firefox.
A newline surrounded only by that group is simply removed (in a view).
Of course, a space is added once copied and pasted on somewhere else.

https://codepen.io/tats-u/pen/poQQVyR

Should't we only need make sure the output equivalence in html?

Ah, maybe you are right, in markdown one single new line doesn't generate a space. But should not related to languages.

@fisker

But should not related to languages.

Does it mean it's better to always treat a newline in Markdown as a space even if surrounded only by han or kana?
Indeed Markdown viewers other than browsers use Blink, but the behavior doesn't look natural as a Chinese or Japanese paragraph for me.
For the first place few people break lines in Chinese or Japanese sentences in Markdown documents, though.

@fisker @sosukesuzuki Recently I have noticed the plan for the release of v4.
How do you think about this change as a content in v4?

Current v4 is published for the new CLI test.

Current v4 is published for the new CLI test.

I see.

I'll create a new PR based on this, but reducing the change.
This PR will be frozen until it is merged and a new major version containing it is released.

This force push is just for following the latest content of main.

• Make newline and whitespace interchangeable even between (Chinese or Japanese) and another character when proseWrap is always or never → frozen but no newline will be added between (Chinese or Japanese) and another character
• Don't trim spaces other than ASCII whitespace at the beginning or end of paragraphs → kept

npx prettier --w is not so perfect to Chinese. It's not correct to add any space between Chinese words. It's recommended to add a space after en words, numbers, and punctuations

open-telemetry/opentelemetry.io#4341

I read this and decided to stop Prettier from wrapping lines even between Chinese / Japanese for a while.
We should face the reality of the broken and stale behavior of WebKit-based browsers rather than pursuing the ideal of WPT and Firefox's behavior.

#16691's title and behavior will be changed.

This PR will be kept opened to be worked on after the following browsers' bugs are fixed:

• https://issues.chromium.org/issues/40069685
• https://bugs.webkit.org/show_bug.cgi?id=260857

I found #16691 hasn't been merged into next. It's dangerous to retarget at next now.

The 2nd last rebase (the last rebase will be next→main) because of the merge of #16796
Duplicated commit 10b2725 with that was dropped
The last rebase will take place after when next merges main once again