It's definitely made to print books and pages from the web. You can preview in a browser, but that's not the goal. It's a polyfill for CSS properties made for print.
Although, you can't tell for sure what people want to do with tools and library right? :)
I don't get the appeal. This isn't anything like a book, since I'm still scrolling, squinting, and reading words from a backlit screen instead of a physical page. Not to mention, using the browser's zoom functionality just straight up doesn't work (the pages and text stay the same size). So much for accessibility?
I really dislike everything about this.
[0]: https://s3.amazonaws.com/pagedmedia/pagedjs/examples/index.h...
[1]: But actually, JS is supposed to be pretty fast nowadays - so let's not build this bloat into the browser's rendering engine please?
I don't see any evidence on their website this is intended for reading in the browser, and tons of clues that it's intended for printing books from the browser. I mean, there are tools for physical page sizes, blank pages, front/back matter, page counters, etc. Things that make zero sense in the browser and are necessary for a nice book printing.
So, what makes you think this is intended for reading in web browsers? As you note, it's horribly unpleasant in a browser...seems like they would have noticed that if they were testing in the browser, rather than using it to print books.
You would either use this for stuff that is only useful printed (e.g. a boarding pass could be HTML instead of PDF) or as secondary, print-specific styling for web content that is frequently printed to paper.
print is just another aspect of responsive web design. And paged.js add the possibility to add things that the paper need and the browser don't (page number, cross rereferences, running-head, etc.)
A bit more info about css print: https://www.smashingmagazine.com/2018/05/print-stylesheets-i...
We're sending webpages to printing press, and it becomes a book. That's it.
HTML is already exceeding good at flow layout, we can flow text into desktop, mobiles. Why not extend the rules so they flow into a piece of A4 document, or two columns?
Another use case is reports, where there are tabular data, where headers should be repeated at the top of every page. Wouldn't it be nice if HTML/CSS could specify this instead of resorting to Crystal Reports? It'd certainly make us doubly productive.
To me, a web browser's purpose is to render markup into something useful for a user, dependent on variables like screen size, user preferences, browser zoom, accessibility needs, etc. A browser's purpose is not to render-a-document-as-an-A4-printout-specifically,-because-no-other-format-will-do.
"Make it look exactly like this" is not an expectation we can or should have about web browsers, and this proposal is an attempt at that.
Anyway, to specifically address your use cases:
> The use case is when I buy a plane ticket it comes with a 3 page receipt and E-ticket, and rather than downloading a PDF, we can have HTML specify how to flow the document into a document
HTML can already specify that document. Why does the browser care that it would be 3 different physical pages? Why would a user care? We're letting the tail wag the dog - just put the information in HTML.
> Why not extend the rules so they flow into a piece of A4 document, or two columns?
Two-column layouts are a concession of print formats due to constraints of needing to get all the other content onto the physical page. We don't have those constraints in Web, there's no need to introduce them.
> Another use case is reports, where there are tabular data, where headers should be repeated at the top of every page. Wouldn't it be nice if HTML/CSS could specify this instead of resorting to Crystal Reports? It'd certainly make us doubly productive.
If we're spinning up this whole AlmostPostscript.js thing to render a <table> with a sticky header, I really don't want to be a modern web developer anymore.
And sure, paginating fixed content is easy. Paginating dynamic length content? Having poked around at the problem, I'm very curious to give this library a try.
Currently, this requires you to use something like pandoc to generate LaTeX and HTML from the same source document, then use two different languages for styling. I don't want to do that. I want to have a single HTML file with one stylesheet that applies a few extra rules to print nicely. I can sort of do this now, but there are lots of features missing that make it impractical for many use-cases. For example, it's currently impossible to make a footnote always display at the bottom of a print page in CSS alone.
In general - why does the Web need this? This is a less-flexible CSS grid, with some auto-increment and @media(print) styles mixed in.
The use case for faithfully representing a textual work is not convincing - this can be done already, more accurately, and in a far less complicated manner by using images or PDF or any other format more suited than hypertext markup and CSS.
We already have pagination on the Web, it's called a webpage.
This just feels so wrong and not what a Web document should be: https://www.w3.org/TR/css-page-3/