6 ms·

In case anyone's interested, here's the Chromium bug(s) that's one of the main reasons the WYSIWYG editor has such issues in Chrome(/Electron): - https://bugs.

In case anyone's interested, here's the Chromium bug(s) that's one of the main reasons the WYSIWYG editor has such issues in Chrome(/Electron): - https://bugs.chromium.org/p/chromium/issues/detail?id=1029374 https://bugs.chromium.org/p/chromium/issues/detail?id=102937... - https://bugs.chromium.org/p/chromium/issues/detail?id=608393 https://bugs.chromium.org/p/chromium/issues/detail?id=608393 - https://bugs.chromium.org/p/chromium/issues/detail?id=608162 https://bugs.chromium.org/p/chromium/issues/detail?id=608162 The gist of it is that they "canonicalize" the DOM selection when you have two adjacent inline elements, so that it can only ever be at the ending edge of the first inline element. Which makes certain selection states impossible. And on top of that, they don't draw the cursor in the right spot when doing the canonicalization. So for instance, it might look like your cursor is here: <b>one</b>|two But it's actually here: <b>one|</b>two Drawn in the wrong place. And impossible to put it at the beginning of "two" at all! It's crazy! I don't know how much the take "starring" into account, but it can't hurt to star them in the hopes they're fixed sooner. --- Edit: If you want to see the craziness in action, check out this sandbox: https://codesandbox.io/s/amazing-breeze-6elsy https://codesandbox.io/s/amazing-breeze-6elsy 1. Try to put your cursor at the end of the word "one" 2. Try to type a character at the start of the word "two"

tasuki 7y ago
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.
- jammaloo 7y ago
  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.
  - martinbooth 7y ago
    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"
    - 333c 7y ago
      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.
      - deathanatos 7y ago
        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.)
    - aitchnyu 7y ago
      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.
- derimagia 7y ago
  All that demo uses is a contenteditable div. The bug is definitely is Chromium.
  - varenc 7y ago
    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
- binarycrusader 7y ago
  Really? It works fine in Edge (edgehtml-based version) and FireFox.
  - ianstormtaylor 7y ago
    Prepare for it to not work in Edge in ~1 month when they switch to being Chromium-based.
- zamalek 7y ago
  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.
  - swader999 7y ago
    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.
    - tiborsaas 7y ago
      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".
  - leeoniya 7y ago
    but it's good enough these days to serve as the basis for the CodeMirror 6 rewrite: https://news.ycombinator.com/item?id=17859291 https://news.ycombinator.com/item?id=17859291
- hobs 7y ago
  So stop implementing WYSIWYG if its a buggy piece of crap across the board.
epistasis 7y ago
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.
- mikekchar 7y ago
  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 ;-)
marknadal 7y ago
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.
- Hupriene 7y ago
  Good point. The developer tendency to resist fixing bugs caused by our tools just leads to complacency about broken tools.
pointcloud 7y ago
On the other hand, Notion (http://notion.so/ http://notion.so/) had exactly same bug a few weeks ago in their Markdown editor, and they have fixed it.
umanwizard 7y ago
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.
- leadingthenet 7y ago
  > 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...
  - umanwizard 7y ago
    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...
    - leadingthenet 7y ago
      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.
Wowfunhappy 7y ago
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.
- wlesieutre 7y ago
  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.
  - Wowfunhappy 7y ago
    > 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.
    - wlesieutre 7y ago
      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.
Vinnl 7y ago
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 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.
jrwr 7y ago
Wow, Firefox handles it just fine, Chrome just flat out breaks, that's a interesting bug!

tasuki 7y ago

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.

jammaloo 7y ago
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.
- martinbooth 7y ago
  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"
  - 333c 7y ago
    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.
    - deathanatos 7y ago
      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.)
  - aitchnyu 7y ago
    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.
derimagia 7y ago
All that demo uses is a contenteditable div. The bug is definitely is Chromium.
- varenc 7y ago
  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
binarycrusader 7y ago
Really? It works fine in Edge (edgehtml-based version) and FireFox.
- ianstormtaylor 7y ago
  Prepare for it to not work in Edge in ~1 month when they switch to being Chromium-based.
zamalek 7y ago
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.
- swader999 7y ago
  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.
  - tiborsaas 7y ago
    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".
- leeoniya 7y ago
  but it's good enough these days to serve as the basis for the CodeMirror 6 rewrite: https://news.ycombinator.com/item?id=17859291 https://news.ycombinator.com/item?id=17859291
hobs 7y ago
So stop implementing WYSIWYG if its a buggy piece of crap across the board.

epistasis 7y ago

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.

mikekchar 7y ago
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 ;-)

marknadal 7y ago

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.

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

pointcloud 7y ago

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

umanwizard 7y ago

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.

leadingthenet 7y ago
> 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...
- umanwizard 7y ago
  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...
  - leadingthenet 7y ago
    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.

Wowfunhappy 7y ago

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.

wlesieutre 7y ago
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.
- Wowfunhappy 7y ago
  > 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.
  - wlesieutre 7y ago
    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.

Vinnl 7y ago

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 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.

jrwr 7y ago

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