On Wed, Jun 11, 2014 at 10:41 AM, Kip Gilbert wrote:
> While beginning implementation I noticed that there is smooth
> scrolling functionality already implemented within
> ScrollFrameHelper::AsyncScroll, using simple splines via
> nsSMILKeySpline. This smooth scrolling behavior is used internall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While beginning implementation I noticed that there is smooth
scrolling functionality already implemented within
ScrollFrameHelper::AsyncScroll, using simple splines via
nsSMILKeySpline. This smooth scrolling behavior is used internally
and not expose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The bug has been split up to track individual parts of the implementation:
Bug 1010538 - Implement CSSOM-View scroll-behavior CSS property
Bug 1022818 - Implement CSSOM-View smooth scrolling DOM Methods
Bug 1022825 - Implement CSSOM-View smooth scroll
On Sunday, 25 May 2014 14:57:13 UTC-7, Robert O'Callahan wrote:
> On Mon, May 26, 2014 at 9:47 AM, Robert O'Callahan
> wrote:
>
>
>
> > On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
>
> >
>
> >> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
>
> >> > I guess what I'm arg
On Tuesday, 27 May 2014 15:12:56 UTC-7, Robert O'Callahan wrote:
> On Wed, May 28, 2014 at 6:14 AM, wrote:
>
>
>
> > Is this behavior acceptable or would it be more desirable to always return
> > the actual scroll position in DOM methods?
>
> All DOM methods that depend on the scroll position
On Wed, May 28, 2014 at 6:14 AM, wrote:
> Is this behavior acceptable or would it be more desirable to always return
> the actual scroll position in DOM methods?
>
All DOM methods that depend on the scroll position (not just
scrollLeft/scrollTop but getBoundingClientRect etc too) should always u
On Wed, May 28, 2014 at 5:36 AM, Kearwood Gilbert <
kearwood.gilb...@gmail.com> wrote:
> My greatest concern is that as platform conventions change, this behavior
> could (or should) be updated to match. Web developers that depend on
> particular acceleration / deceleration curves or time to comp
>
> Actually non-auto values for the ScrollBehavior DOM API override the
>
> scroll-behavior CSS property per spec. So I think the real question for us
>
> is whether to implement the scroll-behavior property, or the ScrollBehavior
>
> DOM API, or both. I think for now we should just implement
The ScrollBehavior DOM API would certainly be useful by itself and solve some
of our immediate needs (paged B2G home page, for example). I also imagine that
it would not preclude us from implementing the css property in the future if we
implement it carefully.
I would like to hear feedback reg
On Mon, May 26, 2014 at 9:47 AM, Robert O'Callahan wrote:
> On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
>
>> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
>> > I guess what I'm arguing is that smooth-scrolling vs. instant
>> > scrolling shouldn't be a per-element CSS propert
On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
> > I guess what I'm arguing is that smooth-scrolling vs. instant
> > scrolling shouldn't be a per-element CSS property, but rather a
> > per-callsite API argument.
>
> I think I tend
On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
> I guess what I'm arguing is that smooth-scrolling vs. instant
> scrolling shouldn't be a per-element CSS property, but rather a
> per-callsite API argument.
I think I tend to agree; I noticed the same thing during the CSS WG
meeting last w
On 25.05.2014 05:00, Jonas Sicking wrote:
I guess what I'm arguing is that smooth-scrolling vs. instant
scrolling shouldn't be a per-element CSS property, but rather a
per-callsite API argument.
It seems to me that it will be the case that for a given element
you'll sometimes want to do smooth s
On Fri, May 23, 2014 at 3:47 AM, Robert O'Callahan wrote:
>
>> One use case that has come up for us in FirefoxOS is the ability to
>> add a few elements to the top of a page, shifting down the contents of
>> the page, but then make that transparent to the user by adjusting the
>> scroll position a
On 23/5/2014, 6:12, Jonas Sicking wrote:
Basically we need an API like
div.addToScrollPosition(hightOfNewContent);
This would allow the browser to send this delta to the compositing
thread along with the newly updated painting of the DOM.
This is certainly a valid use case, and it has come up
On Fri, May 23, 2014 at 10:12 PM, Jonas Sicking wrote:
> How will "scroll-behavior: instant" work on platforms that use APZ? I
> worry about authors expect it to enable them to do a bunch of DOM
> mutations and then set the scroll position and allow them to be sure
> that rendering can't happen o
On 5/23/2014 6:12 AM, Jonas Sicking wrote:
That isn't possible with APZ since the user might be actively
scrolling and so if we just do something like
div.scrollTop += hightOfNewContent;
then the newly set scroll position will be based off of an old value
which has already changed on the compos
On Thu, May 22, 2014 at 1:50 PM, Kip Gilbert wrote:
> Link to standard:
>
> http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
How will "scroll-behavior: instant" work on platforms that use APZ? I
worry about authors expect it to enable them to do a bunch of
Summary:
CSSOM-View defines a new css property, 'scroll-behavior'. When set to
'smooth', scrolling boxes will be scrolled in a smooth fashion using a
user-agent-defined function.
Implementing this property will enable more fluid scrolling interfaces
consistent with modern UI paradigms withou
19 matches
Mail list logo
