RE: [css-snappoints] 2/27 Updated ED

>From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
>Sent: Thursday, February 27, 2014 7:43 PM
>To: Matt Rakow
>Cc: www-style@w3.org
>Subject: Re: [css-snappoints] 2/27 Updated ED
>
>On Fri, Feb 28, 2014 at 3:24 PM, Matt Rakow <marakow@microsoft.com> wrote:
>>I've just pushed an update to the ED for Scroll Snap Points.  This is primarily just inserting issue notes for the various feedback I've received from the Seattle f2f, Robert's mail, and some inspection of the proposal on the Mozilla wiki.  I'll continue to address this feedback and start up discussions as needed prior to FPWD, but please do confirm that I've captured your feedback and let me know if I've missed anything.
>
>I have the following additional issues:
>Section 5:
>Are snap-interval and snap-list actually needed assuming we can snap to element boundaries?

snap-interval is particularly useful for pagination scenarios, where there may not be a single element that spans the height/width of the scroller.  The example we used at the f2f was a "filmstrip" style viewer, where images are viewed N at a time.  Redfin.com's property listings are a good example of this.  An example construction might look like:
    <div style="width: 500px; scroll-snap-points-x: snap-interval(0, 100%)">
        <img style="width: 100px;">
        <img style="width: 100px;">
        ...20 more images...
        <img style="width: 100px;">
    </div>

snap-list I'm less attached to as most of its scenarios could be achieved with elements.  However, the general feeling I got from the f2f was that people still valued the ability to specify exact coordinates to snap to.  I'll add an issue in the spec noting that we need a better scenario justification for it.

>Why aren't we using commas to separate function parameters?

This was feedback from the f2f from Peter Linss and others -- I'm happy to go with whatever the popular opinion is on convention for this.

>Section 6:
>Are these properties actually needed?
>Section 7:
>Are these properties needed?

These are used to define a point in the element, and a point in the scroller box that should be aligned after the scroll.  Example 2 shows where this is important (centering an image in view).  Similarly challenging scenarios include slight offsets from the edge (particularly, allowing the previous element to "peek" in-view) -- I'll add an example on this.

The definition of coordinate vs. axis caused some confusion at the f2f as well, so I'll see if I can come up with a better illustration of the functionality to clear this up.  It was also proposed that we consider better naming for the properties, so that might also help (this is already called out as an issue).

>What are these values relative to?

I'll be defining this better (issues already in spec regarding not using box-sizing and definition of leading edge).  Suggestions welcome :)

>How do we handle the case where elements have different widths and some gestures want to snap to the left edge and others to the right edge (or top/bottom edge respectively)?

The snap-axis and snap-coordinate combination already allows snapping to any edge regardless of element dimensions, though this does not vary based on details of the gesture.  Varying based on gesture is undesirable -- the snap point's location needs to be determined based on the content, not on how it was reached.

Consider a news site like NPR.org, if each article were a snapping element.  The site author is going to want to ensure that each article deterministically lands at an aesthetically pleasing location in the viewport.  Having it land at one of two different locations based on a gesture heuristic is an unpredictable behavior, and likely means that the article is at a non-aesthetically pleasing location 50% of the time.  The user has to learn to focus their eyes at location A while scrolling down, but location B while scrolling up.

Similarly for snapping elements that are larger than the viewport (say, large sections of a long article), it's desirable to ensure that the section header and initial content snaps into view.  If this varied based on direction, then scrolling the opposite direction would only get the last few paragraphs of the section in view, with no header or other context provided.  The user would have to scroll past the section and back down again in order to view the section header.

>Having the initial value be "0px" makes the whole "elements" feature unusable since there will be unwanted snappoints all over the place.

This is already called out as an issue -- feedback from the f2f was to add a "none" value, which I've done in the next revision that I'll be pushing shortly.

>Personally I think there are so many issues compared to the size of the spec that trying to list them all and resolve them one by one is an inefficient way to make progress and will probably not lead to a good result. I'll write another post about that to avoid disrupting your issue list :-).
>
>Rob
>-- 
>Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w

Received on Friday, 28 February 2014 18:44:18 UTC