Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

What we need is the web standards groups to come together and add a rich text input element as a native browser control. Implementing a rich text editing component in javascript is insanely difficult because you need to support:

- Every platform (windows/macos/ios/android/linux, firefox/safari/chrome. There are all sorts of platform specific details - like windows using \r\n instead of \n. Your rich text editing component needs to feel native everywhere - even though that means something different on every platform.

- Undo / redo support

- Support for international inputs - to support Korean, Japanese and Chinese characters.

- Detailed canonicalized editing events for integration with collaborative editing libraries

Years ago I played around with the rich text editing components in Cocoa (MacOS) and coming from the web, its an utter delight. That code is all there on your machine - its just not exposed through the web browser. So we're stuck with janky half working "rich text" editors in reddit, slack and everywhere else online.

Decades of halfbaked attempts has shown that custom javascript isn't good enough to solve this.

Its is a web standards problem. Rich text editing should be built in to the web browser.

well, beforeInputEvent.preventDefault() got close to making the problems in contentEditable tractable... but when it comes to CJK it just shrugs and says "eh, good luck with composition".

On the subject of Cocoa, I can't even find the docs anymore for the low-level text shaping layers of the system. I've looked a couple of times because I want to re-implement some parts of those APIs. Everything seemed so well-designed, but now it's lost to the sands of time as Apple archives documents and Google search deteriorates. Alas.

EDIT: blessings! I found some of the docs for Cocoa's text layout system. Just look at this. If only we had this for the web, as a standard...

https://developer.apple.com/library/archive/documentation/Co...

EDIT 2: Oh, Apple has a new text layout engine "TextKit 2". I haven't found any of the really nice technical illustrations or long-form guides for it. Instead, I'm watching this video: https://developer.apple.com/videos/play/wwdc2021/10061/

This is all true plus other things that make it difficult to implement a rich text editor are accessibility (keyboard shortcuts!), dark mode (theming) and customizability.

Having a rich text editor in the web standards would be nice for prototyping. However all the form elements (select, date picker, progress bar etc.) are also web standards but no one uses them because they are ugly and not customizable.

So the chances that we will get a standard rich text editor on the web that web devs would actually use are slim.

Yeah good catch - OS-native keyboard shortcuts are really important & hard to reimplement well!

Nobody uses the built in date picker because it’s ugly, and making your own date picker is relatively easy. (Well, at least on desktop). Rich text editing is the inverse - it’s basically impossible to make your own. But theming a built in rich text editor should be really easy.

All the browser should implement is a rich text area itself. Leave it up to the web developers to add our own buttons for bold / italics / etc - since people will want to style that stuff themselves anyway. And add a clean, simple event API for “onchange” or something which gets called before any change is applied to the text area - initiated by a user or by the system. The event should tells you exactly what the change is (including styling) and let you tweak the change before it gets applied to the input element.

I think web devs would go bananas for something like that if it was designed well. I’d use it for sure.

You risk ending up with something like the date component which is so ugly nobody uses it.

clients should only ever input plain text

it's the application that should decide how it's to be displayed in different contexts

you're fighting the web if you're trying to do it otherwise, but then again, everybody is nowadays...

Much of the complexity of contentEditable comes from using the same DOM nodes both as an output device to render a semantic data model, AND as an input device, to interpret input-related events into changes to the semantic data model. If you can separate the two concerns, it would be much easier to eg accept CJK text and keep output looking correct, without breaking input.

100% this - but good luck fixing that, since the people who'd have expected contenteditable to work are the ones that want to unify input and output... so it's an intractable mess

you basically want an UI for inputing and validating some schema-enforced JSON, but that's overwhelming and overkill for most users and more apps, so you script into existence a simplified version of that (aking to "everyone who doesn't learn lisp is cursed to reinvent it" or smth like that but for frontend devs).

Plenty of editors do separate the input and output into different DOM nodes. Google Docs does this, as does Coda.

> 100% this - but good luck fixing that

Its fixable. We just need to add a new, better designed rich text input element to the web.

sure, but even if you want people to just be able to italicize or bold their input and nothing else, you're either stuck with the bludgeon that's contenteditable, or you can have fun reimplementing half of the countless nuances of font rendering on canvas. there really should be some sort of better option.

...or add instructions to "have text between _underscores for italics_ and **double stars for bold** - just adopt a subset of markdown and be done with it - we need to stop catering to humanity's lowest common denominator.

At some point you need more than what markdown gives you. I know, encountered it recently.

The formatting equivalent of... "640k ought to be enough for everybody".

sure but that sucks, especially on mobile. doubly so if you try to do anything mildly more advanced like embed images.

Rich text isn't just bold and italics. It also (often) supports tables, embedded images, links, fonts + font sizes and colors. Markdown supports a poor subset of that stuff.

And its not just for "humanity's lowest common denominator". I love being able to copy+paste a table into an email and have it show up correctly. Today's convention where I have to screenshot something to show it to you is horrible.

Markdown isn't the right tool for every job. Would you use markdown to typeset your resume? To write an academic paper?

Lots of popular applications - like Notion or Google Docs - need something more powerful than markdown. And the current javascript APIs are failing them.

The web has HTML and parsing/sanitizing it is a solved problem. I fail to see the need to go back to plain text not to be "fighting the web".

The world wide web is a free platform where you can publish plain text or HTML, but denying that it also became an application delivery platform is fighting against the reality.

I'm an early-internet kid, and even if we are going back to discover the "spirit of the internet", those times are full of contenteditable hacks and custom applet HTML editors.

Being able to edit HTML visually is so common, be it a simple personal homepage, editor to a corporate blog, or a product management tool.

Reply on news.ycombinator.com