Partial fix Navigating to posts broken when page contains Twitter media embeds

It's not broken, as such.

The browser navigates to the correct post, but some browsers lose that position when other content (tweets in this case) load in and start shifting the page around.

It may be possible to workaround. There are already workarounds in place specifically for images, but even that doesn't work as expected in all cases.
 
Chris D said:
It's not broken, as such.

The browser navigates to the correct post, but some browsers lose that position when other content (tweets in this case) load in and start shifting the page around.

It may be possible to workaround. There are already workarounds in place specifically for images, but even that doesn't work as expected in all cases.
Click to expand...
Understood - I meant the workarounds are not working. Is it possible to set the size of the the container for the embed prior to loading them? Seems like Twitter embeds are always the same size, so this would be possible.
 
rfc0001 said:
Twitter embeds are always the same size, so this would be possible.
Click to expand...
They aren't. They'll have a different height depending on the length of the Tweet, whether it's a RT, whether it has media in it and so on.

We can probably do some other things though.
 
So I'm going to call this a partial fix, though it does also depend on browser support. Notably, our most recent set of changes try to improve the browser's use of scroll anchoring via the scroll-padding property. This is currently only supported in Chrome/Chromium and Firefox, though Safari/Webkit did note their interest in a bug report back in 2017.

Scroll anchoring in a browser tries to prevent reflows above the visible area from changing the visible content. This worked pretty well without our changes, though there was a situation where it wouldn't work as expected if the anchor took you to a post directly after a one with embeds that resize. The scroll padding should help with that. Loading up the example URL in the original report works as expected for me, even when the embeds are slow to load.

Other changes (such as expanding our existing attempts to implement something like this) are difficult because we don't want to interfere with a user who has done some manual scrolling and snap them back unexpectedly (particularly where anchoring has done the job for us) and that the browsers can now trigger scroll events internally in some circumstances. Other approaches such as trying to pre-allocate space for an embed may work in some very specific scenarios, but they cause problems in others. In many cases, the size of an embed may vary wildly depending on the content (whether it has an image, how long it is, the aspect ratio, etc). So at this time, browser handled scroll anchoring seems like the best solution.
 
Top Bottom