scrollTo: a case for build or borrow

Colin Clark colin.clark at utoronto.ca
Sat Sep 6 16:30:41 UTC 2008


Eli,

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

> 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  
scrollTo plugin.

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

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:

<div id="thingThatActuallyHasTheScrollbars">
    <div id="uselessWrapperRequiredForIE6Compatibility">
      <ul id="listIWantToMakeScrollable">
         <li>Mango</li>
         <li>Kiwi</li>
         <li>Orange</li>
    </div>
</div>

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.

Thoughts?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org




More information about the fluid-work mailing list