Actually this could be considered a bug since as far as I can tell it doesn't support changing the width of the handle at all without this happening.
Where min=1 and Max=pages the handle juts out of the end of the slider.
An example, if pages is 4, this gives the range 1,2,3,4 and width 25%. However:
valPercent = ( self.values(i) - self._valueMin() ) / ( self._valueMax() - self._valueMin() ) * 100;
This sets the positions like so (exclam=pos, square=container):
[! ! ! !] :(
The result is that when in the last position the slider starts from the last ! and ends at the sad face landmark.
The last position is 100% left. It should be 100%-width. slider is using 33.3% increments each time instead of 25%.
It is easy to take into account the handle width with:
valPercent = ( self.values(i) - self._valueMin() ) / ( (self._valueMax() - self._valueMin()-1) ) * 100;
Line 626 also needs to be changed.
[! ! ! ! :]
I probably wouldn't recommend just doing this blind as it would probably break some other aspect of how slider is to be used. A conditional/option would be ideal to choose between handler positioning/sizing settings. which should choose between centred or to the left. I believe some better/clearer settings are required for the handle settings.
left=(handlewidth*(self.values(i)-self._valueMin()))+"%" would be more efficient.
Apparently, the scrollbar example seems to manage to keep the bar contained. If you look at the code it is unnecessarily complex. Slider should support this ability internally. It was quicker for me to add a couple of -1s to the minified source than to fully absorb the scrollbar example and exactly how it works which seems to be an ugly and kludged solution to implementing a feature that slider doesn't seem to provide; it probably should.
I would recommend making a "get val percent" function to start of with.
This should also be investigated for the slider's onclick clipping.