- 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