Skip to content

q2-preview: keep task-list checkbox and text on one line (bd-qif9l4cx) - #673

Merged
cscheid merged 4 commits into
mainfrom
bugfix/bd-qif9l4cx-task-checkbox-layout
Sep 10, 2026
Merged

q2-preview: keep task-list checkbox and text on one line (bd-qif9l4cx)#673
cscheid merged 4 commits into
mainfrom
bugfix/bd-qif9l4cx-task-checkbox-layout

Conversation

@cscheid

@cscheid cscheid commented Sep 10, 2026

Copy link
Copy Markdown
Member

Summary

A - [x] item in the q2-preview format rendered its checkbox alone on one line with the item text (and the bullet) on the next — seen live on quarto-hub.com on 2026-09-10. Reproduced locally in q2 preview, which shares PreviewRoot with hub-client; every task item was affected, not just nested or mixed lists.

Root cause. TaskItemBody built the <label> around <Node node={Plain}>. The registry's Block entry has been CommentBlock since Comments v1 (#441, which landed nine days after the task-list work in #407); it wraps every commentable block in a positioned <div>. That block box inside the inline <label>, after the <input>, forced the text onto its own line. The attribution wrapper and the measured edit surface are the same class of hazard, so this fix does not depend on bd-q2wqj24c (removing the CommentBlock wrapper).

Fix. Move the <label> into the head block renderer. BulletList/OrderedList provide {checked, onToggle} through a TaskItemContext around the item's head block only; Plain/Para strip the ballot-box marker and render the writer's <label><input type="checkbox"/>…</label> themselves, so every block-level wrapper stays an ancestor of the label. As in the native HTML writer, tight items render li > label and loose items li > p > label — loose (Para-leading) task items previously showed the raw glyph and had no checkbox at all (bd-tvtknbhx polish item 2).

Plan with the full diagnosis and evidence: claude-notes/plans/2026-09-10-q2-preview-task-checkbox-layout.md.

Tests (written red-first)

  • ts-packages/preview-renderer task-list integration tests: the label must hold no block element; new fixtures for the reporter's nested/mixed list, a loose list and an ordered list, with toggle coverage for each. 5 failed before the fix, 10/10 after.
  • New hub-client e2e spec hub-client/e2e/q2-preview-task-list.spec.ts (real hub + q2-preview iframe): asserts the text's first client rect sits on the checkbox's line. Passes; fails on the pre-fix renderer (toHaveCount(5) received 3).

End-to-end verification

  • q2 preview on the reported document after cargo xtask build-q2-preview-spa && cargo build --bin q2: label height 51px → 25.5px, DOM now <li><div …><label><input …>text</label></div></li>; screenshot inspected.
  • q2 preview --allow-edit: clicking a checkbox still writes [x]/[ ] back to disk, including for loose items.
  • cargo xtask verify --skip-rust-tests green (no Rust source changed).

Closes bd-qif9l4cx. Related: bd-q2wqj24c, bd-tvtknbhx.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RhBKwo1GN35y7fqzL364wB

cscheid and others added 4 commits September 10, 2026 13:09
Diagnosis + fix design for the checkbox-on-its-own-line bug in the
q2-preview format (CommentBlock's block wrapper lands inside the
task <label>). Decisions recorded after review.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhBKwo1GN35y7fqzL364wB
A `- [x] item` in the q2-preview format rendered its checkbox alone on
one line with the item text (and the bullet) on the next. TaskItemBody
built the <label> around <Node node={Plain}>, and the registry's Block
entry — CommentBlock since Comments v1 (#441), which landed after the
task-list work (#407) — wraps every commentable block in a positioned
<div>. That block box inside the inline <label>, after the <input>,
forced the text onto its own line. The attribution wrapper and the
measured edit surface are the same class of hazard.

Move the <label> into the head block renderer: BulletList/OrderedList
provide {checked, onToggle} through a TaskItemContext around the item's
head block only, and Plain/Para strip the ballot-box marker and render
the writer's <label><input type="checkbox"/>…</label> themselves. Every
block-level wrapper now stays an ancestor of the label. As in the native
writer, tight items render li > label and loose items li > p > label —
loose (Para-leading) task items previously showed the raw glyph and had
no checkbox at all (bd-tvtknbhx polish item 2).

Tests (red first):
- preview-renderer task-list integration tests: the label must hold no
  block element; new fixtures for the reporter's nested/mixed list, a
  loose list and an ordered list, with toggle coverage for each. Five
  failed before the fix, 10/10 after.
- hub-client e2e spec q2-preview-task-list.spec.ts: real hub + q2-preview
  iframe; asserts the text's first client rect sits on the checkbox's
  line. Passes; fails on the pre-fix renderer.

Verified end to end through `q2 preview` after rebuilding the SPA (label
height 51px -> 25.5px on the reporter's document; --allow-edit toggle
writes [x] back to disk) and `cargo xtask verify --skip-rust-tests`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhBKwo1GN35y7fqzL364wB
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhBKwo1GN35y7fqzL364wB
@posit-snyk-bot

posit-snyk-bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@cscheid
cscheid merged commit b9bcb9c into main Sep 10, 2026
10 checks passed
@cscheid
cscheid deleted the bugfix/bd-qif9l4cx-task-checkbox-layout branch September 10, 2026 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants