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>
