New subject: How can we fix the two-stage page loading problem?

3 Sep 2017

Hi Mike,

Unexpected page jumps are never fun. They tend to be known as a "reflow" or
FOUC [1], and are common all over the web at different times.

Unfortunately, while there may be multiple gadgets / features exhibiting
this undesired behaviour, it is not a general problem or limitation. As
such, at the infrastructure level, no amount resourcing can make this class
of bugs go away.

In a nutshell, there are two primary ways to modify the page of a web site:

* Styling rules (CSS): A declarative way to define rules for how certain
page elements should look. (E.g. any "header" should be "blue".)
* JavaScript programming (JS): A way to provide and execute any arbitrary
program code. Including the ability to create new elements, create
interactions, and even build entirely new applications.

The styling rules are declarative and can be loaded and applied by the web
browser before any content is shown. They apply continuously and
retroactively. As such, most websites (including MediaWiki) do made the
decision that it is worth delaying the initial show of article content by
first loading all style rules (including those from Gadgets). That way, the
initial show will consider all style rules from the start. (Instead of
starting with unstyled plain text from the top left corner, and
progressively applying each style as we go).

The program code, on the other hand, is by design mostly asynchronous and
cannot happen "instantaneously" (much like downloading something, or
starting an application, or performing a computationally involved action).
The program itself is in control of how and what it shows visually. It is
in charge of whether to show individual pieces directly as they complete,
or to insert everything at once after everything is complete. That is up to
individual programs to decide.

For developers, it is best practice to never insert or modify visual
elements on the page from program code, unless their layout space is
reserved ahead of time from HTML or CSS - precisely to avoid reflows. To my
knowledge, there are no reflows on regular article views caused by
MediaWiki core, nor any of the Wikimedia-maintained extensions (with the
notable exception of certain CentralNotice banners, tracked as [2]).

Some experimental Beta Features may have shipped in the past with a reflow
bug, but these can (and for the most part, have) been addressed.

That leaves Gadgets, and in that context, this is mostly limited by
volunteer resourcing and program quality. Finding the right balance between
style rules and program code is not always easy. It is typically easier to
write program code without style rules. And as such, some users do it
without. I've been in that situation myself as volunteer developer. With
limited time, I can either spend time making the actual feature work better
after you click it, or spend time avoiding a reflow. With more time,
eventually things improve. But this is a bug for individual features or
gadgets to address. There is not much we can do about it at the
infrastructure level. When the style rules aren't there, they aren't there.
And when a program later adds an element to the page, you'll want the web
browser to show that in the same way as if it was there all along - which
means other content essentially moves or jumps out of the way.

For common use cases (like adding sidebar links or tabs), it may be
possible to establish conventions that are easy to re-use so that people
don't have to spend as much time thinking up new style rules. But overall,
each use case will require its own style rule one way or another.

-- Krinkle

[1] https://en.wikipedia.org/wiki/Flash_of_unstyled_content
[2] https://phabricator.wikimedia.org/T52865 - CentralNotice: Page content
shifts

Michael Peel wrote:
...

 This is possibly the most annoying feature of the Wikimedia projects at the moment.
You access a page. Then you start reading or editing it. And
then suddenly the page jumps when a fundraising banner / central notice /
gadget / beta feature loads. So you have to start reading the page again,
or you have to find where you were editing again, or you have to undo the
change you just made since you made it in the wrong part of the page.
...
  I understand that this isn't intentional.
Presumably there is a phabricator ticket about this. But how can we fix this - does
this need
more developer time, is this an external problem that we need someone else
to fix, or is this a WONTFIX?
...
  Thanks,
 Mike 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?