7 ms·

I'm quite disappointed that even in the year 2022 the best solution HTML offers for rich text editing is the infamous contenteditable attribute. I can never ex

I'm quite disappointed that even in the year 2022 the best solution HTML offers for rich text editing is the infamous contenteditable attribute. I can never expect a WYSIWYG editor from a library to work 100% without friction on every platform. I know it's already near-impossible to implement a web-browser and adding more to the pile of standards/components to implement sounds counter-intuitive. On the other hand, a basic browser that can render just basic HTML and basic CSS is comparatively easy and I would rather have them be able to render a rich-text-field on a low-capability device than being able to do all sorts of JS/CSS magic. I'm not even against React and all the amazing ecosystem surrounding it - given that your use-case justifies it. I just think auto-completers and rich-text editing and other stuff that nearly every website on this planet re-implements should be standard.

qsort 4y ago
That's because there's no standard for rich text at all, everything is either MS Word, some other bespoke proprietary format, or a kludge on a kludge on a kludge. In part that's due to the shortcomings of HTML itself. And no, markdown a.k.a. whatever the interpreter accepts is decent enough at what it does but it's not what we are looking for here.
- lopatin 4y ago
  So many rich text formats? Ridiculous! We need to develop one universal standard that covers everyone's use cases. [j] https://xkcd.com/927/ https://xkcd.com/927/
  - egeozcan 4y ago
    I never said anything about text formats though. Go crazy as the input, give me HTML as the output. I can sanitize it any way I want on the server-side anyway.
    - ta1636467 4y ago
      Sanitize when rendering the HTML, all other paths lead to hell. I agree with granddaddy, the web just didnt cater for this with all the XSS, XSRF etc shennigans. We're left with everyone implementing hacks, or in some cases, getting it right. Mud pie. Slap on an extra dollop.
      - egeozcan 4y ago
        > Sanitize when rendering the HTML, all other paths lead to hell I didn't mean mangle user input when storing. I mean you can do that if you want to parse it and store it as a semantic subset to deliver to the devices that can't render HTML (yes they exist), but I digress. You can sanitize any piece of HTML to a meaningful subset when rendering (well, before render, if you are doing on the server-side) with virtually any language by choosing among many solid libraries.
- stewx 4y ago
  Office Open XML (e.g., *.docx) is an ECMA and ISO standard format. https://en.wikipedia.org/wiki/Office_Open_XML https://en.wikipedia.org/wiki/Office_Open_XML
  - Cthulhu_ 4y ago
    How well does that render on webpages?
    - zo1 4y ago
      Check out office 365 on the web opening office file formats lik docx and pptx. I'd say it renders pretty frigging amazingly. Every other week I am amazed and want to buy more msft shares.
- egeozcan 4y ago
  The agents can implement any input mechanism. If I'm writing a text-based browser, I should be able to accept mark-down. Chromium can do whatever fancy thing they please. For output (the value of the field), HTML is good enough already. I don't see the problem.
samwillis 4y ago
My prediction is that in 2-3 years we will see WASM being used to run desktop class rich text editors in a canvas (much like Google Docs now does), and an open source framework will appear that enables it. I would even go as far as suggesting WebKit compiled to WASM would be better than trying to make a rich text editor based on contenteditable work everywhere, once you have it working in one version it runs “everywhere”. Although accessibility is going to be the main disadvantage of such system.
- josephg 4y ago
  The other downside is that text editing interacts with a lot of native OS controls. For example, iOS needs to use the OS's keyboard (which is configured outside the web browser). And the user should be able to tap-and-hold to select text just like they can in other webpages and apps. This sort of behavior is basically impossible to reimplement in javascript for every platform in a way that feels "native".
  - samwillis 4y ago
    Yes, maybe my 2-3 years is optimistic. I think ultimately it’s JS APIs for the native controls that need to be exposed rather than better contenteditable.
    - josephg 4y ago
      Accessibility APIs exposed via javascript? Sure. But all the other APIs you'd need would be a mess. For example, what would an API look like to support international character combining? Or drag-select on mobile? Or custom keyboard inputs? How do you respect the user's OS level configuration - Like system-wide emacs shortcuts in macos, weird keyboards on samsung phones or overridden fonts for people with reduced vision? Adding javascript APIs for all this stuff would hurt privacy on the web, because this data is full of entropy for anyone doing fingerprinting. And it wouldn't even solve the problem. You'd still need user code (JS/WASM) to correctly implement platform-specific behaviour for everything to feel native. Thats a janky ride every time. I'd much rather web browsers to just expose each platform's native rich text editing controls. They work great already. They already do accessibility, and have full support for the platform's native text editing controls and behaviour. And there's a precedent for this sort of thing - web browsers have had INPUT elements forever.
josephg 4y ago
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.
- catchclose8919 4y ago
  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...
  - jitl 4y ago
    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.
    - catchclose8919 4y ago
      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).
catchclose8919 4y ago
that's because "rich text" is at odds with everyhting the web is supposed to be... like separating structure and semantics from styling with html and css etc. sure, the "semantic web" failed, but that's the history you were not supposed to be able to control how content looks like on the web, this was supposed to be the choice of the browser customized by the user (eg. a user could set his browser to render sci-fi topics web pages text with font X and financial news with font Y min-size Z etc.) "web design" is something that should't have ever existed or had any reason to even be a concept... it all went off-the rails in the real world ofc, but this was the real context and dream of the web and its tehnologies as they were designed and standardized
- egeozcan 4y ago
  > that's because "rich text" is at odds with everything the web is supposed to be I respectfully disagree. Rich text editing is more about being able to add semantics than making giant red blinking text. I want to explicitly add paragraphs, emphasis, links etc. without learning a new input method for every website.
  - catchclose8919 4y ago
    A paragraph is a different text box. Sure, a standard method to work with links and emphasis would help, but that's about where we should stop. A bulleted list is [add new element] > [buleted list] -> a container with text fields for each bullet (+ add/remove buttons) appears. Same for table, a proper grid with separate inputs for all cells (see modern Confluence).
    - egeozcan 4y ago
      So you are suggesting to implement more stuff with scripting (otherwise that would be horrible to use with page reloads in between, no?). Why go all the trouble when HTML can store all the semantics just fine? I also use Confluence via plain HTML because their editor sucks, especially when copy/pasting. They have something even worse than MS Frontpage but implemented in JS, and my subconscious keeps me wanting to switch to CoffeeCup.
oefrha 4y ago
The problem with asking browsers to implement it is that every browser will implement it differently, and almost everyone will need some extra functionality not covered by browser implementations, so almost everyone reimplements it from scratch (or use one of those reimplementations) anyway. It’s the same story with <audio controls>, <video controls>, <select>, etc.

qsort 4y ago

That's because there's no standard for rich text at all, everything is either MS Word, some other bespoke proprietary format, or a kludge on a kludge on a kludge. In part that's due to the shortcomings of HTML itself. And no, markdown a.k.a. whatever the interpreter accepts is decent enough at what it does but it's not what we are looking for here.

lopatin 4y ago
So many rich text formats? Ridiculous! We need to develop one universal standard that covers everyone's use cases. [j] https://xkcd.com/927/ https://xkcd.com/927/
- egeozcan 4y ago
  I never said anything about text formats though. Go crazy as the input, give me HTML as the output. I can sanitize it any way I want on the server-side anyway.
  - ta1636467 4y ago
    Sanitize when rendering the HTML, all other paths lead to hell. I agree with granddaddy, the web just didnt cater for this with all the XSS, XSRF etc shennigans. We're left with everyone implementing hacks, or in some cases, getting it right. Mud pie. Slap on an extra dollop.
    - egeozcan 4y ago
      > Sanitize when rendering the HTML, all other paths lead to hell I didn't mean mangle user input when storing. I mean you can do that if you want to parse it and store it as a semantic subset to deliver to the devices that can't render HTML (yes they exist), but I digress. You can sanitize any piece of HTML to a meaningful subset when rendering (well, before render, if you are doing on the server-side) with virtually any language by choosing among many solid libraries.
stewx 4y ago
Office Open XML (e.g., *.docx) is an ECMA and ISO standard format. https://en.wikipedia.org/wiki/Office_Open_XML https://en.wikipedia.org/wiki/Office_Open_XML
- Cthulhu_ 4y ago
  How well does that render on webpages?
  - zo1 4y ago
    Check out office 365 on the web opening office file formats lik docx and pptx. I'd say it renders pretty frigging amazingly. Every other week I am amazed and want to buy more msft shares.
egeozcan 4y ago
The agents can implement any input mechanism. If I'm writing a text-based browser, I should be able to accept mark-down. Chromium can do whatever fancy thing they please. For output (the value of the field), HTML is good enough already. I don't see the problem.

samwillis 4y ago

My prediction is that in 2-3 years we will see WASM being used to run desktop class rich text editors in a canvas (much like Google Docs now does), and an open source framework will appear that enables it. I would even go as far as suggesting WebKit compiled to WASM would be better than trying to make a rich text editor based on contenteditable work everywhere, once you have it working in one version it runs “everywhere”. Although accessibility is going to be the main disadvantage of such system.

josephg 4y ago
The other downside is that text editing interacts with a lot of native OS controls. For example, iOS needs to use the OS's keyboard (which is configured outside the web browser). And the user should be able to tap-and-hold to select text just like they can in other webpages and apps. This sort of behavior is basically impossible to reimplement in javascript for every platform in a way that feels "native".
- samwillis 4y ago
  Yes, maybe my 2-3 years is optimistic. I think ultimately it’s JS APIs for the native controls that need to be exposed rather than better contenteditable.
  - josephg 4y ago
    Accessibility APIs exposed via javascript? Sure. But all the other APIs you'd need would be a mess. For example, what would an API look like to support international character combining? Or drag-select on mobile? Or custom keyboard inputs? How do you respect the user's OS level configuration - Like system-wide emacs shortcuts in macos, weird keyboards on samsung phones or overridden fonts for people with reduced vision? Adding javascript APIs for all this stuff would hurt privacy on the web, because this data is full of entropy for anyone doing fingerprinting. And it wouldn't even solve the problem. You'd still need user code (JS/WASM) to correctly implement platform-specific behaviour for everything to feel native. Thats a janky ride every time. I'd much rather web browsers to just expose each platform's native rich text editing controls. They work great already. They already do accessibility, and have full support for the platform's native text editing controls and behaviour. And there's a precedent for this sort of thing - web browsers have had INPUT elements forever.

josephg 4y ago

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.

catchclose8919 4y ago
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...
- jitl 4y ago
  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.
  - catchclose8919 4y ago
    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).

catchclose8919 4y ago

that's because "rich text" is at odds with everyhting the web is supposed to be... like separating structure and semantics from styling with html and css etc. sure, the "semantic web" failed, but that's the history you were not supposed to be able to control how content looks like on the web, this was supposed to be the choice of the browser customized by the user (eg. a user could set his browser to render sci-fi topics web pages text with font X and financial news with font Y min-size Z etc.) "web design" is something that should't have ever existed or had any reason to even be a concept... it all went off-the rails in the real world ofc, but this was the real context and dream of the web and its tehnologies as they were designed and standardized

egeozcan 4y ago
> that's because "rich text" is at odds with everything the web is supposed to be I respectfully disagree. Rich text editing is more about being able to add semantics than making giant red blinking text. I want to explicitly add paragraphs, emphasis, links etc. without learning a new input method for every website.
- catchclose8919 4y ago
  A paragraph is a different text box. Sure, a standard method to work with links and emphasis would help, but that's about where we should stop. A bulleted list is [add new element] > [buleted list] -> a container with text fields for each bullet (+ add/remove buttons) appears. Same for table, a proper grid with separate inputs for all cells (see modern Confluence).
  - egeozcan 4y ago
    So you are suggesting to implement more stuff with scripting (otherwise that would be horrible to use with page reloads in between, no?). Why go all the trouble when HTML can store all the semantics just fine? I also use Confluence via plain HTML because their editor sucks, especially when copy/pasting. They have something even worse than MS Frontpage but implemented in JS, and my subconscious keeps me wanting to switch to CoffeeCup.

oefrha 4y ago

The problem with asking browsers to implement it is that every browser will implement it differently, and almost everyone will need some extra functionality not covered by browser implementations, so almost everyone reimplements it from scratch (or use one of those reimplementations) anyway. It’s the same story with <audio controls>, <video controls>, <select>, etc.