Re: [css-snappoints] [css-scroll-snap] Summary of latest updates 1/13

On 01/13/2016 05:17 PM, Matt Rakow wrote:
> Hi all,
>
> On the call this morning I promised to send an outline of edits
> I've made in the latest editor's draft [1] during the spec merge,
> specifically as compared to Tab/Elika's proposal [2].

Thanks for this list. Fwiw, Tab and I will go through and make
our copy match yours to minimize the differences as we go along;
hopefully we'll end up matching exactly and then delete a copy. :)

> (1) Converted remaining references to "specified box" for scroll-snap-area to "border-box".

Good catch. Fixed.

> (2) Changed "snap viewport" to "snap alignment container" -- the
> term "viewport" isn't really appropriate since it is describing
> a rect for alignment, not a port through which something is viewed.
> It also avoids unintentional conflation with the other uses of the
> word "viewport" in the spec.  I'm sure there is probably a better
> term though, I'm open to alternatives.

Agreed "snap viewport" isn't great. We're thinking "scrollport snap
area" would be a better alternative, though. It makes it clearer
that this is about the scrollport, and not something static. What
do you think?

(We'd have to define scrollport in the css-overflow spec, but I
think we should do that anyway.)

> (3) Replaced usage of "viewport" with "visual viewport".  The
> two-viewport model still needs to be spec'd, but for those not
> familiar with that model, this would be the "actually what I'm
> seeing" viewport as opposed to the "used for layout purposes"
> viewport.

Agreed on using the visual viewport. Also, switching to "scrollport"
overall for scrolling boxes would make this easier; we could
reserve "viewport" for use on the root (which would clarify that
things like viewport units and the @viewport rule don't have
anything to do with overflowing divs).

(Can't remember where we got "scrollport" from, possibly some layout
discussions with Rossen at some point?)

> (4) Specified that scroll-snap-padding does accept percentages
> (percentages are relative to the scroll container's visual viewport).

Good catch on the missing "Percentages" line in the propdef box.
Fixed that and the missing values in the appendix.

> (5) Specified that scroll-snap-area does accept percentages
> (percentages are relative to the border-box).

We actually left out percentages intentionally on scroll-snap-area
because we weren't sure there were use cases, or indeed if referencing
the border-box was the correct answer. (Particularly in transformed
cases, this can be weird. If you base it on the border-box, but
apply it to the transformed bounding box, that's potentially weird;
while if you base it on the transformed bounding box, its size is
harder to predict.) We've a preference for leaving it out until
there's a clear demand for it (and clear guidance on which behavior
is needed).

> (6) More explicit description of the re-snap requirement -- mostly
> just clarification, but does add that mandatory snap points
> "must"/"should" re-snap to the previously snapped position for
> "mandatory"/"proximity" respectively (was "should" for both in
> Tab/Elika's proposal).

IIRC, we made it a "should" to give the UA some leeway in deciding
which element to track in cases where multiple snap positions coincide.
If the WG doesn't think that's necessary, then happy to tighten it to
a must -- though it probably makes sense to have this behavior for both
mandatory and proximity.

Going over this section, however, we've noticed that it's not really
correctly specified overall. We made the following changes to clarify:
   https://hg.csswg.org/drafts/diff/c6492e849001/css-scroll-snap/Overview.bs
which you can see at:
   https://drafts.csswg.org/css-scroll-snap/#snap-type

> Also I should go ahead and call out these items I am planning to omit during the merge:
>
> (1) Example 2, since we generally agreed to push scroll-groups from level 1 [3].

Missed that, good catch. Removed.

> (2) 2d snapping in general, including the "point" value from
> scroll-snap-type (or whatever we settle on for axis specification),
> example 3, example 6, example 7 part 3, and other references to 2d
> snapping.  This is with the intent of pushing 2d snapping from
> level 1 per feedback from Apple [4].  This didn't get a formal
> resolution so may need more discussion, but I have no objections
> with moving it to level 2.  Regardless, I do intend to add some
> other "center in the remaining space" example if example 6 is omitted.

We would prefer to leave it in the spec and mark it at-risk, since
there are use cases for it. For example, centering photos in a
viewport, if said photos don't form a filled rectangular grid.
E.g. in this gridded photo example
   https://webkit.org/blog/4017/scroll-snapping-with-css-snap-points/ (Example 4)
if it wasn't a rectangular grid (if alternating rows were offset in
a subway tile pattern, for example), or there were empty slots in
the grid, it wouldn't work as intended.

(Apple said they were okay with marking it at risk.)

> (3) Example 1 and the rest of example 7, since they overlap the
> existing examples 1 and 2 (snap to top of a page with a buffer
> area, snap to center of a photo in a slideshow).

Yeah, these were drawn up to correspond to your examples, so that's
quite reasonable. :)

> I've also added the warning text to the top of the spec as resolved upon this morning [5].

Thanks!

~fantasai

Received on Friday, 15 January 2016 22:33:04 UTC