starred/opentui

Fork 0

mirror of https://github.com/anomalyco/opentui.git synced 2026-04-25 13:06:00 +03:00

[GH-ISSUE #87] [Proposal] Anchor constrained positioning #19

New issue

Open

opened 2026-03-02 23:43:54 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 23:43:54 +03:00

Owner

Originally created by @Adictya on GitHub (Aug 26, 2025).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/87

Originally assigned to: @Adictya on GitHub.

Proposal

Add support for minute subset of css anchor-positioning like api to enable positioning elements relative to non parent renderables.

Similar behavior can already be achieved by directly referencing the renderables and doing some calculations in user space, this would just be a neater way of doing the same.

The api could look something like this for phase 1 atleast:

export interface LayoutOptions {
...
'positionAnchor': Renderable
'top/left/bottom/right': ...existing | 'anchor-top' | 'anchor-bottom' | 'anchor-left' | 'anchor-right'
'justifySelf': ...existing | 'anchor-center' 
}

Implementation thoughts

Anchored elements would be excluded from the layout
Position anchored renderables after layout calculations with the updated anchor element position
Children of anchored renderables would be relatively positioned.

All in all shouldn't be too hard to implement?

Originally created by @Adictya on GitHub (Aug 26, 2025). Original GitHub issue: https://github.com/anomalyco/opentui/issues/87 Originally assigned to: @Adictya on GitHub. ## Proposal Add support for minute subset of [css anchor-positioning](https://developer.chrome.com/blog/anchor-positioning-api) like api to enable positioning elements relative to non parent renderables. Similar behavior can already be achieved by directly referencing the renderables and doing some calculations in user space, this would just be a neater way of doing the same. The api could look something like this for phase 1 atleast: ```ts export interface LayoutOptions { ... 'positionAnchor': Renderable 'top/left/bottom/right': ...existing | 'anchor-top' | 'anchor-bottom' | 'anchor-left' | 'anchor-right' 'justifySelf': ...existing | 'anchor-center' } ``` ## Implementation thoughts 1. Anchored elements would be excluded from the layout 2. Position anchored renderables after layout calculations with the updated anchor element position 3. Children of anchored renderables would be relatively positioned. All in all shouldn't be too hard to implement?

kerem added the

feature

core

labels

2026-03-02 23:43:54 +03:00

kerem commented

2026-03-02 23:43:55 +03:00

Author

Owner

@kommander commented on GitHub (Aug 26, 2025):

Good proposal!

You cannot exclude anchored elements from the layout, as then their own layout including the children would not be calculated anymore, unless you call calculate layout from the anchored element for the subtree.

I think it would be simpler to force position the anchored element absolute and in the x/y getters use the anchor.x/y as relation/anchor instead of parent.x/y?

@kommander commented on GitHub (Aug 26, 2025): Good proposal! You cannot exclude anchored elements from the layout, as then their own layout including the children would not be calculated anymore, unless you call calculate layout from the anchored element for the subtree. I think it would be simpler to force position the anchored element absolute and in the x/y getters use the anchor.x/y as relation/anchor instead of parent.x/y?

kerem commented

2026-03-02 23:43:55 +03:00

Author

Owner

@Adictya commented on GitHub (Aug 26, 2025):

I think it would be simpler to force position the anchored element absolute and in the x/y getters use the anchor.x/y as relation/anchor instead of parent.x/y?

Yeah makes sense, much simpler

@Adictya commented on GitHub (Aug 26, 2025): > I think it would be simpler to force position the anchored element absolute and in the x/y getters use the anchor.x/y as relation/anchor instead of parent.x/y? Yeah makes sense, much simpler

kerem commented

2026-03-02 23:43:55 +03:00

Author

Owner

@kommander commented on GitHub (Aug 26, 2025):

We would have to make sure that you cannot anchor to a child. Also, anchoring to an element in another branch makes it complicated, as that branch might be rendered later and does not have updated position yet. So you are right that we have to defer rendering of anchored elements until after the anchor is rendered.

I would do that by letting the anchor know which elements use it as anchor, then stop rendering the branch when encountering an anchored element and resume in the anchor by rendering all anchored elements it has referenced.

Sounds complicated lol, it's really not.

@kommander commented on GitHub (Aug 26, 2025): We would have to make sure that you cannot anchor to a child. Also, anchoring to an element in another branch makes it complicated, as that branch might be rendered later and does not have updated position yet. So you are right that we have to defer rendering of anchored elements until after the anchor is rendered. I would do that by letting the anchor know which elements use it as anchor, then stop rendering the branch when encountering an anchored element and resume in the anchor by rendering all anchored elements it has referenced. Sounds complicated lol, it's really not.

kerem referenced this issue

2026-03-02 23:45:29 +03:00

[PR #19] [MERGED] TrackedNode does not mess with node.zIndex anymore #222

kerem referenced this issue

2026-03-14 09:13:13 +03:00

[PR #19] [MERGED] TrackedNode does not mess with node.zIndex anymore #1003