Repository navigation
CSS: apply position: relative with top / left / right / bottom offsets #34
Description
Current behaviour
position is stored in ComputedStyle but nothing in the render path reads it, so position: relative with top / left / right / bottom does not move the element. (absolute / fixed are out of scope for the single-RenderObject design; see doc/LIMITATIONS.md.)
Expected
A position: relative element is laid out in normal flow, then painted (and hit-tested, and selected) shifted by its offsets, without affecting the layout of its siblings.
Notes
- Docs already say "not applied" (
doc/CSS_PROPERTIES_MATRIX.md,doc/SUPPORTED_HTML.md,doc/LIMITATIONS.md);test/docs_matrix_sync_test.dartpins the row as not ✅. Flip them together with the implementation. - Selection and hit-testing read
fragment.offset, so a paint-only shift would draw text where hit-testing and selection handles do not find it. Either apply the shift to fragment offsets after layout, or shift paint, hit-test and selection together. - Inline
relativespans (e.g.sup-style tweaks) and blockrelativecontainers behave differently; decide the scope first. - Add a pixel or fragment-offset test, not just a no-exception test.
Reacted by Viet, Nguyen Tuan
Activity
vietnguyentuan2019 commentedon Nov 4, 2026
Looked into this. A correction first:
positionandtop/left/right/bottomaren't parsed today, the field always staysstatic.Shifting
fragment.offsetalone isn't enough. Hit-testing, selection and paint culling all find the line byyfirst, so text moved vertically into another line's band couldn't be clicked, and might not be painted.Plan: cover both block and inline
relative, applied as a post-layout pass that leaves sibling layout and box height unchanged, with hit-testing, selection and culling updated to match. Flex and grid items useTransform.translate.Known limits for this round:
%offsets aren't supported.vietnguyentuan2019 commentedon Nov 5, 2026
Correction to my earlier comment: I said moved content is clipped to the render box, so untrusted HTML can't paint over the host app. Review of PR #36 showed that wasn't true yet. Flex and grid items and moved block backgrounds could still escape.
That's now fixed in the PR and covered by pixel tests. Moved content paints in its own clipped pass above normal content, so other content isn't cropped. This also removes a limit I listed: a relative element's background now paints above normal text.