Issue 660 - Increase `page_current` and `page_count` fields size to accommodate larger numbers

[Marc-Andre-Rivet]

Closes #660

• Dynamically determine the width of the page_current and page_count fields based on the number of pages (1ch/char + 1)
• Reactively resize the page_current field for the case where no page_count is defined (e.g. page_action='custom' without the server returning page_count

[alexcjohnson]

This seems reasonable, but I wonder if these need to be fixed widths? Is it problematic to let them grow with their content?

[Marc-Andre-Rivet]

Inputs are weird beast and can't typically made to automatically grow with content, unlike other elements.

Typically this can be worked around by using something like <div contenteditable /> as the div will allow resizing - this won't automatically validate for numbers, etc. like the current field and you can actually start writing actual html into the div... I could also look into wrapping the input, position it absolutely + take all the available space, and use an identically styled span or div with the same content to force a resize - never used that method but I don't see any reason why it wouldn't work. I don't have a problem spending more time tweaking this into a more "dynamic" solution if we feel like it.

[alexcjohnson]

Ah right, number validation and other bits of <input> behavior are nice. What if we size both the input and the total page count to fixed widths but based on the number of digits in page_count instead of globally constant?

[Marc-Andre-Rivet]

Modified the proposed fix to:

• apply a min-width of the maximum between 4ch or '{}ch".format(len(page_count)+1)
• dynamically resize the input with the current value by using a shadow div and absolute positioning to support the page_action='custom' case where page_count might be unkown