Is it not possible to display a warning immediately that more things are going 
to load, so that one waits until it is all done?

-----Original Message-----
From: Wikimedia-l [] On Behalf Of 
James Salsman
Sent: Sunday, 03 September 2017 6:44 PM
To: Wikimedia Mailing List
Subject: Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

Can't we render each gadget in a Foundation-controlled <div> with a height 
taller than the gadget ever typically flows to?

On Mon, Sep 4, 2017 at 12:00 AM, Krinkle <> wrote:
> 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]
> [2] - 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
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> and 
> New messages to:
> Unsubscribe:, 
> <>

Wikimedia-l mailing list, guidelines at: and
New messages to:

This email has been checked for viruses by AVG.

Wikimedia-l mailing list, guidelines at: and
New messages to:

Reply via email to