scrollTo: a case for build or borrow
colin.clark at utoronto.ca
Sat Sep 6 16:30:41 UTC 2008
Sorry for the delay in responding. I wanted to take a bit of time to
look into the scrollTo plugin more closely before venturing an opinion.
On 29-Aug-08, at 1:37 PM, Eli Cochran wrote:
> However, there is a jQuery plugin, scrollTo, written by Ariel
> Flesler (of the jQuery team). Nice bit of code. Also does everything
> that we need in Uploader. Doesn't have the predefined literals that
> I wanted to add, but it does handle elements by index. It also
> handles a lot of stuff that we don't currently need, such as
> scrolling by pixels, animation, vertical and horizontal scrolling
> and window scrolling. So there is a lot of functionality that we
> could use in the future.
It's nice, tight code written in a reasonable style. It's got the
basic functionality we need, and a bit of extra pop with the animation
> What it doesn't do, which our scroller doesn't do yet either, is
> wrap an element that currently doesn't scroll in the markup that
> would allow it to scroll. Easy to add to our code. To add it to the
> jQuery scrollTo plugin, I'd probably want to wrap the code in our
> own initer as opposed to extend the scrollTo code ourselves.
When you say "wrap the code in our own initer," I'm assuming you mean
that we'd just provide a function that will self-render the additional
wrapper elements? It seems sensible to write something along the lines
of InlineEdit, where we look in the DOM for the existence of necessary
elements, and if they're missing, render them ourselves.
In that case, you're right that there's no reason to modify the
> Anyway, I have three choices before me:
> 1) Continue to expand our own code as we need new functionality.
> There really isn't that much more to do to support what we already
> 2) Use the jQuery scrollTo plugin, out of the box. Use the
> functionality we need and ignore the rest but know that it's there
> for the future.
> 3) Use jQuery scrollTo plugin but wrap it in our own initer so that
> we can create new scrolling elements on the fly.
> I'm leaning towards #2. I think that there is great benefit in
> leveraging great bits of functionality already out in the world.
> Nothing precluding #3 in the future, I'm just not sure that we gain
> that much by doing it now.
After thinking about it for a bit, I'm leaning towards #3. It's seems
like a good progressive enhancement technique. Here's my rationale:
The wrapper elements required to make an ordinary element scrollable
are essentially decorative and not structurally meaningful. The markup
for a scrollable list would have to look like this:
These wrappers are an added bit of complexity required by authors who
want to make something scrollable, but they're not essential. If
they're missing, we'd be doing a nice thing by rendering them
ourselves. If they're already present, by all means we should use them.
The work of wrapping up scrollTo in this self-rendering code is fairly
simple, so it seems like a good idea to me.
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work