Set Color for Extra Page Parts Visible During Rubber Band Scroll

Javascript/CSS to disable rubber-band end of page scroll for Safari on iPad?

iScroll does a fantastic job of handling framed scrolling. It may be worth looking at.

http://cubiq.org/iscroll-4

Prevent body scrolling but allow overlay scrolling

Theory

Looking at current implementation of the pinterest site (it might change in the future), when you open the overlay, a noscroll class is applied to the body element (setting overflow: hidden) making the body no longer scrollable.

The overlay created on-the-fly or already injected in the page and made visible via display: block — it makes no difference – has position : fixed and overflow-y: scroll, with top, left, right and bottom properties set to 0: this style makes the overlay fill the whole viewport (but now we are in 2022, so you may use inset: 0 instead).

The div inside the overlay is in position: static so the vertical scrollbar is related to that element. This is resulting in a scrollable but fixed overlay.

When you close the overlay, you have to hide it (using display: none) and you could even remove the node via javascript (or just the content inside, it's up to you but also depends on the nature of the content).

The final step is to also remove the noscroll class applied to the body (so the overflow property gets back to the value it had previously)

---

Code

Codepen Example

(it works by changing the aria-hidden attribute of the overlay in order to show and hide it and to increase its accessibility).

Markup

(open button)

<button type="button" class="open-overlay">OPEN LAYER</button>

(overlay and close button)

<section class="overlay" aria-hidden="true" tabindex="-1">
  <div>
    <h2>Hello, I'm the overlayer</h2>
    ...   
    <button type="button" class="close-overlay">CLOSE LAYER</button>
  </div>
</section>

CSS

.noscroll { 
  overflow: hidden;
}

.overlay { 
   position: fixed; 
   overflow-y: scroll;
   inset: 0; }

[aria-hidden="true"]  { display: none; }
[aria-hidden="false"] { display: block; }

Javascript (vanilla-JS)

var body = document.body,
    overlay = document.querySelector('.overlay'),
    overlayBtts = document.querySelectorAll('button[class$="overlay"]'),
    openingBtt;
    
[].forEach.call(overlayBtts, function(btt) {

  btt.addEventListener('click', function() { 
     
     /* Detect the button class name */
     var overlayOpen = this.className === 'open-overlay';
     
     /* storing a reference to the opening button */
     if (overlayOpen) {
        openingBtt = this;
     }
     
     /* Toggle the aria-hidden state on the overlay and the 
        no-scroll class on the body */
     overlay.setAttribute('aria-hidden', !overlayOpen);
     body.classList.toggle('noscroll', overlayOpen);
     
     /* On some mobile browser when the overlay was previously
        opened and scrolled, if you open it again it doesn't 
        reset its scrollTop property */
     overlay.scrollTop = 0;
     
      /* forcing focus for Assistive technologies but note:
    - if your modal has just a phrase and a button move the
      focus on the button
    - if your modal has a long text inside (e.g. a privacy
      policy) move the focus on the first heading inside 
      the modal
    - otherwise just focus the modal.

    When you close the overlay restore the focus on the 
    button that opened the modal.
    */
    if (overlayOpen) {
       overlay.focus();
    }
    else {
       openingBtt.focus();
       openingBtt = null;
    }

  }, false);

});

/* detect Escape key when the overlay is open */
document.body.addEventListener('keyup', (ev) => {
   if (ev.key === "Escape" && overlay.getAttribute('aria-hidden') === 'false') {
      overlay.setAttribute('aria-hidden', 'true');
      body.classList.toggle('noscroll', false);
      openingBtt.focus();
      openingBtt = null;
   }
})

---

Finally, here's another example in which the overlay opens with a fade-in effect by a CSS transition applied to the opacity property. Also a padding-right is applied to avoid a reflow on the underlying text when the scrollbar disappears.

Codepen Example (fade)

CSS

.noscroll { overflow: hidden; }

@media (min-device-width: 1025px) {
    /* not strictly necessary, just an experiment for 
       this specific example and couldn't be necessary 
       at all on some browser */
    .noscroll { 
        padding-right: 15px;
    }
}

.overlay { 
     position: fixed; 
     overflow-y: scroll;
     inset: 0;
}

[aria-hidden="true"] {    
    transition: opacity 1s, z-index 0s 1s;
    width: 100vw;
    z-index: -1; 
    opacity: 0;  
}

[aria-hidden="false"] {  
    transition: opacity 1s;
    width: 100%;
    z-index: 1;  
    opacity: 1; 
}

Cairo + rubber band selection: gui very very slow

Some general tips when drawing with Gtk+/Cairo:

• Draw only as much as neccessary. The idea is to keep track of the areas that have changed, and redraw only those. Gdk does this in parts automatically for you. When it calls expose (in Gtk3 draw), it applies a clipping mask so only the "invalidated" pixels are changed by your drawings.
• You can tell Gdk which areas should be redrawn with GdkWindow.invalidate_rect. Right now your call to widget.queue_draw invalidates the whole window, so you draw too many pixels.
• If you have complex elements that are in a non-invalidated area, you'd still draw / calculate them in expose - they'd just not make it to the screen. For this, you can check event.area (a GdkRectangle). If your elements dont intersect this area, you don't have to bother drawing them, as those pixels are clipped anyway.
  
  • Here lies a trade-off. Sometimes it saves a lot if you calculate whether an element is visible or not. Sometimes it's faster just to draw a few extra pixels if it saves a lot of geometry calculations. You have to decide case by case.
• Expose may be called once for each invalidate_rect, but it's also possible that Gdk recognizes when you invalidate several small/overlapping rects, and just calls it once with a larger rect.
• You shouldn't mix 'raw' Gdk and cairo calls. The Gdk calls (operating on gc) are going away in Gtk3. Now you say your writing this only in Gtk2, but if you want to reuse the code one day in another project, it'll help if you write it now with Cairo. There might be some performance differences, too.
• You should be aware of anti-aliasing. By default, everything is antialiased in cairo (and I don't know whether you can turn it off). That's a good thing most of the time, but sometimes crisp pixels look nicer - and they are a lot faster, too. If you want non-antialiased rectangles, draw filled rectangles on integer coordinates, and stroked rectangles (1px lines) on half-integer coordinates.
• In your concrete example, your Pixmap seems unneccessary. On thing you could try though is to render your stuff to a pixmap or cairo surface when it changes, then in expose copy the invalidated areas from the pixmap over, and draw the rubber band on top. However, I find that it's often easier and faster to just do the drawing directly. If you are doing this manual buffering, you might want to think about disabling the built-in double-buffering (GtkWidget.set_double_buffered) and the automatic drawing of the background (GtkWidget.set_app_paintable).

Here is a little program I make: rubberband.py. I took the code from a project of mine and added a couple of circles one can select. Hope you can use it as a starting point.

---

Related Topics