W3C home > Mailing lists > Public > www-style@w3.org > April 2015

RE: [css-snappoints] Befine behaviour when content is larger than scroll container

From: Guido Bouman <m@guido.vc>
Date: Wed, 15 Apr 2015 09:44:09 +0000
Message-Id: <1429090694286.dc1d60c6@Nodemailer> (sfid-20150415_094414_828162_2464CD2E)
To: "Matt Rakow" <marakow@microsoft.com>
Cc: www-style@w3.org
Hi Matt,


The demo is up on http://guidobouman.github.io/jquery-panelsnap/ (Needs some work, I’m afraid)




Ideally this would work a lot smoother with the CSS solution. Lettering the kinetic behaviour up to the browser, and integrating it in it’s own scrolling engine. The plugin waits for scrolling to stop, and then scrolls towards the nearest panel. With the CSS solution this could be integrated into one step.


—
Sent from Mailbox

On Wed, Apr 8, 2015 at 8:16 PM, Matt Rakow <marakow@microsoft.com> wrote:

> Hi Guido,
> Cool plugin! :)  Is this functionality your plugin provides that we could use to try it out?  I'm curious how this behavior would work when panning the opposite direction.
> Thanks,
> -Matt 
>> From: Guido Bouman [mailto:m@guido.vc] 
>> Sent: Wednesday, April 8, 2015 5:24 AM
>> To: www-style@w3.org
>> Subject: [css-snappoints] Befine behaviour when content is larger than scroll container
>> 
>> Hi all,
>> 
>> 
>> Let me introduce myself first, as I think this is relevant for the issue I’m raising. I am the author of jQuery panelSnap (https://github.com/guidobouman/jquery-panelsnap). This CSS module would render my plugin obsolete, something I’m looking forward to, a lot.
>> 
>> There’s one issue that should be taken into account though: content that is larger than the scroll container.
>> 
>> With the current implementation this is not addressed. There should be a way to specify to only snap when there’s a snappoint in the visible area of the scroll container. I’m trying to describe something which feels in-between the current [mandatory] & [proximity] values for [scroll-snap-type]. It could be named [visible]. In this case [proximity] would be too loose, but [mandatory] too strict. You don’t want to change the behaviour of the current values, as they make a lot of sense in other situations. So adding a new one is my suggestion.
>> 
>> 
>> Kind regards,
>> Guido Bouman
>> 
>> +31 6 42945687
>>
Received on Wednesday, 15 April 2015 17:19:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC