RE: [css-snappoints] The virtues of snapping to element boxes rather than using length-based properties

>From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
>Sent: Thursday, February 27, 2014 7:53 PM
>To: www-style
>Subject: [css-snappoints] The virtues of snapping to element boxes rather than using length-based properties
>
>I've updated https://wiki.mozilla.org/Gecko:CSSScrollSnapping to better reflect what we've actually implemented. In particular it adds a "center" value for scroll-snap-edges and gives more flexibility to the UA for picking what to snap to.
>
>I feel that the focus on length-based properties in the draft is a mistake and starting with a focus on element boxes makes more sense. Hard-coding lengths makes for fragile and non-responsive designs. Consider "Example 1" from the draft:
><style>
>img {
>    width:500px;
>}
>.photoGallery {
>    width: 500px;
>    overflow-x: auto;
>    overflow-y: hidden;
>    white-space: nowrap;
>    scroll-snap-points-x: snap-interval(0px 100%);
>    /* Sets up points to which scrolling will snap along x-axis */
>    scroll-snap-type: mandatory;
>    /* Requires that scrolling always end at a snap point when the
>       operation completes (hard snap) */
>}
></style>
><div class="photoGallery">
>  <img src="img1.jpg">
>  <img src="img2.jpg">
>  <img src="img3.jpg">
>  <img src="img4.jpg">
>  <img src="img5.jpg">
></div>
>With our proposal, just replace
>.photoGallery { scroll-snap-points-x: snap-interval(0px 100%); }
>with
>img { scroll-snap-edges:border-box; }
>and you'll get the same behavior.
>However, the snap-interval syntax hard-codes the assumption that the images are the same width as the container. So suppose the photoGallery element's width is no longer known ahead of time (e.g. it's a desktop browser window). With our proposal (and implementation) you get the following behavior:
>-- Scrolling to the right, we snap the right edge of the scrollport to the right border-edge of each image that comes into view, ensuring the whole image is visible.
>-- Scrolling to the left, we snap the left edge of the scrollport to the left border-edge of each image that comes into view, ensuring the whole image is visible.
>The current draft seems to preclude that behavior, since you can only snap to one point in the element and it can't depend on which direction you're scrolling. Also, the snap-interval syntax in the example will not work; you'd have to change it to snap-interval(0px 500px).
>But the snap-interval() syntax still hardcodes the assumption that the images are 500px wide. So suppose the <img> element widths are also not known ahead of time (maybe not until they're loaded), and in fact the images may have different widths. Our proposal and implementation continue to work just fine, but snap-interval is no longer useful at all.

This is generically true of snapping to intervals vs. elements, regardless of syntax.  In cases where the element qualities are not known, an elements-based solution is needed.  Example 2 covers this scenario.

My other mail has an example (filmstrip of photos a la Redfin) in which the element qualities are well known but the snap points do not map directly to individual elements, in which case the interval is most appropriate.

>It seems to me the draft should be based on features which handle simple cases well. snap-interval may be useful for examples where you want to snap to edges that aren't related to the CSS layout of your document, but those probably aren't simple cases.
>
>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:46:16 UTC