193

TL;DR: We are testing our new open source Stacks editor that offers both Markdown and rich text input options. If you’re interested in testing it out and giving us feedback, you can opt in by visiting your preferences page and enabling the Stacks Editor. You can opt out at any time but it will take up to 10 minutes to revert to the old editor. Note, the new editor will only be active when drafting or editing answers on MSE or MSO during the alpha test.


About six months ago (i.e. circa July 2020), our product teams and Community team began exploring whether we could bring to our public sites the Stacks rich text post editor that launched on Stack Overflow for Teams (or Teams) over the summer. We’ve been spending that time discussing the needs internally and also talking with some of our most highly-engaged users about the new editor - our Moderators and members of the Charcoal group - to understand what might need to change or be included to make using the new editor an easy change-over from the old editor.

Through this process, we’ve received dozens of answers with ideas for improvements, bugs that needed to be squashed, and UX confusion that needed to be ironed out. We’ve addressed many of the concerns these two groups mentioned and are ready to bring it to the larger community through an opt-in alpha test on MSE and MSO. We are asking for your constructive feedback to see where there’s room for improvement to make it into a tool both people who are comfortable with Markdown and those who may be more comfortable with rich text can use successfully.

Here's what the two views look like - you can click to view a larger image:

Screenshot of the new editor window in Markdown mode with the text of this post input the text is monospaced and the Markdown in the post is visible, though sections in bold appear bold Screenshot of the new editor window in rich text mode with the text of this post input. The post is in Arial with bold and headers and horizontal rules being visible rather than the Markdown.

The test

The goal of this alpha test is to get an initial understanding of how well this new editor would be received and to also discover any concerns that would break workflows for users who like the current editor or prefer to work in Markdown. We also want to consider users who may not be familiar with Markdown, too, as they make up many of the users on our non-technical sites. This is the first public phase in a process where we hope to fully test and refine the editor so that, when it launches network-wide, people will find it easy to use and to be a major improvement over the current editor.

We understand that rich text entry is a difficult thing to get right and realize that it may take several months to find the right solutions before we can make this live network-wide - and that comes with the understanding that there may be unsurmountable issues - but we feel that working through this process with y’all will, at minimum, help improve the new editor experience on Teams and may end up with a great new editor for everyone to use.

This is part of a multi-part test that will look something like this:

  • Initial release on Teams with feedback from highly-engaged users (e.g. Moderators) (Completed Summer 2020). The goal of this was to get feedback and get a good idea of how much we need to change the editor so that it will work for our public platform community. This allowed us to test many (though not all) of the features with a small group of people without impacting the public site.
  • Testing on MSE and MSO through an opt-in alpha test. The goal here is to further refine and identify solutions that will help the new editor be openly adopted by users, primarily active members of the community.
  • Usability testing sessions with users of several different experience levels. The goal here is to make sure that the features and UX we create after responding to our highly-engaged users is still transparent to others. We’ll watch how users of varying experience levels interact with the editor to identify and make additional improvements with the goal of an intuitive user experience that has sufficient guidance where needed.

As to a timeline, this is expected to take a while to work through. One of the benefits of the alpha test is that people can enable and disable it as they wish. For the rest of 2021 Q1, our plan is to leave the test running so that y’all can try it out in a more long-term way if you wish. While we’ll be fixing major bugs, we won’t be prioritizing new features or adjustments until we start digging into your feedback from this test and the feedback from the usability sessions in the second quarter of 2021. See a bit more on this in the giving feedback section below.

Assuming these tests go well and we find solutions that make post creation and editing easier than the current system, we’ll move into a gradual rollout phase, starting again with MSE and MSO and then to the sites with standard editing tools, reserving the sites with specialized editor add-ons for the end so that we can make sure that their tools work correctly upon launch.


Why are we working to bring a rich text editor to our sites?

While there have been some requests for a rich text entry option over the years (this one going all the way back to 2009), there’s never been much support for them from users - in fact, many of the requests get strong disagreement from other users. Markdown is a great tool and many users are or have grown accustomed to it - I admit to regularly trying to use Markdown in rich text spaces. That said, many of these requests have been to replace Markdown with rich text and that’s not something we want to do.

As a platform that is largely used by programmers, Markdown is generally a familiar format for many and they’re very comfortable using it, particularly now that we follow the CommonMark standards. For those who don’t know Markdown, we’ve expected them to learn and we give them some assistance but, in many cases, posts end up poorly formatted and need participation from the community to improve. Many of my edits on English Language Learners are purely to improve post formatting.

Additionally, our editor has been around since the beginning with few improvements in that time, so a major upgrade is in order and, in looking forward, we feel that a redesigned editor using Stacks will be more easily maintained and improved as we go forward.

Teams needed a rich text option

We have a great team who works to enhance the Teams product to meet the needs of companies and organizations who are using it for internal knowledge sharing. One frequent pain point from these users was the lack of a rich text editor - here’s a statement from Ham, one of the Teams developers:

We started building the new Stacks Editor as a response to feedback from our Stack Overflow for Teams customers. While Markdown has become a widespread and successful format for writing content - not only at Stack Exchange but across the web - some of our Teams customers told us that they’re not comfortable writing their content in Markdown. They didn’t know the syntax and faced a learning curve before they could start writing the way they wanted to. Writing questions and answers wasn’t as easy as they were used to from other places. For us it’s important to make contributing as easy as possible. Writing questions and answers should feel natural and come without a lot of friction.

This makes sense. Copy and pasting from a rich text editor like Google Docs or Word is much more common within a company where you may be transferring information from existing documentation to a Team, whereas much of our public site content is created from scratch. That said, it’s not unheard of to copy content in the form of quotes into posts, where a rich text detection feature would be helpful so that adding the Markdown manually wasn’t necessary.

The main driving force for the development of the new editor was to improve the experience of Teams for our existing users and give it a feature set that would attract additional users. That said, since many of the people using Teams are developer-centric groups, they also are often comfortable with Markdown, so we wanted to ensure that both options were available. More from Ham:

The new Stacks Editor tries to be the best of both worlds. If you’re happy with writing Markdown and liked the way the old editor helped you with that, the new editor will feel very familiar. You can write Markdown, use familiar keyboard shortcuts, upload images and more. If Markdown is not your strong suit, Stacks Editor allows you to switch over to the new rich text mode that allows you to write in a more WYSIWYG kind of fashion.

We still think that Markdown is the way to go, but we also see the benefits of a rich text editor for less technical users and/or network sites who may be more accustomed to a WYSIWYG style editing. With the new Stacks Editor, Markdown continues to be the leading format for your content and everything you write will be transformed and stored as Markdown at the end of the day.

So, our focus in building the new editor was to add the option of rich text but still maintain a Markdown focus because we love Markdown and think it’s a great experience for those who already know how to use it and is relatively simple to learn but we also want to simplify or improve the experience for people who may be copy-pasting into posts or who don’t know Markdown.

More than just rich text, we’re simplifying future work for development

The current editor has been around since 2008 and, while we’ve made changes along the way, it’s largely unchanged and now makes building new features difficult. Additionally, by adopting and improving the Teams editor on our public network, we’re simplifying future work on ask, answer and edit pages and maintaining similar features between Teams and the network. My final quote from Ham:

Our old editor has served us well for many years, but due to a number of issues (reverse-engineered code that is hard to work with, inadequate API for handling cross-browser issues, and bare-bones content-editable support) we are unable to use it as the base for any major upgrades. Additionally, there are many advantages from basing an editor on a modern foundation (like we have done here on top of prosemirror), which can take care of many of the nasty "content-editable" concerns and keep things safer and more cross-browser compatible.

Being around for so long, it has accumulated quite some cruft and has become hard to maintain and evolve the way we would love to. Over the past years we tried revamping the editor a couple of times only to find out that it would be too hard to do. When we started building the new editor for Teams, we knew this would be a good opportunity to greenfield a new editor overhaul that would ultimately benefit all our users across the network.

On top of this, we’re opening the editor up for everyone to use and contribute to. Like Stacks, the new editor is open sourced, so if you’re interested in how it’s built or want to contribute to improving it, you can find it on the Stacks-Editor repo.

Building editors is hard - particularly when dealing with rich text

I’ve learned the quirks of a variety of different editors over the years, whether it was BBCode on the forums I participated in, Wikitext on MediaWikis, Markdown here on Stack Exchange, or any of the various rich text or hybrid editors on the various platforms I’ve used (e.g. Jira, FreshDesk)… so I’m comfortable adapting to new styles, but I also find that some editors make assumptions that frustrate and confuse me and make me not want to use them any more. We want to avoid this frustration!

Because our focus is on Markdown, with the addition of special formatting for tables and spoilers, we’re able to limit what our rich text editor has to do - we’re not increasing which formatting options are available (e.g. colorful text or underlines) which is one way we’re working to keep our rich text implementation and the conversion between rich text and Markdown simple, easy-to-understand, and as frustration-free as we can.

The major changes

Other than the optional rich-text entry, there are a bunch of other changes, big and small, that you’ll see in this test. Below are some of the biggest ones including a brief overview of how rich text entry works. A lot of what’s written below was penned by Ben Kelly, who’s done a lot of work with Ham to get this editor going and is supremely knowledgeable of the features, so big thanks to him for that!

Rich text mode

This editing mode was designed to largely resemble traditional word processing software that many users are used to. However, we've added in some extra features:

  • Markdown-style "input rules" for block level syntax
    • Typing # , ## , etc creates a header; typing > creates a quote; * creates a list, and so on
    • We’ve got inline input rules (bold, italics, inline code, etc.) on a list of things to investigate for a future release
  • Link and image editing tools will allow editing link URLs for links and the addition of an image description and title for images.
  • Intelligent copy/paste support - Pasting external content from e.g. Google Docs or code from your editor of choice will retain most of its existing formatting, provided that formatting is in Markdown.

Ultimately, the rich text editor is converted back to Markdown and should support everything you can do in Markdown, with some caveats:

  • Pasting rich text from outside sources isn't perfect, especially with very complicated content
  • What we can support in rich text mode is restricted by our backing Markdown implementation, so things like merged cells in tables or super/subscript aren’t supported, even when we do support the HTML (see next bullet).
    • This is really more of a feature than a drawback. We <3 Markdown and are committed to supporting it first-class for the foreseeable future
  • HTML support is HARD. We make no promises that any HTML written in Markdown mode will be editable in rich text mode
    • We recommend using the equivalent commonmark syntax when available. We’re looking to extend our supported Markdown syntax so users won't need to type HTML anymore.
    • Don't ask why HTML is hard. It's a long story that could be a blog post of its own.

The Markdown - rich text switcher

Two screenshots in one - on top, the Markdown switcher in Markdown mode with the switch background green and the selector on the right; on the bottom, the Markdown switcher in rich text mode with the background grey and the selector on the left.

To allow for movement between rich text and Markdown modes, we’ve added a switch. When the dot is on the right (green background), you’re in Markdown mode; on the left (grey background), you’re in rich text mode. The current default for all users is Markdown but, after you use the editor, the system will remember your last-used option as your default. So, if you submit a post or edit while in Markdown view, you’ll see that the next time you open the editor; if you do so in rich text, that will be the view you have when you next use it. The default configuration for users can be changed per-site, so if a site feels that rich text makes more sense as their default, we can allow for that.

Preview is collapsed into the rich text view

Over the years we’ve gotten lots of questions about whether we could optimize the preview so that it didn’t take up so much space on the screen. If you’ve ever written long posts, you may be familiar with the feeling of doing a lot of scrolling to get from the end of a preview back to the edit window. With the new editor, you see the preview by using the Markdown toggle to switch between Markdown and rich text modes and, because the rich text preview is part of the editor, you can edit right in the preview rather than having to find the edit window again. This is a lot more convenient for mobile users, too, with their smaller screens where scrolling through even a short post can mean a lot of work.

Aaron, our Principal Product Designer for Design systems explains the value of an editable preview:

We think this is more than a layout issue. We could put these previews side by side, or toggle between them like GitHub does, but I think having a preview at all is something we can move beyond. Tiny sidenote: I worked on GitHub’s editor in 2016! We could explore alternatives like having a button that launches a full screen preview, but I think that’s wasted effort when we could be writing directly in the preview experience.

The web has matured past the point of requiring Markdown syntax and discrete previews. Why should any text editing offer a read-only preview state in 2021? Is writing, previewing, noticing a mistake, and moving back to the editor truly better than simply being able to edit the text? Would you accept this interaction model in your word processor? In Notion? In Google Docs? In Medium?

We feel this is a positive change for these and many other reasons but we do understand that it’s a big departure from the current format. Please take some time to see how this new workflow feels and let us know what you think and how we can improve this. I know that many of the prior requests have been for a side-by-side preview to cater to the wider screens that many people have, particularly as this matches many other Markdown editors. Unfortunately, this can be complicated on smaller screens, which would require different placement and it’s pretty common to have previews separate from the entry form, like with GitHub’s two-tab format.

We do have a few known issues here:

  • While switching between modes does maintain your approximate scroll position, it doesn’t remember where your cursor was. Any time you switch, your cursor will move back to the top of the post rather than staying where you were.
  • There’s no history when switching modes, so flipping between views will cause you to lose the ability to undo/redo the changes from the other view.
  • Since the rich text preview will interpret your Markdown, any incorrect Markdown (MD) may be escaped out by the rich text editor. When you return to MD view, you will be able to fix these errors.

Syntax highlighting in Markdown mode

You’ll notice your Markdown experience is a bit less monotonous because it now responds to the Markdown you use by changing the text in the pane - headings will be larger, bold text will appear bold, as will italics, and links will be in blue and code will be in grey. I’ve found this really helpful in drafting posts as it identifies a lot of the Markdown errors I might have made, making it so I’m less likely to even need to look at the preview. This isn’t currently CommonMark compliant but we’re working on improving it.

Changes to formatting buttons

We’ve removed some buttons and added some new buttons to the ones available for formatting. Here’s what the formatting bar looks like now:

A screenshot of the post formatting bar showing the various buttons. In order from left to right there's the header button, bold, italic, inline code, links, quotes, block code formatting, image uploading, tables, ordered lists, unordered lists, horizontal rule, and a question mark for help. On the far right is the "Markdown" switch

Removed:

  • Undo/redo - these features still work with your standard key combinations but we’ve removed the buttons themselves - we’ve also improved undo/redo history support to be much more reliable overall.
  • Stack Snippets (temporary) - We couldn't get Snippets built into the initial alpha test, so if you need to add a snippet to a post, you'll need to disable the alpha to do so.

Updated / New:

  • Tables - this button will create a default three-row, two-column table and have special menu options when in rich text mode that allows adding/removing rows and columns.
    A screenshot of the formatting bar with the table tool open and the various options to remove and insert columns and rows visible
  • Headers - this button has been redesigned and moved to the first position.
  • Inline code / code blocks / Stack snippets buttons - one piece of feedback from our early tests was that for rich text, we need to differentiate between inline code and code blocks but on Teams we reused the same icon for code blocks that we currently use for Stack Snippets - to allow all three options, we created new icons. Snippets are disabled for the alpha but you can see the new trio of buttons (left to right - inline code, code blocks, snippets)
    The new icons for the code markup buttons - a pair of angled brackets "<>" with no background for inline code, a pair of angled brackets with a background for code blocks, and a pair of angled brackets in a stack of icons for snippets.

We're planning to add keyboard shortcuts to the formatting buttons but they aren't part of this initial alpha test.

Markdown mode is your go-to for fine-tuning posts

Markdown mode will give you fuller control of your posts, as it already does. Here are a few places you’ll want to stick to MD when composing or editing posts:

  • Adding a language to a code block for syntax highlighting purposes - while we’re looking to add this to rich text, for now it’ll require MD. The system will still auto-detect languages based on tags as it usually does but if you need to call out a specific language, you’ll need to use Markdown mode.
  • Markup that requires HTML - we still support some HTML in posts but the rich text mode won’t create it, so if you need to include HTML in your posts for formatting such as subscript or superscript, you’ll need to enter Markdown mode for this.
  • Spoilers - like HTML, they're supported but we don't have a button for it, so you'll need to use Markdown mode to add them.
  • Creating complex lists - this is possible in rich text mode, but it’s not as intuitive as using Markdown, particularly in special cases such as lists with indented code blocks.
  • Fine-tuning images - resizing or adding links to sources or full-sized images will need Markdown mode.

Inline text and image links are the norm

The image and link tools will now add images and links inline rather than in the bibliography format. While the latter will still work, you’ll have to create it manually. Right now, images don’t have their image plus link formatting but we’re working on getting that added in a future release.

How to participate

Screenshot of the user preferences page with the alpha test opt in option emboxed.

If you’d like to opt-in to the alpha test, visit your preferences page and opt in by enabling the Stacks Editor opt in option. At the outset the new editor will only be available on answers - you won’t see it on questions, profile pages, tag editing pages or any other editing forms around the site. Opting in is global, so if you opt in on MSE, you’ll also see the new editor if you’re on MSO. If you decide you’d like to opt out, you can do so in the same way, switching the slider on your preferences, though it may take up to ten minutes for the editors to return to normal.

Giving feedback

This feedback phase is an incredibly important part of this process so we really appreciate any of you who take the time to try the editor out. If you run into bugs, usability issues or if you think of features that would improve your experience with the new editor, please leave an answer here - one per answer - so that we can review and respond to each. Steps to reliably reproduce are always appreciated along with which browser/s you're experiencing the bug in, and especially so when it comes to obscure edge cases or subtle usability issues. Additionally, because this project is open sourced, for truly technical bugs, you can file them as an issue on the GitHub repo - if you feel comfortable with that - if we get reports filed in both places, we’ll link them.

Our plan is to transfer issues from our internal system to the GitHub repository and add any new ones that come up here so that anyone who’s interested can see what we’re working on and how we’re prioritizing this work.

While it’s great to hear your overall thoughts about the editor, if there’s too much in one post it can make responding difficult so try to keep each answer relatively concise. You’ll have until the end of the alpha to add the answers here. Once it’s over, we’ll let you know how best to give feedback.

Thanks

This project couldn’t have been possible without the work of so many people and they all deserve a ton of credit. In particular I’d like to recognize Ben Kelly, Ham Vocke, Aaron Shekey, Des Darilek and Adam Lear for all of the effort that they’ve put in. Additionally, to those who have taken the time to test and give feedback while the editor was in Teams only, thank you!

47
  • 7
    I like this editor, I've been using it in SO for Teams for a while now. Tooltips are great. And thank you for giving us an option.
    – Ollie
    Jan 26, 2021 at 19:32
  • 5
    This post is getting more answers than upvotes. Popular, you think?
    – Ollie
    Jan 26, 2021 at 20:41
  • 8
    @Ollie sorry, my fault. I can only upvote it once...
    – Glorfindel Mod
    Jan 26, 2021 at 21:13
  • 70
    "in many cases, posts end up poorly formatted" - I doubt that's the fault of markdown. Many askers are just too lazy to apply formatting or grammar.
    – Bergi
    Jan 27, 2021 at 0:14
  • 41
    @Bergi I mean... that's a possibility... but I really don't think that everyone, network-wide, who fails to perfectly format posts are all just lazy. And, honestly, it's kinda uncharitable to assume that. I'd much rather give people more options to make their post look great and honor that's at least part of the problem.
    – Catija StaffMod
    Jan 27, 2021 at 0:55
  • 6
    Watch the terminology around this. Searching for "Stacks Editor" in Google comes up with StackEdit, which isn't built by Stack Exchange. (Incidentally, it seems to be a much more feature-rich markdown editor which also solves many of the problems users have shared in answers below. Play around here)
    – Robotnik
    Jan 27, 2021 at 4:52
  • 29
    On the sites which have mathjax enabled, the MathJax source will be shown in both views, right? Or does the rich text view actually show rendered MathJax?
    – Martin
    Jan 27, 2021 at 6:56
  • 7
    @Robotnik we've come full circle. If you check out StackEdit's GitHub repo you can see how they built it on Stack Overflow's previous markdown engine. Personally, I'm not worried about the name. Ultimately, it's gonna become the editor component in our Stacks design system so people can find it there if they're looking for it.
    – Ham Vocke StaffMod
    Jan 27, 2021 at 8:35
  • 4
    How about you use the official sandbox post for that @ouflak
    – Luuklag
    Jan 27, 2021 at 13:51
  • 14
    "Why should any text editing offer a read-only preview state in 2021?" - arguably, WYSIABNQEUWYG editors that a lot of old forums had and that universally failed at anything more complicated than bold, italic and underline are exactly what the Internet has been moving away from. Jan 28, 2021 at 7:37
  • 51
    @Catija "I think having a preview at all is something we can move beyond" Please, please no. Especially if there's still bugs to work out that wreck your formatting, nixing preview should be a nonstarter.
    – TylerH
    Jan 28, 2021 at 22:54
  • 8
    @TylerH: I know what it is. It is a UI catastrophe. Every place that uses them generally also includes some additional means to try and make clear whether left or right means the feature is activated. Look how much text was spent in describing the feature that went into describing how to turn it on and off. Notice that it also changes color to help make clear when it is on. Compare that to an unambiguous check box that needs no explanation. The sliders suck.
    – JRE
    Jan 29, 2021 at 6:40
  • 8
    @JRE .... So post a passionate posted about why a checkbox would be better rather than having your point of view forgotten, mouldering in the comments. The whole point of this is to try to get these things sorted out
    – Journeyman Geek Mod
    Jan 29, 2021 at 12:01
  • 29
    Chiming in with others. This must be site specific. Killing the preview will introduce difficulties in Math.SE and other MathJax -using sites. I might manage myself, but others needing more complicated formulas and such are seriously hampered. I am also very worried about our new users who have not written thousands of pages of LaTeX like I have. They need the help of a preview pane. Typically they start with simpler pieces when the need to scroll much is not so pressing. Feb 2, 2021 at 19:36
  • 5
    @T.J.Crowder It's not active on SO, only on MSO and MSE. :) To answer your specific question, no, there's no limit.
    – Catija StaffMod
    Feb 10, 2021 at 13:58

114 Answers 114

9

Bug report opened on GH

Images aren’t shown as selected, e.g. in the following I selected from “Google Document” to “blah” and the image wasn’t shown as selected (tested on Chrome with native dark mode+Windows):

Screenshot showing text before and after an image being selected, but showing the image as not being selected

1
  • 3
    Thanks for the report! I can reproduce this locally. Clicking an image shows it as "selected" (with a focus ring), but not when it is part of a cursor selection range
    – Ben Kelly StaffMod
    Jan 29, 2021 at 22:10
9

Extra sidebar in toolbar menu & incorrect SVG rendering in image upload modal

There's an annoying scrollbar on the new editor which appears even when there is no content in the textarea.

enter image description here

When you put a lot of content in it two scrollbars appear.

enter image description here

This can be sort of annoying. It appears that it can be fixed by setting the toggle button's height to 23px instead of the current 24px.

Specifically, here:

Oddly enough, I also ran across a bug when I tried to upload an image in this answer. It displayed something really quirky:

(sorry for the long answer)

4
  • 3
    We noticed this a couple of hours ago and are digging into what happened. Thanks for the report. :)
    – Catija StaffMod
    Apr 1, 2021 at 1:44
  • @Catija Thanks for the update. I also ran across a quirky bug with the image upload.
    – Spectric
    Apr 1, 2021 at 1:46
  • 3
    According to our design systems lead, that's our SVG imgur logo rendered as text. We'll... dig into that, too. Thanks! :D
    – Catija StaffMod
    Apr 1, 2021 at 1:49
  • 5
    Thanks for the report! I've found the root of both issues and will have a fix deployed later today. The odd scrollbar is due to switching the toggle to use a new Stacks component (Stacks is our internal design system) and in this scenario, some dreaded legacy code is adding some margins that's causing the overflow we're seeing here. As for the image uploader, I added some fixes to mitigate potential XSS bugs (found by an eslint rule) and the sanitization was a little too eager in this cases...
    – Ben Kelly StaffMod
    Apr 1, 2021 at 14:50
9

Add a horizontal rule to separate the text field from the controls:

1
  • 2
    This is currently "by design", but I'll bring the suggestion to the design lead. Currently, there's no divider when scrolled all the way to the top, but once a scrollbar is introduced, the bar "floats" and uses a shadow to denote separation.
    – Ben Kelly StaffMod
    Feb 28 at 15:18
9

GH #173

Toggling between modes causes italics within links to be changed like this:

Screen recording showing how a link with italics in, but that doesn't cover the whole link text, it is split up from one to two links when toggling between markdown and rich text.

This seems to have caused the red part to leak into the green one (See rev 20):

I had just deleted an extra space between 'to' and 'delete'.

Image demonstrating an additional rendering bug when the previously demonstrated edit was submitted, resulting in the red associated with text removal being shifted and positioned in the wrong place

8

When having two tables in the rich text editor, selecting everything and pressing backspace only deletes one table, not everything selected.

To reproduce:

  • Add two tables one after the other
  • Select both tables with your mouse and hit backspace
    • Using ctrl + a to select works as expected
1
  • 6
    Oh, this is a strange one. Everything deletes as expected when selecting with CTRL+A, but not when selecting with a mouse. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:08
8

If you start by clicking on the 'Insert code block' button and type the word 'test', it'll say it auto-detects the 'lisp' language. I guess an autodetection feature is nice to have, but when switching to Markdown it doesn't show the ```lisp and without that hint, it won't work.

4
  • 3
    I believe that indicator is telling you which language that Hightlight.js will automatically highlight the code as in its current form, not that it automatically applied that language to the code block. If the code block had a defined language override on it, the "(auto)" part would not be there.
    – animuson StaffMod
    Jan 26, 2021 at 19:39
  • I guess it's different, or broken for Glorfindel, because it's identified as plaintext for me. Screenshot.
    – Rob
    Jan 26, 2021 at 19:54
  • 2
    Code highlighting in rich-text mode still leaves a bit to be desired. We don't want to try and autodetect what language you're attempting to use in real time as you type (for performance reasons), so we do it once when switching from markdown mode and keep the assumption. Even then, the logic doesn't take your post tags into consideration (yet), so it isn't a perfect emulation of the old process. We're still thinking on how to best handle code autodetection in rich-text mode. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:54
  • I also asked if it could be choosed manually ? Jan 26, 2021 at 23:15
8

In Markdown mode, Ctrl+K inserts single backticks (inline code) instead of creating a code block like the old editor.

In the old editor, the only time inline code will be used is when only part of a line is selected. However, when an entire line is selected, multiple lines are selected, or nothing is selected at all, a code block is created. Right now, the only way to turn some lines into a code block (other than doing it manually) is by clicking the toolbar button.

4
  • 1
    I'm pretty sure this is status-bydesign. Ctrl+M used to insert an HTML/CSS/Javascript snippet; it inserts the code block in this new editor because those snippets don't exist anymore.
    – Ollie
    Jan 27, 2021 at 18:46
  • @Ollie Yeah, you're right about Ctrl+M. I rarely use code snippets, so I didn't know that before. The only thing is that they said the code snippets are temporarily absent in the alpha test and I'm assuming it'll be re-added when the new editor goes live. I guess they're going to use a different keyboard shortcut for code snippets then. Jan 27, 2021 at 20:06
  • You're right, yeah. So maybe status-planned then.
    – Ollie
    Jan 27, 2021 at 21:18
  • 2
    Thanks for the report! We're likely going to revisit keyboard shortcuts for the different code types when adding in snippets. We tend to prefer not regressing behavior for these sorts of things, but that isn't a hard rule. Marking as "review" for now, until we decide on the final behavior.
    – Ben Kelly StaffMod
    Jan 27, 2021 at 23:02
8

In rich text mode, toggling a code block on and off makes it visually appear to be a code block in the preview, but not after saving:

Editor showing text as a code block after clicking the code button twice, then saving as plain text

1
  • 3
    Oh interesting... I can reproduce, but I have no idea why it would be doing this. This'll be a "fun" bug to squash. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 29, 2021 at 21:58
8

Selecting a word with a double-click does not work for links

As said in my other answer, it’s standard practice to double-click to select a single word. That works! Except when the word being selected is part of a link’s text. See demo below.

Double-clicking a word doesn't select properly

It looks like it only selects the clicked letter and the ones to its right. When the click occurs between two letters, nothing is selected.

Compare that to what happens in MS-Word, for example:

Double-clicking works well in MS-Word

It also works very well on other websites' RT fields, like Reddit, for instance.

8
  • hmm. I wonder if the triple click to select line is something to consider too
    – Journeyman Geek Mod
    Feb 2, 2021 at 7:47
  • @JourneymanGeek A triple-click works in RT mode but not in MD mode regardless of links, and that's what my other answer (linked above) addresses. Is that what you're referring to? Feb 2, 2021 at 7:50
  • The double click also appears to select part of the popup. For me (Firefox Nightly 87.0a1, Linux), if I double-click the left half of a letter, it selects the letter and the rest of the word to the right and everything in the popup; otherwise, if I double-click the right half of a letter, it selects the letter and the rest of the word to the left and everything in the popup; if I double-click the right half of the last letter of the link, the non-link word next to it, to the right, is also selected. Feb 3, 2021 at 5:07
  • If I didn’t enter a valid link, however (e.g. left it as https://), then selection is very broken, and the input in the popup constantly overrides focus and selection. It’s definitely the popup’s fault, as it gets inserted in the middle of the word. Feb 3, 2021 at 5:07
  • @Sebastian If by "the popup" you mean the one where you enter the link, it works well for me (Chrome, Win10). Feb 3, 2021 at 5:11
  • On Chrome for Linux I can reproduce this report more closely: double-clicking the left half of a letter (to be clear: a letter of a word within a link) behaves like on Firefox. Double-clicking the left half of a space between two words of the same link selects the space; double clicking the right half of it selects nothing. Double-clicking the right half of a letter selects nothing; but double-clicking the right half of the last letter selects only the space to the right of it — the popup doesn’t appear. Feb 3, 2021 at 5:20
  • @41686d6564 Yes, that’s the popup: the <span class="w0 ProseMirror-widget">. What do you mean by “it works well for me”? Does it select the whole word? Does it not select the popup? Feb 3, 2021 at 5:23
  • Oh, you mean selecting text in the editor causes the popup to be selected too? Yes, I can repro this. I thought you meant selecting text in the popup's textbox itself. Selecting text in the popup works as expected. Feb 3, 2021 at 5:27
8

Bug report opened on GH

I can’t type additional text after I insert a code block in Rich mode (underneath the code block). Steps to reproduce:

  1. Go to a question where you haven't drafted an answer, and put the editor in Rich mode.
  2. Put in some stuff. Put in a code block with the toolbar shortcut.
  3. Then you can't click underneath the code block unless you put it in Markdown Mode.
3
  • related: meta.stackexchange.com/a/360056/361484
    – Luuklag
    Jan 26, 2021 at 21:52
  • 2
    Thanks for the report! I'm seeing a trend of "can't click after last element", so hopefully we can resolve all these in one swoop. Temporary workaround - You can use shift+enter to exit a code block (since enter assumes you are typing more code).
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:41
  • @BenKelly +1. Saved my stack-editing bacon! ;)
    – Ollie
    Jan 26, 2021 at 22:42
8

Bug report opened on GH

In Markdown mode, type a header text (e.g. # Test), select all text with a keyboard shortcut (Cmd+A or Ctrl+A) and click the Italic button. This will put the asterisks on the previous and next line:

enter image description here

When selecting the same text with your mouse, and clicking the Italic button, you get something different (which is consistent with the old editor):

enter image description here

4
  • 2
    Ah, fun bug. I have an idea why this is, but will have to review further to make sure. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:45
  • Ah I didn't notice this was already reported. I also reported that here. But it seems that you don't need the text to be a header, as long as there is only one line of text in the editor and you select all of the text. cc: @BenKelly Jan 29, 2021 at 21:55
  • I just went ahead and deleted my bug report. Jan 29, 2021 at 22:01
  • @KodosJohnson Your timing was perfect. I was literally adding a comment to your post at the instant it was deleted. I got a nice shock when it locked my additions and gave me a warning lol
    – Ben Kelly StaffMod
    Jan 29, 2021 at 22:51
8

Feature request opened on GH

When typing 1. test in Rich Text mode, the editor automatically recognizes it as a bulleted list. Great! When typing 1) test, it doesn't:

enter image description here

but when toggling between Markdown and Rich Text mode, it is recognized:

enter image description here

1
  • 2
    Good catch! Looks like our input rules only operate on the . ordered list marker and not ). I'll see what we can do to extend it to allow for both. It looks like these are the only two markers allowed in the commonmark spec, so we likely won't add any more past what you've suggested. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 27, 2021 at 22:57
8

Feature request opened on GH

On the phone it'd be nice not to have to horizontally scroll to be able to access all the edit buttons.

enter image description here

2
  • 4
    Other than collapsing them into one or more dropdowns, we don't have much choice. I'll pass this feedback on to the designer on this project and see if we can't come up with some alternate solutions. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 27, 2021 at 23:17
  • 2
    @BenKelly if there is enough vertical space, maybe have two or more rows? Feb 2, 2021 at 18:30
8

Bug report opened on GH

In Rich Text mode, if you start the post with a code block, you can't get rid of it. The button looks to be a toggle but clicking it again doesn't help; you can't remove it by pressing the Delete key (on macOS; I guess it's the same for the Backspace key on Windows). The only way is to switch to Markdown mode. If you use the code block somewhere in the middle of the post, it is possible to delete it in Rich Text mode.

4
  • Very similar to my answer.
    – Ollie
    Jan 26, 2021 at 20:39
  • Yeah, I just noticed that. It's also similar to meta.stackexchange.com/a/360043/295232
    – Glorfindel Mod
    Jan 26, 2021 at 20:40
  • 1
    A workaround for this is to press Ctrl-backspace to get rid of it, I just found.
    – Ollie
    Jan 26, 2021 at 22:43
  • 3
    Thanks for the report! We're seeing a few instances where blocks like these mess with cursor position. This class of bugs is firmly on our radar.
    – Ben Kelly StaffMod
    Jan 27, 2021 at 23:22
8

Bug report opened on GH

When in Rich editor mode having an image at the end of your post makes the behaviour unpredictable.

If you press the down arrow to get to the end of your input field your cursor disappears. The only way to regain it is pressing the enter key until it pops back up.

2
  • 3
    I'm able to reproduce this. I'm seeing a trend of errors regarding end of document content, so hopefully we can squash them in one fell swoop. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:49
  • @BenKelly I see some status has been put on this at git. Any olans on updating the answers in this post accordingly?
    – Luuklag
    Mar 25 at 17:37
8

Feature request opened on GH

Blockquotes are rendered automatically in rich-text mode, but spoilers aren't.

spoiler not rendered automatically in rich-text mode

1
  • 4
    Thanks for the report! This is simply because we haven't registered a input rule for them yet. It should be a pretty quick feature to add though
    – Ben Kelly StaffMod
    Feb 8, 2021 at 19:36
8

Bug report opened on GH

When copy-pasting a post when Markdown is switched off, it’ll add plenty of new lines and some components such as tags are not copied properly. (tested on Chrome+Windows)

E.g., before copy (https://meta.stackexchange.com/a/360077/178179):

after copy:

3
  • That might be hard to do as you are copying the rendered output which doesn't carry information about markdown code. It would be the same as trying to copy from the preview in the existing editor. A simple workaround would just be to turn on markdown mode before copying. Jan 27, 2021 at 17:42
  • 4
    Thanks for the report! Some info about copy/paste that you didn't ask for, but I'll explain anyways: When copying into the clipboard we actually get the html representation of the content. On paste, we try to take that html representation, figure out what it maps to on our end and then add the correct nodes to the document structure. This is why copying from e.g. Google Docs tends to carry over the formatting on paste. As you can see with the pasted tag, we don't have this perfect quite yet, but we're working on it ;)
    – Ben Kelly StaffMod
    Jan 29, 2021 at 22:15
  • @BenKelly thanks for the information! Getting some info on points we didn't raise is typically a great way to learn. Jan 29, 2021 at 22:23
8

Bug report opened on GH

Inserting a bulleted list trims digits if they are at the start of the list entry

If you want to make a bulleted list from text like this:

3 users need to foo the bar
then the bar becomes foo
4 bars have been foo'd

and you select the text, and press on the bulleted list button it turns into this:

  • users need to foo the bar
  • then the bar becomes foo
  • bars have been foo'd

Removing part of the text you wanted to turn into a list.

If you manually add the - in front of the text you end up with this:

  • 3 users need to foo the bar
  • then the bar becomes foo
  • 4 bars have been foo'd
3
  • 3
    Nice find! This is due to the bullet list command being too "smart" (and it backfiring). The idea was that if you're already using an ordered list, the bullet list will replace it. In reality, it should really only do this if you have the ordered list markers on each line AND the marker is correct (e.g. 1. or 1)). There's some undefined behavior for what to do with nested lists, but I'm not so sure we're going to get that smart in handling the edge cases in markdown mode. Thanks for the report!
    – Ben Kelly StaffMod
    Apr 21, 2021 at 15:13
  • 2
    Good you identified the cause @BenKelly. Good luck fixing it ;)
    – Luuklag
    Apr 21, 2021 at 17:37
  • @BenKelly possibly related: meta.stackexchange.com/a/363589/361484
    – Luuklag
    May 4, 2021 at 19:22
8

Pasting a text with a link in a table results in the text getting cut:

Screen recording demonstrating how pasting text outside a table works fine, but pasting it in a table cell results in the link and the text after the link not being included

Markdown used in the demo:

| Column A | Column B |
| --- | --- |
|  | A margin call occurs when the value of an investor's  |
| [Federal call](https://www.investopedia.com/terms/f/federal-call.asp) | A federal call is a legally mandated margin call pursuant to Regulation T. Investors will receive a federal call when their margin account lacks sufficient equity to meet the initial margin requirement for new, or initial, purchases. |

A margin call occurs when the value of an investor's [margin account](https://www.investopedia.com/terms/m/marginaccount.asp) falls below the broker's required amount

fghj

Tested with Windows 7 SP1 x64 Ultimate and Google Chrome 88.0.4324.190 (Official Build) (64-bit).

1
  • 3
    For me, it pastes the whole text but without the link. Surprisingly, when copying text with a link from the table and pasting it outside, the hyperlink is also lost in this case. Demo. Mar 3, 2021 at 5:43
8

Image in the table causes some periodic movement (Windows 7 SP1 x64 Ultimate + Google Chrome Version 88.0.4324.146 (Official Build) (64-bit)):

Screen recording showing the size of the table fluctuating periodically

Markdown code:

| header 1 | header 2 | header 3 |
| --- | --- | --- |
| cell 1 | cell 2sd   sdf |  |
| sdfcell 3 | klkl<Bjjj![](https://i.stack.imgur.com/MIT9D.png) |  |
| cell 4sdf | cell 5 | cell 6 |
| cell 7 | cell 8 | cell 9 |

jk,
jk,

jk,jk,
2
  • 4
    Oh, who doesn't like perodically moving tables? ;) Good catch!
    – FZs
    Feb 7, 2021 at 9:08
  • 4
    Oh, fun... Thanks for the report! We'll look into it.
    – Ben Kelly StaffMod
    Feb 8, 2021 at 19:40
8

\* causes text to be italicized in the markdown editor, whereas it shouldn't.

Example:

enter image description here

Pasted markdown:

There exist 2 active lists:

1. https://\*.stackexchange.com/?tab=active
2. https://\*.stackexchange.com//questions?tab=Active

https://\*.stackexchange.com/?tab=active has a limit, as [Tim Stone](https://meta.stackexchange.com/users/150235/tim-stone) mentions in their [answer](https://meta.stackexchange.com/a/117120/178179).

Tested on Windows 7 SP1 x64 Ultimate with Chrome 91.0.4472.12.

8

Bug report opened on GH

Pressing Ctrl+H does not toggle Heading in Rich Text mode

  • In the old editor, it would cycle between several Headings.
  • In the Markdown mode of the new editor, it toggles between Heading1 and no heading.
  • However, in the Rich Text editor, it only works one way. Pressing Ctrl+H for a second time opens the browser's history tab in Chrome.
5
  • 1
    Nice find! We have concrete plans to extend the headings implementation, so I'll see if we can't work this in to the roadmap since it's a regression from the behavior of the old editor. Thanks for the report!
    – Ben Kelly StaffMod
    Jan 27, 2021 at 22:59
  • 5
    FWIW, @Ben - H1 should really never be used in questions (the title becomes the H1) or answers here. There may be other contexts where that heading is appropriate, but it'd be nice if the editor guided folks toward H2 & H3 exclusively.
    – Shog9
    Jan 28, 2021 at 6:15
  • @ben as context: meta.stackexchange.com/a/214449/175002 Feb 3, 2021 at 11:55
  • Hello! I created a PR that should fix this issue (preview). Does it look good? Apr 11 at 12:32
  • The ctrl-h toggle is fixed. The "show the same header options" is being tracked in GH #165 and this post. Marking this as completed.
    – Yaakov Ellis StaffMod
    Jul 13 at 12:25
7

When making the screen of my browser smaller, some other buttons (undo/redo) become visible and the Markdown label for the toggle switch becomes a logo:

enter image description here

The same happens on Safari on my iPhone (though I have to scroll the toolbar sidewards for the other buttons to become visible).

4
  • 3
    This seems like odd behavior to me too. I understand logic of why it was done this way. They are hidden by default (intentionally) and only appear at smaller screen widths because it assumes you are on mobile at the small of a width, and thus would not have access to Mod-Z and Mod-Y keyboard shortcuts. That assumes everyone likes using those and if there's space available, and removes the options for people who might be browsing the site in desktop mode on their phone. Curious if there was some other reason why it was designed this way.
    – animuson StaffMod
    Jan 26, 2021 at 20:13
  • 2
    This is the desired functionality. In the spirit of responsive design, we reduce the "Markdown" text to an image to provide more horizontal room for the rest of the toolbar and show the undo/redo buttons since the majority of the cases where the screen is this small are mobile/touchscreen devices. As you note, on very small screens there is a potential for the toolbar still being too big and needing some scrolling.
    – Ben Kelly StaffMod
    Jan 26, 2021 at 22:21
  • 2
    I don't think adding new buttons is in keeping with "the spirit of responsive design".
    – Cody Gray
    Jan 29, 2021 at 0:45
  • 1
    @BenKelly What about people on tablets, which have big screens, but no keyboard? Feb 2, 2021 at 17:45
7

On Google Chrome on Android, one can't access the table menu to alter the table structure (add/del rows/cold).

Demo:

enter image description here

Tested on Android 10 with chrome 89.

4
  • 1
    I can't reproduce this issue on Chrome 89 on Android. Can you provide reproduction steps? My repro steps are: 1) Rich text mode 2) Create table by tapping button 3) Tap table cell 4) Tap table button (can see menu) 5) Tap remove column or similar
    – Ben Kelly StaffMod
    Mar 16, 2021 at 15:23
  • @BenKelly Demo: i.stack.imgur.com/ENIEY.gif using the same steps as yours Mar 16, 2021 at 18:23
  • 3
    Oh! You're in markdown mode. We only support the column/row commands in rich text mode currently. The reason being that it is so much simpler to manipulate nodes than it is plain text.
    – Ben Kelly StaffMod
    Mar 16, 2021 at 19:38
  • @BenKelly got it, good catch! Mar 16, 2021 at 19:39
7

My entire answer was deleted when I went to edit the question

I have not used this editor much (maybe 2-3 answers), but I discovered a fatal flaw: when in markdown mode, my answer is wiped out a few seconds after I click edit on the question (which happens inline due to me having 2k+ rep). When the answer is in WYSIWYG mode, it simply wipes out what I have in code fences.

So far, this has only happened to me when I was answering a question. In this case, I was able to recover by refreshing the page to access the autosave. I posted my answer there, and the same thing happens to me when I am editing the answer then click to edit the question. It's not caused by an extension and there are no console errors.

7

Formatting Toggle Bugs

I know there's a lot to take in here, but I wanted to get the formatting bugs that I've run across documented. I searched for duplicates in this thread, but didn't find any; feel free to point them out and I'll remove them from the list/ add a reference to an already addressed duplicate.

I noticed that some keyboard shortcuts don't "toggle" off properly in one editor mode or the other in certain circumstances.

The post states...

We're planning to add keyboard shortcuts to the formatting buttons but they aren't part of this initial alpha test.

...so let me know if any of these aren't really bugs, and are more part of features that just aren't turned on yet or something.

For all of these, I'm experiencing them on Chrome 91.0.4472.77 on Windows 10. If a repro gif would be helpful for any of these which don't already have one, comment and I'll add it.

Lists

  • In rich text mode, hitting Ctrl+O or Ctrl+U with non-list text highlighted will format the highlighted text as an (un)ordered list, but doing the same with text that's already formatted as a list doesn't map to the shortcut. Ctrl+U does nothing at all, and Ctrl+O triggers the browser "Open" function.

Blockquotes

  • In rich text mode, Ctrl+Q moves highlighted text into a quote block, but successive presses simply increase the quote level, rather than removing the quote block (like the button does).

  • In Markdown mode, when highlighting all text in an answer box which happens to include one or more line breaks with Ctrl+A (specifically), all line breaks will be removed, and the last couple characters of each line will be duplicated and garbled... I can't figure out a pattern here, but it's odd (Not using Ctrl+A works as intended):

    Animated gif of block quote shortcut garbling text in markdown mode

  • In Markdown mode, adding a list to a blockquote via the ribbon button or shortcut will remove the list syntax, and clicking/ pressing it again will not restore it:

    Animated gif of block quote removing list syntax in markdown mode

Code Formatting

  • In Markdown mode, highlighting all text with Ctrl+A and then clicking the code block ribbon button doesn't keep all content highlighted, leading to strange behavior on subsequent button clicks. The code block syntax is not toggled away, and instead adds newlines and further borked code fences indefinitely (Not using Ctrl+A works as intended):

    Animated gif showing the code fences fail to toggle away properly when all text is highlighted with Ctrl+A

    • The same behavior as above also occurs under the same circumstances for inline code formatting, via ribbon button or Ctrl+K presses
  • In rich text mode, toggling off a code block doesn't render properly. The code block visually sticks around, but the detected language switches to plaintext: Animated gif showing code formatting not disappearing in rich text mode when you toggle it with the ribbon button

7

When adding a picture, you can click it in rich text mode, and a popup will appear (you may need to scroll due to this bug) where you can enter the image source, the image description and a title text. Similar to this related bug, the popup is displayed inside a <div draggable>, together with the picture. Since a mouse down or mouse up will be interpreted as a drag start or drag end, respectively, and moving the mouse while holding it down is interpreted as a drag action, it is difficult to select text within the popup or to place the cursor at a specific point.

  • On Firefox, the drag always starts, no matter what you do. You can only focus a specific text box with your mouse, but beyond that you have to use your keyboard.
  • On Chrome, you can actually use text boxes normally, but click-and-drag to select text is only possible if you’re clicking in the boundary of the text itself; clicking the padding of the text box still triggers the drag action. Double-clicks and triple-clicks work fine.

Example below. You can click the edit link, enable rich text mode, click the image, and try to adjust (or even read) the text in the image description and the title text (and the image source) using your mouse.

Some very long description. Try to select some text here with your mouse

Example picture is 1000 years Old Thanjavur Brihadeeshwara Temple View at Sunrise from Wikimedia Commons; public domain.


This has now also been reported here: Unable to position my cursor by mouse inside the image textboxes in the Answer section in the Firefox browser.

3
  • If I start drawing my mouse on the text, it works form me as expected, but it's still a bit annoying that even if it's one pixel off of the text (not the textbox), it starts dragging.
    – FZs
    Feb 10, 2021 at 14:50
  • 1
    @FZs Ah, there’s a difference between Firefox and Chrome! On Firefox, it doesn’t work at all. Feb 10, 2021 at 15:20
  • Oh, yes, I used Chrome.
    – FZs
    Feb 10, 2021 at 15:25
7

feature request opened on GH

Use a more appropriate resize anchor. The current one suggests it has horizontal resizing support, but it only supports vertical resizing:

enter image description here

3
  • 4
    This isn't exclusive to the question dialogue, it's also present on the comment box.
    – Luuklag
    Feb 25 at 21:13
  • 1
    @Luuklag Good spot, although that one bothers me less because it has no obvious place to be resized to. While the answer form has a whole lotta whitespace to the right of it. Feb 25 at 21:17
  • 1
    That's actually the browser default resize handle, so we can't do much to style that icon specifically. This is a topic we've discussed internally in the past, but have yet to take action on. I've opened a feature request item on our GitHub repo.
    – Ben Kelly StaffMod
    Feb 28 at 15:15
7

/

TL;DR: The new editor must refrain from reformatting/ destroying unrecognized markup in Rich Text mode.

At the moment, when you switch the editor from Markdown to Rich Text mode, the editor does its best to parse and display the formatting "live," which works well most of the time. The problem is that it also largely destroys or reformats any markup it doesn't recognize, which is downright disastrous for at least two reasons.

Reason #1: "Previewing" content may break it

One of the top reasons that I refer to the preview, whether in the old or new editor, is because I'm unsure about the syntax of the markup I've written, or when I'm using several formatting elements at once and I want to make sure they're all playing nicely together.

With the old editor, that was as simple as scrolling down the page, and on the new, it's as simple as flipping a switch– except it's not, because by "checking the preview" in the new editor, my markup is likely to have been changed in unanticipated ways. I have zero guarantees that flipping that switch isn't going to destroy a delicately formatted post, and that's a royal pain.

Using the Rich Text mode as a stand-in for the preview pane is fine for me, but if there truly isn't going to be a different substitute, then I need to be 100% certain that switching modes isn't going to wreck my markup. This is especially true given that undo/ redo history is currently lost as soon as the mode is switched!

Reason #2: Unintended post edits

The second major issue with the forced formatting is that if you go to edit a post and the editor opens in Rich Text mode, this will automatically reformat and/ or break post content (no need to toggle modes). There's also no built-in way to revert these changes (you have to refresh the page or cancel the edit altogether).

This makes it really easy to introduce broad, unneeded changes into posts, especially when editing large FAQ-style ones (I did it myself here, view the Markdown side-by-side in Rev. 104).

I know that I'm not the only one that's stumbled into this specific trap based on other reported bugs here, and the fact that the editor does this forced reformatting without warning or notification leads to pretty awful UX in this case. In the best scenario, I recognize something of value has disappeared, and in the worst, I don't notice at all, which can lead to posts with missing and/ or broken content.

2
  • 4
    You're definitely not the only one. There are several related answers that were posted about the many issues with switching between the two modes. It's still a good idea to have an answer that mainly focuses on losing formatting though. +1 May 19, 2021 at 19:17
  • 1
    Can you add one or more examples of the destruction and reformatting? E.g., will List<map> be converted to List? May 21, 2021 at 10:13
6

A lot of elements, such as spoilers, tags, blockquotes etc., rendered immediately in the preview as soon as you finished typing them in the old editor. In this editor, I have to toggle between Markdown and Rich mode in order to get them to render. I get it in Markdown mode, since it’s supposed to show only Markdown, but it would be nice if they rendered immediately in Rich mode.

2
  • 2
    I'm not quite sure I understand the issue being reported. We do support a few input rules where a limited amount of markdown typed in rich-text mode gets converted into a styled block (typing > or # for instance), but otherwise any text typed is just text. What behavior is it that you're seeing and what behavior is that that you are expecting to see?
    – Ben Kelly StaffMod
    Jan 29, 2021 at 21:23
  • 1
    @BenKelly In Rich mode (the old editor's equivalent of a preview, I guess) spoilers, tags and a few others don't render immediately, like they did in the old editor's preview. Is Rich mode too different from that?
    – Ollie
    Jan 29, 2021 at 21:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .