[CSSWG] Minutes Telecon 2016-01-20 [css-grid] [css-snappoints]

Grid Layout

  - RESOLVED: Gaps between grid tracks are suppressed (always) at
              fragmentation breaks. Add note pointing out this is
              different from margins.
  - Rossen will review the discussion on missing named lines search,
      but pending his review it looks good.

Snap Points

  - RESOLVED: Rename scroll-snap-area to scroll-snap-margin
  - RESOLVED: If previously snapped, must resnap to that same snap
              position after content changes (if possible). If not
              snapped previously and now in range of a snap
              position, must snap.
  - After the above resolution, there was concern about the second
  - RESOLVED: The second sentence of the previous resolution is not
              precise enough.

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jan/0132.html

  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Tantek Çelik
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Thierry Michel
  Simon Pieters
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Alan Stearns

  David Baron
  Dave Cramer
  Dael Jackson
  Brad Kemper
  Peter Linss
  Johannes Wilm

  Scribe: fantasai

Grid Layout

Suppressing grid gaps at fragmentation breaks

  <astearns> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-19
  fantasai: mats filed issue on suppressing grid gaps at
            fragmentation breaks.
  fantasai: We added text to spec saying that gutters (grid-gap) and
            gaps due to content alignment (e.g. align-content: space-
            evenly) are suppressed at fragmentation breaks,
  fantasai: both for forced and unforced breaks.
  fantasai: We wanted to check with WG.

  Rossen: Are we sure of this difference?
  TabAtkins, fantasai: yes
  TabAtkins: Gutters are only for separation between tracks, never
             at the start of content in the box, unlike margins
             which are used for both (hence heuristic).
  Rossen: just want to make sure this is what we want to do
  florian: I buy the rationale from TabAtkins.
  stevez: Me too.

  Rossen: Model makes sense from layout point of view, unsure about
          design point of view. I defer to people who are
          representing designers point of view.
  fantasai: If you want, I can ask more people, but seems really
            obvious to me.

  astearns: I'm not sure I understand the problem with regard to the
            background of grid being fragmented [concern from Rossen
            mentioned earlier, not minuted].
  Rossen: You'd have misaligned background.
  fantasai: You can't be relying on pixel alignment of backgrounds
            and content during fragmentation.
  fantasai: Fragmentation introduces extra space,
  fantasai: due to moving things so they don't get sliced in the
  Rossen: I guess if group doesn't have a problem with this, then

  astearns: Rossen has the one concern. Anyone else have a concern,
            or just go with what we have in the draft now?
  astearns: Should we put a note about alignment with background
  fantasai: I don't think it's needed. We don't do that with margins
  Rossen: ... with margins, backgrounds are assigned to the elements
          themselves. With grid I can imagine setting background on
          the grid container.
  Rossen: If we're ignoring this case, not a concern, want to make
          sure we're considering it.
  fantasai: Don't understand why this is different from block layout.
  TabAtkins: More likely to want to have background on the grid
             container, because stuff like sizing is set on the
  fremy: Why not clip out the background?
  fantasai: I would rather just be consistent with the way margins
            and everything else works
  Rossen: Yes, let's be consistent with everything that's not a grid
  fantasai: I don't think we can make a good argument that being
            different is better for grid. Maybe make argument that
            both options are the same. So let's be consistent.

  astearns: So, proposal is fantasai's proposal, plus a note.
  fantasai: If you really want space at the top after a forced
            break, can always add margins.

  RESOLVED: Gaps between grid tracks are suppressed (always) at
            fragmentation breaks. Add note pointing out this is
            different from margins.

Missing named lines search

  <astearns> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-26
  <astearns> email from Manuel:
  fantasai: Issue raised by Manuel on searching for a missing named
  fantasai: E.g. looking for 2nd foo line, and only one foo line; or
            looking for foo line and no foo line.
  fantasai: We specced that all implicit lines carry all names,
  fantasai: but this creates weirdness if you start in implicit
            grid, and then span to a named line.
  TabAtkins: Exact situation is a bit complicated, see email from
             Manuel's email with good examples.
  TabAtkins: If you're interested, please read into it. But we're
             trying to match Firefox and proposed Chrome behavior
  <fantasai> (have agreement on the ML)
  TabAtkins: This is an error case anyway.

  astearns: Do you think this needs wide review?
  fantasai: No, pretty sure this is the right answer. Just wanted to
            give WG a heads-up in case someone particularly wants to
            take a look.
  Rossen: I'll review and provide feedback later.
  fremy: Looks good to me.
  astearns: Okay, will give a chance for more review, seems fine
  TabAtkins: Grid's in a stage where we want to make sure the WG
             gets a heads up on all changes, since it's pretty
             stable (nearly CR).

Scroll Snap

Rename scroll-snap-area to scroll-snap-margin

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0095.html
  fantasai: We propose to rename scroll-snap-area ->
  TabAtkins: Originally scroll-snap-area specified both the box and
             the offsets.
  TabAtkins: But decided to stick with border-box always, which
             makes it exactly like 'margin'.
  TabAtkins: So like scroll-snap-padding is just like padding, this
             is just like margin, should make it match.
  Florian: What if want to add that ability later?
  TabAtkins: Can put into another property if needed.
  Florian: Sure, go ahead.

  RESOLVED: Rename scroll-snap-area to scroll-snap-margin

Re-snapping Requirements

  fantasai: Next issue is resnapping requirements.
  TabAtkins: Whenever your content changes, you're either snapped or
  TabAtkins: New snap positions get added, removed, stuff moves
             around, what happens?
  TabAtkins: Previous wording in spec wasn't great, didn't describe
             cases appropriately.
  TabAtkins: We settled on wording that if content changes, pretend
             the user had just scrolled to the position that it's
             now at, and re-snap if necessary
  TabAtkins: However, if it was previously snapped to an element,
             follow that element even if it's farther away now,
  TabAtkins: because that keeps what's in the viewport most
  TabAtkins: Both cases are must, not should.
  TabAtkins: The only difference is that if not tracking a snap
             position, proximity might not snap if there's no nearby
             snap position.

  Florian: Yes, agree with this wording. Agree must is important,
           would insist on it.
  TabAtkins: Doesn't seem like there is any rationale for following
             in mandatory case but not proximity.
  TabAtkins: That's why must in both cases.
  MaRakow: Yes, I agree...
  MaRakow: Do we want musts all the way across?
  Florian, TabAtkins: yes.
  MaRakow: I think it's an edge case considering is if you're
           snapped and that position becomes invalid.
  TabAtkins: What's invalid?
  MaRakow: If viewport shrinks so the snap position is out of bounds.
  Florian: We wanted to deal with edge case separately (agree we
           need to deal).
  MaRakow: Yes, agree, if possible to snap to the previously snapped
           position, must re-snap to that.
  MaRakow: If not possible, then can't...

  RESOLVED: If previously snapped, must resnap to that same snap
            position after content changes (if possible). If not
            snapped previously and now in range of a snap position,
            must snap.

  <MaRakow> I think we were only resolving on the first sentence --
            discussing the second sentence now

  Florian: If you're snapped to a no longer reachable mandatory snap
           point, you should re-snap to something else.
  TabAtkins: As currently written, a snap point that is outside
             scrollable area, it's still a valid snap position. You
             can still snap to it, just can't get all the way over
             to it.
  TabAtkins: I think this is sane, especially if the item is moving
             around and goes only a little out of range.
  TabAtkins: You just scroll over as far as possible.
  Florian: I agree to proximity, not sure for mandatory...
  <MaRakow> +1 Florian
  <astearns> I thought this was already-snapped, now in a state
             where that snap might not be possible
  <MaRakow> maybe we should clarify

  TabAtkins: If you have 2 snap points, 1 10px into unscrollable
             area, and one 1000px away in scrollable area, you will
             snap to the element that's 10px outside the scrollable
             area; it is the closest snap position
  Florian: From authoring pov...
  fantasai: Imagine I have, e.g. CSSWG issues list.
  fantasai: I have a bunch of small boxes, mandatory snapping.
  fantasai: If I'm snapped to a box at the bottom of the page,
            should be same behavior as if I targeted with #fragment.
  tantek: I agree with fantasai.
  Florian: For proximity makes sense, for mandatory doesn't make
  Florian: Mandatory says it's wrong to be anywhere except where I
  fantasai: If your viewport is too big, then, you will *never* be
            able to reach certain content because it won't fit

  <vollick> It sounds like this is a difference of opinion on what
            it means to be "at" at snap point. If we define snapped
            to be "at or as close as you can get" then this is
            consistent, right?

  MaRakow: 3 items to mention:
  MaRakow: I agree with Florian wrt mandatory if snap position
           becomes invalid.
  MaRakow: We already resolved not to artificially add snap point at
           start/end of scroller.
  TabAtkins: Right.
  MaRakow: [missed]
  MaRakow: The next scrolling operation.. we hit this bug a few
           times .. next scroll operation will try to hit the next
           nearest snap point, which would have a disruptive action.
  MaRakow: Would look like browser forgot to scroll to nearest snap
  MaRakow: If you touch screen and then release, it would snap
           somewhere else.
  MaRakow: e.g. have a snap point just out of reach, and one a page
  MaRakow: A user tries to scroll to see what's left,
  MaRakow: you're in an error case if out of range for snapping to.
  MaRakow: Not a great state to be in.
  MaRakow: We wouldn't want an artificial snap point at start/end.
  TabAtkins: This isn't an artificial start/end snap point.
  MaRakow: You're in a limbo state, can't naturally get to.

  [fantasai gives example of an item on the left edge, mandatory
            snapping, other snap points far enough away that you
            can't see it when snapped to any other point]
  fantasai: If you don't allow the user to snap to this item by
            scrolling all the way to the left, just because it won't
            center like it requested, then the user can't see it ever.
  Florian: I still think that when the author puts the list of
           mandatory positions, means that the content match exactly
           there... however if it's not possible for it to render
           some unreachable content, it's an author error, should
           therefore have behavior TabAtkins and fantasai are
           advocating it.
  Florian: Should warn authors not to do this.
  <MaRakow> +1 to Florian
  fantasai: I think it's an error if the item is off the screen to
            where we can't scroll it into view, never mind snapping.
  fantasai: However, I don't think it's an authoring error to have
            an item that can be seen but can't be snapped into its
            preferred alignment position.
  tantek: I agree with fantasai ...
  tantek: Also, if you can't get what the author asked for, getting
          close as possible makes more sense than draconian giving
          up... for apparently no reason, if you're just a few
          pixels off.
  tantek: I'm against draconian methodology.
  Florian: Okay, I now agree with fantasai.
  Florian: Having a warning...
  fantasai: I think putting things in invisible regions is generally
            bad authoring ...

  hober: Webkit behavior, thinking was that when an author makes a
         mistake, should still be possible for the user to get to
         all the content.
  <fantasai> hober++
  <tantek> yes - that's kind of a11y 101
  hober: So I agree with Tab and fantasai's proposal here.
  hober: Especially with differences of screen sizes, quite easy for
         authors to make this mistake.
  hober: Want to make sure you can cause all the snap elements to be
         visible on the screen at some point.
  <Florian> hober+1
  Florian: Do you still consider it an authoring error?
  hober: I think it's possible in CSS to make content invisible to
         user, not necessary to call out every case.

  MaRakow: Sounds like we should allow snapping to such positions by
           user action as well.
  fantasai: Yes, definitely.
  MaRakow: So should we reverse resolution on start/end snappoints?
  fantasai: No!
  fantasai: There shouldn't be a snap position at start/end always.
  fantasai: It's just that if an item can't be positioned as it
            wants for snapping, you pretend its snap position is as
            far as is possible to scroll.
  TabAtkins: If you're using snap points, assume that you've put
             snap positions on anything that's worth looking at.
  fantasai: E.g. consider case of photos, view on smaller screen
            have center snap for each, great.
  fantasai: On larger screen, can fit 1.5 photos, can't get last
            photo centered. Treat scrolled-to-edge as its snap
  MaRakow: Seems like we need to specify conditions under which this
  fantasai: Proposal has spec text already...

  Florian: What happens if you have several mandatory snap positions
           that are all out of reach. Do you collapse them, or
           maintain each as an individual position for semantic
           gestures like pgup?
  TabAtkins: Not defined
  TabAtkins: Wording about this is in 7.3 of the proposal
  <astearns> If the most appropriate snap position is unreachable,
             such that aligning to it would require scrolling the
             scroll container’s viewport past the edge of its
             scrollable area, the scroll container must be scrolled
             as much as possible in each relevant axis toward the
             desired snap position.
  <TabAtkins> https://drafts.csswg.org/css-scroll-snap/#choosing
  TabAtkins: Not copied over into Matt's copied yet

  Florian: Okay, I agree with what Tab and fantasai are proposing. I
           think we should resolve on that. Might later ask for a
           note, but in any case agree with proposal.
  astearns: So back to second sentence in previous resolution?
  MaRakow: Disagree with it for proximity.
  MaRakow: Suppose case where rapidly deleting things..
  fantasai: Re-snapping is after settling... Why would mandatory /
            proximity behave differently?
  fantasai: Don't want to leave user in situation via JS that they
            can't get to themselves, right.
  MaRakow: [missed]
  TabAtkins: If you don't move it, you're in an impossible scroll
  TabAtkins: If you have 2 things close to each other, delete one,
             other one is in range, do you scroll to it.
  MaRakow: There are ways to scroll to proximity snap points that
           don't encourage snapping?
  TabAtkins: How does that work?
  MaRakow: e.g. our implementation of proximity varies the proximity
           well size depending on precision of scrolling mechanism[?]
  MaRakow: If you try to precisely drop the scroll, don't want to
  TabAtkins: That's fine.
  TabAtkins: We invoke that with "if the user did a direct scroll to
             that spot", so should match that behavior.
  <fantasai> "The UA must resnap as if the user scrolled to this
             snap position"
  TabAtkins: Do whatever if the user would do if the user scrolled
             to that spot.
  TabAtkins: If you have better wording, great.

  Rossen: Maybe hack this out offline?
  MaRakow: I think the 2nd resolution should be modified based on
           what you said.
  TabAtkins: Resolution is usually a bit rough wording in the minutes.
  TabAtkins: I'm fine with more precision whatever.

  RESOLVED: The second sentence of the previous resolution is not
            precise enough.

Received on Thursday, 21 January 2016 00:08:34 UTC