Hacker News Reader

Comment by marijn | Hacker News Reader

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.

View on HN

how do you plan to handle multiple cursors (eg: simultaneous-edit & collab), vertical / column selections, and multiple disjoint selections?

By the way, how do we select multiple lines in chrome? I can do it in firefox in the "old" CodeMirror, but not in my chromebook.

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.

Interesting! I actually wrote https://github.com/SjonHortensius/LRTEditor to replace CM, but the many subtle browser bugs eventually forced me to abandon it. Do you expect to use shims and possibly let browser-vendors fix bugs/inconsistencies you find?

We're not really using shims, just targeting the lowest-common-denominator contentEditable behavior that we can count on, and implementing anything else ourselves.

‘Because you can't really rely on the browser to get them right‘- welcome to the state of the web today- inconsistencies everywhere and no fix in sight :(

Now you either recreate things yourself or offload the consistency patching to a framework to (hopefully) correctly handle.

Well, this has been the case with the web for a while. See: jQuery.

Reply on news.ycombinator.com