[css-snappoints] Blink team position on snap points

Hi,
We realized that there hasn't been much involvement from the blink team on
this proposal.  I just wanted to send a quick note to communicate our
position (especially since I was so enthusiastic about this in initial
discussions with Microsoft immediately after it was announced in IE).

We're currently focused (eg. see [1]) on low-level mechanisms that give
framework developers more flexibility to customize the behavior while
scrolling.  We imagine a world where frameworks can implement a wide
variety of effects like snap points without needing any new APIs and the
associated web-standards efforts.  For example, the "hidey bars" that slide
and snap in and out in while scrolling in the Twitter app for Android share
some similar properties to snap points, but can't be implemented directly
with such a high-level proposal.  We don't yet have a specific proposal
that would enable scenarios like snap points and "hidey bars", but hope to
in the near future.

As such, we have no plans at this time to implement snap points in blink.
 We don't have any fundamental objection to it, but just feel we need to
focus our efforts on enabling framework developers to innovate in this
space without being blocked on us all the time.

Thanks,
   Rick

[1]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4jBAnIVwrt0

On Wed, Feb 19, 2014 at 7:18 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> 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
>         thusly.
>
> -fantasai
> 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
>            changes
>   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
>   [discussion]
>
>   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]
> </br>
>
> Bikeshed Spec Processor
> -----------------------
>
>   [logistical discussion]
>   TabAtkins talks about bikeshed.py
>   <tantek> smfr, re: bikeshed, I started this wiki page too:
>            http://wiki.csswg.org/tools/bikeshed
>   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
>           situation
>   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!
>
>