I was having a bit of difficulty finding a jQuery plugin that not only provided scrolling behavior to a list of elements, but also used & then generated markup that could still be accessible, semantic & validate whether or not the user ran the javascript.

The best plugin that I could find that was already out there was Tero Piirainen's jquery.scrollable.js. If you check it out you'll quickly see that the markup that's used to generate the scrolling items could be improved upon. Nothing in my version of jquery.scrollable.js removes functionality from what Tero put together, and the improvements are basic.

1. make those items scrollable horizotally or vertically
2. decide how many items are visible at once
3. scroll elements with mouse, arrow keys and mousewheel (requires mousewheel.js)
4. make navigational buttons without programming
5. have programmatic actions: next, prev, nextPage, prevPage, seekTo, begin, end
6. need to know when list is scrolled with custom event listener
7. You can now start with semantic markup
8. I want this all in single js file that weights only 3.9 4.1 Kb minified!

First we start with simple & semantic markup

There's nothing fancy going on here at all, just a wrapping element, an anchor and an unordered list. Unfortunately due to the design requirements of this particular implementation, an additional <div> had to be added. If it wasn't for the creative constraint, and the lack of support for vertical-align: middle across many browsers, this extra <div> would have not been included.

Presentation

Now we add styling that makes it match the look & feel of the main site.

The css required to make this bit work for you will be different for every project, so take a look at the included styles and tweak as necessary.

And now for the behavior

If the user's browser allows javascript to run, we add some additional unobtrusive behavior (including mousewheel support)

This is the generated source we end up with... There's one thing you might notice, and that's the div class="__scrollable", though I initially placed that element outside of it's parent ol it did not work. It has something to do with how the xhtml 1.0 strict doctype is handled by the browsers. Though this may work in HTML 4.0 or various browser quirks modes, I haven't specifically tested all possible cases.

This build is currently in a non-public svn repository, but I will be moving it to google code or github shortly (depending on whether or not I feel like learning how to use Git)

Standalone Demo:

http://www.naterkane.com/sandbox/scrollable/

Download:

First you'll of course need jQuery v.1.2.6

jquery.scrollable.js (7.5k)

jquery.scrollable.min.js (4.1k)

scrolling-list.css – the stylesheet used for the example

You can also grab a copy of jquery.mousewheel.js here

I've been playing with Summize for a bit now. Their super-fast queries are just really gratifying. I'm also a fan of Get Satisfaction (and trying to get satisfaction in life in general as well), though my relationship with GS is much more recent. Yesterday I found an article that showed me something pretty cool that GS is doing. They call it Overheard.

What is Overheard?

Overheard is a new feature of Get Satisfaction that bridges the public Twitter stream into Get Satisfaction's support network. Overheard lists recent Twitter posts ("tweets") related to a company and allows any user, employee, or customer to convert a selected tweet into a rich, searchable Get Satisfaction topic.

When somebody replies to a tweet via Overheard, Get Satisfaction sends a reply to that person to let them know a conversation was started in response to their issue.

So now, whenever you post something on Twitter about a company, brand, service or product that's been added to Get Satisfaction, you're indirectly adding content to Get Satisfaction. It's similar to when users of Facebook would accidentally add content to their profiles with Beacon, but not so creepy.

Last week I was in a meeting with a current client who put together a nice little presentation on webstandards and accessibility. Their corporate standards are very progressive and they don't let anything slide. This is a very grateful situation, as I've found it pretty rare that a client is savvy enough to say "We need all of your deliverables to be W3C compliant, accessible and semantic".

Going through their IA documents (which are estensibly just wireframes) I was still left with a few important questions. This site has alot of articles as it's the web-based version of a print publication, and many articles have images inline with the text content, just like a magazine. And one of my questions was, "How can I wite xhtml for images with captions in a semantic and meaningful way?". Part of understanding the most appropriate approach to this problem is understanding what a caption is and how it relates to an img.

What is a caption?

I decided to go to one of my favorite places and look it up.

cap–tion [kap–shuhn]
-noun

1. a title or explanation for a picture or illustration, esp. in a magazine.
2. a heading or title, as of a chapter, article, or page.

Interesting eh? So it looks like a caption is two things, and technically heading tags (ie. <h1>, <h2>, <h3>, <h4>, etc…) are all considered captions. So how does a caption relate to an image?

A caption is the definition of an image

Since we use <caption> (and alt attributes) to describe what is represented visually in an image, we can surmise that a definition list (<dl>) is going to be the most appropriate solution to this issue. By using definition lists we can define the relation ship between the image is the definition's title (<dt>) and the text is the definition's definition (<dd>)

This is my new 1978 Honda CB750 F2 cafe racer.

So as you can see, providing image captions this way allows you to group and associate the content together without requiring a wrapper <div> for positioning or referencing. and if there isn't a caption available, the image can still sit within the <dl> and <dt> tags for a logical inclusion of a caption at a later time.

It turns out that Darren Brierton write this article back in Feb of '05 about this very same topic. He goes to mention in a comment to his own post that definition list's aren't limited to one <dt> element followed by one <dd> element.

The semantics of definition lists is implicit rather than explicit. A <dl> element can contain any old mish-mash of <dt> and <dd> elements and still be valid. It might not, however, make any sense

This next monday On Monday October 2 I will be giving a presentation to the lovely folks at ULTRA16 on Progressive Enhancement, Accessibility, Semantics and also how to make it happen with Flash. After monday, the presentation will be available here for anyone who may have interest.