W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[CSSWG] Minutes Sapporo F2F 2015-10-27 Part II: Fragmentation, Scroll Snapping Issues [css-break] [css-snappoints]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 23 Nov 2015 20:15:37 -0500
Message-ID: <CADhPm3t9Y_L3sUAfmGXbVE7LdgYUcsDXpaRMXfXxxdkpKAtzWw@mail.gmail.com>
To: www-style@w3.org
Fragmentation
-------------

  - RESOLVED: No change on issue 24.

Scroll Snapping Issues
----------------------

  - RESOLVED: Issue 54 is closed with no change (the original
              request was retracted).
  - RESLOVED: Defer scroll jumping / "discrete snapping" feature to
              level 2.
  - There was tentative agreement to create a property to allow
      control over if inertial scrolls can go past snap points.
      - Tentatively it is called scroll-snap-stop and takes the
          values 'always' and 'auto' (all names pending bikeshedding)
      - There was a desire to see a written proposal before a final
          resolution is passed.
  - RESOLVED: If no snap positions defined, no snapping happens;
              scroll freely.
  - RESOLVED: 'overflow: auto | scroll' captures snap positions in
              both axes, regardless of scroll-snap-type value.
  - RESOLVED: scroll-snap-type applies to all elements, non-none
              values trap snap positions of descendants.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: dauwhe

Fragmentation
=============

  astearns: Fragmentation was scheduled in the morning.
  fantasai: There was an issue raised by hober.
  dino: Can you link to that point?
  <Rossen> https://drafts.csswg.org/css-break/issues-lc-2015#issue-24

  fantasai: Issue 24
  fantasai: hober can't remember; he denies it happened.
  <fantasai> "hober: I liked the compound names with force."
  astearns: hober liked the names with force-
  Florian: That's my understanding.
  dino: I don't think this is worth ... . he didn't raise an
        objection.

  fantasai: The question is, we have break-before which has values
            column, page, region, auto
  <fantasai> break-before: auto | page | column | avoid-page |
             avoid-column
  fantasai: We have avoid-page.
  fantasai: It's a bit unclear what break-before: page means, it
            means a page break before the element.
  <fantasai> break-before: page
  <fantasai> break-before: force-page
  fantasai: Maybe having force- is clearer.
  dino: I don't think hober feels strongly.
  Rossen: I like shorter.
  astearns: I prefer shorter.

  RESLOVED: No change on issue 24.

  fantasai: We need a transition request.
  Rossen: We have two staff contacts in room.
  fantasai: Transition request for fragmentation to CR,
  Rossen: Chris, you'll do this?

  astearns: Do we have tests?
  Rossen: Some.
  Rossen: More would be better.
  astearns: It's nice to have a test for every section, just one,
            when we make transition to CR
  Rossen: I think that's the case.
  astearns: It's nice to have slight coverage.

  Rossen: That's all on fragmentation.
  Rossen: we've exhausted the morning session items.
  Rossen: It's fourteen minutes before noon.
  Rossen: Any quick topics?
  fantasai: Some short scroll snapping.

Scroll Snapping Issues
======================

  <astearns> https://drafts.csswg.org/css-scroll-snap/issues-by-issue
  fantasai: Let me find an issue that is not long.
  dino: We were up to 28.
  dino: 28 is simple.
  fantasai: We planned to defer 28.
  fantasai: I haven't updated it.
  dino: We talked about 28.

Have the children determine the scroll snapping behavior (Issue 54)
-------------------------------------------------------------------

  fantasai: We should do 54.
  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-54
  fantasai: It's to determine whether mandatory or proximity per
            element rather than per scroll container.
  fantasai: So the question is we don't know how this works.
  fantasai: Should we investigate or close as no change?
  Rossen: That's the model where half elements mandatory, half
          proximity?
  TabAtkins: It's mandatory, but some don't have wide attraction
             radius.
  TabAtkins: That's dumb.
  astearns: One with very large radius.
  TabAtkins: Don't put in author's control.
  Rossen: This is something we can push to level 2.

  fantasai: It was raised by Florian.
  Florian: I disagree with old Florian.
  fantasai: Closed as no change.
  RESOLVED: mandatory/proximity determined by container, not child

Add scroll jumping / "discrete snapping" feature (Issue 60)
-----------------------------------------------------------

  fantasai: Next is issue 60.
  fantasai: Scroll jumping / "discreet snapping" spreadsheet thing.
  TabAtkins: Some spreadsheets scroll only by whole rows.
  TabAtkins: I'm ok with deferring,
  TabAtkins: unless the working group thinks this is crucial.

  Steve: How do you make cut for level 1?
  TabAtkins: The simplest possible thing that robustly solves
             interesting cases.
  Rossen: Let's record a resolution.

  RESLOVED: Defer scroll jumping / "discrete snapping" feature to
            level 2.

Specify whether inertia can skip snap positions (Issue 64)
----------------------------------------------------------

  <fantasai> Discussing
https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-64
  fantasai: Can inertial scrolls skip snap positions?
  fantasai: Microsoft has a distinction between single and multiple
            mandatory.
  TabAtkins: The initial windows version had mandatory and
             proximity, and a separate axis, single and multiple.
  TabAtkins: Single meant that inertia captured next point.
  TabAtkins: Safari is mandatory multiple.
  TabAtkins: Microsoft is mandatory single (???)
  MaRakow: The biggest problem with single is home and end keys.
  MaRakow: Those should go directly to the start and end.
  MaRakow: That's a too-strict interpretation of mandatory.
  MaRakow: There's no distinction in Windows implementations.

  TabAtkins: What should we default on?
  TabAtkins: If we need both, what behavior is mandatory, and what
             call the other.
  Florian: Both makes sense.
  Florian: Suppose I have a set of articles on one page, and I want
           to go to the next one. I don't want to force to always be
           on a snap position, but also I can't calibrate my fling,
           so I just want the next one.
  <fantasai> [Florian was talking about proximity single]
  TabAtkins: It's a separate axis.
  Florian: Multiple and single doesn't sound great.
  fantasai: "This scroll point captures all inertia" might make
            sense by element.
  fantasai: For example, in Florian's case, you might want snap
            positions within the article, don't want those to trap
            all inertia,
  fantasai: but want the snap points between articles to trap all
            inertia.
  dino: I don't think that use case is valid.
  TabAtkins: Articles arranged vertically.

  dino: I still think navigation to next one; it's hard to
        distinguish between scrolling and swiping.
  MaRakow: There's a lot of nuance.
  MaRakow: There's two ways of describing single:
  MaRakow: at least one vs no more than one.
  MaRakow: Make single gesture, article is very long,
  MaRakow: there's 2 ways of interpreting.
  Florian: It's not incompatible with what you say.
  Florian: If you have recognized gesture that does that; there's no
           detection on my mouse wheel,
  MaRakow: We're trying to define default action for certain inputs.
  MaRakow: No spec says arrow down should doing something specific.
  TabAtkins: We're just sorting out your two behaviors.
  MaRakow: There's some potential leniency here.
  <Florian> scroll-snap-stop: always | inertial

  TabAtkins: Which behavior should we default to?
  MaRakow: Leave it up to UA.
  TabAtkins: Single vs Multiple changes behavior a lot.
  TabAtkins: Does a fling go really far, or to next page?
  TabAtkins: That's too different for it to be UA default.
  MaRakow: UA could have a smart default.
  TabAtkins: The two interpretations are not equally good
  MaRakow: It can vary on whether UA has animation support, etc.
  TabAtkins: None of them do.
  TabAtkins: You have an amount of inertia.
  TabAtkins: The amount of inertia calculated is a minor detail for
             users.
  MaRakow: There's some that will accelerate based on number of
           gestures, etc.
  MaRakow: Lots of UA-specific inputs that don't exist in all UAs.
  TabAtkins: The fling gesture is universal.
  TabAtkins: It gives you same basic behavior across all devices.
  TabAtkins: Single vs multiple are distinct are distinct and
             separate behaviors that authors will either want or not
             want.
  <fantasai> single = inertia cannot take you past one snap position
  <fantasai> multiple = inertia, however it's calculated, can take
             you past one snap position; you go until the nearest
             snap position to your landing position
  Florian: There's a bigger variation on author use cases.
  Florian: In a slide show you mean go to next slide no matter how
           hard.
  Florian: In a carousel a big fling should go farther.
  Florian: We need to know if inertial fling means go to next thing
           or go far.
  TabAtkins: Nothing else in spec allows such a gulf in behavior.

  <Florian> scroll-snap-stop: always | inertial
  Florian: I just pasting into IRC a proposed name.

  fantasai: Given that you might want different behavior per snap
            point in same scroller, either way we're going to have a
            separate switch because it's on item instead of behavior.
  fantasai: Both proximity and mandatory can have single behavior.
  fantasai: The default for proximity and mandatory is to allow for
            multiple.
  fantasai: We can consider adding a switch for single for element
            inside of scroll container.
  Florian: The property would apply to element not container.
  fantasai: Call it auto;
  fantasai: it means multiple.
  fantasai: From author perspective these are all methods of
            scrolling.
  Florian: You and I are bikeshedding.

  MaRakow: Do you have proposal?
  TabAtkins: Florian's scroll-snap-stop, naming tbd
  TabAtkins: It can be deferred to next level, keep multiple (Safari
             behavior) for L1.
  dino: I'm happy with the default Safari behavior.
  dino: I think there is a case for full screen don't use inertia.
  dino: So I would prefer not to defer.
  TabAtkins: Happy to do that.
  TabAtkins: For majority use case we don't need it.
  Florian: It belongs in level 1.
  fantasai: Proximity is multiple for sure.
  fantasai: That's least intrusive for users.
  fantasai: Given that, multiple has to be the default.
  Florian: I still want switch in level 1.

  MaRakow: I want to see a proposal.
  TabAtkins: I'll write up what Florian posted.
  TabAtkins: We can resolve on default the behavior.
  Florian: That's what they want a written proposal for.
  Rossen: The proposed resolution as is, multiple always for both
          proximity and mandatory
  fantasai: Looking to adding a switch.
  TabAtkins: Proximity doesn't force you to land,
  TabAtkins: you can scroll around.
  fantasai: (drawing at white board)
    proximity:   ____  _____
               /     \/     \  multiple
                 ____    _____
                /    \  /     \  single
               |      || <-- infinite hole, like when you miss a jump in Mario
   mandatory:
              (same drawing, except flat-top sections are curved
downwards ◠◠◠◠ )

  Florian: In proximity you can stop anywhere,
  Florian: but you cannot scroll past on an inertial fling,
  Florian: a fling will stop you.
  MaRakow: I have no trouble understanding.
  MaRakow: What does it mean for compat, etc. There's more thought
           needed there.
  TabAtkins: compat-wise it won't matter as you are prefixed/flagged.
  TabAtkins: behavior-wise, definitions are already in API guide.

  Rossen: Let's move on.
  dino: Lunch line is an issue.
  Rossen: Lunch break.
  Rossen: Given Matt wants a week, we have a proposed resolution in
          a week.
  fantasai: There's two more short issues; after lunch.
  Rossen: 3pm we have joint meeting.
  astearns: We'll resume after joint meeting.

  <jchiba> https://www.dropbox.com/s/g3fwj38z8kagx01/snap-point-multiple.jpg?dl=0

  <break type=lunch>

Scribe: fantasai

Define what happens when there's no snap points (Issue 69)
----------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-69
  fantasai: Define what happens when there's no snap points.
  fantasai: Do you snap to something, or don't snap or what?
  fantasai: Tab and I figured if there's no snap positions defined,
            scroll freely.
  fantasai: If there isn't, you don't snap to anything.
  <MaRakow> If a valid, reachable snap point exists, you must snap
            to it (for mandatory)

  RESOLVED: If no snap positions defined, no snapping happens;
            scroll freely.

Define that snap point defined by element is triggered when targeting
    fragment of element (Issue 72)
---------------------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-72
  fantasai: [summarizes]
  MaRakow: This is way outside scenarios that I've ever looked at.
  MaRakow: I'm happy to go to with simpler one.
  Rossen: Yeah, seems to agree with what I remember.

  RESOLVED: 'overflow: auto | scroll' captures snap positions in
            both axes, regardless of scroll-snap-type value.

Trapping Snap Points (Issue 82)
-------------------------------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-82
  fantasai: Someone mentioned that it would be nice to trap
            descendant snap points even if not a scroller.
  fantasai: The original suggestion was to use snap-points-x/y lack
            of elements value.
  fantasai: Tab and I thought that's weird, snap-points-x/y are
            about coordinates.
  fantasai: But scroll-snap-type is about processing descendant snap
            positions, so thought that a non-none value, or perhaps
            a special "trap" value, would apply to all elements and
            capture snap positions inside.

  MaRakow: So snap positions are associated to nearest ancestor with
           overflow: scroll | auto or scroll-snap-type: non-none
  MaRakow: That seems reasonable.
  fantasai: Variations on proposal is, non-none values, or do we
            want a special keyword.
  MaRakow: I would prefer non-none
  fantasai: Seem reasonable to others?
  <astearns> ...general head-nodding...
  Rossen: Yeah, similar to how position traps things.

  RESOLVED: scroll-snap-type applies to all elements, non-none
            values trap snap positions of descendants.
Received on Tuesday, 24 November 2015 01:16:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC