concept

Before we dig into the actual code though, it's important to understand that ever since I wrote those two articles two year ago, I started seeing carousels in a different light. This newfound knowledge has a great impact on the resulting front-end code and setup of the carousel, so it's absolutely crucial to get this cleared up first.

Instead of regarding a carousel as a unique/separate content pattern, I came to understand that a carousel is nothing more than a display mode of other, already existing content patterns. In other words, a carousel doesn't need a separate html structure or base class, rather it should be defined as an option on existing content patterns (the same line of thought works for tabs, accordions and other similar patterns). The carousel becomes a true behavioral pattern, where I used to think of it as a simple content pattern.

As long as there is a list of repeating content patterns (preferably of the same type, though it's equally possible to mix different content patterns) it can be displayed as a carousel. These patterns can be anything from banners and images to more complex content patterns like focus blocks, products, events and whatnot. The bottom line: our approach should be way more generic than before as we can't depend on tailored html code anymore. Luckily html5 provides us with exactly the right tools.

the html

Carousels are typically javascript-powered patterns, so it's only natural to use a data- attribute to initiate the carousel behavior. The data-displaymode attribute can also be used for other display modes (tabs, accordions), other data- attributes can be set to configure the carousel (animation options, timing, ...). An additional benefit of this technique is that clients who don't support javascript will see the list of content patterns as is, only javascript-enabled clients will go the extra length of creating a carousel (go progressive enhancement!).

Since we're dealing with a list of content patterns it's useful to implement a typical header-main-footer structure. In the case of a carousel, the header can be used to harbor additional control elements (prev/next links and or paging). If there is no need for a header in the basic html structure, you can just add it with javascript, the only thing that needs to be present is the div.main element. For styling purposes, it's probably a good idea to add a base class that restates the display mode. This way we can easily differentiate between the regular list (no javascript) and the carousel (javascript-enabled).

carousel controls

Whether you include the anchor navigation in the basic html structure is entirely up to you (it depends on context and personal beliefs), but the prev/next links have no use in the non-javascript version of a content pattern list, so they'll need to be added with javascript. The extra class .controls could be dropped (because you already have the .carousel base class for extra styling) but I like how it illustrates the changed semantics of the element.

the future

Of course this isn't the final solution, things might be quite different when I write another follow-up article two years from now. But it is a major update, mostly in the way I think we should approach behavioral patterns like carousels. If you want to have a peek at a (possible) future, check out the Web Components proposal (still a very preliminary draft), there's some absolute crazy (yet very interesting) ideas in there.

For now though, let's try to separate behavior from semantics. The best way to do that is to rely on data- attributes that function as markers for behavior. Other examples of this are welcomed!