W3C home > Mailing lists > Public > www-style@w3.org > June 2016

[CSSWG] San Francisco F2F 2016-05-11 Part III: Scroll Snapping [css-scroll-snap]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 7 Jun 2016 21:25:23 +0300
Message-ID: <CADhPm3vfX0AULmde8gU8JJwwS+_+w3LAVT2xwHUUOW0t4JQLYQ@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.

Scroll Snapping

  Archival Copy of the Change Proposal being discussed:

  - RESOLVED: No ability to specify the strictness of snapping
              separately per axis.
  - RESOLVED: Allow the keyword to be dropped, default to proximity.
  - RESOLVED: Ordering of keywords is strict in scroll-snap-type
              (to allow for extensions)
  - RESOLVED: Values are x | y | block | inline | both | point ,
              where point would be dropped after next publication.
  - RESOLVED: Require (for now) an explicit axis and will gather
              more info as we can (to decide between physical and
              logical direction as the default).
  - RESOLVED: make snap-align behave like a subset of background
              position (from fantasai's proposal:
  - RESOLVED: Add section 6.2.2 (Snapping Boxes that Overflow the
              Scrollport) and add issues.
  - RESOLVED: Add section 6.2.1 (Scoping Valid Snap Positions to
              Visible Boxes) as an open issue
  - RESOLVED: Add section 6.2.3 (Unreachable Snap Areas)
  - RESOLVED: Merge section 6.3 (scroll-snap-stop) with
              * an issue about whether it applies to 2D
              * an issue to bikeshed "normal"
  - RESOLVED: Merge section 7.3 (Choosing Snap Positions) with
              * parenthetical of "corridor" point moved to start the
              * JS element-targetting scrolls added into the :target
  - RESOLVED: Add section 7.1 after removing "explicit" "inertial"
              and "directional" definitions, moving the first
              sentence and adding a more precise definition of when
              an active scrolling operation is done so we know when
              to start snapping.
  - RESOLVED: Merge 7.0 (introductory text) too
  - RESOLVED: Add fantasai and TabAtkins as editors to scroll
  - RESOLVED: Shortname css-snappoints -> css-scroll-snap


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

Scribe: Florian

Scroll Snapping

Change of axis

  <fantasai> https://drafts.csswg.org/css-scroll-snap/diff
  <fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes

  <fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-axes
  fantasai: An outstanding difference is syntax of scroll-snap-type
  fantasai: Matt is wanting to change from the proposed syntax
            none | [ proximity | mandatory ] || [ x | y | block |
            inline | both ]
  fantasai: to a syntax where both is replaced by repeating axes
  fantasai: in order to allow for different snapping strictness per
  MaRakow: I previously didn't like axes being different for
           mandatory vs proximity was because it didn't make sense
           for point snapping
  MaRakow: but it does make sense for 2 x 1D.
  MaRakow: So the proposed syntax allows do different mode if you're
           2 x 1D, but a single mode for point snapping.

  myles: Usecases?
  MaRakow: In one dimension, you have clearly defined columns, and
           in the other you want sort of a paginated experience in
           the other.
  myles: If you have columns, you would want mandatory in 1
         dimension, and no snapping in the other.
  MaRakow: Are you making a case against 2 x 1D snapping?
  myles: Yes.
  fantasai: We could change the syntax to pair the axis and its
            snapping type, and for now only allow for 1 axis, and
            defer to later the possibility to have both.
  MaRakow: We initially talked about separate properties for axes
           and strictness, but if we're merging into a single
           property ....
  <MaRakow> https://lists.w3.org/Archives/Public/www-style/2016Apr/0146.html
  MaRakow: A few things I was concerned. Should we allow snapping
           differently between each axis, and make sure we only get
           one strictness for point snapping?
  MaRakow: Are people interested in having different strictness per
  myles: Apple is not interested in having different strictness.
  TabAtkins: Fine for now.
  astearns: Objections?

  RESOLVED: No ability to specify the strictness of snapping
            separately per axis.

  Florian: Should we also resolve on a concrete syntax?
  fantasai: Yes
  fantasai: The syntax in our spec allows for the keyword to be
            omitted, so we need to either require it or pick a
  <fantasai> A) none | [ proximity | mandatory ] || [ x | y | block
                | inline | both | point ]
  <fantasai> B) none | [ [ mandatory | proximity ] [ x | y | block |
                inline ]? ]{1,2} | [ mandatory | proximity ] point

  fantasai: First: do we require the strictness keyword?
  fantasai: If we don't, an axis would imply proximity.
  MaRakow: Explicit is good.
  fantasai: Short is good.
  fantasai: That we're snapping is implied in the name.
  leaverou: Conciseness is good, we should pick a default. And
            proximity is a good default.
  astearns: MaRakow would you object?
  MaRakow: No objection.
  astearns: Anyone else?
  RESOLVED: Allow the keyword to be dropped, default to proximity.

  fantasai: Second: do we require a particular ordering, or is "x
            proximity" and "proximity x" both fine?
  fantasai: In general we allow reordering
  fantasai: but that gets in the way of allowing (in the future) to
            add different strictness by axis.
  fantasai: So I would prefer being conservative, and not allowing
            reordering for now.
  MaRakow: works for me
  (+1 from Myles)
  leaverou: Alternatively, we can allow different orders now, and in
            the future we use a slash to separate.
  fantasai: Or required ordering only if you have two.
  astearns: I prefer being strict now.
  fantasai: Sounds good.
  RESOLVED: Ordering is strict.

  <Rossen> https://drafts.csswg.org/css-snappoints/#valdef-scroll-snap-type-point
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Mar/0353.html
  Rossen: We already have a resolution to move point snapping to
          level 2.
  Rossen: Resolved in Sydney.
  Rossen: Why is it still in the spec?
  fantasai: That prose was never on /TR, we wanted there before
            pushing to next level. Just procedural.
  Rossen: Ok

  <astearns> x | y | block | inline | both ?
  fantasai: syntax would be x | y | block | inline | both | point ,
            where point would be dropped
  MaRakow: plus the optional strictness?
  fantasai: yes
  RESOLVED: x | y | block | inline | both | point , where point
            would be dropped

Difference in logical axis

  <fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-align-axes
  fantasai: A difference is logical axes. We felt it was important
            to have the difference between block vs inline.
  fantasai: One major reason is consistency with Level 4
            background-position, which was already resolved.
  fantasai: Another is that, although which axis is snapped may be
            physical or logical, whether you snap to the start or
            end within an axis is nearly always logical.
  <fantasai> (I know of no physical use case)
  MaRakow: The reason I put it as x + y is to match the overflow
  fantasai: The overflow props don't have a 2-value syntax.
  fantasai: We have overflow-x and overflow-y, but also -block and
            -inline in the logical props spec.
  fantasai: You can choose which is more important to you.
  fantasai: Once you have chosen, within an axis, the decision is
            writing mode dependent.
  fantasai: I have a hard time seeing use cases for physical.

  MaRakow: For background position, if you have 2 values, the first
           is horizontal and the second is vertical.
  <fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
  MaRakow: but I am more worried about overflow:auto, not specifying
  MaRakow: and then specifying snapping physical makes more sense.
  fantasai: If you don't specify, it defaults to the block axis.
  fantasai: If you don't specify the scroll-snap-type axis it
            defaults to block axis.
  fantasai: Scrolling inline is an exceptional case.
  fantasai: The spec is intentionally biased to be a logical system.
  MaRakow: I prefer default to physical.
  fantasai: [disagrees]
  MaRakow: Discussed that on the phone a couple of months ago.
  MaRakow: My position is still that the main use cases are physical
  <fantasai> This is my position:

  Scribe: fantasai
  Florian: My recollection is the conclusion was more subtle than
  Florian: regardless of whether primary use cases are physical or
  Florian: Even when physical, the coupling of scrolling axis works
           better when logical, even for physical use cases.
  Florian: I think back to what you were saying earlier: when you
           only have one axis for scrolling, which is typical case,
           you don't need to specify and it just falls out.
  Florian: If you specify scrolling axis physically, it just works.
  Florian: The case for having to specifically physical snapping
           axes, is a bit of a red herring.
  Florian: Use case might be physical, but the scrolling is physical
           not just the snapping.
  Florian: In Tab and fantasai's proposal, it works.
  Florian: Without doing anything extra fancy, if you have physical
           scrolling in the case, it just works.
  Florian: For these cases it's okay either way.
  Florian: For the other cases, where you care about logical
           directions, its preferable with logical coordinates.
  MaRakow: Reason why these are chosen physically, is based on
           physiology, eg using mouse wheel,
  MaRakow: or swiping on a screen.
  MaRakow: Layout seems to be based on that.
  Florian: Scrolling is physical, not the snapping.
  fantasai: I didn't understand what you just said Florian.

  Scribe: Florian

  fantasai: The cases given demonstrate that often scrolling and
            snapping are physical.
  fantasai: That's why we have x and y.
  fantasai: But once you have chosen an axis
  fantasai: within that axis, whether you're going to the start or
            end is a logical dimension
  fantasai: so we should use logical coordinates for alignment
            within one axis, once you've picked it (regardless of
            physical or logical).
  Florian: I understand MaRakow's preference, but not its

  myles: What if the start edge of the box and the container are
         different sides?
  fantasai: No problem, alignment is specified on the child.
  TabAtkins: You don't get the mismatch given how it is specified.
  MaRakow: A relevant discrepancy is the default axis
  MaRakow: of snapping.
  [segmentation fault]

  MaRakow: Nothing specifies the scroll wheel is in the block
  fantasai: It tends to happen.
  TabAtkins: I assume that when in vertical writing modes, there's
             an easy way to scroll.
  koji: IE does horizontal, webkit/blink do vertical. Horizontal is
        better, but not always done.
  Myles: WebKit is interested in matching IE.
  koji: So will blink.

  fantasai: I want to either resolve now, or to know how to proceed.
  [technical difficulties]

  <smfr> vertical-rl scrolling testcase:
  * smfr notes that mac trackpad scrolling is physical
  <MaRakow> it's really inconsistent across the board
  <MaRakow> e.g. arrow keys are physical, home/end is logical in edge
  * fantasai notes that trackpads are equally competent in both
             axes, unlike scroll wheels

  [The group split at this point and those interested in Color moved
      to another room (see next set of minutes)]

*** Scroll Snap Breakout Session Minutes ***

  Scribe: vollick

  fanatasai: How do we make progress? We fundamentally disagree.
  astearns: One way forward is for MaRakow is to give up. what do
            you think, MaRakow?
  MaRakow: Against my better judgment?

  myles: If the snap points are physical, they don't need to be
         recomputed on style change.
  myles: Therefore faster.
  fastasai: Unless you're changing the writing mode, doesn't really
            matter. how often does that happen?
  myles: I offer this comment as, hopefully, a way to move forward.

  fantasai: I think one way forward is to try and be conformant with
            how background-position works.

  MaRakow: Would it make more sense to resolve on axis before
           alignment behavior?
  fantasai: The block axis is usually the one that's scrolling. if
            the inline axis is scrollable, it's usually because the
            screen is inconveniently small.
  MaRakow: I think you're thinking of a document, rather than
           something that's 2D snappy, like a tiled view.
  fantasai: Stuff grows, overall, in the block axis.
  tantek: Like a spreadsheet?
  MaRakow: Another example, maybe you have rows of movies to watch
           and no snapping preference in the x axis (or columns).
  tantek: Like netflix ui.
  MaRakow: My point is that those layouts probably don't change in a
           writing mode locale.
  tantek: Could we look at japanese netflix ui? (looking for a real
          work example to guide us).

  fantasai: The primary scroll axis should match how the scroll
            wheel behaves.
  MaRakow: If you think about UIs like a flipper view, they're
           commonly horizontal even where block axis is vertical.
           Flipping through content is a physical, not logical thing.
  fantasai: And a flipper view would explicitly specify.
  MaRakow: Yeah, it's possible, but in the majority of cases the
           author isn't thinking about the logical orientation, but
           the physical arrangement of the content...
  MaRakow: Flipper view is something like at the top of many
           websites, you can flip left-right through stories.

  astearns: We _could_ take a straw pool of those remaining. Would
            rather hear people express a preference one way or the
  shans: There's no functionality lost through choosing one vs the
  fantasai: No, we could specify anything explicitly.
  shans: Just trying to summarize. 1) consistency with other css
         props and matching text behavior
  fantasai: And that scrolling is usually logically...
  shans: and a counterargument (albeit obscure) is performance.
  shans: And the counterargument is that snapped layouts are usually
  shans: Perhaps we could do a survey of content and find out what's
         truly prevalent?
  gregwhitworth: Would either party change their minds based on this
                 study, or would we just be informing folks?

  fantasai: I think that there's a combination of logical/physical,
            but primarily you're scrolling in the block dimension,
            because you've got too much content.
  fantasai: The inline scrolling is unintentional because screen is
            too small.
  fantasai: The physical case, therefore, should be specified
  gregwhitworth: I'd posit the reason scroll snap is physical is the
                 map scenario. The widgets you bring up (usually
                 completely different than typical scrolling), in
                 these maps scenarios, scrolling is very physical.
  gregwhitworth: It boils down to: do we want consistency in syntax
                 or behavior?

  fantasai: This is the case where you didn't specify an axis. What
            will frequently happen is that the author says "I want
            snapping" and if we default to 2D snapping, we get
            snapping to the wrong stuff if we overflow
            unintentionally in the wrong direction.
  fantasai: But what tab and I know is that the author may not have
            tested thoroughly and didn't anticipate the
            unintentional scrolling, and we get weird behavior if we
            default to 2d scrolling.
  fantasai: So we need the default behavior to be scrolling in 1D
            and in the primary direction, because it's most likely
            what's intended.
  fantasai: Most scroll ports have the primary axis be the block
            axis, so we should spec for that.

  MaRakow: I want to go back to what shans was saying, I think that
           doing a survey of content is a great idea. Seems like
           you're focusing on documents, but I don't think it's the
           primary use case for this feature
  <fantasai> Use cases include photo flippers, but also blog posts,
             address books, train schedules, etc.
  astearns: We're talking about the default behavior, correct? (yes)
            It's not about all the places we use scroll snaps, it's
            the cases where the author has chosen the default.
  fantasai: We also key off the overflow values. If we have
            overflow-x and not overflow-y, we'll do horizontal. It's
            only where it's ambiguous where we default to block axis.
  fantasai: Yeah, if you have an app-centric view of the world, you
            may think that the dimensions are equivalent, but there
            are a whole bunch of docs on the web.
  MaRakow: Not just apps, but docs, too. flippers, stores often are

  flackr: We're talking about a default behavior, but can we require
          this to be specified until we have more data?
  MaRakow: Fine by me.
  astearns: What does it mean if we punting on?
  fantasai: We always specify, and we don't try and guess until later.
  astearns: But can we defer this? If we require this, but then
            default it later...
  MaRakow: I think that this will be a lot easier, because we can
           measure the common case.
  shans: That might actually be good, if we see people specifying
         y-axis and pages break when the writing mode changes, then
         that's an argument for logical..
  fantasai: Changing axis is very rare.
  fantasai: A novel could do this, but not a fancy-layout magazine.
  fantasai: The concern I have with going physical, is that our
            defaults are often logic and choosing physical here is
  MaRakow: I think we have a way forward by avoiding ambiguity.
  shans: I have a preference for fantasai's suggestion. how about a
         straw poll to check for strong opinions. Failing that, we
         go with explicit requirement.
  astearns: I would like to use IRC and get folks to say physical or
  <fantasai> 1) logical
  <fantasai> 2) physical
  Straw Poll:
    Rossen 2
    Florian 1
    MaRakow 2
    fantasai 1
    shane 1
    myles abstain
    bradk 1) logical
    flackr 1
    jensimmons 1
    astearns 1
    gregwhitworth 2) physical
    iank_ abstain
    koji 1
    vollick abstain
    ojan abstain
    Tabatkins 1
    dauwhe 1

  astearns: There's an obvious preference for logical, so we go back
            to asking for objections from Microsoft.
  MaRakow: I think we have an opportunity to gather more data by
           doing what shans suggested, so I propose that we go with
  astearns: The people that abstained may be expressing a preference
            for gathering more data. Both ian's and tantek are in
            that camp.
  ojan: Abstaining due to lack of informed opinion.
  astearns: Alright, given this and that we're likely not going to
            get further, let's go with explicit.
  shans: Can we go for explicit with the understanding that without
         strong data for physical, we go with logical.
  fantasai: How are we going to get this data?
  fantasai: The info we get from what author's type isn't
            trustworthy. e.g. they might inaccurately use margin-top,
            because they didn't consider other writing modes.
  fantasai: The only way we can truly judge is by looking at use
            cases and see what would have ideally been done.
  fantasai: I'm ok with this to move forward, though. we can talk
            about this later.
  fantasai: I just want to point out that it's not as simple to
            gather data as "turn on explicit and measure"

  RESOLVED: Require (for now) an explicit axis and will gather more
            info as we can (to decide between physical and logical

  * fantasai would like to revisit this resolution with the rest of
             the WG
  astearns: I agree that parsing what people type is not reliable.
  * Rossen points out that Matt's examples are from real apps that
           already work with our impl

Snap-align and background position

  fantasai: We have the related issue of snap-align
  fantasai: My opinion - unless we change background position syntax,
            this should work exactly the same way.
  <fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
  fantasai: This is the syntax we discussed at TPAC in Sapporo.
  fantasai: It can express physical, logical, or combinations.
  fantasai: The scroll snap align takes a subset, so should be the
  fantasai: If we want to have physical/logical coordinates, we
            should use the same syntax.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0133.html
  fantasai: In lieu of repeating myself a lot, read this ^
  fantasai: Either we add a bunch of keywords to be explicit, or we
            interpret the same as background position.
  MaRakow: ok.
  astearns: You're ok with fantasai's proposal?
  MaRakow: Yeah, seems to favor logical, but we could add words to
           make physical in future. ok.
  RESOLVED: Make snap-align behave like a subset of background
            position (from fantasai's proposal:

Scoping Valid Snap Positions to Visible Boxes

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-scope
  fantasai: In the interest of time and minuting, I will paraphrase...
  astearns: Alternatively, we could have matt respond and we could
            see if we need to discuss.
  MaRakow: I haven't looked at these as closely
  MaRakow: but can go into detail on what I've read in detail. The
           issue I have with visible boxes
  MaRakow: could give wiggling while scrolling or snap points
           outside scroller.
  MaRakow: With this specification, there could be a great
           candidate, that happened to be out of scroll at the
           beginning, so we wouldn't consider it.
  MaRakow: Problem, basically, is that you need to make a decision
           where you're going to scroll.
  MaRakow: During scroll is crummy, but at the beginning causes you
           to ignore good candidates.
  fantasai: The goal of this section is to avoid snapping to
            something that is way off to the side, out side the
            scroller, but not in the direction you're scrolling.
  MaRakow: Yeah, I get the scenario you're considering (and agree it
           needs to be addressed), but not sure what prose to suggest.
  fantasai: We could replace the text of this section with an issue
            that describes the problem.
  MaRakow: I think that if such prose exists, would love to look at
           it, but don't know if any algorithm exists that could
           address the issue.
  fantasai: Do you have other concerns about this section that we
            should address if we were to try to come up with better

Snapping Boxes that Overflow the Scrollport

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-overflow
  fantasai: The next section is snap points that overflow the
  MaRakow: Doesn't account for more than one element that overflows
           the viewport...
  fantasai: <quotes some of the prose>
  <fantasai> “and there are no other snap areas within the snapport
             that would provide a snap position aligning the
             overflowing snap area within the snapport,”
  <fantasai> “then any scroll position in which the snap area covers
             the snapport is a valid snap position in that axis”
  MaRakow: In general this has issues with multiple elements in the
  fantasai: I don't get it.
  MaRakow: Say we have two huge elements, and a tiny view port. When
           you scroll out of one and another huge element appears,
           the only valid snap points will be the centers.
  MaRakow: So, at the time that you've panned into the 2nd element,
           then your 2nd condition doesn't pass anymore. You don't
           necessarily snap then, but the list of snap points only
           includes the centers.
  astearns: So the text doesn't cover that case.

  fantasai: I don't understand why, but we can talk offline. do you
            have a problem with this, or just need better prose?
  MaRakow: Same as before. need better prose, but not sure if such
           prose exists.
  astearns: fantasai and tab have reasons for adding these sections
            once we have prose, and I would like the reasons stated
  fantasai: Go back to giant photo requires center alignment
            (expected bigger screen).
  astearns: You want to get away from the center
  fantasai: Yeah, you want to be able escape, but the author hasn't
            let you.
  astearns: Do you agree that we at least need a note for this?
  MaRakow: Yeah, but I thought we had one. .. looks like it got
           dropped. We talked about this in January.
  fantasai: It's an interesting point. although the prose isn't
            ideal, I think it's better to have this than not, and
            just fix the section.
  fantasai: Might be awkward as specified, but leaves content
            inaccessible, if we don't address this.
  MaRakow: Problem is that this text doesn't solve the problem in
           many cases.
  astearns: At least gets you to the edge.
  MaRakow: Maybe if it's a single element that's really large.

  <fantasai> If you remove “and there are no other snap areas within
             the snapport that would provide a snap position
             aligning the overflowing snap area within the
             snapport”, which probably needs some tweaking,
  <fantasai> Then having this section solves the accessibility
  <fantasai> And behavior could be improved on top of that.

  astearns: So, I think I agree with fantasai that we should have
            this section because it's a problem we need to solve. I
            don't mind if it's just an issue describing the problem.
  MaRakow: I am ok with describing the problem. I don't want
           unimplementable prose.
  fantasai: It at least solves 100% of the accessibility problem,
            but we can refine the snapping behavior.
  fantasai: It might not do enough snapping, but removes barriers
            from content.
  MaRakow: I'm fine with adding an issue. I don't think this text is
           going in the right direction.
  MaRakow: I remember you suggesting a disjointed set of points...
           did that go anywhere?
  fantasai: We started with that, but ended with this prose.
  MaRakow: I agree this is an important problem.
  fantasai: I would prefer to add prose with an issue, rather than
            just issue.
  MaRakow: I'm not convinced this is going in the right direction,
           but am interested in the disjoint set.
  shans: Having something that can be critiqued is better than
         nothing. and preferable to throwing up our hands and saying
         "dunno". I think we should add this and matt should add
         specific issues.
  MaRakow: I would like to add a note saying "don't implement this
  astearns: I propose we add section with issues detailing the
  astearns: Objections?

  RESOLVED: We add the section 6.2.2 (Snapping Boxes that Overflow
            the Scrollport) and add issues.

Scoping Valid Snap Positions to Visible Boxes (revisited)

  fantasai: Can we do this for the previous section?
  MaRakow: The other one is not just bad prose, it's not
  <fantasai draws on the whiteboard>
  <It is a scroller with a snap candidate off to the side>
  myles: If they intersect the viewport by 1px, still stinks to snap
         to them.
  fantasai: happy to make it fuzzier, but when? up to the ua?
  myles: should leave it up to the ua
  MaRakow: this is why we went with point based.
  myles: I don't think something like a raw intersection test would
         give us the best experience
  MaRakow: agreed.
  astearns: You agree we should have this section, but the wording
            is MUCH more up in the air because we can't agree on the
  myles: different UAs could disagree with what's in and out
  MaRakow: scrolling is intended to bring out of view content into
           view; ignoring out-of-view content is against the spirit
           of the thing.
  fantasai: Want to clarify that we _can_ snap to that stuff as long
            as it's actually visible when we've snapped.
  astearns: Agreement that it's something we should have but don't
            have the right wording. my proposal is to add a section
            with just an issue.
  <MaRakow> +1 astearns
  astearns: objections?
  fantasai: I think we should add section with issues.
  astearns: I disagree. In this case I think the wording is going to
            be completely different.
  fantasai: can't work on diff forever
  astearns: let's work on the issue.

  RESOLVED: Add section with just the issue.

Unreachable Snap Areas

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#unreachable
  fantasai: I want to center an image in the screen.
  fantasai: The image is at bottom right of scrollable area.
  fantasai: Its small
  fantasai: (so i can't center it).
  fantasai: So, the used snap position means you should just scroll
            as far as possible.
  fantasai: So you still snap "there" but it's not really "there".
  <MaRakow> No objection on this one.

  RESOLVED: Add section 6.2.3


  <fantasai> https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop
  fantasai: scroll-snap-stop
  fantasai: We discussed the difference between when you flick, you
            scroll until you run out of inertia
  fantasai: then you determine where to snap.
  fantasai: The other behavior is when you stop at the next snap
            position, always
  fantasai: "infinite sinkhole" effect.
  fantasai: Microsoft's API has a matrix of proximity vs mandatory.
  fantasai: Sometimes you want to only snap by one "stop" and you
            might want to cross the next "stop".
  fantasai: Florian's use case: you have snap positions at every
            heading, but every article has a mandatory snap.
  myles: Does this interact with 2d snapping?
  myles: You shouldn't be able to only go one stop when 2d snapping
         isn't enabled.
  fantasai: You could say that you just go in one direction to choose.
  gregwhitworth: (to myles): do you think that this should only work
                 1 dimensionally or do you think this shouldn't be
  myles: A note or an issue is fine.
  MaRakow: "Normal" is non-descriptive
  MaRakow: Let's use "multiple" or something else.
  fantasai: If we decided to make this work for mandatory, it'd be
            the snap position that you'd choose if you had very slow
            speed and no friction.

  gregwhitworth: Is it ok to merge if we note to bikeshed the normal
                 keyword and define inertial scroll?
  MaRakow: I think so.
  MaRakow: There are issues with inertial scroll.
  astearns: Objections?

  RESOLVED: Merge section 6.3 with 2 issues

Choosing Snap Positions

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#choosing
  fantasai: Choosing snap positions
  fantasai: We have 2 concepts: we have 1) valid snap positions, and
            2) the chosen position
  fantasai: The UA determines #2.
  fantasai: Don't lock down #2.
  fantasai: Locking down #1 is good though.
  fantasai: Guidance for #2 is valuable for a spec to have.
  fantasai: Expository writing shows some guidelines.
  fantasai: We also have bullet points.]

  <fantasai> “Snap positions should be chosen to minimize the
             distance between the end-point (or the natural
             end-point) and the final snapped scroll position,
             subject to the additional constraints listed in this
  <fantasai> “Point-snapping is all-or-nothing; if the snap position
             of an element is chosen to align to, the scroll
             container must set its scroll position according to the
             element’s snap positions in both axises; the scroll
             container must not “partially align” to the element by
             taking its snap position in one axis and aligning the
             other axis according to something else.”

  fantasai: Let's come back to this.
  fantasai: Clarification of point snapping: you can't snap to the
            x-axis of a point w/r/t point snapping when snapping to
            the y-axis of another point.
  fantasai: This is uncontroversial.
  MaRakow: Normative or recommendation?
  fantasai: Normative (but you have leeway)
  fantasai: We have some "should"s or "may"s.

  fantasai: next! "axis locking"
  <fantasai> “If a scroll is axis-locked and the scroll container is
             axis-snapping, any snap positions in the other axis
             should be ignored during the scroll. (However, snap
             positions in the other axis can still effect the final
             scroll position.)
  <fantasai> If a scroll is axis-locked and the scroll container is
             point-snapping, snap positions should be penalized in
             the selection process according to the amount of other-
             axis scrolling they would cause.”
  <fantasai> “Additionally, because page layouts usually align
             things vertically and/or horizontally, UAs sometimes
             axis-lock a scroll when its direction is sufficiently
             vertical or horizontal. An axis-locked scroll is bound
             to only scroll along that axis. This prevents, for
             example, a nearly horizontal fling gesture from
             gradually drifting up or down as well, because it is
             very difficult to fling in a precisely horizontal line.”
  fantasai: ^^^^ this is how axis-locking is defined
  fantasai: It means "if we are scrolling close to vertical, we may
            disregard horizontal scrolling" this rule means that if
            you're doing this locking, you don't snap in the
            opposite direction.
  fantasai: If you have two snap positions you're choosing, and they
            are otherwise equivalent, it's not specified how you
            choose a point, but you should penalize the point in the
            orthogonal direction to the axis locking

  <MaRakow> points aligned with the axis of scrolling should be
            preferred over points off-axis
  astearns: It is ambiguous. we don't know if you should penalize
            depending on how far we are trying to scroll.

  gregwhitworth: We don't need to define everything now, we need to
                 determine what needs to be addressed to get the
                 specs merged in, not define right now. let's get
                 through this stuff!!
  astearns: We need to determine what needs to be an issue.
  gregwhitworth: Let's not define ambiguity.
  gregwhitworth: myles summarizes a lot
  MaRakow: "axis locking" the reader needs to know what this is.
           It's not well defined.
  fantasai: It was defined earlier.
  MaRakow: It depends on the reader to already know what is up.
  MaRakow: Maybe this needs to be defined better.
  fantasai: No. It means "here's a thing that UAs do, and we are
            assigning it a name so we can refer to it"
  fantasai: We aren't defining exactly what it does.
  fantasai: It is normative, but it's not a directive.
  MaRakow: Everything here says "should" right
  fantasai: Correct. Next!

  <fantasai> “ Snap positions should be ignored if their elements
             are far outside of the “corridor” that the snapport
             defines as it moves through the scrollable area during
             an inertial scroll, or a hypothetical “corridor” in the
             direction of a directional scroll, or the snapport
             after an explicit scroll. (This is to prevent a far-
             offscreen element from having difficult-to-understand
             effects on the scroll position.)”
  fantasai: If you're scrolling in a direction, you probably want to
            ignore things that are in another direction.
  fantasai: You should ignore elements that are far away in an
            orthogonal direction.
  fantasai: This is so the user doesn't scroll way off in the weeds.
  fantasai: This is about choosing snap positions, not about what is
            a valid snap position.
  fantasai: The other section is about valid snap positions.
  myles: One is a filter, the other is scoring.
  fantasai: It's not a filter.
  fantasai: You can't snap to an element which is super far away.
  fantasai: The other one is saying that, among the valid snap
            points, you should prefer ones which are in the
            direction of scrolling.
  fantasai: The user intent is to go in one direction, try not to
            pull the user in an orthogonal direction.

  MaRakow: Can we focus on the parenthetical "UAs should avoid
           difficult-to-understand scrolling behaviors"?
  astearns: Let's talk about "scroll vectors"
  astearns: How about "don't change the 'scroll vector' by a large
  MaRakow: Scroll vector & corridor are bad, because you may scroll
           in multiple directions (when you hit the edge of a page).
  MaRakow: Let's say "don't let far away elements affect snap points".
  MaRakow: This is easy to interpret.
  MaRakow: It doesn't have to delve into crazy edge cases.
  fantasai: It helps to clarify the specific cases
  fantasai: Obviously we don't want bad user experiences
  MaRakow: Let's just lead with the parenthetical.
  astearns: Let's do it.

  RESOLVED: Merge it with the parenthetical first.

  <fantasai> “User agents must ensure that a user can “escape” a
             snap position, regardless of the scroll method. For
             example, ...”
  fantasai: if the next mandatory snap position is super far away,
            normal flings won't take you that far ordinarily
  fantasai: but the UA should not trap you
  astearns: Maybe it's a use case to let strong people win prizes
            for hard flinging.
  MaRakow: I'm imagining a use case and it is like a carnival game
  MaRakow: Sounds good to me.

  RESOLVED: merge that puppy

  <fantasai> “If a page is navigated to a fragment that defines a
             target element (one that would be matched by :target),
             and that element defines some snap positions, the user
             agent should snap to one of that element’s snap
             positions. The user agent may do this even when the
             scroll container has scroll-snap-type: none.”
  fantasai: If you are navigating to an element which has been
            targeted, don't put the element to the top of the
            viewport. Instead, you should snap to that element if it
            has a snap position. Even if an element has a snap
            position, you may want to use the snap area as a
            guideline for how to move it into view.
  MaRakow: How does this work when you have scroll-snap-type: none
  MaRakow: This allows you to have scroll snap points but they are
  fantasai: This doesn't interfere with scrolling, but if you want
            to see the box, and the box has a preference for how
            it's being seen, then let's honor it.
  fantasai: It's better than the UA default.
  MaRakow: Wouldn't it have a scroll-snap-type then?
  fantasai: The scroll snap on the scroller is about snapping
            behavior (vs smoothly scrolling).
  fantasai: Here, let's move it into view using these settings.
  fantasai: This is more refined than the course UA.
  fantasai: We have the technology!

  MaRakow: I understand, but fragment navigation gets a special case
           for ignoring scroll-snap-type? This is an outlier.
  MaRakow: Most UAs have the same machinery for scrolling, so
           special casing is bad.
  fantasai: Currently it's undefined how scrolling to an element is
  fantasai: because it's undefined, it makes sense to prefer to use
            these things.
  astearns: This makes sense.
  astearns: I like this one except for the last sentence.
  MaRakow: Same.
  astearns: It's a "may".
  fantasai: It's better if we do this.
  fantasai: If you're going to a heading, you might want to say
            "let's show the decoration around the heading".
  fantasai: We've given control to the author about the breathing
            space around an element. Authors have given us the info.
  fantasai: Browsers can use it, but they don't have to (but it's
            better if they do).
  astearns: If the author is concerned, though....
  fantasai: Then they would turn off snapping.
  fantasai: The user wants the decorations around their elements.
  astearns: This is weird and backdoor.
  fantasai: We could add this as other properties if you prefer
            a completely identical but independent set of properties...

  astearns: Any other opinions?
  bradk: fantasai makes sense.
  bradk: We should do this for scrollTo and scrollIntoView() as well.
  fantasai: This should occur any time we want to go to an element.
  MaRakow: No objections.

  RESOLVED: take section 7.3 with 2 issues

Types of Scrolling Methods

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#scroll-types
  fantasai: Next: types of scrolling methods.
  fantasai: Let's describe how scrolling works.
  fantasai: We have a list of scrolling methods.
  fantasai: We want to define the model of how snapping works.
  fantasai: So we have a category of scrolling operations.
  fantasai: Based on 1) if they have an intended end position and/or
            2) if they have an intended direction.
  fantasai: This is used to explain behavior that is in the rest of
            the prose.
  fantasai: The issue should be removed.
  <fantasai> (Tab did the rewrite already; I'll remove it)
  fantasai: It should be removed because it is already done.

  MaRakow: Some might be controversial:
  MaRakow: - categorization
  MaRakow: Mouse wheel scroll should be classified as directional,
           not inertial in our UA.
  MaRakow: Fling gesture depends on UA a lot.
  MaRakow: A kindle web browser has no inertia.
  MaRakow: So that's more of a directional scroll.
  fantasai: 'kay.
  MaRakow: The definition is better split if you talk about
           scrolling operations which are instantaneous vs play out
           over a duration.
  MaRakow: This separates the first two categories.
  MaRakow: Directional scrolling makes sense.
  MaRakow: A new category of active scrolls.
  MaRakow: This is a scroll which is driven by a user over a duration.

[At this point the people from the Color breakout rejoined the room]

*** End Breakout Session Minutes ***

  MaRakow: "explicit" and "inertial" is controversial as what is
           categorized in each.
  MaRakow: My suggestion: there is a different way of dividing
  MaRakow: which avoids confusion.
  MaRakow: Let's say "instantaneous" vs "play out over a duration"
  MaRakow: and "scrolls that are active over a duration"].
  MaRakow: Like "if there is continuous input or not"
  MaRakow: Directional makes sense, but it might need to be
  <fantasai> TabAtkins, the fling gesture without inertia is e.g. in
             in an ebook reader, sometimes it's more like PageDown
             or DownArrow than like smartphone flings.
  TabAtkins: multi-interaction scrolling isn't a single interaction.
  MaRakow: When you do the selection of a snap point, this depends
           on one point in time - either when a driven scroll ends,
           when an inertial phase begins, etc.
  MaRakow: The timing is interesting and has to do with phase
           transitions between active driving, inertia phase, and,
           for instantaneous, the instant and the play out of the

  TabAtkins: What's wrong with the current categorization?
  MaRakow: If you had a description of "active driven scrolling"
           then you could say that the time we select a point is
           when the driving of the scroll is completed.
  MaRakow: This uses the "active scroll" definition.
  TabAtkins: What is a "driven scroll"?
  MaRakow: During a drag (touchpad gesture) or dragging the
           scrollbar thumb.
  MaRakow: During this, you don't want the page to be jumping.
  MaRakow: So don't do this during the active scroll.
  TabAtkins: We already define this during the spec.
  TabAtkins: Don't snap until the scroll is "basically done".
  TabAtkins: We snap "At the termination of a scroll"
  TabAtkins: So, while the user has their finger down, it's already
             defined that you don't snap then.
  TabAtkins: 3 categories: intended endpoint, intended direction, or
  MaRakow: In general, you want to define the time period clearly.
  MaRakow: active scroll operation: is okay there.
  MaRakow: But we don't know the period over which the animation
           plays out.
  MaRakow: We have these input types in the section, but they might
           fall into different buckets based on the UA.
  TabAtkins: Prove it.
  MaRakow: The fling gesture. If you're on a non-animating user
           agent (kindle) doesn't have inertia.
  TabAtkins: The way that your scrolling method works is that you
             don't have an intended end position.
  TabAtkins: The UA can interpret gestures differently.
  TabAtkins: After the interpretation, you always end up with one of
             the three buckets.
  MaRakow: You don't have to worry about it.
  MaRakow: Instead of saying that particular gesture ties to an
           inertial scroll which ties to these other behaviors, you
           can say the user did something and the result is either
           an directional scroll, or an instantaneous scroll delta I
           don't know.
  MaRakow: No matter how they get into the situation, the behavior
           is defined.

  TabAtkins: We agree in semantics but not names.
  MaRakow: Nope.
  TabAtkins: How so
  MaRakow: Mouse wheel, fling gesture, scrollto are different.
  MaRakow: scrollbar/scrollto don't talk about inertia.
  MaRakow: scrollto and scrollbar don't talk about whether they
           should or not have an inertia phase.
  TabAtkins: Because inertia isn't part of the definition.
  TabAtkins: scrollby has a direction and direction.
  TabAtkins: scrollto just has a postion.
  TabAtkins: So the definitions fall out.
  (general confusion)
  TabAtkins: [clarifies point made above]

  Florian: I have a 4th one!
  Florian: "implicit scrolling"
  Florian: This is where the user gave nothing. For example, the
           user focused a button.
  TabAtkins: This is the same as a scroll destination alone.
  Florian: The conversion between what the user did and what the UA
           did may what to take scroll-snap stuff into account.
  TabAtkins: How is it not currently taken account.
  TabAtkins: How do you want it to change.
  TabAtkins: You can click a #link to focus something, and you will
             snap there (as if you called scrollTo()).
  astearns: MaRakow had a point that you're making these definitions
            but you don't use them.
  astearns: The other terms are not used.

  astearns: Please describe why we need this section.
  TabAtkins: They are used!
  TabAtkins: Terms are just for general background.
  TabAtkins: We have several bits about if there is a direction or
  astearns: We define categories "inertial" "directional" but we
            don't use them.
  astearns: We don't use the categories themselves.
  TabAtkins: It just describes the types of things which has only a
             destination, and has only a direction, and both.
  astearns: For MaRakow, some of these things are miscategorized.
  MaRakow: Yup.
  MaRakow: astearns got it right. the interesting points are not the
           category headings, instead they are the names you
           reference many times.
  MaRakow: Let's rename the headers to be the interesting bits.
  TabAtkins: If you just want to prefer more on the actual
             definition (these two qualities) then that's cool.
  MaRakow: Let's go further and define at what point in time you
           select a snap points.
  MaRakow: Now it's not defined.
  TabAtkins: The answer is "when the scroll operation is done and no
             more active scrolling happens"

  MaRakow: Let's define "active scroll operation"
  TabAtkins: 'kay
  TabAtkins: If you think it's possible.
  TabAtkins: We are not disagreeing with notions.
  MaRakow: Yep.
  MaRakow: We don't need to dive into input types.
  TabAtkins: ???
  MaRakow: We have some categories, but different UAs disagree on
           what goes into each category.
  Florian: Some UAs may consider a fling in one or the other category.
  Florian: We agree on, regardless the UA determined the
           destination, it then has a destination.
  Florian: If it has a destination and a direction, then it has a
           destination and a direction.
  Florian: It's not interesting how we get to these states.
  TabAtkins: The ebook fling gives you a direction but no position
             (or magnitude).
  MaRakow: Let's move away from categorizing that fling gesture must
           be an inertial scroll.
  fantasai: Let's just use an example block to make it clear they're
  MaRakow: These may be classified differently, and that's okay.
  TabAtkins: We don't define how different user interactions are
             classified on.
  TabAtkins: Fling is different on a phone vs a kindle.
  TabAtkins: These should be examples.
  TabAtkins: We need another directional example to talk about swipes.
  TabAtkins: The three categories are not wrong.
  * fantasai notes that the fling gesture described is explicitly a
             kind that is interpreted with momentum; the ebook swipe
             doesn't fit this description
  MaRakow: They are not useful.
  TabAtkins: So I should just swap the first sentence into the DT
  TabAtkins: and remove the "explicit" "inertial" and "directional".
  TabAtkins: People incorrectly assign meaning to them so let's
             remove them.
  MaRakow: 'kay

  astearns: Proposed resolution: add section 7.1 in the spec with
            these minor changes ^^^^
  astearns: & add a more precise definition of when an active
            scrolling operation is done so we know when to start
  MaRakow: That depends on my text.
  MaRakow: That is how we implement it.
  astearns: Any objections?

  RESOLVED: Add section 7.1 after removing "explicit" "inertial" and
            "directional" definitions, moving the first sentence and
            adding a more precise definition of when an active
            scrolling operation is done so we know when to start

  fantasai: Let's do 7.0 too
  MaRakow: We need to update terms too.
  TabAtkins: yeah.
  fantasai: 7.0 is general background knowledge.

  RESOLVED: Merge 7.0 too

  fantasai: We are done.
  fantasai: No we're not.
  fantasai: "default axis" issue revisit. This was our strawpoll
  Rossen: We were following on IRC so the previous resolutions are
  fantasai: But there were other people who did not vote!
  astearns: There was a resolution to require an axis and not have a
            default behavior (for now).
  astearns: We can relax it later based on usage.
  astearns: Let's not open it up.
  TabAtkins: I don't have an objection.

  astearns: Should we add fantasai and TabAtkins as editors of the
            spec to grease the wheels of the merges?
  astearns: What do you think MaRakow?
  MaRakow: 👍

  RESOLVED: add fantasai and TabAtkins as editors to scroll snapping

  Scribe: fantasai

  astearns: Did a merge discussion of scroll snap. Mostly merged,
            added some issues.
  TabAtkins: Did we discuss short name?
  fantasai: MaRakow merged in the title change.
  fantasai: I guess shortname should follow.
  tantek: What's the proposal?
  <MaRakow> yeah go go shortname
  TabAtkins: css-scroll-snap

  RESOLVED: css-snappoints -> css-scroll-snap
Received on Tuesday, 7 June 2016 18:26:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC