- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 May 2020 14:37:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `scroll-snap`. <details><summary>The full IRC log of that discussion</summary> <fremy> Topic: scroll-snap<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4496<br> <fremy> florian: a while back we resolve the layout containment traps snapping<br> <fremy> florian: but it's not clear to me as to what spec should define this behavior<br> <fremy> florian: I don't think that css-contain should contain all the rules in details for all the other specs<br> <fremy> florian: I would rather this be added to the snapping spec, because this is where you are most likely to need this<br> <fremy> florian: but in this particular case<br> <fremy> florian: scroll snapping discovered a whole class of things we forgot to mention<br> <florian> 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.<br> <fremy> florian: so I would like to suggest an edit<br> <fremy> florian: (just typed it above)<br> <fremy> florian: an example would be scroll synchronization or scroll locking<br> <astearns> s/of containing/of the containing/<br> <astearns> (I think)<br> <fremy> florian: like if you scroll one, the other follows<br> <fremy> florian: but if you contain the layout, this probably shouldn't work<br> <fremy> florian: i think this should be specified further in scroll-snap<br> <fremy> florian: because this slows down the progress of containment<br> <fremy> florian: and I would rather not<br> <astearns> ack dbaron<br> <fremy> dbaron: two contains<br> <fremy> dbaron: you wrote "scroll containment"<br> <fremy> dbaron: did you mean to write that?<br> <dbaron> s/contains/questions/<br> <fremy> dbaron: is that a new type of containment?<br> <fremy> florian: no, its wrong.<br> <fremy> florian: I meant layout containment, good catch<br> <fremy> dbaron: second question then<br> <fremy> dbaron: the text seems to imply that if you use the #hash part of the url to target an element, then if it is inside something that has layout containment<br> <fremy> dbaron: it shouldn't work<br> <fremy> dbaron: but I don't see why<br> <fremy> florian: I didn't mean to say that<br> <fremy> florian: I should fix the text if that incorrectly conveys that meaning<br> <fremy> fantasai: I would also argue that scroll is not layout<br> <fremy> TabAtkins: but you need some layout to know what is scrollable<br> <fremy> florian: but you don't need the layout for the effect<br> <fremy> florian: I agree it's not strictly layout<br> <fremy> florian: but you can't delay recomputing a subtree if you have these interactions<br> <fremy> astearns: so if I understand your proposed text would add further requirements on layout containment<br> <fremy> astearns: if we don't that means that scroll effects would be have side-effects of forcing layout<br> <fremy> florian: yes, but we can remove from scroll-snapping all cases we don't like<br> <fremy> florian: that said, of course, if you focus from js etc then you will have to do layout anyway<br> <fremy> florian: and that seems reasonable<br> <fremy> florian: this is "contain" property, not "isolate"<br> <fremy> florian: I think we mostly want to limit interactions, not especially outside>inside interactions<br> <fremy> TabAtkins: no<br> <fremy> TabAtkins: the containment is mostly from the layout perspective, the rest of the page is still allowed to affect<br> <fremy> fantasai: I think scroll and layout in general are two different things<br> <fremy> fantasai: maybe we should have a "scroll" containment not bundled in layout containment<br> <fremy> fantasai: this might need a bit more thought<br> <fremy> florian: implementors, what's your opinion?<br> <fremy> florian: is scrolling more like paint, or more like layout?<br> <fremy> fantasai: well, if you have a widget with 10 elements in it<br> <fremy> fantasai: and I contain their layout<br> <fremy> fantasai: for perf reasons<br> <fremy> fantasai: but I might still want snapping to work<br> <fremy> florian: if you have mandatory scroll snapping<br> <fremy> florian: none-of-which has scroll-snap-position<br> <fremy> florian: but the last one, has one<br> <fremy> florian: but is off-page<br> <fremy> florian: if the scroll-snapping is required to work, then you need the layout of all the children to know where to snap<br> <fremy> fantasai: but if you target it, you still do right?<br> <fremy> florian: yes?<br> <fremy> florian: I guess it maybe doesn't break if the elements inside don't have snap points inside<br> <fremy> TabAtkins: I think this is a particular case<br> <fremy> TabAtkins: but now that I think about it<br> <fremy> TabAtkins: but maybe that's not the most common case, maybe we can make an exception<br> <fremy> florian: then we need a test<br> <fremy> astearns: are you saying we should undo the previous resolution tab?<br> <fremy> TabAtkins: yes<br> <fremy> astearns: heycam felt it was weird anyway last time<br> <fremy> astearns: so, ok, let's resolve to revert that resolution?<br> <fremy> astearns: any objection?<br> <TabAtkins> Except for the case Florian brought up (of an off-screen element being the only snap point in a mandatory container), you only need to care about snaps when the element is on-screen (and you're doing layout anyway), so unless an implementor has a good reason why layout containment trapping snaps would be good for optimization, I think we should *not* trap snaps from layout containment.<br> <fremy> astearns: RESOLVED: revert the previous resolution about layout containment trapping snapping points<br> <fremy> ???: which resolution are we reverting?<br> <fremy> astearns: (restates_<br> <cbiesinger> s/???/cbiesinger/<br> <fremy> cbiesinger: ok<br> <fremy> florian: so we reverted and resolved in the opposite direction right?<br> <fremy> astearns: yes<br> <fremy> astearns: also, no engine did trap snap before<br> <fremy> astearns: so we revert back to what implementations do right now, if I understand<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-624687682 using your GitHub account
Received on Wednesday, 6 May 2020 14:37:17 UTC