W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[CSSWG] Minutes Seattle F2F Wed 2014-01-29 AM II: Scroll Snap Points

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 19 Feb 2014 16:18:42 -0800
Message-ID: <530549E2.2010709@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Scroll Snap Points

   Microsoft presented its proposal for CSS scroll-snapping properties.
   There was a lot of feedback.

   Some use cases presented:

     - Scrolling through a photo album, wanting to snap each photo to the
       center of the window, or slightly offset from the center of the window.

     - Scrolling through photos filmstrip style, wanting to snap to every
       5 photographs.

     - Scrolling in 2D: snapping to faces in a photo or points on a map.

     - Effect of zooming on the use cases; whether properties set for one
       zoom level will still work in larger/smaller viewports than expected.

   Some structural concerns:

     - Removing the 'elements' value and just merging lists of snap points.

     - Having the elements within a scroller, not the scroller, determine
       scroll-snapping behaviors.

     - Syntactic concerns (consistency with the rest of CSS on capitalization
       and hyphenation, use of commas).

     - Discussion of -x/-y properties and/or use of <position>.

     - Multiple snap points per element.

     - Interaction with box-sizing vs. using box-sizing keywords.

   Behavioral concerns:

     - Distinguishing mandatory vs. proximity behavior. Possibly mixing the
       two within a scroller.

     - Snapping points vs. snapping areas.

     - Distinguishing various snapping behaviors, e.g. accelerating towards
       a snap position vs. resisting leaving a snap position.

Microsoft will draw up a new draft for review by the WG after considering
all feedback; currently withholding FWPD until the draft better represents
the views of the WG.

====== Full minutes below ======

Scroll Snap Points

   Rossen: This a spec that we talked about a few months ago
   Rossen: I helped Matt from our team to add to the CSS WG
   <dbaron> http://dev.w3.org/csswg/css-snappoints/
   Rossen: Matt will give us an overview of the spec. There were a bunch
           of comments and requests that were fired away as soon as spec
           was introduced
   Rossen: I believe we addressed most of them. Hoping to get FPWD after
           review today.

   Matt: Our first methodologies were snap list and snap intervals
   Matt: Snap list is a list of lengths at which snaps would be  at
   Matt: Scrolling element would snap to those offsets
   Matt: Snap-interval was similar, but instead of lengths was offset for
         first one and then interval to be repeated
   Matt: The feedback we got was most of the scenarios people have is to
         snap to specific elements
   Matt: e.g. next photo or whatever
   Matt: So pushed update last night for element-based snap points proposal

   Matt: A number of scenarios we wanted to cover with this
   Matt: pagination, photo slide shows, want photo centered, or offset by
         some amount
   Matt: In Windows we often have 100px of previous section to peek in,
         so you know there's a prev section
   Matt: So defining a snap axis, which is position within scroller area,
         and then snap coordinate, which aligns to that snap axis

   Matt: Here photo album, example 2 in spec, photo slide show example
   Matt: snap coord is 50% through each photo in slideshow
   Matt: snap axis (red line) is 50% through scroller.
   Matt: As you page through, try to align snap coord to snap axis

   Matt: Only other addition here is elements value for scroll-snap-points-x
         and scroll-snap-points-y
   Matt: so you don't have elements and points simultaneously
   fantasai: is there a reason to disallow that?
   Matt: doesn't make a lot of sense to merge these
   Matt: Do you merge them, one wins
   fantasai: I think you just merge the two lists

   fantasai: I'm less convinced of the need for the other one, if you have
             element-based one, why need other one?
   Matt: interval one, might want one page content at a time
   dbaron: If you have pages, usually you have elements for that
   [discussion of use cases, such as images, graphic novel panels]
   fantasai: There's an <area> element in HTML. If you mapped that to
             graphic novel panels, would you be able to snap to those areas?

   smfr: Suppose an element and its child both have scroll-snap-points
   Matt: Associate them all to nearest ancestor scroller
   Matt: You take all of the snap points into account.
   Matt: use case: section for news, section for sports, each have snap
         points. Articles within them have snap points, etc.

   heycam: For element-based one, can you use SVG elements?
   heycam: How would that work?
   Matt: set your snap coordinate
   <heycam> [so you could do a 0px offset from a bounding box edge, it
             sounded like]

   fantasai: Can you have a snap area? Like say you have a very large image,
             you snap to that image, then can pan around freely, but it
             resists pulling the image off the screen. Then can swap to
             next image
   Matt: Currently only points
   Matt: This is only allowing a single snap point per element
   fantasai: This is different from multiple snap points
   fantasai: there's no tension, unless I try to pull the photo away from
             the edge
   smfr: Haven't ever seen that
   plinss: photo viewer on iPhone does that
   Bert: Maybe you have snap tolerance or snap area
   Bert: ...

   Matt: Haven't really thought about using these as a boundary effect
   Matt: Not sure if that's the same problem we're trying to solve, or
         something different
   fantasai: I think it's the same problem, just slightly different case
   Matt: not sure about that

   dbaron: It sounds like you're describing mandatory vs proximity
   <smfr> http://dev.w3.org/csswg/css-snappoints/#scroll-snap-type0
   dbaron:  property has scroll-snap-type: none| mandatory | proximity
   dbaron:  Mandatory means you have to rest at that point
   dbaron:  proximity is that if you are near a snap point, then you snap
            there. If not close then don't snap to it
   plinss: That doesn't match what fantasai was describing

   dbaron: One comment I have is that you have different snap types in x
           and y dimensions
   dbaron: that's a comment from roc
   florian: x and y or block and inline?
   <dbaron> part of roc's document at https://wiki.mozilla.org/Gecko:CSSScrollSnapping
   plinss: Well, it should match scrolling properties
   smfr: This one has different points
   for x and y in different properties
   smfr: but for points we tend to use a single <position> property
   dbaron: ....

   dbaron: My impression was that roc was in favor of simpler proposal for
           defining where snap points are
   dbaron: which was to say that you can have either margin or border edges
           as snap points
   Matt: Wanted to also solve problems of centered photos in photo album, e.g.
   dbaron: Not quite following solution you have here
   Matt: Idea is that scroller element defines within its space an axis
   Matt: Each element defines which points it wants to match to that axis
   Matt: [talks through image]
   Matt: after you complete a scroll, align point to axis

   fantasai: I think roc and I are talking about having an area, where you
             resist leaving that area
   fantasai: and Matt is talking about having an alignment point, you try
             to match to that alignment

Scribe: TabAtkins, edited by fantasai
   fantasai: [draws a diagram]
   fantasai: [several images in the content, larger than the container]
   fantasai: There are two types of snap points.
   fantasai: Snap points in the middle of each image.
   fantasai: As I scroll around, it resists having a scroll offset that's
             not having the snap points centered.
   fantasai: [describes two method, using energy potential metaphors]

   fantasai: In this case, the snap points are grooves that we lock to.
             Mandatory means in between there's a curve; you're always
             sliding towards a groove. Proximity means there's a flat
             space in between grooves, only curves into it when close enough.
             mandatory: ◠◠◠◠◠
             proximity: /``````\/`````````\/````````\

   fantasai: Second type is resisting sliding from one area to another.
             This is the photo panning, but resisting a swap to the next
             photo. Looks like ridges between photos, flat area across photo.

   dbaron: Is that why there's an extra property that's confusing?
   MaRakow: [...]
   smfr: Snap points are what you put on the thing with overflow:scroll.
   smfr: Snap coords are on the elements inside. They provide snap points

Scribe: smfr
   <smfr> [explanations of the spec]
   dbaron: trying to think of real-world examples of snapping to 90% intervals
           and no other points within that
   florian: makes more sense with proximity
   MaRakow: example: on redfin.com, photo viewer with set of 5 images,
            which are paginated
   MaRakow: clicking arrow goes to next image
   more like going to the next page, or filmstrip of images
   dbaron: snap points are associated with edge of images
   MaRakow: edge of every 5th image
   MaRakow: could wrap images in elements, but simpler to say you're snapping
            to 100%

   SteveZ: what if I have zoomed?
   MaRakow: for element based snap points, it works
   MaRakow: lengths are in css units, so it should be consistent
   MaRakow: IE does everything in CSS units, not physical
   florian: this works in 2d, but it's defined to work in either horizontal
            or vertical
   florian: wouldn't work for a large area, and snapping to points within that
            e.g. if 2 x and y coords, you may only want to snap to 2 of those
            points (not the 4 intersections)
   Rossen: you're asking for snapping for diagonal scrolling
   SteveZ: e.g. snapping to cities on a map
   MaRakow: yes, for now florian's example would give you 4 snap points

   shepazu: slides and galleries is a common use case. you want to change
            the url hash as you do that
   shepazu: not CSS, but how would you integrate snap points with url hash
   MaRakow: have not thought about this

   <TabAtkins> Simplified grammar, suggested by me on the list some time ago:
   <TabAtkins> scroll-snap-points: <lenper>+ | <lenper>* repeat(<lenper>+)
                                   | elements | elements(<lenper>)
   <TabAtkins> scroll-snap-axis: <lenper>
   <TabAtkins> Lets us avoid having scroll-snap-coordinate property.
               Also uses simpler means than specialized functions.
   <TabAtkins> Also, we never do capitalization in function names.
   plinss: no camel case (snapInternval etc)
   plinss: don't use commas in function notation

   smfr: some naming issues
   like "axis"
   smfr: terminology needs clarification
   plinss: elements is not a good term. could be other boxes
   <TabAtkins> Actually, we don't need "elements" at all.

   <TabAtkins> Add a "none" value to the "I contribute a snap point" property,
               which is the initial value.
   <TabAtkins> scroll-snap-points: <lenper>+ | <lenper>* repeat(<lenper>+)
   <TabAtkins> scroll-snap-axis: <lenper>
   <TabAtkins> scroll-snap-coordinates: none | <lenper>
   <TabAtkins> Or better, none | <position>

   florian: would be nice to have an object model, so you can get snap
            points from JS
   shepazu: would fit with the hash changes
   plinss: need to spec how this interacts with JS-driven scrolling
   florian: is common to have scrolling feedback (dots under the scroller),
            so need some OM way to hook up to these

   MaRakow: have had requested for snap to next, snap to previous
   TabAtkins: we can simplify the syntax quite a bit
   [see above]
   TabAtkins: no need for flag on the scroller to say that it should look
              at its children

   TabAtkins: is there a use case for scroll-snap-coord to have x, y,
              rather than a position
   TabAtkins: is there a reason we have separate X and Y properties?
   MaRakow: it's common to use in 1D scrollers hence the separate X and Y

   TabAtkins: is there a use case for multiple positions per element
   Rossen: yes
   Rossen: photo with faces
   TabAtkins: don't use <area>

   dbaron: strongly agree with what I think I heard TabAtkins saying
   dbaron: scroll-snap-coordinate should have initial value of "none"
   TabAtkins: allows you to skip some elements, rather than all or none

   dbaron: scroll-snap-coord should not just apply to block-level elements
   dbaron: I would want this to work on inline-blocks, flex boxes, etc
   dbaron: and inline images
   dbaron: would say "applies to: all elements"
   TabAtkins: it's defined relative to the content box, so we'd need to
              figure out what that means for inlines

   dbaron: I don't like tying this to box-sizing
   dbaron: box-sizing was a design mistake; it should have been a modifier
           to particular values
   dbaron: the global flag that changes all the things is bad
   dbaron: if you want different boxes it should be part of the value,
           rather than using box-sizing
   tantek: from a web dev or implementor perspective?
   dbaron: from a web developer perspective
   <TabAtkins> scroll-snap-coordinate: none | [ <position> <box>? ]#

   astearns: there's value in both
   tantek: it makes sense for some developers
   florian: how does this work with fragmentation

   florian: if the elements that define the snap point have been fragmented
            by a fragmentainer inside the scroller, what happens?
   TabAtkins: would be defined by the definition of the reference box

<br type="coffee">
   <tantek> I've gotten feedback from numerous developers who think
            box-sizing:border-box is the way the CSS box model should
            have been from day 1.
   <tantek> new developers too - that have no memory of the old IE box model
   <fantasai> tantek: I agree with them, too. It's just too late to fix now
   <tantek> fantasai - obviously we're not going to fix it now, but
            "box-sizing" is a pretty decent workaround
   <tantek> whereas per-property-value hacks would be a huge pain in the a**
   [fantasai thinks the right solution to this is not to use border-box
    for future things that would find it unnatural, not to tie everything
    to box-sizing]

Bikeshed Spec Processor

   [logistical discussion]
   TabAtkins talks about bikeshed.py
   <tantek> smfr, re: bikeshed, I started this wiki page too:
   TabAtkins: please file bikeshed.py issues on the github tracker
   plinss: bikeshed gets spec data from Shepherd
   <tantek> please feel free to add requests for documentation to the wiki
            page too
   plinss: you can tell bikeshed to update your local data

Snap Points (continued)

   Rossen: would like to publish first public working draft. Have 8 points
           to address before we publish
   ChrisL: how many of those points require discussion
   Rossen: will add issues for things like 2D panning. Some editorial things
           (camel case)
   Rossen: naming issues, -x and -y rather than single property, multiple
           points per element
   ChrisL: do people want to review?
   TabAtkins: yes, i want to review. Can you request in 2 weeks at next
              conf call?
   Rossen: OK

   Bert: what if next snap point is too far away (further than scroll width)
   MaRakow: depends on proximity
   Bert: is there no smart behavior?
   Rossen: yes, the mandatory one. proximity is a better choice in that
   florian: would it make sense to be able to switch to mandatory and
            proximity per snap point
   MaRakow: mandatory means that it's mandatory that you end up at a snap
            point. Have to think it through
   Rossen: we'll do the edits, and request FPWD in 2 weeks

   * fantasai finishes reading through the snap-points minutes
   <fantasai> I don't understand, from the minutes, what were the key
              changes requested. Could somebody at the next break (or
              while ignoring current discussion ;) please summarize
              them clearly?
   * fantasai can't process minutes when they don't make sense
   <glazou> fantasai, you're at SEATAC ?
   <fantasai> yep

   <Rossen> Feedback notes to snap points discussion:
     - Don't use camel case for property names.
     - Use only one property to specify the point.
     - CSSOM - you want to know be able to read back the points and use them?
     - No need for the 'elements' value
     - Allow multiple point per element being snapped
     - It should be allowed to apply to all elements.
     - Snapping in 2D by using both scrollers at the same time.
       Ex. I want to pan around in a map from city to city.
     - Shouldn't be bound to box-sizing. See how the reference boxes are used
       in the Shapes spec.
     - Should we have mandatory vs proximity per element?

   <fantasai> Some additional notes:
     In Grid Layout we created some naming conventions to distinguish between
     properties set on the container vs. on the items.
     Might be helpful to group scroll-snap properties similarly

     Also, might want to think about snapping area to area rather than just
     point to point. Snap points resist having a point on the scroller move
     away from a point on the element. But sometimes you might want to say
     that the viewport resists moving away from the boundaries of an element,
     but as long as the element covers the screen there is no tension.
     If you are close to a boundary of the element (that is off screen),
     it does not snap to that boundary. But if you bring that boundary to
     the edge of the screen, it resists the viewport edge crossing that
     boundary (and displaying things beyond the element boundary).

     Wrt mandatory vs proximity and allowing both within an element...
     It's not the snap point that has this behavior, it's the space between
     the snap points. If I am between a mandatory snap point and a proximity
     snap point, what does that mean?
     - In between mandatory points, it's clear that the viewport must slide
       to the nearest snap point
     - In between proximity points, it snaps to the nearest snap point if it
       is close enough, but doesn't accelerate to any snap point if it's far
       enough from either snap point.
     - But between a mandatory point and a proximity point, what happens?
       Is that treated as mandatory? Or does the behavior change at the
       halfway point? Or something else?

     I think the photo album example is a great use case for mandatory snap
     points and the axis snapping model that's in the spec.
     But what happens if we zoom in and the photos are no longer smaller
     than the viewport? That same behavior is no longer sensible, because
     it resists letting the user see the parts of the photo that aren't
     visible when the center is snapped in.
     So what model would be appropriate then?
     And since the user can zoom in and out, how can we make the controls
     we offer provide the right behavior in both cases, without the autho
     having to detect when a photo is larger than the screen?
   <fantasai> These are questions I think should be explored.

   <liam> [ability for the user to scroll slightly shouldn't go away altogether]
   <fantasai> I suspect they can be solved by area-to-area snapping rather
              than point-to-point snapping.
   <fantasai> You could use <position> syntax to align the snap-point within
              the viewport if the snap-area is smaller than the viewport.
   <fantasai> So the photo use case would use an element snap-area (rather
              than snap-point) consisting of the photo border-box, and a
              snap-position (rather than axis) of center center.
   <fantasai> Which would cause it to try to center the border-box within
              the viewport when it is smaller than the viewport
   <fantasai> and to merely rest the viewport within the photo area when
              the viewport is smaller than the photo.

   <liam> if it's something like pinterest, with an image wall, you might
          want a scroll "detent" at the top of each image , or more likely
          just above it
   <fantasai> ?
   <liam> you have multiple parallel images
   <liam> not all aligned vertically

   <fantasai> The other thing I haven't quite thought through is the two
              behaviors you could want at the edge of a box.
   <fantasai> In one case, you merely resist leaving the box, but don't
              try to align to it if you're still completely within it.
   <fantasai> In the other, if you're near an edge, you try to align the
              viewport edge to the box edge. Kindof like how in Win7 the
              window edge snaps to the screen edge if it gets close enough.
   <fantasai> (the first behavior would be resisting the user trying to
              push the window off the screen, but not being attracted to
              the edge if it's if nearby)
   <fantasai> Anyway, I should go board. :)
   <fantasai> Have a happy time discussing, CSSWG!
   <Ms2ger> Have a good flight
   <glazou> bye fantasai
   <dauwhe> thank you, fantasai!
Received on Thursday, 20 February 2014 00:19:12 UTC

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