Conversation
commit: |
b2c1856 to
2d44ee2
Compare
4802219 to
e030433
Compare
Introduces specs/scroll-spec.md (v0.2) with caller-owned scroll model.
Clip API changes from { horizontal, vertical } to { x?, y? } with
numeric offsets. Adds scrollDelta on ElementInfo for wheel delta
reporting. Adds RenderOptions.event for input event integration.
Includes scroll demo with ~10k lines of lorem markdown.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Clayterm's renderer spec lists scroll containers as a deferred area, but the underlying layout engine (Clay) already supports clipping, child offsets, and scroll hit testing. Before fully implementing scroll support, we need agreement on the API surface.
View Rendered Spec
specs/scroll-spec.md
Approach
The
clipproperty onopen()changes from{ horizontal?, vertical? }to{ x?: number; y?: number }, where each axis is a numeric offset the caller provides each frame. The caller always owns the scroll position — there is no renderer-managed scroll state.Wheel scrolling works through a delta reporting mechanism on
RenderInfo. When aWheelEventis passed via the newRenderOptions.eventfield, the renderer performs hit testing to find the targeted scroll container and reports the resulting delta onElementInfo.scrollDelta. The caller reads the delta and applies it to their own position:scrollDeltais always defined onElementInfo—{ x: 0, y: 0 }when no wheel event targeted the element — so the caller can unconditionally read it without null checks.RenderOptions.eventaccepts a singleInputEventper render call. The renderer extracts pointer state from mouse events and scroll deltas from wheel events, deprecating the manualpointer: { x, y, down }option. When multiple events are available from a singleinput.scan()call, the caller renders once per event — the diff engine ensures unchanged frames emit zero bytes.Drag scrolling and momentum are out of scope but not precluded — they would produce additional deltas through the same
scrollDeltamechanism.TODOs and Open Questions
Sign convention for manual offsets (scroll spec Section 10.1): Should
clip: { y: 20 }mean "scroll to position 20" (positive, matching browserscrollTop) or should the caller passclip: { y: -20 }as a raw offset matching Clay'schildOffset? The spec lays out pros and cons for both — would love community input.