Repository navigation
[3.9 regression] Markdown: raw HTML in ordered list drifts right on every format with tabWidth 4 #19986
Description
Prettier 3.9.6
Playground link
--parser markdown --tab-width 4Input:
1. Enable images:
```json
{}
```
<p align="center">
<img alt="example">
</p>
2. Continue.Output:
1. Enable images:
```json
{}
```
<p align="center">
<img alt="example">
</p>
2. Continue.Second output:
1. Enable images:
```json
{}
```
<p align="center">
<img alt="example">
</p>
2. Continue.Expected output:
Input unchanged and idempotent, as in 3.8.5.
Version bisect:
| version | <p> indentation after passes 1 / 2 / 3 |
|---|---|
| 3.8.5 | 4 / 4 / 4 |
| 3.9.0 | 5 / 6 / 7 |
| 3.9.6 | 5 / 6 / 7 |
current main (036e72a) |
5 / 6 / 7 |
This appears to be a regression of #4112, previously fixed by #4115. It surfaced while testing the Markdown parser fix in #19838 against the real ultralytics/ultralytics docs tree. The affected downstream file is docs/en/guides/view-results-in-terminal.md; repeated formatter runs never converge.
Activity
Refzlund commentedon Sep 5, 2026
Independent reproduction of this regression with a different trigger, which may help locate the common cause: it does not need raw HTML, an ordered list, or a non-default
tabWidth.Repro — prettier 3.9.6, default options, no config file:
Repeated
prettier --write:onetwoThe first line of the block stays put; every subsequent line gains four columns per run, without bound.
Same bisect as this issue reports, measured here on the repro above (column of
twoafter runs 1–3):So this lands in the same 3.8.5 → 3.9.0 window as the ordered-list/HTML case above, which I think is decent evidence the two are one regression rather than two.
Boundary, all measured against 3.9.6 with default options:
-item is a fixed point.- [ ]reproduces it identically to- [x].- [x]). At column 5 it normalises once and settles; at 6, 7 and 8 it never converges. A fenced block at column 6 diverges too.Why the plain-text case may be worth having on file separately from the HTML ones (#18066, #18067): those repros all involve raw HTML or HTML comments, which makes "prettier is mishandling an HTML block" a plausible reading. Here the block is an ordinary paragraph, so whatever is re-indenting it is not HTML-specific.
I have not tried to identify the mechanism, so this is only the measured boundary rather than a theory about the cause.
webdevsamran commentedon Sep 6, 2026
Hi team, I would like to investigate and fix this regression.
In 3.9.6, raw HTML and indented content inside list items drift rightward on repeated formatting passes under Markdown parsing. I can trace the indentation calculation in the markdown printer to identify where nested element offsets are being accumulated rather than reset relative to the list marker column, and add regression tests covering both raw HTML and indented blocks inside lists.
Could you please assign this to me? Thanks!