Layout

Domotion captures the laid-out box positions Chromium computed — it doesn't re-implement layout. That means anything that affects where boxes land (flex, grid, float, position, display: block / inline / inline-block / table / contents / none, the full margin / padding / sizing model, logical properties, border-collapse) is implicitly supported because the captured coordinates already reflect the resolved layout.

Floats and clears work because text wrap is captured per visual line — Chromium has already done the line-breaking around the float, and the resulting line boxes are what Domotion records. Lists work end-to-end: list-style-type markers (disc / circle / square / decimal / lower-alpha / lower-roman / etc.) are synthesized as shapes or text, list-style-image: url(...) renders as an <image> at the marker slot, list-style-position is honored, and ::marker styling (color, font-weight, font-size) flows through.

The exceptions

• position: fixed and sticky — paint order is correct, but the element renders at the captured position with no scroll-following. The SVG output is one static frame, so there's nothing for it to follow.
• overflow: scroll and auto — content is clipped to the visible region and the captured scrollTop is honored, but the native scrollbar chrome isn't yet emulated. The visible scroll region renders correctly.
• Nested stacking contexts — a child with z-index that's "trapped" inside an opacity / transform stacking context may paint above an outside sibling that should logically be on top. Sibling z-index at the same stacking level always paints in the right order.

overflow: hidden / clip / visible and overflow-clip-margin all work — children are clipped to the padding box via SVG <clipPath> when needed.