\n\nI cleaned up the example and had a working text editor in a few dozen lines of code. (I'd post them but they're written for a client. I believe the whole project will eventually be open-sourced, but right now it hasn't been. If and when it ever gets open-sourced, I'll link the code. Failing that I may write my own simpler version for personal use (and integration with Foldermark).\n\ndocument.execCommand implements most of the functionality you need to write a perfectly good word-processor from scratch in a browser. In fact, if you're willing to put up with some UI quirks, pretty much all you need to do is implement some trivial UI components. Almost all the implementations out there create a complete blank document inside an iframe by default, but it's perfectly viable to edit inline in a div, especially if you're planning to use the ambient styles anyway.\n\nThe beauty of writing your own word processor using execCommand is that the browser gives you fine-grained access to all events, allowing you to arbitrarily fine-tune the low-level behavior of your word-processor. Microsoft Word, for example, has always had unfathomable UI quirks.\n
What don't you get?
\nFirst, you do get pretty solid table support.\n\nYou don't get fine control over styling, although there's nothing to stop you from implementing a CSS editor of some kind (disguised or not). From my point of view, the default behavior of the browser word-processor is to be very styles-driven, and that's a good thing. It's not so easy out-of-the-box to, for example, set a specific point size for text.\n\nSome execCommand commands don't work very well. E.g. you can implement a \"hiliter\" using execCommand(\"backColor\"...) but there's no way to toggle it off (unlike bold) so to properly implement it you need to directly mess with the DOM, which — given the way selections are represented, can be a tad ugly.\n\nThere's stuff that is simply difficult because you're in a browser. E.g. without implementing some kind of service platform (or perhaps leveraging an existing one) you're not going to be able to drag-and-drop a picture from your desktop into a document. It would be fairly straightforward, I suspect, to integrate DropBox with a word-processor to allow drag-and-drop images and attachments — anything that can be represented by a url is, of course, golden.\n\nMost of the missing features from the free word-processor in your browser are what you'd expect. E.g. anything to do with overall document structure: automatic index and table of contents generation, footnotes, endnotes, headers, footers, and so forth. None of this stuff is hard to do in a browser. The real problem is support for printing — browsers generally suck at targeting printers — so you're not going to replace Quark or InDesign — but if you're targeting ePub rather than paper, I don't see why you'd want to use anything else.\nFinal Thoughts
\nThe advantages of \"owning\" your word processor's codebase are enormous, especially if you're trying to integrate it into a complex workflow. You can fine-tune exactly what happens when a user hits delete (e.g. we need to track dependencies — was this paragraph based on that paragraph template or not?), and what is editable or not. You can do validation inside input fields while allowing other text to be edited free-form. It's pretty wonderful. One day, perhaps, there will be free off-the-shelf editor that solves key UI and workflow integration issues, but we're a ways from there.\n\n ","$updatedAt":"2024-06-05T09:21:33.850+00:00",path:"the-browser-as-word-processor",_created:"2024-07-09T20:29:10.602Z",id:"5147",_modified:"2024-07-09T20:29:10.602Z","$id":"5147",_path:"post/path=the-browser-as-word-processor"}}