10 03, 2015

Building a paginated listing with only HTML and CSS for Responsive Design

By | 2017-06-16T12:34:34+00:00 March 10th, 2015|Categories: Web Development|Tags: , , , , , , , , , , |

Most paginated listings on the web are managed either with server side logic, javascript, or a combination of both. With the first option, the user’s browser wait on network traffic back to the server and back down again. Even if the data is as succinct as possible, a bad connection or crowded wi-fi can make your site look slow. An example of this sort of method can be seen on google search results. Each page requires a new querystring and page load. With the second option, the html for each page can be loaded into the dom on the first page load and then a script will manage displaying each separate page or section of data as the user interacts with the page’s navigation. The downside of this approach is that if script is disabled, as is so often the case on computers with high security settings, the only ways to recover are to display either a single page at a time using server side logic, or to display the entire listing without pagination at all, which can make for an enormously long page. The last option uses a combination of both, and can result in a smoother user experience, but also then suffers from the drawbacks of both. This last option can be seen in effect by scrolling to the bottom of a facebook page; the first “page” of content is loaded up first, and only by scrolling down is additional content then called down from the server and added to the page via javascript.

I think that’s enough of the bad news! You’re here to find a way to circumvent all of these headaches so that you can give even the most restrictive browsers as much access to your content and with the very best user experience possible.

Lets get started shall we?

We’ll start with a sample of how you might list results currently. For ease of reading and instruction we’ll keep the content short and sweet, and we’ll keep our pages limited to 3 results per page.

We have to make a few changes to this to make it work in pages. Let see what that looks like:

Now that we’ve got them separated into page containers there’s one thing that’s important to make note of. You may have noticed that page1 is actually listed last. It’s also important to note that the order of all pages that aren’t the first page isn’t relevant to this process, only that the page you want displayed by default, or first, is the last child of the .pages container. This is so that we can take advantage of a special kind of css selector in order to get around css’s inability to select nodes up the dom. If you intend to use my advanced method below however, it is necessary to display the pages in order with the only exception still being that the first page be listed last.

That selector is called the General Sibling selector, which is the last selector outlined here. This selector selects all elements that match the right hand selector that are siblings of the left hand selector only as long as they appear in the html after the left hand selector. In our sample, a rule for “#page3 ~ .page” would select #page2, and #page1, but “#page2 ~ .page” would only select #page1.

We’re going to use that selector to hide all pages that aren’t the first one.

This ensures that when the webpage loads, only one page of your list will display, and that it will be the first page. In order to give the user a way to change the pages, we need to create a page listing in our html.

The new .pageNav element can go anywhere on the page, but it must not be added as the last child of the .pages div so that our previous rules will continue to show and hide the correct divs. To get those links to functionally show their respective pages we need to make an additional tweak to our css:

These new rules showcase the two selectors that make this whole thing work. One we’ve already discussed. The new one is the :target selector, which applies to an element if it has an id that matches the hashtag (for lack of a better word) in the url. When one of the nav links is clicked, it appends it’s href to the url. A live demo of this in action is available here.

The key to this html/css trick is just outputting your first page last, which is easily possible in most content management systems. The rest of it is very simple. This solution is responsive, is 508 compliant, and search engine friendly.

Another benefit this method has over javascript is that it take advantage of the browser’s ability to remember the previous page’s hash tag, which means that if a user follows a link in your paginated listing, and clicks the back button, they’ll retain their active page.

To be fair to the other pagination methods above, this too comes with a drawback, although it is in my opinion a minor drawback. In order for this method to be fully encapsulated by html and css all html content for all pages must be loaded on the first page load, which can slow down the page if the content of each page is exceptionally large. In the case of most paginated listings however, that is rarely the case.

Advanced

Now that the base concepts have been outlined, I’d like to show you what I consider to be the correct and most exhaustive solution for applying this sort of method to a responsive site where we don’t want to limit the user to only the core html/css experience if they’ve allowed scripts on their browser.

NOTE: This implementation uses jQuery for ease of understanding, and portability. jQuery is, however, a very large library and might not be the most efficient way of accomplishing this from a performance perspective.

First, lets look at some easy changes to the html:

Specifically what we’ve done here is add previous and next buttons to each page. The reason these have been added here, and not with the rest of the navigation buttons is because without javascript enabled, we can’t properly style or control the behavior of them dynamically, so we need static but functional links that we’ll only render on our mobile view. Functionally, at smaller screen sizes (like smart phones), requiring the user to click on one of several small links next to other small links can be frustrating, and giving them the same pagination functionality, but restricting them to only previous and next navigation is a simple process that drastically improves user experience. For all of these changes, we’ll need to update our css:

You’ll notice several new lines, so lets break them down.

  • The first change is to our existing rules. We’ve added :not(.js) to the .cssPagination selector. This is going to enable us to maintain css control over the general layout of the elements, even if (when) we upgrade the functionality with javascript.
  • Next we’ve taken the liberty to hide the next and previous buttons by default, so that we don’t have two lines of navigation controls for the user to interact with.
  • The next 3 lines are going to work specifically with the two new classes (js and paginationActive) in order to give our script the ability to manage pagination without having to get its hands dirty mucking about with styles.
  • Last is the media query. If you’re familiar with responsive design and development you’re already familiar with what this does. For those of you who might not recognize the tag: this call “@media screen and (max-width: 480px)” tells the browser to only enable these rules when the device reading the browser has a screen, and the current resolution is 480 pixels wide or less. For more information on media queries read here.

Lastly we’ve added a script section, which will take over pagination when scripts are enabled (and in our case when jQuery is present):

To see this all together in action click here. To see how this setup looks without javascript enabled all you need to do is set addInjQuery at the top of the script file to false. The demo also demonstrates how the previous and next buttons respond in a responsive manner to the available screen resolution both with and without the script enabled.

NOTE: To use this script as is, I recommend using the version shown here and not the one in the demo, as it is hard-coded to a specific version of jQuery, rather than this version which is compatible with virtually any version of jQuery that you might already have on your site.

The script that was added now only works when scripts are enabled and jQuery is available. This allows the content to be enhanced progressively depending on what features are or aren’t enabled on your user’s browser and device. This ensures that no matter what device or browser your client is using they will get the best possible experience from your site in the most efficient manner possible.

To recap this method for how to paginate a listing on a web page is responsive, not dependant on javascript, not dependant on posts to the server (either synchronous or asynchronous), 508 compliant, and in most cases incredibly efficient. It is also heavily customizable to fit in any website design in any language.

That’s all for this topic. To read more by some of our other incredibly talented staff see below:

4 10, 2013

Progressive Enhancement

By | 2017-08-11T16:23:44+00:00 October 4th, 2013|Categories: Web Development|Tags: , , , , , , , , , , , , |

I had the privilege of attending “An Event Apart” in Austin, TX this week and feel like I have come home with an abundance of knowledge about leading practices in web development. This conference is an educational session for those passionate about standards-based web design and this year focused heavily on best practices for our multi-device world. Many developers are facing the challenges of 1000s of screen sizes and the multitude of ways people can now access the websites we create. With new devices coming out daily plus fascinating new ways to enhance sites visually and interactively, we sometimes forget that many people are still using older slower browser and devices. That doesn’t mean we shouldn’t be designing our sites without all the bells and whistles, but we cannot forgot about the other users. At the conference, one topic in general really helped explain how we create amazing sites without leaving anyone out. Progressive enhancement!

What is Progressive Enhancement?

“Progressive enhancement is a strategy for web design that emphasizes accessibility, semantic HTML markup, and external stylesheet and scripting technologies. Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.”

Basically, progressive enhancement allows everyone, no matter what their browser or internet connection may be, to access a web page and view the basic content and functionality. If you are running a more advanced browser or better bandwidth, you will get the enhanced version of the page.

Progressive Enhancement vs. Graceful Degradation

Both graceful degradation and progress enhancement focus on how a site works in all browsers and devices. The focus and how it affects the workflow is the key between these two methods.

graceful

For many years, web designers have been using the principle of graceful degradation to make sure users in older browsers can at least see the content on a site, even if it doesn’t look exactly like the design intended. It allows designers and developers to focus on building the website for the most advanced/capable browsers. Using this method leaves older browsers with poor, but passable experience.

progressive

Rather than focusing on browser technology and support, we can focus on the content and how the user will see this content no matter what they are on. The content of your site is the most important element, it’s what brings users to your site and should always be first priority.

So how does Progressive Enhancement work?

It’s best to think of progressive enhancement as different layers. We couldn’t build a home without a solid foundation, the same goes for our websites. Each layer builds on the previous to improve the interactivity on the website without losing a solid functional base.

Content first! Start with your content, marked up in rich, semantic HTML. Having well-thought-out HTML has the advantage of not needing presentation layers to make sense. This also means screen readers, search engine spiders and those on basic mobile browsers will be able to view your content without any distracting formatting issues.

Visual Enhancements (CSS) Once your base HTML and content is ready, you are ready for the visual enhancement layer, CSS.  The majority of desktop and mobile browsers support CSS, though not all support CSS3. The CSS should enhance the content and make the overall user experience better.

Interaction (JavaScript) The final layer of our web site is JavaScript and should be handled last. JavaScript can contribute so much to the usability and user experience of a website. It has revolutionized the way sites work and how we do things online. However, your website should always work without JS and there should be an HTML or server-side scripting alternative. While most web users have JS enabled, there are still some cases where JS is undesirable and not every mobile browser or screen reader has good support for it.

Once you understand progressive enhancement, the concept of it makes sense and is easy to do. We build for the very basic structure and then build out so that no matter what device or speed someone is viewing the site at, they will always be presented with what is important. The content!