marijn

ProseMirror (and as the sibling comment mention, Lexical) should handle this fine.

Both mobile Safari and Chrome Android do a ton of weird things that their desktop siblings don't, and play loose and fast with standards, so getting things to work correctly there tends to involve a long tail of hacks. Wordgard will get there but the focus before this first release has been on architecture.

I know that's how sanctions work. What I mean is that the possibility of being locked out of a central facet of my digital life by US legal processes is another strong motivation for self-hosting.

(Filed this [here](https://code.haverbeke.berlin/wordgard/wordgard/issues/3).)

I've had another report like this (they claimed it had been down for days). But I haven't noticed anything wrong with it (and I'm using it a lot). What did 'down' look like?

Also, though GitHub's lack of reliability was part of the motivation to self-host, it was only a minor factor. The way they are trying to make Copilot a thing, at the cost of everything else, the way they handle US sanctions by blocking everybody from entire countries, and the way the web interface feels ever more heavyweight and sloppy were also factors.

There's a significant amount of code in Wordgard that is copy-pasted from CodeMirror or ProseMirror, but modified enough that trying to share it would involve nightmarish amounts of type parameters and extra indirection. You could certainly build a generic editor framework and then build several editors on top of it, but you'd end up with Raku-level amounts of architecture acrobatics and extra complexity, much of which would leak out in the public library interface, and I don't think that is generally worth it. I do occasionally, when I realize a bug fix applies to one of my other projects as well, repeat it there. But that's okay.

The menu can be replaced, either entirely or by item, but the default buttons use icons, not text labels.

First-class mobile support should be there (though there will be bugs, given that this hasn't seen much real-world testing yet — report them if you see them).

I haven't entirely decided what utilities I'm going to include in the core library, but mentions are definitely on the list for potential inclusion.

Tried to reproduce this, also on Chrome Android, but undo removes the typed character as expected.

> The thought that Prosemirror is no more in active development is scary.

Which is a thing that I never said. In fact I went out of my way in all the announcements to stress that ProseMirror maintenance is continuing as it has been.

Many of them do pay.

Also MIT-licensed software doesn't 'go away' all that easily. If a piano fell on my head tomorrow, interested parties would probably manage to continue development in a fork.

> why wordgard is worth the switching cost?

It may not be. If you're happy with ProseMirror, continue to use ProseMirror. I have your back.

But as the blog posts describes, I had a whole pile of new design insights that avoid some of the issues I've ran into with ProseMirror, so I had the itch to build a new iteration.

I'll add a link to the blog post to the docs section of the website.

(It's marijn, not merijn.)

See https://code.haverbeke.berlin/wordgard/wordgard/commit/9c9b2...

I'll be the first to admit that ProseMirror's change representation is a bit messy, but I don't think that's the root of the issue here. The problem is about generalized tree-structured document representation (as opposed to the flat-string model of Quill). I believe such a representation has value, and is the appropriate choice for a system like ProseMirror or its successor. Joining and splitting blocks is not a weird quirk of ProseMirror—it is a basic, essential editing operation. But there doesn't appear to be a known appropriate way to map that structure to a CRDT in a way that can properly express such splitting and joining. And that's fundamentally limiting the approach taken in y-prosemirror.

I watched the presentation, but I'm getting the impression that you're still using a hierarchical XML-like structure for the document, which sounds like it still cannot merge or split nodes (without recreating the content after the merge or split point). Will issues like https://github.com/yjs/y-prosemirror/issues/205 be addressed by this? (Which not only breaks ProseMirror's position mapping, but also your own, and which I consider a serious enough bug that recommending y-prosemirror for anything feels unserious.)

Hi Alex, I'm the author of prosemirror-collab. I agree with your point that CRDTs are not the solution they often claim to be, and that CRDT editor integrations (at least the ones for Yjs and Automerge) are often shockingly sloppy.

But, seeing how I've had several people who read your article write me asking about this miraculous collab implementation, I want to push back on the framing that ProseMirror's algorithm is 'simple' or '40 lines of code'. The whole document and change model in ProseMirror was designed to make something like prosemirror-collab possible, so there is a lot of complexity there. And it has a bunch of caveats itself—the server needs to hold on to changes as long as there may be clients to need to catch up, and if you have a huge amount of concurrent edits, the quadratic complexity of the step mapping can become costly, for example. It was designed to support rich text, document schemas, and at least a little bit of keeping intentions in mind when merging (it handles the example in the first post of your series better, for example), but it's not a silver bullet, and I'd hate for people to read this and go from thinking 'CRDT will solve my problems' to 'oh I need to switch to ProseMirror to solve my problems'.

Missed chance, to fail to reference Le Guin's [patterning frame](https://en.wikipedia.org/wiki/City_of_Illusions#Objects) somewhere in there.

You're welcome

Makes it available to more people. Also probably helps paper books sales more than it hurts them, through exposure.

How is a `<pre>` tag for code blocks a 'weird format'?

> but we felt that having a source-of-truth that wasn't the DOM was a better approach

Which is... exactly what ProseMirror does?

This is mostly accurate for CodeMirror version 5. But this article is talking about version 6, which was intentionally built in a way that avoids the problem.

That would explain the weird experience of having your open software used in Apple products — no one from the company ever talks to you. I'm a bit baffled how they deal with upstream bugs with this mentality. Not my problem, of course. Just weird.

You used to be able to do `git clone https://codemirror.net`, which was kind of neat. But the constant barrage of emails from "security researchers" who had found a "vulnerability" (an exposed git directory holding an open source codebase), have made me configure my server to deny all .git paths.

Tiptap builds on ProseMirror, so it uses the same approach.

(Not really, at this point—the project, like most libraries with dependencies, uses non-relative imports, which browsers don't really handle yet at this point.)

The project is written in TypeScript—not sure where you looked, but this conclusion isn't correct.

Right. But that only works for resources whose initial version is fully trusted (due to review or trust in its source), and which never change. Which doesn't cover a lot of the usefulness of the web.

> Brave concerns about WebBundles are legit in a location-based addressing Internet, but all of them would immediately be removed the moment we switch from a location-based addressing to a content-based addressing approach for the Internet.

I failed to find any good case being made for why content-addressable content would be any less likely to try to perform malicious actions than URL-addressed content. Is this just utopian wishful thinking or did I miss something?

I'm not going to defend the article, but I really bristle at this idea that if you just _get_ CSS it isn't problematic anymore. CSS tries to solve a hard problem and it's certainly preferably to inline-everything, but its design (global, cascading, with many types of behavior—positioning, z-stacking, etc—depending on the styling of parent elements in interesting ways) is actively hostile to many kinds of modularity, and that's a real issue even for people who "get" CSS.