Skip to content

width/height silently no-op on <List>,<Paragraph>, <Line>, <CurveLine>, <Table> #74

Description

@Cadons

Summary

width/height are documented as common attributes across nodes, but on five tags they parse without error and then simply do nothing: <List>, <Paragraph>, <Line>, <CurveLine>, <Table>. An author setting <Table width="400"> expecting it to constrain the table's layout gets no error and no effect — the table sizes itself exactly as if the attribute were never written.

Root cause

apply_common_attributes() in docraft/src/docraft/loom/craft/docraft_loom_tree_builder.cc:218-231 gates the setter call on a compile-time trait check:

if constexpr (requires(NodeT& n, float v) { n.set_width(v); })
{
    if (common.width) { node.set_width(*common.width); }
}

(same pattern for set_height, lines ~225-230)

width/height are correctly parsed into common.width/common.height (docraft/src/docraft/craft/parser/docraft_parser_helpers.cc:153-160), but the if constexpr branch is compiled away entirely for any node type that doesn't declare a matching set_width/set_height — and none of DocraftLoomList, DocraftLoomParagraph, DocraftLoomLine, DocraftLoomCurveLine, DocraftLoomTable (nor the shared DocraftLoomNode base) declare one. DocraftLoomRectangle/DocraftLoomText, by contrast, do (e.g. docraft_loom_rectangle.h:29,32) and work correctly.

This matches gotcha #7 in .claude/skills/craft-language/references/gotchas.md.

Suggested improvement

Pick one, consistently, for all five tags:

  1. Wire up explicit sizing where it's meaningful (e.g. an explicit <Table width="..."> capping/distributing column widths, <List>/<Paragraph> constraining wrap width) — the better fix where it's a legitimate, requested capability.
  2. Or reject the attribute at parse time for tags where explicit width/height genuinely doesn't make sense in the current layout model, instead of accepting and silently discarding it — consistent with how this codebase already turns other unsupported-combination cases (e.g. malformed <Cell> content) into a clean parse-time error rather than a silent no-op.

Whichever is chosen, it should probably be resolved per-tag rather than applying the same answer to all five, since e.g. <Line>'s "height" is a different kind of concept than <Table>'s.

Source pointers

  • docraft/src/docraft/loom/craft/docraft_loom_tree_builder.cc:218-231 (apply_common_attributes())
  • docraft/src/docraft/craft/parser/docraft_parser_helpers.cc:153-160 (attribute parsing)
  • docraft/include/docraft/loom/nodes/docraft_loom_rectangle.h:29,32 (a node type that does wire it correctly, for reference)
  • .claude/skills/craft-language/references/gotchas.md, item 7

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions