scrollTo: a case for build or borrow

[Eli Cochran]

In Uploader, we have a nice little mini-component that handles the  
vertical scrolling of an overflow element. Based on some code that I  
wrote a long time ago, it does what we need for Uploader; initialize  
it with a container, pass in an element, and it will ensure that the  
element is scrolled into view.

I started to think about how to expand the functionality: mostly  
adding the ability to specify elements by index, and adding some  
predefined literals for relative position (next, previous) and  
absolute positions (first, last, top, bottom, etc.)

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 does all this with barely double the weight of our code.

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.

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 have.

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.

So I put it to the group. Any reason in this case to grow our own?

Thanks,
Eli


. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley

"Do not solve the problem that’s asked of you. It’s almost always the  
wrong problem."
     - Don Norman




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080829/80792f5d/attachment.html>