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

On 01/15/2016 03:26 PM, Matt Rakow wrote:
>> 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.

Well, yes. What I was saying is that the word "scrollport" could
be used to mean the visual viewport both for the root element and
any subscrollers, and that would make "viewport" less confusing
because it would only have one meaning--the root viewport.

> Maybe "scroll snap inset"?  Or even just "scroll snap padding"
> to match the property name?

We're naming a rectangular area here... it's not padding or an
inset, which is an offset from outer edges!

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

Yes, agree that we should share the same term for both the root
and overflowing divs; just think that making the term a bit more
different from "viewport" -- which in CSS syntaxland, is specific
to the root scroller -- would be a good idea.

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

Well, yes. We realized that since in no other case (not for any user
gesture or any JS API call) is the scroller ever scrolled to a
position where it *would have* snapped, had the user landed there,
it doesn't make sense for a content change to land it within range
of a proximity snap and not snap. It's, as you said, an invalid
scroll position...

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

Not specifically, no. But we did just check in a bunch of clarifications
in response to Sebastian Zartner's email:
   https://lists.w3.org/Archives/Public/www-style/2016Jan/0099.html

~fantasai

Received on Friday, 15 January 2016 23:52:58 UTC