marijn

You have to do that yourself—this is only the editor component. There's things like https://icecoder.net/ that provide a more web-ide like thing on top of CodeMirror, but I don't know them intimately so I don't know which one to recommend.

Thanks! It's going to get a little more abstract in v6 (but only where the abstractions carry their weight).

They are not putting _that_ much energy into Monaco, and these are not terribly huge systems. Also, I've been doing this for ten years, so that helps, in terms of experience.

Mouse drag or shift up/down works for me? Or what kind of selecting are you trying to do? (Or, if this was about multiple _cursors_, those are only half-implemented, and not exposed through the UI yet.)

The DOM selection corresponds to the primary selection, the others are drawn using CSS spans. This means you only get touchscreen-style handles on the primary one, but I think that's acceptable.

CodeMirror aims to be slimmer, and less of a cut-off piece of vs code. I also think our API is more well designed and expressive. And, as Adrian mentioned below, though he got downvoted, CodeMirror works on phones

> one thing that's always bugged me about the current v5 syntaxes is that colors (and token types) are not consistent across languages.

Yeah, me too. We're planning to move to something more close to what other editors (ST, Code) do and work with hierarchical token types (variable.local, variable.type.definition) instead of having a set of disjoint types. There remains the problem of some modes simply supporting more features (i.e. if one mode doesn't distinguish definitions from uses and another does, the colors will, depending on the theme, still look different), but it should help unify things quite a bit more.

It's underspecified and very hard to implement (and hence, not implemented all that well), but if you know the pitfalls (only some DOM/style structures are well supported, cursors vanish in some circumstances, etc) and avoid them, and implement non-trivial editing commands yourself (because you can't really rely on the browser to get them right), contentEditable is a functional way to represent editable content in the browser.

Oh hi, I'm Marijn, one of the maintainers. It doesn't look like this submission is going anywhere, but I'll keep an eye on the comments and respond to questions.

> I don’t know anything at all about Jeong, other than some highly... erm... problematic old tweets.

That's the power of a smear campaign, right? Planting a negative perception in people who previously had no attitude about a person. I recommend researching a bit before repeating the message of the campaign ("racist tweets"). Jeong is okay.

The DOM example further down the page, which does no result checking on queries that can absolutely fail to find an element, makes me very skeptical of this claim.

Since most people in those neighborhoods are already suffering under increasing rent prices, I really doubt many of them would be happy to have another gentrifying influence near them.

ProseMirror requires a certain willingness to work with strict data flow and immutable data structures, and to cobble together a loose set of small modules before you have something user-friendly, but if you can handle that I think it's a safe bet at this point. (Disclaimer: I wrote it, and am heavily biased.)

Yeah thanks for dropping some deeply outdated impressions in here. (Also not even fair—the code was never a mess and at the time it wasn't clear how ES modules would be used so using CommonJS was a completely reasonable choice.)

Did proseline.com do anything for anybody? Is it supposed to? Trying to create/open an actual draft crashes for me on both Firefox and Chrome (with different errors).

Another nice thing about Grammarly is that the plugin just blindly detect contentEditable inputs and start screwing with their content. This very much breaks modern WYSIWYG web editors, which typically expect to have control over the editable content. Which more or less comes down to "move over page scripts, I'm a browser plugin, this is _my_ webpage now".

Most of these cases have had the accused admitting they did it, or their actions being a public secret. You might want to take a good hard look at why your first reaction to this (very positive) development of men being held accountable for their misbehavior is to cry wolf about a problem that is not there.

> The gist of it: if you mark onscroll/ontouch event listener as passive, Mobile Google can scroll your page faster

onscroll has never been cancelable, and is fired after the actual scrolling takes place. So I don't see how it being passive by default changes anything. Is this an oversight in the article (and a bunch of comments here), or am I missing something?

https://developer.mozilla.org/en-US/docs/Web/Events/scroll

Does anyone know what the "Investigate into a native model layer" point might be about? It sounds very relevant to my interests, but though it is apparently ongoing, I wasn't able to find any issues or other pages referencing those terms.

Focus a demo editor [1] and inspect `document.activeElement` in the console. You'll get a parent div of the content whose `contentEditable` attribute is true.

[1]: https://docs.ckeditor.com/ckeditor5/latest/examples/builds/c...

People [1] are working on this, but as usual with standards processes, it's slow and there's constant pushback from browser implementors.

[1]: https://www.w3.org/wiki/Editing_Taskforce

They appear to have reimplemented most of these things, doing their own layout entirely etc. I wouldn't call google docs compact, but indeed, it's also not overly bloated, and it handles corner cases well. It'd be interesting to know more about its architecture.

The "end of contentEditable" spin in this is weird. CKEditor 5 uses contentEditable. And that's a good decision—getting bidirectional text, IME, touch selection, spell-check, and screen reader support right without contentEditable, while possible, would require you to reimplement a _lot_ of browser functionality, which would necessarily lead to a blowup of complexity and download size.

So sure, the new CKEditor does more or less what Quill, Slate, ProseMirror, and most other modern WYSIWYG components do—it separates its data model from the editable DOM. That's good, but not new.

Unfortunately, it's not that easy. Composition events are typically controlled by the IME software, which is not part of the browser proper, and tends to be a lot less serious about conforming to standards. The result is that the data in those events often simply doesn't correspond to the actual DOM changes that they caused. On Android, you can't even rely on the fact that compositionstart fires when a composition is started—with some virtual keyboards (which act as IME providers) you routinely get compositionupdate or compositionend before a start event.

Listening to these events and using DOM diffing can get you a more or less accurate idea of what happened. But 'relatively easy' does not apply.

That. And also how to deal with the interaction between browser state (around IME and such) and the component state. And how to properly model updates (see thread [1]) in a way that plugins can extend and consume in a modular way.

[1]: https://discuss.prosemirror.net/t/discussion-the-limits-of-a...

> Interested in hearing Marjin’s [sic] thoughts

Sure. I think it's fair to say that ProseMirror is a more ambitious project, reaching for features that aren't part of (even the new crop of) existing libraries.

* Firstly, the schema feature. ProseMirror's content expressions [1] are a regular language that can be used to describe a sequence of child nodes. The editor will make sure the content of the node always matches this expression. This allows significantly more interesting things than Quill's array of allowed children—i.e. "heading block＊ section＊" to say that a given node must first contain a heading, then any number of blocks (say, paragraph, list, figure, aside, etc), then any number of subsections. (HN's half assed markup doesn't seem to allow escapes on asterisks, so I used ＊'s)

* Quill uses imperative data structures and events throughout. I've really become convinced of the power of functional Redux-style architectures for this kind of component—I've found it makes it much easier to write bullet-proof extensions. (This may be a matter of taste.)

* Table support doesn't appear to exist in Quill yet. A table module with features like colspan/rowspan and cell selections has been written as a relatively small plugin [2] for ProseMirror.

* Exposing all the system interals (and designing them in a way that makes them usable), rather than hiding stuff behind a small API, means that people can do really advanced things as extensions. This was a lot of work, and wasn't initially planned, but the kind of users we're aiming for require it.

* As for real-world use, yeah, we've just released 1.0, your project is older. Still, our users (including Atlassian, which has already rolled out ProseMirror in user-facing products) have been doing very advanced stuff already, and my ten years of experience with CodeMirror mean that I more or less know what I'm going to run into.

[1]: http://prosemirror.net/docs/guide/#schema.content_expression... [2]: https://github.com/prosemirror/prosemirror-tables

(Also your website claims, wrt to ProseMirror: "Quill’s architecture is more modular, allowing for easier customization of internals. Core modules that handle basic functionality like copy/paste and undo/redo can be swapped out in Quill." I think that's a mischaracterization.)

No, it wouldn't. That requires a completely different set of features (gutters, syntax highlighting, etc).

As announced, breaking changes are over now. And the interface is written to be easy to type, and [type definitions](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/1698...) are available.

If you press backspace in an empty list item in the demo, you can continue the item above. The schema is tree-shaped, so you don't have the usual awkwardness about nesting things.

Or, if you mean lists starting at something other than 1.--The schema used in the examples actually supports a `start` attribute on numbered lists, but the UI doesn't currently expose it.

Atlassian is experimenting with ProseMirror for their wiki—I think the configurable schema feature goes a long way towards solving this. (Coincidentally, Adrian, who is a contributor to ProseMirror, was one of the people who worked on WikiMedia's editor effort.)