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-boun...@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 <krinklem...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe> --- This email has been checked for viruses by AVG. http://www.avg.com _______________________________________________ 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-requ...@lists.wikimedia.org?subject=unsubscribe>
