- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:47:53 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Grid/Flexbox/Multicol --------------------- - There's definite interest in being able to style gaps/gutters (Issue #2748) but there are complexities due to spanning items and row/column intersections. Trying to draft up a proposal won't work in this virtual format, so deferring to GitHub and/or an in-person meeting. Scroll Snap ----------- - RESOLVED: Revert the previous resolution about layout containment trapping snapping points (Issue #4496: Snap area trapping behavior of non scrollable elements) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-three-time-slot-3a Grid/Flexbox/Multicol ===================== Scribe: fremy Styling Gaps/Gutters -------------------- github: https://github.com/w3c/csswg-drafts/issues/2748 fantasai: This seems to be a feature that people really want to have fantasai: and we don't really offer any affordance for that fantasai: One major issue, is what happens in a grid when an item spans across a gap fantasai: Should the gap break over this item or not? fantasai: But I am concerned that discussing this kind of stylistic feature should best be done in a real f2f because we need to whiteboard. astearns: Any other opinion? rachelandrew: More than rows and columns rachelandrew: I have had many requests for borders around grid areas iank: Also, we get into issues similar to tables iank: What happens at intersections, when the borders are not the same astearns: I think we should not mix those two things up astearns: Styling gaps sounds easier astearns: Styling areas is more complex, and might need more work astearns: Could be done later jensimmons: I agree with astearns here jensimmons: and it's a feature that makes a lot of sense to do from a design point of view jensimmons: and getting half of what authors want is still great progress rachelandrew: The issue about spanning also applies to multi-columns as well rachelandrew: because we can also span things in multi-columns rachelandrew: so authors will want to "exclude" areas from the lines rachelandrew: So it's not clear to me that ignoring areas entirely is fully possible/desirable florian: If you have an area going through, don't you always want to break the rule? iank: Not always, the thing in the area can have a transparency background effect miriam: What does happen in multicol now? rachelandrew/florian: It's interrupted astearns: Based on all these comments, I think it would indeed be nice to have a whiteboard astearns: So I propose to move back to the github issue as a proxy-whiteboard astearns: Any other comment? Scroll Snap =========== Snap area trapping behavior of non scrollable elements ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4496 florian: A while back we resolve the layout containment traps snapping florian: but it's not clear to me as to what spec should define this behavior florian: I don't think that css-contain should contain all the rules in details for all the other specs florian: I would rather this be added to the snapping spec, because this is where you are most likely to need this florian: but in this particular case florian: Scroll snapping discovered a whole class of things we forgot to mention florian: so I would like to suggest an edit <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 the containing box for layout containment. florian: (just typed it above) florian: An example would be scroll synchronization or scroll locking florian: like if you scroll one, the other follows florian: but if you contain the layout, this probably shouldn't work florian: I think this should be specified further in scroll-snap florian: because this slows down the progress of containment florian: and I would rather not dbaron: Two questions dbaron: You wrote "scroll containment" dbaron: Did you mean to write that? dbaron: Is that a new type of containment? florian: No, its wrong. florian: I meant layout containment, good catch dbaron: Second question then 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 dbaron: it shouldn't work dbaron: but I don't see why we want that florian: I didn't mean to say that florian: I should fix the text if that incorrectly conveys that meaning fantasai: I would also argue that scroll is not layout TabAtkins: But you need some layout to know what is scrollable florian: But you don't need the layout for the effect florian: I agree it's not strictly layout florian: but you can't delay recomputing a subtree if you have these interactions astearns: So if I understand your proposed text would add further requirements on layout containment astearns: If we don't that means that scroll effects would be have side-effects of forcing layout florian: Yes, but we can remove from scroll-snapping all cases we don't like florian: That said, of course, if you focus from js etc then you will have to do layout anyway florian: and that seems reasonable florian: This is "contain" property, not "isolate" florian: I think we mostly want to limit interactions, not especially outside>inside interactions TabAtkins: No TabAtkins: The containment is mostly from the layout perspective, the rest of the page is still allowed to affect fantasai: I think scroll and layout in general are two different things fantasai: maybe we should have a "scroll" containment not bundled in layout containment fantasai: This might need a bit more thought florian: Implementors, what's your opinion? florian: Is scrolling more like paint, or more like layout? fantasai: Well, if you have a widget with 10 elements in it fantasai: and I contain their layout fantasai: for performance reasons fantasai: I might still want snapping to work florian: If you have mandatory scroll snapping florian: none-of-which has scroll-snap-position florian: but the last one, has one florian: but is off-page florian: If the scroll-snapping is required to work, then you need the layout of all the children to know where to snap fantasai: But if you target it, you still do need to know right? florian: Yes? florian: I guess it maybe doesn't break if the elements inside don't have snap points inside TabAtkins: I think this is a particular case TabAtkins: but now that I think about it TabAtkins: but maybe that's not the most common case, maybe we can make an exception florian: Then we need a test astearns: Are you saying we should undo the previous resolution tab? TabAtkins: Yes <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. astearns: heycam felt it was weird anyway last time astearns: So, ok, let's resolve to revert that resolution? astearns: Any objection? RESOLVED: Revert the previous resolution about layout containment trapping snapping points cbiesinger: which resolution are we reverting? astearns: [restates] florian: So we reverted and resolved in the opposite direction right? astearns: Yes astearns: Also, no engine did trap snap before astearns: So we revert back to what implementations do right now, if I understand
Received on Friday, 15 May 2020 22:48:40 UTC