Thanks for the contribution. +1 for AI disclosure.

This test is not what I expected:

- [ ] a
  -
.
<ul>
<li>
<h2>a</h2>
</li>
</ul>

The square brackets should be preserved (and not just reinserted, the parsing should be canceled completely in this case). That said, I'm not sure how to accomplish that cleanly.

GitHub's own behavior seems correct, and we should try to match it, I think?

- [ ] a
  -

- [ ] b
  =

- [ ] c
  x

• [ ] a

• [ ] b

• c
  x

Alternatively, we could try to match what pandoc does, and just put the task marker outside the header.

Both answers seem defensible to me. Just, please don't silently eat the [ ].

Thanks both, agreed the marker shouldn't vanish. I pushed a revision that cancels the task-list interpretation and keeps the marker's own [ ]/[x] source bytes as literal text:

- [ ] a          ->  <h2>[ ] a</h2>
  -
- [x] a {#id}    ->  <h2 id="id">[x] a</h2>
  -

It reuses the marker node's existing span (only growing it across the separating whitespace) rather than synthesizing a new string, so it's the "cancel completely" variant rather than a reinsertion. A following backslash escape isn't pulled in (- [ ] \*a\* over a rule still gives <h2>[ ] *a*</h2>), and normal task lists are untouched.

One edge worth flagging: since the brackets become a single literal text node, they no longer take part in reference-link resolution, so - [x] foo over a rule with a matching [x]: definition would render [x] literally rather than as a shortcut link ([ ] is always safe, since a whitespace label can't match a definition). If you'd rather match pandoc and put the marker outside the heading instead, I'm happy to switch, both read fine to me.

I'm not picky about which implementation we follow, as long as we actually do it. Since GitHub resolves link defs, we should too if we're following their lead.

- [x] h1
  =

[x]: https://example.com

• x h1

Since GitHub resolves link defs

Ah, about that...

Even if you have a perfectly normal checked task, it will prioritize the link because this is done in postprocessing.

- [x] abc

[x]: https://example.com

• x abc

But yes, if we reject the[x] as a tasklist marker, I think it should be eligible to be parsed as a link.

Makes sense, thanks. So the agreed behavior: reject [x] as a task marker, but let those bytes go through normal inline parsing, so a matching [x]: definition still resolves as a link (matching GitHub's postprocessing order).

My current commit converts the marker to a single literal-text node, which is inert. To get link-eligibility I'll re-scan the marker's span as inline content instead, so it yields the usual MaybeLinkOpen / text / MaybeLinkClose nodes and the second pass resolves it. Then - [x] foo over a setext rule with a [x]: url definition renders the heading with a link, while - [ ] a stays literal (a whitespace-only label can't match a definition).

Sound right? If so I'll push that version.

Pushed that version. When the task-list interpretation is canceled (item content is a setext heading), [x]/[ ] now split back into the normal MaybeLinkOpen / text / MaybeLinkClose inline nodes instead of a single inert text node, so a matching [x]: url definition resolves as a link (matching GitHub's postprocessing). Added a regression example covering it. A whitespace-only label like [ ] can't match a definition, so it still renders literally. Full suite + fmt + clippy clean; the existing setext cases are unchanged when no definition is present.

I found another problem with this PR. It turns out, you can reproduce the same bug using tables, not just headings.

- [x] | one | two | three    |
  |-----|-----|-------|------|
  | one | two | three | four |

GitHub:

• [x]	one	two	three
  one	two	three	four

pulldown-cmark:

$ cargo run --release -- --enable-tables --enable-tasklists
    Finished `release` profile [optimized] target(s) in 0.07s
     Running `target/release/pulldown-cmark --enable-tables --enable-tasklists`
- [x] | one | two | three
  |-----|-----|-------
  | one | two | three
<ul>
<li><table><thead><tr><th>one</th><th>two</th><th>three</th></tr></thead><tbody>
<tr><td>one</td><td>two</td><td>three</td></tr>
</tbody></table>
</li>
</ul>

And definition lists have a slightly different, but still basically similar, bug:

$ cargo run --release -- --enable-definition-list --enable-tasklists
    Finished `release` profile [optimized] target(s) in 0.07s
     Running `target/release/pulldown-cmark --enable-tables --enable-tasklists`
- [x] a
  : b
<ul>
<li>
<dl>
<dt><input disabled="" type="checkbox" checked=""/>
a</dt>
<dd>b</dd>
</dl>
</li>
</ul>

Both reproduce, both fixed.

Tables were the more interesting one. The marker's bytes are ordinary row content, so I moved the header-row scan back to the marker's start instead of the paragraph's. That means the marker counts as a leading cell, which is what makes your example agree with GitHub: four header cells ([x], one, two, three) against the four-column delimiter row, rather than three-vs-four and no table at all.

Worth flagging the flip side, since it's a behavior change beyond the bug: - [x] | a | b | over |---|---| used to be a two-column table and is now a plain task list item, because the header is three cells now. GitHub does the same, and there's a spec example pinning it.

Definition lists just reuse the setext cancellation, so - [x] a / : b gives <dt>[x] a</dt>, and a matching [x]: definition still resolves to a link there too.

One thing I noticed while doing this: cancelling left the marker's bytes outside the heading's own range, so into_offset_iter reported text events starting before the node containing them. Fixed for all three paths and added a test, since nothing asserted it.

Full suite + fmt + clippy clean. I also brute-forced ~540k generated bullet/marker/pipe/setext/deflist combinations for panics and bad ranges, and confirmed the structural table decision is now identical with ENABLE_TASKLISTS on and off, which it wasn't before.

Closed in favor of #1135.