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:

Reply via email to