slachiewicz commented on PR #151:
URL:
https://github.com/apache/maven-doxia-converter/pull/151#issuecomment-5234593878
`6cb6771` — **reconciled: it is a Doxia version boundary, and both sets of
observations were
correct.** My earlier "a `name`-only anchor is deleted" was true for the
stack this project's own
site builds on and wrong as a general statement.
Measured here with `doxia-module-markdown` pinned either side, same page,
same five placements:
| written in the page | 2.0.0 | 2.1.0 |
|---|---|---|
| `<a name="x"></a>` | **deleted** | `<a id="x"></a>` |
| `<a id="x"></a>` | `<a id="x"></a>` | `<a id="x"></a>` |
| `<a name="x" id="x"></a>` | `<a id="x"></a>` | `<a id="x"></a>` |
`maven-site-plugin` 3.21.0 brings 2.0.0; 3.22.0 brings 2.1.0. This project
resolves 3.21.0, which
is why my fixture deleted them.
**Placement turned out to be irrelevant to this.** I tested the exact
patterns from the real
pages — anchor on its own line, glued to a raw `</table>`, glued to a raw
`</pre>`, immediately
after a fenced block. On 2.0.0 all five are deleted; on 2.1.0 all five are
rewritten. So the
hypothesis that raw-HTML-block context preserved them is wrong; it is purely
the version.
`id` is still the form to write, but the reason is now the version spread
rather than a defect,
and the page says so.
### The boundary makes the folding rule a delayed failure
Worth flagging beyond this PR. A `name` anchor folded into heading text
looks *fine* on 2.0.0 —
precisely because it is deleted before it can suppress the section's
generated id. On 2.1.0 it
survives, and the section id disappears:
```
doxia 2.1.0, "<a name="x"></a>Folded Name" above a setext rule
anchor kept: yes
section id Folded_Name: NO
control heading id: yes
```
So a page can be converted, checked, and merged clean, and then lose its
section anchors on a
later site-plugin bump that changed nothing else. Any conversion that folds
`<a name>` into
heading text is carrying that.
### Closing fence: the two block kinds are now separated
Gluing an anchor to the end of a **raw** `<pre …></pre>` is fine and is what
converted xdoc pages
carry — that placement works, and I have stopped implying otherwise. Only a
**fenced** block
refuses to close and swallows the rest of the document. Converting a raw
block into a fence is
what takes the placement away, so the page now says to keep those two
decisions together.
`mvn site` and `mvn verify` green (JDK 21, Maven 3.9.16, macOS); RAT 0
unapproved, 23/23; all ten
`<h2>`, the `<h3>` and both tables render.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
