- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 Feb 2014 16:18:42 -0800
- 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
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!
Received on Thursday, 20 February 2014 00:19:12 UTC