It's mystifying, absolutely mystifying, to me that Slack shipped that editor when both electron and chrome show such obvious problems.

What sort of out of control process let this get out, and also let them ignore bug reports for so long?

This significantly lessens my opinion of Slack and their internal culture. In prior threads there were rumors that Slack employees were hesitant to give negative feedback internally, due to culture. I don't put much stock in rumors, but I'll be paying attention now to that possibility.

When Slack first showed up, their development process seemed pretty fast and loose. There were tons of bugs and everyone who endured their initial forays into 2FA will probably remember the discussions of "Is Slack (the company) responsible enough for people to use the product in a mission critical application?" To be completely fair, they've tightened up their development process significantly and I'm actually pretty impressed that this is the first major gaff I've seen from them in a long time. I'm hoping its an aberration. I'm pretty public in saying that I don't really like SaaS offerings unless I get source code, but I have to use Slack at work, so I'm hoping they are successful ;-)

Not sure Chromium is to blame here. All the WYSIWYGs in all the environments I've ever seen I found fiddly and unpleasant to use.

The above demo works fine in Firefox, FWIW. I had a large hand in building a WYSIWYG email editor a few years back, using direct DOM editing, that was the most full featured available at the time. I would only recommend it to people with very high pain tolerance, as the differences between browsers are stark, undocumented and hard to work around.

In firefox it skips one letter at a time and maybe that is the intended behaviour, but it doesn't seem consistent with what I'd expect from a WYSIWYG editor.

I'd expect there to be 2 positions between the "e" and the "t" that the cursor would stop at so I can either insert text with the formatting of "one" or "two"

There is a position at the start of "two" in Firefox, but you have to approach it from the right. That feels sane to me.

The "approach from the direction you want to take styling from" breaks down when you cannot approach from the other direction, or if there are >2 possible insertion points in the middle of a piece of text. I'm going to use Markdown to show the markup in HN, but pretend like it's rich HTML:

  A string that ends in *bold!*
                             // 
                            AB

Only position A is possible in Firefox's "approach from" algorithm; there is no way to tack on non-bold text to the end, short adding it and then re-/unformatting it.

You can then pretty quickly see what goes wrong here:

  A string that have *_italic bold_ and bold!*
                    ///
                   ABC

In Firefox, only positions A and C are possible; there is no way to start editing at B.

I think you could turn any of these into interesting box forms like one of the links in this thread that has two colored boxes, and you could have text somewhere (like between A & B in the second example here) and delete that text, and suddenly not be able to get a cursor back there, short of laying some text down and reformatting it.

Markdown, and other markup/syntax based inputs, make this trivially obvious, to a large degree. (Some ambiguities in the syntax can cause issues, but those seem to be rarer than issues w/ Slacks WYSIWYG editor.)

Don't Fuck with Paste, extension that disables anti-paste event handlers some banks use, triggers this when pasting into rich editors. Even Facebook and old Slack editor, IIRC.

Yup, in order to be able to paste into any of those inputs you need to have clipboard events on

It doesn't work fine on Firefox android.

Firefox on Android ( / Preview) is generally terrible with input handling anyway. I still haven't figured out a way to paste into a textbox without removing existing text — long press is required to show the menu, but also selects the last word, and unselecting removes the menu.

>long press is required to show the menu

It's not. Tap on the caret and the menu will show up without selecting anything.

Thank you! This does seem to work intermittently (at least, it didn't work when this text box was empty, but started working once I typed in some text). I guess I'll have to file that in my head as "works inconsistently", but at least it… sometimes works?

Same for FF preview.

Checked and it behaves the same in Safari as Chrome so it appears this is left over from WebKit and by HN logic since Apple did it it's the right way! (jk)

Yes, I agree it should be fixed. Most WYSIWYG editors do have issues though. Just tried Pages (apple's word processor. abc <b>def</b>. Putting the cursor before after the space before the d I would personally think is more intuitive to insert bold but it inserts plain. As it is there is no way to type bold at the front of the bolded word. You either have to type new text and bold it OR you have to insert after the d, type a new text and an extra d then delete the leading d. Yes you can press Cmd-B then type but of course if the text had more styling applied that would get cumbersome to reapply styling so you're left with the previous solution of inserting new text in the middle and deleting the leading character.

The reason is that content editable is a gaping hole in the HTML5 spec, at least last time I checked, there are tons of undefined undefined behaviors (not a typo) where vendors have to choose what they want to do and where developers have no idea that the behavior does not exist in a specification.

My very wise coworker made every effort to avoid that minefield. I thought he was wrong for many years, but I have been forced to agree, content editable is completely and utterly useless and should be avoided at all costs.

I always thought the entire cms space, the idea that non coders could manage web content, was a non starter just because of the editors.

But it's utterly inefficient to use coder time to manage web content. That's why the best idea is to create a block by block content editor with textareas or severally limited editors that remove and reformat HTML that's being generated. I've seen good results thanks to this.

I agree though, whenever I included a full WYSIWYG editor to a CMS the end users created unimaginable havoc. "Hey it's Word, I know this".

but it's good enough these days to serve as the basis for the CodeMirror 6 rewrite:

https://news.ycombinator.com/item?id=17859291

All that demo uses is a contenteditable div. The bug is definitely is Chromium.

Safari on Mojave and iOS has the same problem...so it'a likely a bug in that's been around since Chromium/Blink forked from WebKit

So stop implementing WYSIWYG if its a buggy piece of crap across the board.

Really? It works fine in Edge (edgehtml-based version) and FireFox.

Prepare for it to not work in Edge in ~1 month when they switch to being Chromium-based.

I really hope they don’t think they can fix a few “bugs” and make this thing usable.

I’ve noticed this in the past, when a previous employer got rid of their Markdown interface for interview candidate feedback. In response to everyone’s angry comments about their flaky piece of garbage WYSIWYG replacement, they responded “please file bugs if our Markdown-like shortcuts aren’t working right!”

They were completely missing the point since even if their tool was 100% bug free (which it wasn’t, and I’m sure still isn’t), WYSIWYG editing will NEVER feel like text editing, and I NEVER want it in a critical work tool.

Honestly people thinking their WYSIWYG editor “supports markdown” because “Star Star” is an alternate shortcut for Ctrl+B seems to be so severely missing the mark that I wonder if they’re deliberately insulting my intelligence.

> I wonder if they’re deliberately insulting my intelligence.

They are, but in cases like these you should always ask yourself if you're the target market. Frankly, if you're not the one deciding whether to adopt Slack at your workplace, you're probably not...

I work at a very small company with eminently reasonable management. If the engineers didn't want to use Slack, we wouldn't use it.

Sadly, you're probably right that most people aren't in that boat...

Exactly. At my current place, management would laugh in my face for even thinking of such a thing. And this is a small company, mind you.

Yes, I do want to leave asap.

My request for every rich text WYSIWYG editor is as follows: please never change the text style of my cursor unless I explicitly say so. Regardless of the cursor's location.

Toggling bold should function identically to toggling caps lock: if I press the bold button, any letters I type should be bold until I press the bold button again. Caps lock does not disable itself when I click into a non-all-caps block of text, and neither should bold.

This would be annoying sometimes, but it would help far more often than it would hurt. For some reason, however, nobody does it this way.

If I'm in non-bold mode and I click in the middle of a bold word/sentence to make edits, do I automatically start typing in non-bold? That sounds much more annoying than helpful.

> If I'm in non-bold mode and I click in the middle of a bold word/sentence to make edits, do I automatically start typing in non-bold

Yes! You'd need to press ⌘B to enter bold mode, and then begin typing.

It's ever-so-slightly more effort, to be sure. But, I loose so much more time trying to add non-bold to the end of a bold section, or vise versa.

I can learn to use systems which behave in repeatable and understandable ways. Once a system starts making decisions for me based on information I can't see—like invisible markup tags—everything becomes much harder.

The alternative is of course to make the markup visible, but for writing prose, I appreciate the clean look of WYSIWYG editors. Visible markup can feel messy.

What about text styling that doesn't have fairly standardized hotkeys? Pretty much anything outside of bold/italic/underline.

Text color, background color, strikethrough, superscript, etc.? If I'm typing in a block of red text, is my new text black unless I tell it again to be red? If I'm editing a superscript, do I type normal text in the middle of it and then need to select it and make it superscript afterward? Editing text that was highlighted with a yellow background?

It might be an easy toggle for bold/italic/underline but there's a lot of other text formatting that would either need to behave differently or would become a huge pain. Personally I'd rather keep it consistent.

It's been a while since I read this, but IIRC this article describes that bugs like these are exactly the reason why CodeMirror doesn't rely on contentEditable: https://codemirror.net/doc/internals.html

> CodeMirror 1 was heavily reliant on designMode or contentEditable (depending on the browser). Neither of these are well specified (HTML5 tries to specify their basics), and, more importantly, they tend to be one of the more obscure and buggy areas of browser functionality—CodeMirror, by using this functionality in a non-typical way, was constantly running up against browser bugs.

On the other hand, Notion (http://notion.so/) had exactly same bug a few weeks ago in their Markdown editor, and they have fixed it.

Wow, Firefox handles it just fine, Chrome just flat out breaks, that's a interesting bug!

Um, no, this is not impossible, us editor folks have been inserting 0-width space after the tag and selecting it for years.

The team the size of Slack should/could have easily worked around that.

Good point. The developer tendency to resist fixing bugs caused by our tools just leads to complacency about broken tools.