Skip to content

An overlay can be placed at a viewport coordinate (RFC-0017 §Positioning) - #243

Open
Briany4717 wants to merge 1 commit into
feat/overlay-match-widthfrom
feat/overlay-absolute-at
Open

An overlay can be placed at a viewport coordinate (RFC-0017 §Positioning)#243
Briany4717 wants to merge 1 commit into
feat/overlay-match-widthfrom
feat/overlay-absolute-at

Conversation

@Briany4717

Copy link
Copy Markdown
Owner

Stacked on #242. This diff is the top commit only.

The last unimplemented row of RFC-0017's positioning table. Overlay could put a child in the centre, pin it to an edge, or (since RFC-0036) hang it off another element. What it could not do is the simplest thing on the list: put it at (300, 24).

Why at: rather than anchor_to: (x, y)

anchor_to names an element and is compile-checked against the as tags declared before it. A property whose type silently decides which of two unrelated behaviours you get is a property people get wrong, and the compile check would have had nothing to say about half of its own inputs.

Viewport-space, unconditionally

It does not flip and it does not clamp. A coordinate off the window leaves the panel off the window, because pulling it back would make a wrong number look like a layout decision — the harder bug to find. Writing at: and anchor_to: together is refused rather than settled by a precedence rule nobody would remember.

One note on the tests

The "measured from the viewport's origin" test renders the same source at two window sizes and asserts the actual coordinate. Without that second half it passes with the feature switched off, because a panel left where the wrapper put it is viewport-invariant too. The other two were watched failing with the placement branch disabled.

Example

crates/byard-cli/examples/anchored_overlay gains a badge placed with at:, beside the three anchored panels, so "follows an element" and "sits at a coordinate" are next to each other.

Gates

cargo fmt --all --check, cargo clippy --locked --workspace --all-targets -- -D warnings, cargo test --locked --workspace (97 suites, 0 failures), cargo run -p byard-cli -- check crates/byard-cli/examples/anchored_overlay.

…sitioning)

The last unimplemented row of RFC-0017's positioning table. `Overlay` could
put a child in the centre, or pin it to an edge, or (since RFC-0036) hang it
off another element. What it could not do is the simplest thing on the list:
put it at (300, 24).

Spelled `at: (x, y)` rather than by letting `anchor_to:` take a pair.
`anchor_to` names an element and is compile-checked against the `as` tags
declared before it; a property whose *type* silently decides which of two
unrelated behaviours you get is a property people get wrong, and the compile
check would have had nothing to say about half of its own inputs.

Viewport-space, unconditionally. It does not flip and it does not clamp: a
coordinate off the window leaves the panel off the window, because pulling it
back would make a wrong number look like a layout decision, which is the
harder bug to find. Writing `at:` and `anchor_to:` together is refused rather
than settled by a precedence rule nobody would remember.

The test that says "the offset is measured from the viewport's origin" renders
the same source at two window sizes, and also asserts the actual coordinate:
without that second half it passes with the feature switched off, because a
panel left where the wrapper put it is viewport-invariant too.
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.

1 participant