Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Custom pagination elements #8

Closed
jzfgo opened this issue Mar 27, 2010 · 7 comments
Closed

Feature request: Custom pagination elements #8

jzfgo opened this issue Mar 27, 2010 · 7 comments

Comments

@jzfgo
Copy link

jzfgo commented Mar 27, 2010

Currently the plugin assumes using anchors as pagination elements but, since the pagination doesn't show up with Javascript disabled and for usability and semantics sake, I would prefer to use <button> type elements instead.

It's actually possible to use any element as a pagination one, but doing that, the plugin loses some of its functionality.

@malsup
Copy link
Owner

malsup commented Mar 28, 2010

No, the plugin does not assume anchors. You can use whatever you like. Here are two examples using buttons instead of anchors:

http://www.malsup.com/jquery/cycle/pager-button.html
http://www.malsup.com/jquery/cycle/pager-button2.html

@jzfgo
Copy link
Author

jzfgo commented Mar 28, 2010

Yes, I know, but for example, updateActivePagerLink looks for an anchor no matter what, and it doesn't work if you specify anything but that.

@malsup
Copy link
Owner

malsup commented Mar 28, 2010

Yes, that's a good point. But updateActivePagerLink can be overridden. Here's an example: http://jquery.malsup.com/cycle/pager7.html

@jzfgo
Copy link
Author

jzfgo commented Mar 28, 2010

Thanks. That's exactly what I've been doing so far. But, since I believe this can be improved, hence my feature request :)

One possible solution would be adding an option to specify the type of element you would like to use as pagination, being this an anchor by default.

@malsup
Copy link
Owner

malsup commented Mar 29, 2010

Hmm, maybe it makes sense to assume that immediate children of the nav element are the ones we care about. Would that work in your case? So instead of:

$.fn.cycle.updateActivePagerLink = function(pager, currSlide, clsName) {
    $(pager).each(function() {
        $(this).find('a').removeClass(clsName).filter('a:eq('+currSlide+')').addClass(clsName);
    });
};

I would do this:

$.fn.cycle.updateActivePagerLink = function(pager, currSlide, clsName) {
    $(pager).each(function() {
        $(this).children().removeClass(clsName).filter(':eq('+currSlide+')').addClass(clsName);
    });
};

@jzfgo
Copy link
Author

jzfgo commented Mar 29, 2010

Sure, and it's still specific enough, imo. It works perfectly for me, thanks.

By the way, I guess I've found a bug about overriding this function in the default opts. I'm creating an issue about it.

Issue #10 created.

@malsup
Copy link
Owner

malsup commented Mar 30, 2010

I checked this fix into v2.83.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants