Is your feature request related to a problem?
A floating element can choose where it attaches, but not where it attaches on its parent. The floating.attachTo: PARENT path always anchors to the parent's top-left corner, so a width:5 parent's float that asks to sit at the parent's right edge should land at dot.x = parent.x(0) + parent.width(5) = 5 but lands at 0. Underneath, we pack zIndex directly over the parent-corner slot and never write the z-index bits, so floating.zIndex: 5 actually sets the parent corner and the requested z-index is dropped.
Describe the solution you'd like
Make the parent corner first-class via a structured attachPoints.{element, parent} (exact names TBD), each one of Clay's 9 attach points; the element corner anchors onto the chosen parent corner:
open("dot", {
floating: {
attachTo: ATTACH_TO_PARENT,
attachPoints: {
element: 0,
parent: 6,
}, // element LEFT_TOP onto parent RIGHT_TOP
},
});The 9 attach points form a 3×3 grid around the parent, mirroring CSS anchor positioning's position-area. C already decodes both corners and z-index, so the fix is JS-side: pack element into bits 8-15, parent into 16-23, and move zIndex to 24-31. The number form keeps working as the element corner with parent defaulting to LEFT_TOP.
Describe alternatives you've considered
Compute the offset yourself—read the parent's info bounds from a prior render and set floating.x to parent.width. That needs a two-pass render, breaks on resize, can't express vertical anchors, and leaves zIndex unusable.
Additional context
Failing test case on nm/repro/floating-attach (test · diff); both cases report dot.x = 0 today. The change likely lives in ops.ts:168 (pack mis-slots attachPoints/zIndex); src/clayterm.c:546 already reads parent from bits 16-23 and zIndex from 24-31.
Is your feature request related to a problem?
A floating element can choose where it attaches, but not where it attaches on its parent. The
floating.attachTo: PARENTpath always anchors to the parent's top-left corner, so awidth:5parent's float that asks to sit at the parent's right edge should land atdot.x = parent.x(0) + parent.width(5) = 5but lands at0. Underneath, we packzIndexdirectly over the parent-corner slot and never write the z-index bits, sofloating.zIndex: 5actually sets the parent corner and the requested z-index is dropped.Describe the solution you'd like
Make the parent corner first-class via a structured
attachPoints.{element, parent}(exact names TBD), each one of Clay's 9 attach points; the element corner anchors onto the chosen parent corner:The 9 attach points form a 3×3 grid around the parent, mirroring CSS anchor positioning's
position-area. C already decodes both corners and z-index, so the fix is JS-side: packelementinto bits 8-15,parentinto 16-23, and movezIndexto 24-31. Thenumberform keeps working as the element corner with parent defaulting toLEFT_TOP.Describe alternatives you've considered
Compute the offset yourself—read the parent's
infobounds from a prior render and setfloating.xtoparent.width. That needs a two-pass render, breaks on resize, can't express vertical anchors, and leaveszIndexunusable.Additional context
Failing test case on
nm/repro/floating-attach(test · diff); both cases reportdot.x = 0today. The change likely lives inops.ts:168(packmis-slotsattachPoints/zIndex);src/clayterm.c:546already readsparentfrom bits 16-23 andzIndexfrom 24-31.