Re: [csswg-drafts] [css-scroll-snap-1] Snap area trapping behavior of non scrollable elements (#4496)

I agree with the intent of this resolution, but would like to discuss the precise way to spec it a little further, due to a few principles I think ought to be true:
* the css-contain spec should not need to be (normatively) revised every time another spec adds a new feature. (Adding notes to highlight the effects of 
* the css-contain spec should state the requirements in a way that is generic enough to be always true. It's goal is to create a mode where correctness can be guaranteed, even in some otherwise necessary steps are skipped for the sake of optimizations. If we find classes of effects that ought to be affected by containment, that's worth revising css-contain for, but the revision should capture the whole class.
* other specs which introduce new features ought to clarify how these features interact with containment when that isn't obvious.

So, what I think we should do here is:
* in the contain spec, add an additional effect to layout containment about scrolling:
    > * The content, layout, or scroll position of an element with scroll containment or any of its descendants must not affect the scroll position of any box that is not a descendant of containing box for layout containment.

    On top of that, we could add a note in css-contain pointing readers to css-scroll-snap for details, for convenience.
    > Note: See "capturing snap positions" in [[css-scroll-snap]] for a specific mechanism affected by this requirement.
* in the scroll-snap spec, be specific about the implication for snapping:
    > A box captures snap positions if it is a scroll container<ins>,</ins> or has a value other than none for scroll-snap-type<ins>, or if it has layout containment</ins>. 

This more generic phrasing in the css-contain spec would not only apply to scroll snap, but also would cover potential future features with similar effects. Let's say we later introduce scroll-locking, where you can somehow declare that the scroll position of one box must continuously be adjusted to track the scroll position of another one, so that when you scroll one, the other follows. The generic phrasing I'm proposing above for css-contain would catch that, while phrasing that is specific to scroll snapping would not.

This would be similar to the second effect of layout containment, about fragmentainers with layout containment trapping the rest fragmented flow. It is stated in generic terms, and leaves it up to spec which would run into that possibility, like css-regions would, to clarify what it would mean for them.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-618158077 using your GitHub account

Received on Thursday, 23 April 2020 03:39:14 UTC