[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.

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