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? Cheers, Peter
-----Original Message----- From: Wikimedia-l [mailto:wikimedia-l-bounces@lists.wikimedia.org] 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 krinklemail@gmail.com 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] 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
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
_______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
--- This email has been checked for viruses by AVG. http://www.avg.com