scroll-padding is set on the scroll container and acts like an "inner offset" for its scrollport — it pushes the snap/scroll target away from the container's edge. scroll-margin is set on child elements and pushes that specific element away from the scrollport edge. Think of scroll-padding as "container-level padding" and scroll-margin as "element-level margin" — both affect scroll alignment, but at different levels.

Use scroll-padding when you have a fixed header or sticky element that obscures the top of the scrollport — it ensures all scroll targets clear that obstruction globally. Use scroll-margin when only specific elements need extra breathing room (e.g., a section with a special callout that shouldn't touch the viewport edge). They can be combined for layered offset control.

Yes! Both scroll-padding and scroll-margin are fully respected by element.scrollIntoView() and anchor-link navigation (URL hash). The browser automatically factors them into the final scroll position. This demo uses scrollIntoView({ behavior: 'smooth', block: 'start' }) under the hood — try adjusting the sliders and clicking the nav pills to see it in action.

Absolutely. Each child element can have its own scroll-margin-top value. This is one key advantage over scroll-padding: you can fine-tune individual targets. For example, a hero section might need scroll-margin-top: 80px while a footer anchor only needs scroll-margin-top: 20px.

Both properties are supported in all modern browsers (Chrome 69+, Firefox 68+, Safari 14.5+, Edge 79+). They are part of the CSS Scroll Snap Module Level 1 specification. For older browsers, they gracefully degrade — the scroll still works, just without the offset.

Yes. scroll-padding-inline-start, scroll-padding-block-end, and other logical property variants are supported. These are especially useful for internationalization (RTL layouts) and when working with writing modes. The same applies to scroll-margin-inline-* and scroll-margin-block-*.