Incessantly-jumping Web Pages

Am I the only one being driven to near-distraction by the fact that most web pages never seem to quit loading and even when (I think) they have finished loading, they continue to intermittently jump up or down? It seems bits of content are added, deleted or moved non-stop on many pages I visit. I have begun to flinch, curse or just quit the page following extreme frustration. I get this recurring wish that my that screen (like the windows in some public transports with a sign “In Case of Emergency – BREAK GLASS.”) had a hammer affixed for emergency exit. It is that frustrating.

Are others suffering this phenomenon? Is it dependent on platform/OS/browser (I use MacOS, Safari)?

If any of our Ratburgher experts can explain, I would appreciate it. I would also be greatly indebted for a fix.

5+

Users who have liked this post:

  • avatar
  • avatar
  • avatar
  • avatar
  • avatar

Author: civil westman

Driven to achieve outward and visible things, I became a pilot, a doctor and a lawyer. Eventually, I noticed the world had still not beat a path to my door with raves. Now, as a septuagenarian I still work anesthesia part-time, fly my flight simulator to keep my brain sparking and try to elude that nagging, intrusive reminder that my clock is running out. Before it does, I am trying, earnestly, to find a theory of everything - to have even a brief "God's-eye" view of it all before the "peace which passeth all understanding."

9 thoughts on “Incessantly-jumping Web Pages”

  1. You are not alone. I figured it was because the 2 things I use to access the internet (my ancient iPad and work PC) are old and can’t load all the pictures everybody seems to want to put up. I can’t ever get one of the local news station’s site to load at work through whatever ancient version of IE we are running. I have stopped going to a fair number of sites because it’s not worth it. Thankfully, Ratburger is not one of them!

    3+

    Users who have liked this comment:

    • avatar
    • avatar
    • avatar
  2. The jumping around of Web pages after initial loading is usually due to over-use or abuse of Dynamic HTML (DHTML) (also referred to as JavaScript/DOM/CSS).  Like many bad ideas, it was originally invented by Microsoft (in 1997) and has now become near-ubiquitous on the Web, especially on glitzy over-produced sites.

    In the original concept of the Web, the HTML for a page was completely static as seen from the browser.  It may have been generated on the fly by the server (for example, in reply to a query), but the result was a HTML document containing the entire content of the page.  The browser could display this content as it arrived (which was particularly important for users on slow, dial-up connections) and, once displayed, it did not change.  Images caused no problem because every image in well-formed HTML specifies its size in pixels, which allows the browser to lay out the page with a box the right size for the image which is filled in with the image when it finishes downloading.

    With DHTML, however, the content of a page is allowed to change after it has been downloaded by running JavaScript code which modifies the content of the HTML or the document’s style sheet(s) on the fly.  A change which results in the size or shape of something which the browser has already laid out and displayed will cause the rendering of the page to be re-done, which will usually cause everything appearing subsequently in the document to jump around.

    Consider, for example, a site which includes a box that displays advertisements served by an ad server.  Usually, the ad service will prescribe the size of the box and then, after the page is loaded, run JavaScript which goes out to their server and fetches ads and HTML link code which is plugged into the box on the user’s browser.  As long as the ads are the same size as the original static box everything will be fine, but consider a sloppy/sleazy ad network which sometimes serves different-sized ads.  When its JavaScript code plugs them into the user’s Web page, everything after the ad will bounce.  If the JavaScript periodically goes back to the server for new ads and they continue to change in size, things will bounce every time a differently-sized ad is shown, for as long as the page containing the ad server’s JavaScript code is displayed.

    While this example uses the common case of ad servers, there are a multitude of JavaScript animated “widgets” people add to their Web pages, and any one of these which changes the size of the part of the document it modifies will cause the page to bounce.

    There is no real defence against this except for blocking JavaScript which will, on today’s Web, cause a lot of Web sites to break.  Since advertising is a principal culprit, running a good ad blocker will cut down the clutter and irritation.  I find I simply stop visiting sites will lots of bouncing and other visual fireworks.

    6+

    Users who have liked this comment:

    • avatar
    • avatar
    • avatar
    • avatar
    • avatar
    • avatar
  3. I find this supremely irritating, as I frequently try to click on something which jumps out of the way, leaving me to click on some nonsense — sometimes dangerous nonsense.  I suspect that some page elements load but do not display until an OnClick event, which probably got that way for all the right reasons, namely, prioritizing what you want vs what “needs” to be loaded first, provided that any of that crap needs to be loaded at all — sigh.  I also suspect that this OnClick functionality is abused specifically for the purpose of causing erroneous clicks where somebody wants it — but not you.

    One justification for all of this nonsense is the variety of monitor sizes and individual computer capabilities.  As John points out, specifying element sizes in pixels gets yields a predictable, quick presentation.  Well in the early days of the visual web, screens were nominally 640 x 480, or somewhat less (IIRC 640 x 440 or sommat) if you used a contemporary Mac.  This made it easy to hard-code web pages to look perfect.  Fast forward several years, and you get 1024 x 768 or 1280 x 960, and a website hard-coded to display nicely on a 640 x 480 monitor is suddenly impossibly tiny.

    Soooo, it became more popular to specify things in terms of percentages (“this picture’s width should be 75% of the width of the page”).  Problem — this is even easier to get wrong than hard-coding a single size.  If my picture elements have a padding of 2 pixels on each side, and I put a 75% next to a 25%, that’s right,m they show up one on top of the other, because there isn;t 100% plus eight pixels to work with.  So HTML in its wisdom flows the content to the next place it can put it.  OR, worse yet, it adds a scroll bar at the bottom of the page, so that you have to scroll the page left and right.  Oh, and the scroll bar just took ten pixels away from your screen height, which can cause a horizontal scroll abr to now appear.

    Various means to deal with this have been developed.  Most of them are awful.  Add to this the intentional Microsoft strategy of “Make, Take, or Break”, and you get a universe of things which do not work in ANY configuration except the actual machine used by the website designer.

    For a long time, machines limited the speed of element loading because (among other reasons) graphics were rendered by the CPU, which was already doing everything it could just to get through its business.  Some machines had powerful processors and graphics cards, and others did everything while jugging in a handstand.  So methods were developed to allow a graceful degradation, except that it didn’t work out that well.  Why?  Because HTML as designed already did that.  And we had gotten hopelessly far by now from simple pages which allowed the browser to decide how to display it.  HTML was intended to provide content, not to perform desktop magazine layout graphic design nonsense.  But people paying to put content up wanted it to look a certain way.

    E-books demonstrated the same failing later when people published e-books by dashing off a .pdf of the text, and then nobody could read the darned thing.  We *and our machines* should be reading text, not looking at pictures of text.

    Tables and frames were introduced as ways to manage some of this.  But tables were soon abused into holding the whole content of the page as content frameworks, rather than, you know, holding tabular data.  And frames were quickly abused into traps you couldn’t back out of, and ways to steal content by effectively hot-linking entire sites.

    Technical means were developed to overcome these excessive freedoms.  Javascript runs in the browesr, not the server, and offloads the work to your PC.  meanwhile, your PC waits for each element to load, then processes the next task involved in moving things around to accomodate the arriving element.  Wait a minute!  Why not just send the SIZE of the element first so that the browser can pre-layout the page?

    Well, that’s where we started, wasn’t it?  And so we are stuck with a browser full of dancing baloney.

    DANCING BALONEY

    5+

    Users who have liked this comment:

    • avatar
    • avatar
    • avatar
    • avatar
    • avatar
  4. John Walker:
    The jumping around of Web pages after initial loading is usually due to over-use or abuse of Dynamic HTML (DHTML) (also referred to as JavaScript/DOM/CSS).  Like many bad ideas, it was originally invented by Microsoft (in 1997) and has now become near-ubiquitous on the Web, especially on glitzy over-produced sites.

    In the original concept of the Web, the HTML for a page was completely static as seen from the browser.  It may have been generated on the fly by the server (for example, in reply to a query), but the result was a HTML document containing the entire content of the page.  The browser could display this content as it arrived (which was particularly important for users on slow, dial-up connections) and, once displayed, it did not change.  Images caused no problem because every image in well-formed HTML specifies its size in pixels, which allows the browser to lay out the page with a box the right size for the image which is filled in with the image when it finishes downloading.

    With DHTML, however, the content of a page is allowed to change after it has been downloaded by running JavaScript code which modifies the content of the HTML or the document’s style sheet(s) on the fly.  A change which results in the size or shape of something which the browser has already laid out and displayed will cause the rendering of the page to be re-done, which will usually cause everything appearing subsequently in the document to jump around.

    Consider, for example, a site which includes a box that displays advertisements served by an ad server.  Usually, the ad service will prescribe the size of the box and then, after the page is loaded, run JavaScript which goes out to their server and fetches ads and HTML link code which is plugged into the box on the user’s browser.  As long as the ads are the same size as the original static box everything will be fine, but consider a sloppy/sleazy ad network which sometimes serves different-sized ads.  When its JavaScript code plugs them into the user’s Web page, everything after the ad will bounce.  If the JavaScript periodically goes back to the server for new ads and they continue to change in size, things will bounce every time a differently-sized ad is shown, for as long as the page containing the ad server’s JavaScript code is displayed.

    While this example uses the common case of ad servers, there are a multitude of JavaScript animated “widgets” people add to their Web pages, and any one of these which changes the size of the part of the document it modifies will cause the page to bounce.

    There is no real defence against this except for blocking JavaScript which will, on today’s Web, cause a lot of Web sites to break.  Since advertising is a principal culprit, running a good ad blocker will cut down the clutter and irritation.  I find I simply stop visiting sites will lots of bouncing and other visual fireworks.

    Like NRO

    2+

    Users who have liked this comment:

    • avatar
    • avatar
  5. Bryan G. Stephens:
    It is all evil.

    Programmers can ever leave something that works alone. Why is that? We always etc ew features we did not ask for.

    100% on target! The latest “upgrade” to our EMR at the hospital was awful and the only thing we asked for was a check box for right or left arm for BP. Did we get it? Heck no!

    2+

    Users who have liked this comment:

    • avatar
    • avatar
  6. Blondie:

    Bryan G. Stephens:
    It is all evil.

    Programmers can ever leave something that works alone. Why is that? We always etc ew features we did not ask for.

    100% on target! The latest “upgrade” to our EMR at the hospital was awful and the only thing we asked for was a check box for right or left arm for BP. Did we get it? Heck no!

    The programmers are preparing you for the dorsal probe BP monitor.

    1+

    Users who have liked this comment:

    • avatar

Leave a Reply