I guess they are going to track the DOM position rather than the scrolling
offset. This does make sense, and we probably should do this as well.
There are certain details we would need to take care. Not sure whether they
are tracking the position based on the center or the top (or the bottom?).
Ah, I think I spoke to quickly -- the jumping is caused by javascript,
but not by javascript scrolling. It's certainly possible that javascript
hiding of large elements would be treated as reflow events by this
approach...
/a
On 5/20/16 15:19, Adam Roach wrote:
There is one FAQ on that
There is one FAQ on that page, and I think it basically says the opposite.
/a
On 5/20/16 12:35, Kartikaya Gupta wrote:
Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en
kats
On Fri,
Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en
kats
On Fri, May 20, 2016 at 12:15 PM, Adam Roach wrote:
> On 5/20/16 10:13, Gijs Kruitbosch wrote:
>>
>> On 20/05/2016
On 5/20/16 10:13, Gijs Kruitbosch wrote:
On 20/05/2016 16:11, Tobias B. Besemer wrote:
Plz open e.g. this URL:
https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations
FF49a1 loads the page, jumps to "Alternative implementations", stays
there for 1-2 sec and then go ~1
On 20/05/2016 16:11, Tobias B. Besemer wrote:
Plz open e.g. this URL:
https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations
FF49a1 loads the page, jumps to "Alternative implementations", stays there for
1-2 sec and then go ~1 screen-high (page) down.
Can someone very
6 matches
Mail list logo