W3C home > Mailing lists > Public > www-style@w3.org > May 2020

[CSSWG] Minutes Virtual F2F 2020-05-06 Part II: Styling Gaps/Gutters, Scroll Snap [css-grid] [css-flexbox] [css-multicol] [css-scroll-snap]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:47:53 -0400
Message-ID: <CADhPm3s9th+LVPKCE8NQMRiwHFZj=+oB3dooWXcvK7QfmRohjg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 15 May 2020 22:48:41 UTC