[cssom-view][css-scroll-snap] State scrollport and target scroll-snap properties effects in cssom for SIV and jump links

[jonjohnjohnson]

https://drafts.csswg.org/cssom-view-1/

Though I find disparate mentions of scroll-padding/scroll-margin values being used in scroll position decision making for scrollIntoView and general "jump links", I see implementations of css-scroll-snap not going so far as enabling the properties effects outside of snapports.

• https://drafts.csswg.org/css-scroll-snap-1/#change-2017-scroll-margin
• #1707 - Consider more specific guidance for scroll-into-view
• #1708 - Define interaction of ScrollIntoView options and scroll-snap
• #1954 - Should scroll-snap-margin lose it's snap?

In hopes that we can get rid of hacks like...

.target-sentinel-for-reference     { position: relative; top: -3rem; }
.target-sentinel-for-section-title { position: relative; top: -6rem; }

In relation to articles like...

• css-tricks - Hash Tag Links That Don’t Headbutt The Browser Window
• nicolasgallagher.com - Jump links and viewport positioning.

I think these properties should be referenced/highlighted in cssom-view?

Edited - Blink has now enabled these properties for use outside of snapports, though only in the block (or maybe just vertical) axis.

[Malvoz]

I resort to these type of hacks all the time, but alot of authors don't, and you end up scrolling past a heading usually on pages with a position fixed header which can be pretty awkward especially if you clicked a url fragment so you have to scroll up again just to read the heading.

[jonjohnjohnson]

@fantasai Again, if you think that #3721 makes it now clear enough in css-scroll-snap (regardless of cssom-view), for vendors implementing that spec, to enable these properties effects outside of snapports, then this issue can be closed. I just want it clear so that there is no confusion when filing bugs against the different vendors for these effects.