Skip to main content

Jquery.scrolling: check HTML elements visibility in Viewport after a page scroll or resize

With responsive design and adaptive layouts constantly increasing their audience, the importance of controlling the visibility of HTML elements inside the viewport is continuosly increasing. Unfortunately, neither javascript nor the popular jquery frameworks provide a native way to check the visibility status of an element after a page scroll or resize.

This is the main reason behind the development of jquery.scrolling, a jQuery plugin that does exactly this: it basically adds the scrollin and scrollout custom events that will fire when any given element becomes visible/invisible in the browser viewport. This allows you to:

  • automatically or programmatically show/hide any HTML content as soon as it comes inside or outside the browser viewport (i.e. when the user scrolls to them).
  • prevent unnecessary processing for content that is hidden or is outside of the browser viewport.
  • trigger a custom function or behaviour (such as loading external AJAX content) when a certain point of the page is reached.

and more.

Read More

Using JQuery UI and Bootstrap togheter in the same web page

In the past few months we’ve seen the Bootstrap framework became more and more popular among web developers. The reasons are fairly obvious, we’re talking  about a powerful CSS/JS enhancement library featuring a lot of useful stuff to build a responsive, mobile-friendly webpage fully compatible with every major browser/device. The most recent version of the framework (v3.3.1 by the time of this post) contains a lot of useful javascript plugin requiring JQuery v1.9.0 or higher in order to work: there’s no doubt that some of these websites are also running JQuery UI.

These 2 frameworks are indeed able to work togheter, but we need to pay attention to at least two naming conflicts between them which need to be fixed in order to avoid JS errors and, most importantly, get them to work properly. We’re talking about the tooltip and button plugins, which happen to exist in both of these libraries with the exact same name.

The Issue.

Let’s take the tooltip plugin as an example. Open the address and look at the sample code – by clicking on the “view source” link – to see how the JQuery UI tooltip plugin actually works:

The highlighted text shows a call to the tooltip function which, thanks to JQuery UI, is added at runtime to any JQuery object. Bootstrap does the exact same job, as shown in the official tutorial:

This nasty naming conflict prevents the plugins to work an might also generates some Javascript errors depending on the framework <script> references order inside the web page. For example, here’s what you’ll most likely get in your Javascript Console if Boostrap is inserted after JQuery UI and the latter’s tooltip plugin is being used:

Uncaught TypeError: Cannot read property ‘documentElement’ of null

We get this message because the tooltip plugin provided by JQueryUI has a completely different – and hardly compatible – interface than the Bootstrap plugin sharing its name.

 The Solution.

The best way to make the 2 libraries blend togheter and “constructively” fix the aforementioned naming conflicts is to use the not-so-well-known $.widget.bridge plugin, which allows us to re-define each previously assigned prototype function name. The plugin is already included inside the JQuery UI standard distribution package, so we won’t add any additional stuff to our website. The usage is quite simple:

These commands need to be executed after the JQueryUI and before the Bootstrap js file references. In the following example we can see a full implementation example in the <head> block of a common webpage:

After you do this, the tooltip and button prototype methods will be univocally routed to the Bootstrap ones: those provided by JQuery UI will also be usable as long as we call them by using the new alias we gave them: uitooltip and uibutton.

References: (my answer on StackOverflow which kinda inspired this post).


ASP.NET – MantainScrollPositionOnPostback for Chrome and most recent browsers

To keep (or to say it better, to recover) the page scrollbar position after a postback is definitely a feature any form-containing page should have. This used to be a trival task for any ASP.NET developer, who could just by add a simple configuration parameter to their code:

On web.config level:   <pages maintainScrollPositionOnPostBack="true" />

On page level:   <%@ Page MaintainScrollPositionOnPostback="true" %>

On code-behind level:  Page.MaintainScrollPositionOnPostBack = true;

Unfortunately all these methods, other than being unavailable with Razor, aren’t working anymore with any recent non-IE browser. Sure, it’s still possible to detect and configure the behavior of each one of them by using the ASP.NET Browser Definition Files accordingly, but in order to achieve better results it’s advised to adopt a centralized, versatile solution. Here’s a simple script based on the popular jQuery framework who does the trick in a cross-browser compatible way:

For WinForms:

For Razor (and also for any web page):

Needless to say, in order to make these scripts work you have to place the input element on top (asp:HiddenField for the WinForms one) inside the form element who will handle the Postback.

If you don’t like the standard HTML <input>  you can use the helper method equivalent provided by Razor, such as: