Apologies for a bombastic title. This is an invitation for a discussion, a vote for keeping some flexibility in this wonderful library, and not an incitement of flame wars.
I've been using the v1.1.2 in my sites integrating it into MODx, light boxes, and other stuff. The nice set of parameters like 'size', 'item', and page controls were great tools to take the content fetched by the CMS and present it in a very interactive way.
In the latest example my content was just a list of image links shown in a scrollable. Clicking on a link would open prettyPhoto lightbox to show a collection of images in that category.
The element structure of the links was constrained by the prettyPhoto in order for it to work (the limitation of prettyPhoto to be sure). But Scrollable was flexible enough to handle those constraints by specifying a different element for the item (item: "a"). The size parameter was a flexible way to control how many items would appear in a scrollable page.
Simple, effective, and compliant with the unobtrusive Javascript principle, which asks us to keep the html structure separate from the behavior. IMHO the size of the scrollable page has nothing to do with the content and everything to do with the behavior since it can change depending on the size of the screen.
That is why i think that the "simplifications" of scrollable in version 1.2.2 are a step backwards as the html content now is required to be set in strict nested structure of divs in order to make scrollable pagination work and there's no way that i see to use different elements as individual items. So now i'm forced to write extra code in order to organize my pretty semantic content into non-semantic divs just to get scrollable to paginate. Please let me know if there's a way and I somehow missed it.
Looking at the cost-benefit ratio I suspect that the small savings in the library size are not worth the loss of the flexibility and the resulting complexity of the overall project. I certainly understand that a single library cannot please everybody. But i'd like to point out that the audience for a Javascript library is a pretty smart bunch and that there's no need to oversimplify the library unless there's a pressing need for it. I hope that the next version will bring back a way to customize the library's behavior without touching the semantics of a page content. Until then i'll happily roll back to 1.1.2.
I've been using the v1.1.2 in my sites integrating it into MODx, light boxes, and other stuff. The nice set of parameters like 'size', 'item', and page controls were great tools to take the content fetched by the CMS and present it in a very interactive way.
In the latest example my content was just a list of image links shown in a scrollable. Clicking on a link would open prettyPhoto lightbox to show a collection of images in that category.
The element structure of the links was constrained by the prettyPhoto in order for it to work (the limitation of prettyPhoto to be sure). But Scrollable was flexible enough to handle those constraints by specifying a different element for the item (item: "a"). The size parameter was a flexible way to control how many items would appear in a scrollable page.
Simple, effective, and compliant with the unobtrusive Javascript principle, which asks us to keep the html structure separate from the behavior. IMHO the size of the scrollable page has nothing to do with the content and everything to do with the behavior since it can change depending on the size of the screen.
That is why i think that the "simplifications" of scrollable in version 1.2.2 are a step backwards as the html content now is required to be set in strict nested structure of divs in order to make scrollable pagination work and there's no way that i see to use different elements as individual items. So now i'm forced to write extra code in order to organize my pretty semantic content into non-semantic divs just to get scrollable to paginate. Please let me know if there's a way and I somehow missed it.
Looking at the cost-benefit ratio I suspect that the small savings in the library size are not worth the loss of the flexibility and the resulting complexity of the overall project. I certainly understand that a single library cannot please everybody. But i'd like to point out that the audience for a Javascript library is a pretty smart bunch and that there's no need to oversimplify the library unless there's a pressing need for it. I hope that the next version will bring back a way to customize the library's behavior without touching the semantics of a page content. Until then i'll happily roll back to 1.1.2.
