As designed PageNav > 9999

[digitalpoint]

So I see that when a navigation number is greater than 999, the font size is dropped down to 9px, but still retains the fixed width of each link. This makes still makes numbers over 9999 spill out of the bounding box.

I know *why* it needs a fixed width (because the scroller looks funky with arbitrary widths, and one of when one of the links are cut in half, it looks really bad).

But...

There's really no reason that we *have* to used a fixed width for .PageNav .scrollable... instead when the next 5 links are added to the DOM (but still hidden), you could get the rendered width of it before and after they were added to the DOM, and then take the difference and animate like so:

startWidth = $('.PageNav .scrollable .items').width();
{code that adds the 5 links to the dom}
endWidth = $('.PageNav .scrollable .items').width();
$('.PageNav .scrollable').animate({width: endWidth - startWidth});

Then you could just have variable widths that scale to any number as well as consistent padding regardless of the number.

There aren't going to be a ton of places where the number is > 9999, but there certainly will be... The biggest example would be the member list, which would be > 25000 pages for mine as of today.

 

[Kier]

I wish it were that simple, but an awful lot of the scrollable code is internal and private to jQuery Tools, and I don't think we can adjust the widths following the initial creation of the scrollable object.

 

[digitalpoint]

Does the event fired when you click a link become an event controlled by jQuery Tools (sorry, I've never used their scrollable module myself for anything)?

The element itself is certainly adjustable after creation, but would be a matter of getting an event fired when one of the links is clicked.

To be honest, what the scrollable plug-in is doing for the pagenav is really simple when it comes down to it... I suppose I could just rewrite the XenForo.PageNav JavaScript to not be dependent on jQuery Tools and have more control over it.

 

[digitalpoint]

Okay, did a little poking around on jQuery Tools...

You guys are already using the onBeforeSeek jQuery Tools event for setting the visibility of the right/left arrow link as needed. They have another event that is fired after the scroll which would be perfect... onSeek... http://flowplayer.org/tools/scrollable/index.html

Measuring the width during onBeforeSeek (I assume that fires before AddItem is fired), and then again during onSeek should let you calculate what the width should be and animate to that width.

 

[Kier]

It's not just the container width that needs to change though, it's the width that is stored for a 'page' of pages so it knows how far to move the element around on scroll - and as far as I can tell, that is locked and unavailable, isn't it?

 

[Mike]

We do actually handle the cases of over 9999 with bigger spaces for the boxes. You can see that here: http://xenforo.com/community/pages/pagenav-playground/

Any way we can see an example where it's not working for you?

 

[digitalpoint]

Yeah, I saw you guys are sort of handing anything up to 7 characters long. I guess mostly I was thinking it would be nice to have some consistency with padding and font size (like how it gets smaller after 999). I think I'm going to rewrite the XenForo.PageNav functions to not use scroller... that way there's a little more control over how it works. Might be the best option in my case...

 

[Martyn]

Yeah, I saw you guys are sort of handing anything up to 7 characters long. I guess mostly I was thinking it would be nice to have some consistency with padding and font size (like how it gets smaller after 999). I think I'm going to rewrite the XenForo.PageNav functions to not use scroller... that way there's a little more control over how it works. Might be the best option in my case...

it does look abit weird, and i guess if i ever had 1million page threads it would annoy me!