Divide long html input into auto pages

I can’t seem to find this:

You have a user inputted text or photo html page that you can continuously add to and after it gets a current length it automatically goes to the next page and then places at the bottom of the page a link to page 1, page 2, next, previous, etc.

So, my thought process is that if you have an 800px length page and the next item added (text or photo) would go to the next page because it doesn’t fit on that page - and then that process would repeat itself.

Not talking about different records from a database, just one long html page that you can divide into pages automatically.

Just wondering if that is possible?

1 Like

Is it possible? Yes.
Is it doable without being clunky as all getout? Debatable.

If there’s no controls on the user’s input, what do you do if the user puts a 900px height image in?

User input of photos is limited to photos of 450px. Perhaps if it’s a photo at the end of the page that exceeds the 800px limited, it’s allowed on that page, and then go to the next. page.

Yes, as said, 450px and text only that would have to roll to the next page at the 80opx limit (or whatever limited in used, perhaps best to use 1080px.

So the limits make it less clunky.

Basically, you’d have to paginate the system. It would get messy though to do it based on element height.
if the browser’s size changes, you’d need to reevaluate the entire pagination.

1 Like

Thanks for the information. Probably too difficult to do because I couldn’t find anything like that when during an extensive search; that’s probably why!


I mean… theoretically could it be done? sure.

Take your entire block of text and tokenize it, splitting images and word breaks.

Set start = 0.
Start adding tokens to the page from index start until your target element is X high or more; stop and record the number of the last token seen, last.

Forward motion is simple; start = last, repeat previous instruction.

Resizing would require a repeat, but without changing start.

Backwards movement is the semi tricky one; you’d have to invert your logic; start at last - 1, and walk until size, then stop. you wouldnt end up at the same point. set start to your current token, last to be last - 1.

Due to the nature of the measurement, you would end up having different starts and ends of pages depending on which way you went to get there.

1 Like

Then sounds too complicated for me to tackle if you have that opinion.

I appreciate you breaking down the process.

Yes, it is possible to divide a long HTML page into multiple pages automatically based on a specified length. One way to do this would be to use JavaScript to measure the length of the page and add new content to the next page when the current page reaches the specified length. Additionally, links to navigate between pages such as “page 1, page 2, next, previous” can be added to the bottom of each page using JavaScript.

Your explanation sounds very logical. That is way beyond my capability though! Have you seen or do you have any links of examples. I have yet to find any myself.

I have some old ASP Classic code that does that by the number of records from the DB per page and then puts the pagination at the bottom so I figured that there could be some JS out there doing the same.

Thanks for taking the time to make your comments.

Which works great when you’re doing it by something pre-quantifyable - You know ahead of time you want 20 records on a page, so you can easily say “give me 20 records”.
An unbroken block of text, what can you quantify before its rendered? Number of words, sure. Number of paragraphs, number of images… but you cant do things like height unless you’re going to fix the width and font size.

1 Like

Exactly! Hence, the problem!

So it is first a case of deciding how you divide the content into separate pages. Using a pixel based dimension seems a nonsense to me, since everyone’s page/screen/window is a different size, these dimensions are something you can get, but then factor into it a users custom font size and browser zoom, it quickly gets over complicated.
I think it really depends upon the nature of the content and breaking into natural blocks. If you go by some magic number like word count, I would find it jarring to change page mid way through a sentence. Granted that happens in printed literature, but here you are not needing to conserve paper.
We don’t know what the content is like. If it were an article divided into chapters or sections, it could be done that way. If it were a series of paragraphs without sections, you could divide every x number of paragraphs.
The problem then could be the varying size of sections or paragraphs making uneven page sizes. To fix that, it may be possible to make the cut-off the paragraph before or after a certain word count.
But you mention text and pictures, which is a further complication. Perhaps one picture could be considered one paragraph in terms of page volume.

1 Like

Excellent points!

But I think the key here is that you don’t have to make the pages the same size, nor you should. As long as the pagination is a the bottom of the page all is good.

For example, you set a minimum of “x” pixels and if an image at the bottom of “x” exceeds it by 300px then that page would be x + 300 with pagination at the bottom of that page, etc. I don’t see that it’s problem that the pages are of different lengths as long as you have pagination numbers and next arrows, etc underneath the last paragraph or image on that page.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.