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

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

I'm somewhat averse to adding another term to the scrolling space, particularly if it sounds too much like "viewport".  I think "scrollport" would ultimately end up the same thing as "visual viewport" based on my assumption of what the definition would be, and since the snap padding is already defined in terms of visual viewport inset we would be mixing terms.  Maybe "scroll snap inset"?  Or even just "scroll snap padding" to match the property name?

>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?)

Colloquially we refer to them as subscrollers at MSFT, maybe that's what you're thinking of?  However we use that to mean "the overflowing element with scrolling mechanism" rather than "the currently visible portion of the overflowing element with scrolling mechanism".

I actually like sharing visual viewport for both root and overflowing divs since (I think) we want the visual component of scrolling to behave more or less identically between root scrollers and subscrollers.  Viewport units and @viewport apply to the layout viewport so there's already disambiguation there.  Using visual viewport will also help future-proof this feature for if/when we define zoomable elements.

>> (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).

Sounds good to me, updated the ED to match.

>IIRC, we made it [resnap requirement] 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

Yeah, I think that area still needs further scrutiny too.  E.g. probably also needs to account for when the type is toggled and a few other things.  I'll put some more time into it.

I'd generally favor going more-strict here, must for both sounds fine to me.  I've updated the ED to specify that prox/mand MAY/MUST resnap and it MUST/MUST be the same position as before.  I see your updates put it at MUST/MUST resnap and it MUST/MUST be the same position as before.  I'm fine with that too -- any strong preference between those?

>We would prefer to leave it [2d snapping] in the spec and mark it at-risk, since there are use cases for it.
>(Apple said they were okay with marking it at risk.)

Ok.  Did you and Apple discuss any additional clarifications that should be added to address their original concerns?

Thanks,
-Matt

Received on Friday, 15 January 2016 23:27:37 UTC