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.
<section class="(...)" data-displaymode="carousel" ... > <header>...</header><div class="main">...</div></section>
<section class="(...) carousel" data-displaymode="carousel" ... > <header>...</header><div class="main">...</div></section>
<header> <div class="anchors controls"> <div class="prev"><a href="#">...</a></div><ul>...</ul><div class="next"><a href="#">...</a></div></div></header>
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!