Wax: The Word Processor for the Web
waxjs.net
waxjs.net
But to call this component a word-processor - is a bit overkill. Why? To call an editor a word-processor it should support pagination & page layouts - as in Google Docs & Zoho Writer. Given the limited graphics capabilties of DOM, it is near impossible to build a paginated editor on top of the DOM.
Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control to achieve a proper word processing experience on the web. Something like that can never be built upon contenteditable augumented frameworks like Prosemirror.
There are other players in this category that are building extensible editors without pagination - like Tiptap, Froala, CKEditor, etc. Except CKeditor, every other project is built on top of Prosemirror too!
This is developed by the some of the same people who work on paged.js [1], which enables exactly that and is actually used to create printed materials, including books.
How do these in-browser applications keep rendering logic out of browser's control? They do it server-side?
I can’t speak for Zoho Writer, but despite popular impression, Google Docs doesn’t actually do this: its text layout and rendering, at the very least, is left entirely to the browser. Thus, Google Docs does not offer static pagination. Sure, it does some layout itself, but it doesn’t really offer anything even vaguely interesting to justify doing so: it’s all stuff all major browsers could already do at least as well. (And the whole “Google Docs renders using canvas” thing people often speak of is essentially false, measuring it against what people generally understand that to mean: https://news.ycombinator.com/item?id=33863185. I still have no idea why they’ve gone canvas to the extent they have, as they haven’t gone far enough to make it worthwhile, but they have gone far enough to makes things significantly worse in the general case.)
I’d be surprised if Zoho Writer were any “better” in this regard, because being “better” in this regard makes you fundamentally worse in other, generally-more-important regards. Because the web simply doesn’t give you the primitives you need to make a traditional paginated word processor good.
It does seem that Google Docs is using the browser to measure and render individual units of text. But that is very much not the same thing as layout: deciding how much text fits onto a line, how many lines fit onto a page, making room for footnotes, etc. My understanding is that Docs is handling layout itself, in order to support features like pagination and footnotes.
You say the browsers can support all of the layout features Docs provides, but do they allow live editing and on-screen display of paginated text? That certainly wasn't the case back when I wrote the original Google Docs (I'm a co-founder of Writely) and I don't believe it was the case when the current canvas implementation shipped. (I had left Google by then and have no inside knowledge of that rewrite.)
One final note: back in the day, I have implemented and shipped a full word processor for the Mac (FullWrite). We very much handled layout ourselves, but relied on the OS for text measurement and rendering, presumably in a similar fashion to how Docs leverages the browser today.
I’ve seen the same Google Doc use different numbers of pages both on screen and in print/PDF so I don’t believe this is correct.
Given that Docs nowadays uses Canvas to render the document being edited, how would it even be possible to delegate rendering to the browser? (Not to mention the challenge of live rendering of pages, footnotes, etc.)
It’s worse when you do it with browsers, because you can’t inspect anywhere near as much, and because you can’t even guarantee which font will be used: font files may fail to load (networks are far less reliable than people imagine, quite apart from third-party origins), or you might get users like me who just disable custom fonts altogether because it makes the general experience of the web so much better.
As far as pagination is concerned, there was never any reason why you couldn’t do that in DOM—and in fact, Google Docs did do it in the DOM. You simply have to monitor where the break position should be, and adjust things at that point. It’s not hard. The specific adjustment, there are a few approaches for. You could have the whole document be a contenteditable, and draw the page background outside that, and just inject an inline spacer element in the location of the break; or maintain it inside distinct block elements, using text-align-last on the last line of the previous page if it’s mid-paragraph and justified (or an approximation of the effect for older browsers); or there are several other viable approaches. Seriously, it’s not hard. You’re not limited to “just contenteditable”, you expect you have to maintain various more complex DOM. But I contend that maintaining that is easier that rendering the whole thing in a canvas, and entirely adequately powerful, and probably faster, if you perform similar performance optimisations, and that it functions better. I just all-round cannot think of any legitimate reason why they went the way they did. It’s not like switching from DOM to canvas allowed them to add any new functionality: no, they stayed at just the same feature set, just worse in places, from my perspective.
Is this just historical vestige stemming from Words dominance? I don't see why word processor should handle print layout instead of doing it in dtp or something
Not supporting this is why it's called a word processor for the web.
The About page is clearer, "Wax is a framework for building web-based word processors", but that lacks pop.
However, this gives off very unpolished vibes.
The demo renders poorly on mobile, with the textarea on the first page squished horizontally. The "Basic Editors" demo has the opposite problem, and there is horizontal scrolling with elements out of view. It's not clear if this is a fault of wax.js or of the demo page, but it's a bad first impression.
There is also a typo on the Features page:
> Select text and add a comment or particpate [...]
They have actually quite a lot of open source projects, among others "paged.js", a "Typesetting Engine for Creating PDF from HTML" and "CokoDocs", an "open source, collaborative, web-based Word Processor."
This site can’t be reachedwax-demo.coko.foundation refused to connect.
I don't understand how projects like this ever get new contributors, or how the current maintainers manage to remember everything about why the code is the way it is.