194

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!

Improve this question
48
  • 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
    Commented Jan 26, 2021 at 19:32
  • 5
    This post is getting more answers than upvotes. Popular, you think?
    – Ollie
    Commented Jan 26, 2021 at 20:41
  • 8
    @Ollie sorry, my fault. I can only upvote it once...
    – Glorfindel Mod
    Commented Jan 26, 2021 at 21:13
  • 71
    "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
    Commented 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
    Commented 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
    Commented 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
    Commented 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
    Commented Jan 27, 2021 at 8:35
  • 4
    How about you use the official sandbox post for that @ouflak
    – Luuklag
    Commented Jan 27, 2021 at 13:51
  • 15
    "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.
    – Maciej Stachowski
    Commented 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
    Commented 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
    Commented 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
    Commented 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.
    – Jyrki_Shog9Supporter
    Commented 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
    Commented Feb 10, 2021 at 13:58

114 Answers 114

Reset to default
1
2 3 4
329

Automatic conversion of "straight quotes" to “smart quotes” is catastrophic for code-centric sites.

When in Rich Text mode, the editor auto-converts double-quote characters into “smart quotes”, even for text entered in inline code format, but, fortunately, not in code blocks.

This will cause massive problems on code-centric sites like Stack Overflow, and is likely to cause substantial issues on at least some other sites.

To be clear: at least for code-centric sites, there should be no mode in the editor which automatically converts straight, double-quote characters into “smart quotes”. To have a mode which automatically does that conversion will result in automatic “smart quote” conversion being done to code, which will break the code. Having such a mode will increase the average time and effort necessary for every post in all of original entry, editing, moderation, determining actual issues, etc. Users often enter code as regular text, which they may, or may not, later apply code formatting to, so having automatic “smart quotes” enabled in any mode will cause additional problems. Having such a mode will reduce overall user satisfaction for all code-centric sites, due to the additional issues introduced.

Basically, automatic conversion of straight, double-quote characters into “smart quotes” is a feature about which some people think "ohhh pretty quotes", but which causes fundamental problems for other people (and some people just really, really hate “smart quotes”). Please, please don't inflict “smart quotes” upon us.

Improve this answer
13
  • 129
    This is a catastrophe waiting to happen even on non-code-centric sites. Copying something I wrote on the Mod Team feedback post: Arqade has a very dedicated community surrounding Minecraft, which has both single-line commands and JSON-like syntax for writing scripts or setting properties on objects. Most users writing Minecraft commands and scripts are not programmers, and lack the basic diagnostic awareness/skills to handle when the wrong quotes are used. This will likely cause ongoing strife/headaches for our site
    – Robotnik
    Commented Jan 26, 2021 at 22:44
  • 1
    Looks like this only happens with inline code, but not in code blocks (not to say that it's not a problem).
    – 41686d6564
    Commented Jan 26, 2021 at 23:00
  • 3
    Heh, I noticed that yesterday when I was writing one of the other bug reports; when I finished it, I knew I noticed another bug but couldn't figure out what it was. Thanks for refreshing my memory!
    – Glorfindel Mod
    Commented Jan 27, 2021 at 7:07
  • 6
    @Makyen I hear your concerns and agree that this can indeed become a hairy problem. Code blocks and inline code should not trigger smart quotes at all, but at least on my machine inline code seems to trigger them. Are you on a Mac by any chance? I see a couple of options - we could disable smart quotes for specific sites or drop the feature altogether and let users who want them use their OS settings to type them. I'll check in with the team and see if there are good reasons for smart quotes to stick around. Stay tuned!
    – Ham Vocke StaffMod
    Commented Jan 27, 2021 at 8:29
  • @HamVocke I've tested this on both a Windows 10 based PC and an Android device using both Google Chrome and Firefox. I didn't have to do anything other than just open the editor and start typing to have the quotes be changed to “smart quotes”. I don't recall ever having this issue in anything other than this editor. I don't see any way to not have it happen. Thus, I'm a bit surprised that Ben is having problems reproducing the issue.
    – Makyen
    Commented Jan 27, 2021 at 9:26
  • 2
    @Makyen thanks, that helps! It's definitely Stacks-Editor handling the smart quotes. It's an optional ProseMirror feature that I hooked up to Stacks-Editor early on and never bothered to think too hard about. It's easy to disable but I want to check in with the Team first.
    – Ham Vocke StaffMod
    Commented Jan 27, 2021 at 10:09
  • 82
    @HamVocke From my POV, it needs to be that smart quotes are never used, not just not in code format. We get a lot of code that is saved in a post revision as normal text (i.e. not in code format) and a lot more that is initially entered into the editor as basic text and only later placed in code format (sometimes several post revisions later). Once the editor changes the quotes, it's done and over; an additional problem has been introduced, which can have substantial negative repercussions for the post, and will commonly affect how it's received by others.
    – Makyen
    Commented Jan 27, 2021 at 10:26
  • 117
    We just discussed this with the team. We're dropping the smart-quotes feature (and a few others that are in a similar vein). You can find the pull request here together with some additional explanation. Thanks for getting this onto our radar. This was really something I didn't put much thought into when I introduced it early on but I totally see how this was a bad idea.
    – Ham Vocke StaffMod
    Commented Jan 27, 2021 at 15:19
  • 15
    I'm not even sure why "smart quotes" are a thing or what they are supposed to represent. Better to just not have them at all on the site.
    – TylerH
    Commented Jan 28, 2021 at 22:52
  • 3
    @Braiam No, the code formatting which you tried to change is not emphasis. It's a demonstration of what happens when typing in code format. It's demonstrating the issue which is the entire point of this post. If the reason for that formatting was that I was just trying to emphasize it, then it would be in bold and italics.
    – Makyen
    Commented Jan 29, 2021 at 18:45
  • 25
    @Braiam Because it is a short, concise demonstration of the issue that directly communicates (to everyone, except, apparently, you). Sure, I could make the whole thing longer by using an example of actual code, but I'd still have to explain that example with basically exactly the existing text. I would be doing that only in order to not have non-code in code format, when what I'm explicitly talking about there is text in code format. I agree one should not use code formatting for emphasis, and do edit posts to remove it. Again, if emphasis was the intent, it wouldn't be in code format.
    – Makyen
    Commented Jan 29, 2021 at 21:46
  • The middle ground here would be to do what MS Word does: It auto-converts quotes to smart quotes; but you can hit Ctrl+Z after you type a (single or double) quote to convert it back to a normal quote. If need be, there could be a preference setting with a site-dependent default that enables that behaviour vs disabling smart quotes altogether.
    – RobH
    Commented Feb 5, 2021 at 23:20
  • I would personally argue, from a design perspective, smart quotes should always stay smart. In other words, if you copy and paste a smart quote, it should still grab the underlying straight quotes, and require any software that you paste it in to display them as smart quotes if they so wish.. Granted, I'm not sure HTML would make this easy (without some font shenanigans). But I've always opposed actually converting straight quotes to opening and closing quotes. Smart quotes are always just a cosmetic detail and contain no semantic difference.
    – trlkly
    Commented Feb 9, 2021 at 3:34
294

Preview mode is now available
MathJax is not yet integrated in the new preview mode, but will be included before the Stacks Editor is opened for testing on sites that include preview mode.

Disclaimer:

Let me start off by apologizing for the blunt tone in this post. I very much appreciate the spirit of openness and hard work that underlies the development side, and I want to thank you for both the hard work in improving the UI and for the time and willingness dedicated to soliciting community feedback. I offer this feedback with some blunt edges because it is important -- you're doing great work, but if you don't do that work carefully then there is a clear potential to cause significant harm, and most of the signs I can see indicate that your current trajectory goes towards that harm.

What follows is intended exclusively as constructive criticism, and I hope it reads as such =).

That said:

This change is extremely alarming from a MathJax perspective.

The design philosophy makes a lot of sense for a lot of sites, but several of the proposed changes (specifically, the removal of the live preview) would be a catastrophe for sites where MathJax is a common or essential part of the site experience. As a reminder, this is no less than 42 sites out of the network total of 176, i.e., 24% of the network sites.

(Also, as pointed out in the comments, there are several other essential site-specific post formatting plugins which are in an identical situation to MathJax, the clearest examples of which are chess, go, furigana and music notation.)

Here are the things that worry me the most:

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.

uh... no it isn't.

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?

Yes I would. I already do. This is my main mode of work. In my discipline -- similarly to many of those represented in MathJax-holding SE sites -- the industry standard word processor is LaTeX. Having a separate editor and preview is not only standard, it is the only way to work efficiently.

At the very least, building a WYSIWYG editor for math is a major software undertaking. But, to be blunt, none of the existing solutions, with decades of trajectory, make the bar as a professional standard. (For clarity: it would be absolute nonsense to attempt it here.) Editing math absolutely requires a code-and-preview configuration. As such, if your design philosophy is that "having a preview at all is something we can move beyond", then your design philosophy is blind and deaf to the requirements of the technical sites.

I am of course sympathetic to this concern:

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.

and indeed it can be annoying (though, as has been pointed out, not universally). But that viewpoint is missing another vital aspect of how MathJax works on Stack Exchange, and that is the amazing and extreme convenience of having an instant preview rendered alongside the plain-text Markdown/MathJax source. In fact, the current editor is more convenient than the standard LaTeX editors, due to the speed and constancy of the preview refresh -- it refreshes as soon as anything changes, and it is only limited by the (very fast) speed of the rendering.

In the proposed changes (Markdown source and rich-text preview on the same pane, with a button to switch between them), writing and editing mathematics will become noticeably and significantly harder. To put it bluntly, getting rid of the simultaneous preview kinda shafts the mathy technical sites, bigtime.

Now, I appreciate the points made regarding the age of the code and the difficulty of maintaining it and of using it as a base for further upgrades. It makes complete sense that there is a need to have a better codebase for the editor, and that it should, at the end of deployment, be used across the board throughout the SE network.

... which is why it is essential that the concerns surrounding MathJax form part of the initial design stage. This:

Sites with MathJax are among the last we'd ship this on

is not good enough. The concerns surrounding MathJax are part of the core design decisions that need to be made. If the plan is to wait until the end, once everything has been hammered out and all of those design decisions are set in stone, and hope fingers-crossed that those decisions will work for the 40+ sites that use MathJax, then the plan reads "we don't care if the mathy technical sites end up getting shafted" to me.

If the goal is to have a single codebase work for rich-text-oriented sites and Teams as well as for MathJax-oriented technical sites, then that jointness needs to be recognized from the get-go: the design decisions regarding the preview need to be made now, and a mathy site (math.se, physics.se, stats.se, etc. - your choice) needs to be among the first sites to test it out.

One more thing:

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.

That's great! But you also need to turn it off inside MathJax delimiters. Some of those problems have already been pointed out, but I'll say it explicitly here: messing with the formatting like in this screenshot is extremely distracting, utterly useless (in the sense that it is not achieving any of its goals, as it's responding to syntax that's going to produce other output than what the highlighter thinks will happen) and it has no place in a math editor in the 2010s, let alone the 2020s.

Improve this answer
61
  • 50
    Admittedly your disclaimer had my finger hover over the downvote button in anticipation. But you’re obviously 100% correct, and this is kind of a deal-breaker.
    – Konrad Rudolph
    Commented Jan 27, 2021 at 17:56
  • 40
    It's not just MathJax, but all post formatting, see: "What site-specific post formatting settings are available?" - without a live preview composing on most of those sites will be very difficult; it's also a problem that enabling the alpha-test editor on Meta Stack Exchange breaks the other versions of the editors on other sites (already reported).
    – Rob
    Commented Jan 27, 2021 at 18:08
  • 51
    But this answer is exactly why we have this discussion here - We need to be able to see what we're missing, where our focus needs to turn to ensure parity in experience around the network. This editor, as I say, is months away from ever being shipped even to a single site, let alone made the default - and that assumes that we're able to get it in a good enough shape to meet the needs of the users. Understanding how much effort will need to be put into making it a great experience is why we're asking for your help. :)
    – Catija
    Commented Jan 27, 2021 at 19:41
  • 33
    While it's typical to start work on a "minimum viable product" and expand the feature set, this answer shows why any rewrite has to have an architecture that's designed from the beginning to handle the most difficult cases. One of the biggest problems with the bit-by-bit agile approach is that it too often eschews that kind of design.
    – Caleb
    Commented Jan 28, 2021 at 19:41
  • 58
    I couldn't agree more with this answer. Latex or MathJax is essentially unworkable in a WYSIWYG setting. Many have tried and failed. For example, Overleaf has a rich text option, but it's not usable. If MathOverflow were to switch over to rich text with no option to revert to markdown, there would be riots. I, and I've no doubt many others, would strongly consider exercising our contractual option to leave the Stack Exchange network. I suspect users at Math Stack Exchange would be similarly upset, and in all likelihood the same could be said about various other technical sites.
    – Tim Campion
    Commented Jan 29, 2021 at 18:15
  • 24
    It should be a no-brainer, if rich text editing is added, to allow the option to switch back to markdown. For instance, that's what wikipedia has. If you think you can design a workable rich text mathjax editor as an afterthought, when so many others have tried and failed with this as their main goal, then you are afflicted with profound hubris.
    – Tim Campion
    Commented Jan 29, 2021 at 18:21
  • 35
    I would add, after reading the comments a bit more, than a solution like the MS Equation Editor -- which I'm sure was a huge undertaking to create and is an impressive piece of software -- would still be completely inadequate for use on MathOverflow at any rate. To ask a mathematician to use something like that is like asking them to type with their thumbs. I'm sorry if MO is an edge case, but all we'd need is the option to revert to markdown -- whether it's at the site level, or at the individual question /answer level.
    – Tim Campion
    Commented Jan 29, 2021 at 18:32
  • 23
    To clarify my last comment -- the MS Equation Editor would be strictly worse than being forced into typing mathjax in rich text on two counts. First, it's less expressive: the range of what you can write the the equation editor is a small subset of what you can write in latex or mathjax. Second, even for the things you can write, it is in every case more cumbersome to to write in the equation editor that it is in mathjax. The only benefit of the equation editor is its decreased learning curve for use, which is a non-factor when the community standard is already Latex / MathJax.
    – Tim Campion
    Commented Jan 29, 2021 at 18:59
  • 38
    One last comment (hopefully): You would never ask a developer to write their code in Microsoft Word. If it's not clear that there are a dozen good reasons for that, just ask any developer in the world. Asking a mathematician (or, I believe, a person in any of several other technical fields) to write in rich text is laughable for exactly the same reasons.
    – Tim Campion
    Commented Jan 29, 2021 at 19:03
  • 20
    @DavidMulder In my (limited) experience those fields that can get away with using MS word to write mathematics, do not have really complex math formulas to begin with. For truly complex mathematical formulas (of the kind I routinely use every third lines in my papers for example), writing them in Word would be a nightmare hard to express. Note that I consider even Mathjax lacking (compared to a fully fledged LaTeX), especially in writing commutative diagrams, reverting to something like the equation editor would make writing answers essentially impossible for me.
    – Denis Nardin
    Commented Jan 31, 2021 at 9:13
  • 37
    @HamVocke Apologies -- from your comment, you seem to have missed the point here, and you're certainly not addressing the concerns. Nobody thinks that you will suspend MathJax as a plugin, but that is not what this is about. For the MathJax (+chess,go,music,furigana) composing to actually work, it needs a live preview. If your initial designs don't allow for one, then you're painting yourselves into a corner. It's not about "implementing site-specific plugins later", it's about creating a design framework that won't collapse under the weight of those plugins when you do enable them.
    – E.P.
    Commented Feb 1, 2021 at 11:01
  • 22
    @HamVocke I too am confident you can build something that will fit into most users' workflow -- you have built one already. But it's hard to take the assertion that you're really flexible at face value, when the one thing that you don't seem to have allowed on the table is the one thing which is guaranteed not to break workflows (i.e. the thing we're asking for).
    – E.P.
    Commented Feb 1, 2021 at 11:30
  • 22
    In addition, any suggestion that E.P. has engaged in any form of fearmongering would be completely unfair. E.P. has been meticulous in attention to detail and has bent over backwards to avoid doing any such thing, while at the same time being clear and blunt about the severity of these issues.
    – Tim Campion
    Commented Feb 1, 2021 at 17:28
  • 47
    @HamVocke: I don’t mean to start a fight, but those aren’t “bold ideas.” They’re very old ideas that have been tried many times and always been eventually discarded in professional settings to return to the simple clean idea of having a separate preview.
    – Noah Snyder
    Commented Feb 1, 2021 at 19:41
  • 20
    @HamVocke That makes MathJax usable in rich-text mode, which is superior to it not being so. It still isn’t a rerendered-as-you-type preview, and it does nothing for the Markdown editor, which is by a vast margin the preferred way of working for almost everyone doing MathJax in the first place. If your proposal is “hey, this is another neat thing we could do,” sure, have at. If your proposal is “hey, if we did this, we wouldn’t need the separate preview, right?” then no, absolutely not. There does not exist any acceptable alternative to the separate preview. You must accept this.
    – KRyan
    Commented Feb 2, 2021 at 15:44
124

Allow viewing the Markdown at the same time as the rich text

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.

As someone who's edited posts here quite frequently, I definitely understand the sentiment here. A large portion of my time in editing those was in scrolling back and forth between the preview underneath the post editor and the editor itself.

However, the new editor removes the ability to view the rendered output of text at the same time as viewing its raw Markdown. As someone who frequently makes use of advanced Markdown techniques and subtle nuances (and the occasional HTML) while typing posts, having to constantly flip a switch back and forth every time I want to see how my post looks like is an extreme burden compared to simply scrolling.

This is also quite important because in the current preview, since the rendered output took as much space on the overall page as it would use when posted (slightly less due to the lack of a left margin for voting buttons), this would allow me to get a rough estimate of how long my post is, so I can tune it back (e.g. remove unnecessary details) if it was too long. The new preview makes it much more difficult to estimate how long a post will be on the actual page when posted, which is, again, something I make use of frequently enough to put up with having to scroll.

Again, I definitely completely understand the sentiment behind the way the new editor is designed currently. Having to scroll can be quite difficult for many people, especially for larger posts (e.g. FAQs here). However, I'm one who frequently makes use of more advanced things enabled by the current setup that the new setup would make it more difficult for me.

Can there please be an option to view a live rendered preview of a post at the same time as when typing raw Markdown into the editor? This need not be below the post as it currently is, but please consider this.

I should probably note that as a member of a Team, I've had access to this editor for quite a while. I've made repeated attempts to get used to this new workflow, but I'm still unsatisfied.

Also, those looking into this answer may also want to look at two additional answers written by Tinkeringbell, which expand upon the argument in this post.

Improve this answer
35
  • 44
    Having an option to have it side by side could be useful on wider desktop screens.
    – user1937198
    Commented Jan 26, 2021 at 22:44
  • 27
    Being unable to see the rendered output while typing Markdown would be utterly unacceptable. Absolutely must be fixed.
    – KRyan
    Commented Jan 26, 2021 at 23:17
  • 16
    @Catija In the case of posts that aren't longer than one screen, I actually can see what I type in both raw Markdown and a rendered preview: the page is scrolled so that the bottom 2-3 lines of the editor box are visible, so they're both visible at the same time. The same also applies when I'm editing the top sections of posts that are longer than one screen. When editing the bottom sections of longer posts, however, you're right, I can't see both at the same time, but that's only some of the time, not all of it. (continuing)
    – Sonic the Anonymous Hedgehog
    Commented Jan 27, 2021 at 1:41
  • 16
    @Catija For a lot of posts - the default edit box size gives plenty of preview. Also - what about placing the render alongside, rather than under, the edit box?
    – Robotnik
    Commented Jan 27, 2021 at 2:44
  • 11
    What you mean huge screen ? I work on 24'' and this is for me standard.
    – Michał Lipok
    Commented Jan 27, 2021 at 3:19
  • 11
    @Catija - the image I provided was from a 1920x1080 screen (image resolution is 1920x1048 because I cropped the taskbar) - is 1080p considered a 'huge screen'? Plus, the content section being too skinny was something specifically called out by the community when the responsive design changes were announced. I don't see why Left/Right sides can't be moved out to give the Q&A more space. Another post by Monica (pre-incident) asks why the right-hand column is even needed - there's enough space in the left column to fit most of the RHS stuff.
    – Robotnik
    Commented Jan 27, 2021 at 5:23
  • 8
    @Catija Is there a keyboard shortcut to switch between Markdown and non-Markdown preview? Without any shortcut, it's barely usable for now. I think this is asbolutely needed, even during an alpha test. Good luck to the team! And congrats SE for always innovating :)
    – Basj
    Commented Jan 27, 2021 at 8:39
  • 4
    @Catija A useful feature but not a replacement for the fundamental ability to see the result as I am typing. I routinely type—with Markdown syntax—while watching the preview rather than the actual text field. I do not want WYSIWYG, I like controlling my Markdown and moreover it simply isn’t how I work, I write * not Ctrl+I and retraining my fingers is approximately 0% within my interests. I don’t write documents in word processors, I write code. What is shown here is akin to what is found in Github—which I find miserable near to the point of unusability. This is a massive regression.
    – KRyan
    Commented Jan 27, 2021 at 14:43
  • 6
    I'm with @Robotnik here: sizing concerns would be irrelevant if the content area was fully-responsive (both large and small), but because there are constraints the editor can provide a misleading view of what will be visible / what will be cut off. Stuff like max height for code blocks makes that even more of an issue. Not everyone cares about presentation, but the system should accommodate those who do!
    – Shog9
    Commented Jan 27, 2021 at 17:05
  • 7
    @Toastrackenigma No, the ideal one is probably size-by-side maintaining both scroll and caret position, but that has already been nixed since SE is adamant about their poor design decisions revolving around widths despite fairly massive community opposition. Which just puts this feature request as another example of the core functionality of the site being sacrificed on the altar of pushing new products.
    – KRyan
    Commented Jan 27, 2021 at 17:10
  • 13
    One thing that isn't mentioned in this post: I use the current, live preview a lot when writing posts. When writing regular sized posts on a regular sized screen, I keep my eyes on the live preview instead of the editor >90% of the time, probably only taking them off if I have to add an image (as just pasting those in doesn't work and requires a click to confirm). Toggling to get this preview is nowhere near as fluent or useful, and the argument that you can 'edit right in the preview' makes no sense to me as you can't actually write MD in the RT editor.
    – Tinkeringbell Mod
    Commented Jan 27, 2021 at 17:11
  • 7
    @KRyan I've written hundreds of short posts across the network. I'm 100% willing to accept that my usage is atypical but I think it's fairer to say that everyone uses the platform differently and have different experiences. For example, some may only look at the rendering while drafting and others never look at it except when actually previewing. The reality is that everyone is different and all experiences are valid. We need to understand them all so we can find a solution that works for people.
    – Catija
    Commented Jan 27, 2021 at 17:38
  • 24
    @Catija The tone of your every comment on this request has been very much “Who needs this? No one needs this. This is dumb and pointless and we shouldn’t waste our time.” So while I agree entirely with your position that we all use the platform differently, and have different needs, and there is an importance to finding a solution for everyone, you are the one who has been dismissing the needs of people with different use cases and advocating against there being any solution for us.
    – KRyan
    Commented Jan 27, 2021 at 17:59
  • 6
    @Catija All right, that is not the impression I had gotten—side-by-side is one thing, but your apparent dismissiveness and negativity began before that was ever suggested. My suggestion, then, is that a “show/hide preview” toggle under the Markdown editor, similar to what we currently have for editing posts, be provided (and remember its state). That would result in no loss of functionality for those who prefer what we have (and we would reap other significant benefits, such as the in-line formatting in our Markdown, which I love, just not enough to give up the preview willingly).
    – KRyan
    Commented Jan 27, 2021 at 18:08
  • 20
    This is absolutely a deal-breaker for me. I rely so much on being able see the produced output that I regularly resize the current editor text box to maximise the preview area so I can have full control over what the final rendering of my hand-crafted Markdown looks like. I just can’t get that same immediate feedback and control from the new editor.
    – Martijn Pieters
    Commented Jan 27, 2021 at 23:49
76

Feature request opened on GH

I’m not sure all users will understand how the ‘Link selection’ button works. (Hint: you have to select the text first, then the button will become enabled.) Other rich text editors I use regularly have an 'Insert Link' button where you can specify both the link and the text to display.

enter image description here

So something like this (excuse the bad mockup, hopefully the idea is clear):

enter image description here

Or enable the button at all times, and if nothing is selected, ask the user for a link (like the current editor) and insert it, with the popover visible so that users know they can edit both the link text and the link itself:

enter image description here

Improve this answer
4
  • 7
    ...as does the current editor
    – Sonic the Anonymous Hedgehog
    Commented Jan 26, 2021 at 20:43
  • 4
    @SonictheCuriouserHedgehog now is the best time to ask for enhancements I'd assume ;)
    – Luuklag
    Commented Jan 26, 2021 at 20:49
  • 4
    Your second suggestion is what we're currently doing in the "markdown" mode, ~to match the behavior of the old editor~. I'm not opposed to adding this type of functionality to the rich-text mode as well. Thank you for the suggestion! edit: I was mistaken, the old editor behaves like your first suggestion.
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 21:53
  • This was completed in release beta 1
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:30
73

Preview mode is now available

If we can't have the side-by-side preview due to technical limitations, we're going to need a better alternative than the Rich Text mode for previewing our Markdown. Even just another setting or toggle to put a live preview pane below the MD editor (like the preview works now) would be much better than having to toggle between MD and RT editors.

I use the current, live preview a lot when writing posts. When writing regular-sized posts on a regular-sized screen, I keep my eyes on the live preview instead of the editor >90% of the time, probably only scrolling up and taking my eyes off the preview if I'm pasting in an image and the dialog asks me to confirm, or if I decide to add another sentence to a paragaph. My usual workflow includes scrolling down the site to see the live preview over actually looking at the editor a lot of the time.

The post states that one reason the RT editor could be better than the current arrangement is that

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.

Toggling between two editor modes to get an approximate idea of what your post may look like isn't a live preview of what you're writing. It slows writing down. And saying that "you can edit right in the preview" isn't actually true: If I'm working in the RT editor, using it as both an editor and a preview at the same time, I can't continue writing in Markdown. I have to switch back, losing my "preview". Honestly, this is less than ideal. While it is less scrolling, it's also not live. And the RT editor does a worse job at showing how a post will look like than the current live preview does.

I like the idea of RT for mobile writing. I rarely use MD anyways when on my phone, just because asterisks, hyphens and hashtags aren't a one-click thing when looking at your phone keyboard. But right now, and most of the time, I'm writing my posts on a computer. This means I have my hands a the keyboard, and a screen big enough to actually show me what I'm doing.

This whole post right now easily fits on my screen. And the preview of it is live, and it's something that I treasure. It makes writing this easier, quicker, more interactive, more fluent. Whatever you do, for those people that do write using the Markdown editor, do not take away our live preview. The Rich Text editor isn't a live preview, switching between the two breaks flow, and you can't write Markdown if your editor is in Rich Text mode while seeing it the result as the live preview allows now.

Improve this answer
5
  • 13
    Just as a comment, I do routinely use Markdown in mobile. I’d give rich text a shot in that context, but honestly I doubt that I would prefer it even in that situation.
    – KRyan
    Commented Jan 27, 2021 at 18:47
  • 8
    +1 for "I use Markdown on mobile," because selecting text is a pain. I'd much rather just type an extra character, which my Android keyboard allows me to do with a long press from the normal keyboard.
    – Ryan M
    Commented Jan 28, 2021 at 7:45
  • 1
    @RyanM I don't need to select text on mobile with the new editor :) I can just press the B or I icon and start typing, and whatever I type will show up in italics or bold. It's the one thing I actually like about the Rich Text editor on mobile: No more switching keyboards with long button presses, and no more selecting text.
    – Tinkeringbell Mod
    Commented Jan 28, 2021 at 8:28
  • 6
    It would be really helpful to me if the devs said something about why they’re so opposed to markdown mode having a preview. I assume there’s some reason behind it, but I haven’t seen it explained anywhere (maybe I missed it?). OP just says it’s embarrassingly old-fashioned and lists a bunch of software I don’t use or hate and says they don’t do it. My main experience with this paradigm is Canvas and it’s an awful mess that I hate and can never get to behave the way I want it to.
    – Noah Snyder
    Commented Feb 1, 2021 at 14:01
  • 1
    Believe it or not the existing editor with preview works so nicely in mobile (i use Firefox on android). Almost 80 percent of my contribution on math.se is from mobile (ie from last 5 years or so even before they launched responsive design).
    – Paramanand Singh
    Commented Feb 4, 2021 at 2:21
64

Bug report opened on GH

This markdown:

# one heading

## two heading

### three heading

#### four heading

##### five heading

###### six heading

renders this preview in the rich editor:

It gets posted like such:

Improve this answer
11
  • 13
    Side-note, actual 4th-, 5th-, and 6th-level headings might be nice. Rare that I want them (and there’s an argument to be made that anytime one does, it implies something structurally wrong with the post), but sometimes I feel it would be the right option and it’s unavailable.
    – KRyan
    Commented Jan 26, 2021 at 23:19
  • 8
    Nice catch. There's been some internal discussion recently on whether we want to allow h4-h6 in markdown. Historically, we don't allow these because... well, nobody I asked could remember exactly why. In the meanwhile, it was more work to disallow these in the Editor, so they were left in. I'll resume discussions on allowing h4-h6 everywhere (not just in the new Stacks-Editor) and fix one or the other.
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:20
  • 6
    For what it's worth, I see no need for h4-h6 on Stack Exchange. We're not writing posts long enough, or we shouldn't be.
    – Asteroids With Wings
    Commented Jan 27, 2021 at 22:30
  • 9
    @BenKelly - there's an argument to be made that we shouldn't be using h1 in posts at all, because it's semantically incorrect to place it underneath the other h1 and h2 tags used to render the actual page
    – Robotnik
    Commented Jan 28, 2021 at 23:57
  • 1
    @Robotnik It be a bit confusing to have single # not work, though? Or, out of the expected behavior, anyway. I don't generally use H1, to be fair - you can see in the question here that my headers are all H2 and H3 - but I wonder if it's still reasonable to argue that post headers aren't the same? I'm pretty sure they're not actually formatted the same as page headers. That said, I'm not a web dev so maybe what I'm saying doesn't make sense.
    – Catija
    Commented Jan 30, 2021 at 22:10
  • @Catija, couldnt agree more. I feel that it would be highly confusing to have a "wrong" order in the headers. Although I do understand Robotniks point, that using H1 is rather wrong. I don't feel whe should disable it in any shape or form.
    – Luuklag
    Commented Jan 31, 2021 at 0:06
  • 13
    @Catija One could cause # to create an h2 “under the hood,” so to speak (and cause the h2 within Qs and As to look like the h1 does now), and then ## would produce an h3, and so on and so forth. The reason for this is that having a single h1 on a page is a rather major web-accessibility standard—just last week my development team got slapped pretty hard for missing that one. Legal was very concerned about it getting us sued (that site is legally obligated to maintain a certain level of accessibility).
    – KRyan
    Commented Jan 31, 2021 at 4:07
  • 5
    @AsteroidsWithWings On RPG, we’re pretty often quoting things that have headers in them, which means if we want our own headers above them, we can push into h4 territory (especially if we’re avoiding h1 for accessibility reasons, which we should). Somewhat niche case, and even there it doesn’t come up often, but if it’s literally a matter of removing a special block on them, it seems worthwhile to have them.
    – KRyan
    Commented Jan 31, 2021 at 4:09
  • 2
    @Catija making # output a <h2> (and bumping down ## and ### to <h3> and <h4>) would solve the semantic problem, and you could change the font size/styling to match, so visually there'd be no difference.
    – Robotnik
    Commented Feb 1, 2021 at 0:28
  • 2
    @Robotnik Related discussion under this answer on New post formatting. The problem of changing the Markdown header semantics is that all posts would need to be migrated again, but which semantics should be used? If all ## Headers become <h3>Header</h3>, then this breaks all posts of mine, since I use Markdown headers correctly all the time. Maybe, the migration script can figure out if # Header is used, or not, and based on that, shift everything one level down, or leave it as is. And then I’d need to relearn the Markdown semantics…
    – Sebastian Simon
    Commented Feb 1, 2021 at 3:41
  • 1
    I believe SE now supports h4-h6 headings, so this is status-completed.
    – double-beep
    Commented Apr 11, 2022 at 14:17
59

"Preview is collapsed into the rich text view"

The preview is a necessary part of editing, particularly on some sites, and it is a great convenience to be able to see the entire post and proofread for redundancy.

Enabling the new editor on Meta Stack Exchange breaks the editor on other sites.

Take this question on Physics.SE for example: "How the unitary operator acts on this vector?". Copy pasting the text here shows that without a preview it can be more difficult to read what you have written:

Example of complicated text

Copying that same text into an answer on the Physics.SE site reveals a rendering issue, without the preview this wouldn't be obvious at first; leading to a lot of additional edits.

See this screenshot (editor enabled on Meta Stack Exchange):

Rendering Issue - Enabled

See this screenshot (editor disabled on Meta Stack Exchange):

Rendering Issue - Disabled -

Notice how enabling the Rich Text Editor caused misrendering on a different site where it wasn't enabled.

Improve this answer
0
56

Bug report opened on GH

When using an asterisk for italics, but not terminating it, like *this, the preview shows the rest of the line in italics but the rendered post won't.

enter image description here

Improve this answer
3
  • 21
    We're using highlight.js to power the syntax highlighting for our markdown editor. Currently, the parser is not 100% commonmark compliant. This is something we've been working toward, but have not yet finished. This is currently on our list of things to fix. Thanks for the bug report!
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 21:56
  • @BenKelly in cases like this one (where it's arguably a user mistake), having some highlighting of the error might make sense. Maybe make the starting star red?
    – Paŭlo Ebermann
    Commented Feb 2, 2021 at 17:39
  • 2
    @BenKelly just checking: will cases like this also be covered? Wikipedia links are full of underscores, but of course I always try to format them, and then it works fine.
    – Glorfindel Mod
    Commented Feb 22, 2021 at 18:27
52


Preview mode is now available
for having an "always start in this mode regardless of my last usage" preference

Sonic already wrote about missing the preview function. I do too, but I have some more reasons I miss the preview. Two of them are already known issues:

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

I've used this editor a few times on Teams, and I'm not really looking forward to turning it on here, because it saves the last used option as a default.

My usual workflow goes something like this:

  1. Start writing a post in Markdown.
  2. Look at the preview to see what it looks like.
  3. Repeat 1-2 several times.
  4. One final, careful look at the preview before posting.

While I think I may be able to get used to toggling a switch to see a preview (and not having to scroll), the fact that my last-used option is saved is what makes this new editor so frustrating to use.

Usually, my 'step 1' includes a pretty big chunk of text before I even look at the preview. But my step 4 means that every time I post something, I should either a.) return to Markdown mode first or b.) return the editor to Markdown mode when I start writing the next post. And I don't want to pay attention to that toggle, I just want to start writing. Which means I often run into the part where I write Markdown in the rich text editor, then have to switch and delete all the slashes that are now escaping the Markdown:

enter image description here

enter image description here

enter image description here

Is there anything that could be done, perhaps a profile setting, that means I always will start writing in Markdown mode, that will override the 'last-used' setting and perhaps even override site-specific defaults?

Improve this answer
4
  • 15
    Yes please! This bothers me too. Perhaps we can choose out of 3 options in the profile settings: 1. Use last setting (default) 2. Always use rich editor 3. Always use markdown editor
    – Luuklag
    Commented Jan 27, 2021 at 9:10
  • 20
    @Luuklag Perhaps more precisely: Open editor in 1. Rich editing mode, 2. Markdown mode, 3. Last used mode.. "Always" sounds like it can't be changed from the editor itself.
    – Zev Spitz
    Commented Jan 27, 2021 at 11:30
  • 2
    I constantly run into this on Reddit, and untangling the unholy mess of escaped Markdown formatting is such a pain. I don’t use Teams nearly as much but it has already happened to me there too.
    – Martijn Pieters
    Commented Jan 27, 2021 at 23:58
  • 3
    It seems to me that the source of the problem is that you don't have any preview of the markdown code without switching the editor. Sure this works as a bandaid but it's really nothing but that: A bandaid.
    – Voo
    Commented Jan 28, 2021 at 11:44
44

Feature request opened on GH

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.

It would be nice to have some way to specify the number of rows/columns at the creation of the table (and not after), e.g. from Google Document:

Improve this answer
3
  • 1
    Yeah, like with the image specifications.
    – Ollie
    Commented Jan 26, 2021 at 23:16
  • 7
    I agree, this would be a nice feature to have. I'll see if I can't work it into the roadmap at some point. Thanks for the suggestion!
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:21
  • 1
    Yes please. This would be great.
    – V2Blast
    Commented Mar 13, 2021 at 22:18
41

Bug report opened on GH

I wholeheartedly support the requests to, in some form, allow simultaneous viewing of the Markdown and the preview. If at all possible, I'd rather that be done in some way instead of this. However, if that can't be done...

Toggling between Markdown and rich text to preview the result without editing anything should not be a destructive action

As one of the CMs noted:

I literally do not preview my posts on Teams because I can not take the risk of the RT mucking with my MD

If the user only toggles between Markdown and rich text (for example, to see the preview) without making any changes, then toggling back should remember and restore the exact previous state. It’s understandable that there can’t be a 1:1 correspondence between the two, and that editing something in the rich text view may result in different Markdown upon returning.

However, it should be possible to special-case “not changing anything” and return the user back to the previous state upon return, allowing the rich text editor to serve as a preview of the Markdown.

Improve this answer
7
  • 5
    It is definitely the final intent for toggling back/forth to be a relatively non-destructive action (for the vast majority of cases). However, this is a lot harder than it may seem. We have a lot of these cases laid out in our automated testing suite, with a number of them currently failing. Every time we come across a new edge case, we add a unit test ;). We're working to close the gap, but there's still quite a bit of work left to do so. Thanks for the suggestion!
    – Ben Kelly StaffMod
    Commented Jan 29, 2021 at 21:45
  • 19
    @BenKelly: Then it seems that there's something wrong with the editor architecture. Source markdown text should be the single source of truth. And the rich text editor should be built on top of it, it should not have its own internal model that doesn't map to source text 1:1 (with all its spacing and formatting variations). Switching editor must be non-destructive always, since 1) it's going to be used as preview, 2) editing posts in editor that were written in md and vice versa will introduce source differences and ugly diffs otherwise
    – user
    Commented Jan 30, 2021 at 21:55
  • 3
    In practice, this is why I’ll likely end up just using post as my “preview”, since you can always make edits after posting.
    – Noah Snyder
    Commented Feb 1, 2021 at 19:31
  • @user: I doubt if that kind of architecture can be implemented. Markdown is plaintext so the editing part is simple and implementing preview is tough. For rich text the editing is tough and I guess some form of compilation goes on to convert from the internal rich text representation to markdown. But expecting the compiled markdown to match a natively written markdown will be difficult.
    – Paramanand Singh
    Commented Feb 4, 2021 at 1:39
  • 3
    It seems to be implemented such that switching the editor mode immediately discards the contents in the other editor. A lot of this pain could be avoided if the other editor was simply hidden instead. It only needs to be discarded if an edit is made in the visible editor. If no edits are made, you could re-show the hidden editor and it would be guaranteed to be non-destructive.
    – Stephen Ostermiller
    Commented Feb 10, 2021 at 11:54
  • @StephenOstermiller There already is a hidden textarea that contains the raw Markdown. Even then, the Markdown could simply be stored in a string — no need to use HTML at all.
    – Sebastian Simon
    Commented Feb 10, 2021 at 14:06
  • 1
    This was completed in release Alpha 2
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:16
39

Preview mode is now available
MathJax is not yet integrated with the new preview mode, but this will be done before the Stacks Editor is released on any site that has MathJax

(I apologize for the uneven formatting in this post — it was written in the alpha-testing editor. I’m finding that even when in Markdown mode, the “syntax highlighting” features are too aggressive -- to the point that I am frequently unsure whether I am in Markdown mode or rich text mode. Moreover, the syntax highlighting in Markdown mode appears to be inaccurate. For instance, in Markdown mode, most of the text of this post is currently displaying in bold and italics, contrary to the case in rich text mode or when I publish. For another instance, apparently when I initially wrote three dashes below, at least two of them were written in rich text mode and converted to an em-dash, so that the separating line below initially did not render properly.)

My comments on E.P.'s answer are already overflowing, so let me continue here. I strongly agree with everything in E.P.'s answer. Like E.P., I understand that there is no malicious intent behind these proposed changes and I understand that everybody is here in good faith, but like him I feel that the situation requires me to be blunt. Most of all, I agree with E.P.'s central thesis that

This is extremely alarming from a MathJax perspective.

Moreover, as Rob points out, the issues raised here will likely extend well beyond MathJax, to many other site-specific formatting plugins.

Basically, when thinking about rich text,

The MathJax-centric user is an entirely different use case from a non-MathJax-centric user.

As discussed in E.P.’s answer and in my comments there, it would be a joke to suggest that the MathJax-centric user compose their post in rich text mode. However, as currently envisaged, the MathJax-centric user would still be dependent on rich text mode, using it as a poor man’s MathJax previewer. In other words, in order to incorporate the MathJax-centric use case, the rich text editor would also be moonlighting as a MathJax previewer. This is a terrible idea because

Fundamentally, MathJax is not compatible with a rich text representation.

MathJax is designed to be written in a Markdown-like environment and compiled into a separate final output. So a MathJax previewer is a completely different sort of thing from a rich text editor. Trying to make a rich text editor which is also a MathJax previewer is just asking for trouble -- especially when the MathJax business is an afterthought anyway. As discussed in my comments to E.P.'s answer, many have tried to do this and failed. If you try to do this, I anticipate that you will eventually throw up your hands and stop fully supporting MathJax, and then we're back to the sort of rioting that I talked about in my comments above (which were initially written under the mistaken understanding that there would be no Markdown mode at all, but which would be equally applicable in a scenario like this). To be clear:

If MathJax were not fully supported, it is quite likely that MathOverflow would exercise its contractual option to leave the Stack Exchange network, and sites like Math Stack Exchange would be similarly unhappy.

Solution: For these reasons, the only solution I see is the following:

There needs to be a dedicated preview for Markdown mode which is not dependent on the rich text editor.

This dedicated preview needs to fully support MathJax. Similarly, it needs to support plugins used at other sites like chess, go, furigana and music notation. What MathJax and these plugins have in common is that it would be infeasible to create a rich text representation which fully supports them, especially if this rich text representation is also supposed to be functioning as a preview of the published output.

Here's the kicker: the requirements of the sort of preview needed for this solution are already met and exceeded by the current live preview. So such a preview is 100% feasible, and the only remaining question is whether Stack Exchange is willing to commit to supporting these communities by (re-)implementing the preview.

Here are some further thoughts:

As discussed here, I agree that the live preview which exists in the current, non-rich-text, editor is in some ways an upgrade over many LaTeX editors because of its constant and automatic refresh. I don't need the refresh to be so frequent, or to be automatic, but it's a nice thing.

If there's no live preview in Markdown mode, I would prefer to have some form of preview I can see by hitting a "compile" button like in a standard LaTeX editor, without switching to rich text mode, for several reasons:

  1. In rich text editors I've seen which have MathJax or Latex, the MathJax does not render fully before publishing (for example it may fail to render user-defined macros). There are good reasons for this -- MathJax / LaTeX is not designed with the understanding that there will be a one-to-one correspondence between the characters you're writing and the characters that will be output, so it would be infeasible to create such a correspondence for the purposes of a rich text representation.

  2. For this and other reasons, I don't trust that what I see in the rich text representation adequately reflects what I will see when I publish. This makes it hard to catch errors before publishing.

  3. It's cumbersome to switch frequently between modes, which I would need to do for previewing purposes (I would be writing exclusively in Markdown mode, for reasons discussed in E.P.'s answer and my comments there, and previewing in rich text mode).

  4. One reason it would be cumbersome is that I anticipate there would be a time lag when switching modes.

  5. Another reason it would be cumbersome is that I also anticipate that it would feel like the whole interface was being redone when switching modes, which is a jarring effect when all I want is to preview what I wrote.

  6. The rich text interface would likely be designed with the presumption that the user was composing their post entirely in rich text mode, (and learning how to use the interface from that perspective) but since I would be using rich text mode exclusively for previewing, mine would be a completely different use case from what was intended. I anticipate this would lead to a frustrating experience for MathJax-centric users using rich text mode exclusively for previewing, both in learning and using the interface this way.

  7. In order to toggle between rich text and Markdown content when writing a post of any length, I have to scroll up to access the toggle button. This is cumbersome for my anticipated use case, where I need to frequently toggle between modes, writing in Markdown and previewing in rich text mode. For one thing, I lose my place in what I'm writing, and have to find it again after switching modes. It’s doubly annoying because when I scroll up to toggle, I need to be sure I’m engaging the browser scroll rather than the editor scroll.

Improve this answer
2
  • 7
    Your point 7 is exacerbated by the cursor jumping to the start of the text when you toggle between rich text and markdown.
    – PM 2Ring
    Commented Jan 30, 2021 at 12:16
  • 7
    Still freaking out. personally, the ability of mathjax to render expressions which are neither recognizable as linearly structured text nor in any way anticipated by things like the ms equation editor is not an abstract thing but an essential component of communication with others in my subfield and dozens of neighboring ones, primarily in the form of what are called “commutative diagrams”. For us, mathjax is already a significant downgrade over full latex in this regard but we’ve been able to get by. This was also mentioned by denis nardin in the comments to E.P.’s answer above.
    – Tim Campion
    Commented Feb 1, 2021 at 1:01
32

Bug report opened on GH

  1. Start in Markdown mode
  2. Write any text
  3. Hit the Enter button

I expect the editor to take my cursor to the next line, but it doesn't. I need to hit Enter another time for the cursor to move, but when I restart typing words, they appear on the third line. In other words, the Enter button works, it's just the cursor that's lagging.

Reproducible in Firefox 86, but not in Chrome 88.

Improve this answer
9
  • 2
    Having trouble reproing this - can you indicate your browser?
    – Catija
    Commented Jan 26, 2021 at 19:46
  • @Catija latest Firefox, latest macOS
    – Glorfindel Mod
    Commented Jan 26, 2021 at 19:47
  • @Catija same for me, FF Android.
    – Rob
    Commented Jan 26, 2021 at 19:56
  • 2
    Reproduced, Markdown mode, Firefox 86.0a1, Desktop, Win10.
    – Ryan M
    Commented Jan 26, 2021 at 22:52
  • I looks like this is related to another ENTER bug
    – Michał Lipok
    Commented Jan 27, 2021 at 1:43
  • 1
    Strange... I was able to reproduce in FF, but not Chrome. I'll update the post with details. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:28
  • Also still reproducible in Firefox Nightly 87.0a1, Linux.
    – Sebastian Simon
    Commented Jan 29, 2021 at 2:14
  • 1
    Found the same/similar bug. Pressing enter after a one-letter line (e.g. "a\n") enters what seems like a carriage return without moving the cursor (need to hit backspace twice to get back to where I was) and I seem to get a normal return without moving the cursor only in code blocks (e.g. "```python\n"). Not really tested much else though.
    – Peilonrayz
    Commented Mar 13, 2021 at 18:27
  • 1
    This was completed in release Alpha 2
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:21
31

Bug report opened on GH

Quoting a multi-paragraph text messes up the paragraph segmentation.

E.g.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au

Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.

becomes

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au> u> Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.t.

enter image description here

Improve this answer
3
  • 12
    I'm able to reproduce this issue, but only when using ctrl+a to highlight, rather than highlighting via mouse. I'm noticing a trend of these sorts of bugs and I have a theory on why they're happening. Hopefully they can all be fixed in one fell swoop. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:25
  • @BenKelly thanks, interesting yes I was indeed using ctrl+a
    – Franck Dernoncourt
    Commented Jan 27, 2021 at 23:27
  • Similarly: select two paragraphs with CTRL+A and add multiline code or a numbered/bulleted list. It will break.
    – double-beep
    Commented Jan 28, 2021 at 9:22
24

Bug reported opened on GH

A triple-click selects the entire text in Markdown mode

It's a standard practice in modern text fields to double-click in order to select a single word and triple-click to select a single paragraph. This has worked in the old editor, works in the Rich Text editor, but does not work in Markdown mode and the entire text gets selected instead.

Selecting paragraph in Rich Text vs Markdown mode

Improve this answer
8
  • 2
    Thanks for the report. I believe the reason for this is due to the underlying browser behavior. Triple-click works in rich-text mode because items there are independent elements (<p>, etc). In markdown mode, the entire surface is a single <pre><code> element. I agree that the current behavior is not entirely ideal, especially since it is a regression. I'll look into it and see what we can do.
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:42
  • 1
    Actually triple click should select a single sentence, not a whole paragraph. cc @BenKelly
    – TylerH
    Commented Jan 28, 2021 at 23:01
  • 4
    @TylerH I've never seen the behavior you described in any web browser, text editor, or just about anything that displays text. Using a triple-click to select a paragraph/line is pretty much the standard.
    – 41686d6564
    Commented Jan 28, 2021 at 23:10
  • @41686d6564 I said it should do that, not that other people do that already.
    – TylerH
    Commented Jan 29, 2021 at 4:11
  • 3
    @TylerH Well, that's subjective then :) I, personally, don't see how that could be useful. Also, not to mention that classifying a piece of text as a "single sentence" is not particularly easy for a computer.
    – 41686d6564
    Commented Jan 29, 2021 at 4:17
  • @41686d6564 It's pretty easy actually: a period followed by a space will catch most cases. Add a few regexes for common/known edge cases. When I need to select more than a single word, I find at least 9 times out of 10 I am trying to select a sentence rather than an entire paragraph. If things were nice we could have both and select a paragraph with 4 clicks. But I know that's difficult because typically the way it's implemented is to select the whole element (e.g. in web browsers), so unless people start parsing each sentence as an individual span...
    – TylerH
    Commented Jan 29, 2021 at 4:21
  • @TylerH To select your sentence easily and quickly you can also double-click and drag.
    – Dev
    Commented Feb 20, 2021 at 16:47
  • This was completed in release Beta 1
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:31
24

Can we have a symbol that resembles more of a table, then a calculator?

Toolbar of the new rich text editor with the table symbol highlighted

To me the large field in the top reminds me of a calculators display, with the buttons below it. I don’t recall ever using tables in which I merged columns in the title row.

Improve this answer
7
  • 13
    ... and merged cells (iirc) are not supported at all by the current specs to begin with.
    – E.P.
    Commented Jan 28, 2021 at 11:07
  • 3
    Thanks for the suggestion, I'll run this feedback by our designers and see what we can do
    – Ben Kelly StaffMod
    Commented Jan 29, 2021 at 21:16
  • 1
    Great to see you're working on this @BenKelly
    – Luuklag
    Commented Mar 15, 2021 at 20:52
  • 2
    We have the new icon ready, I just haven't put it into place yet. Soon™
    – Ben Kelly StaffMod
    Commented Mar 15, 2021 at 22:02
  • looks great @BenKelly
    – Luuklag
    Commented Mar 15, 2021 at 22:05
  • 2
    The new icon is now being used in the new editor, so [status-completed].
    – Justin
    Commented Jul 12, 2022 at 17:38
  • 2
    I edited accordingly @Justin. Thanks for the headsup
    – Luuklag
    Commented Jul 12, 2022 at 18:48
23

Feature request opened on GH

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.

First off: This doesn't quite work yet.

enter image description here enter image description here enter image description here enter image description here If you're going to allow manually adding a bibiliography format, please don't have switching editor modes mess with it (unless we're getting a different way to see a preview than the Rich Text editor :D)

Secondly, defaulting to inline links and images in Markdown breaks my workflow. I used the 'link' button a lot on longer posts with lots of links to research articles, as it would start a bibliography. The bibliography format made it easier to provide attribution, especially if I was reusing/quoting the same posts or articles multiple times in the same post. I could just type [text][number of link to reuse] and be done with it. While the syntax for inline links is easy to remember, it doesn't allow for this kind of reuse.

Another great benefit from the bibliography format in the 'old' editor, is that it adds images like this: [![enter image description here][1]][1]. It makes it much easier to hyperlink your image to another site, like this faq explains. Just change the second number, and put another entry in the bibliography list at the bottom of the post. The current editor inserts images using the ![enter image description here](https://i.sstatic.net/RRHYf.jpg) format, which gets messy quickly if you want to insert an extra hyperlink... it takes a lot more to memorize how to do that.

And, in long posts with lots of links, having them at the bottom of the post makes the work of potential editors a bit nicer, especially if the links used are long.

I'm not sure why this decision was made, but in my opinion it makes posts messier, not neater. I don't see many support questions on meta from people that are struggling with the bibliography format, so I don't think it's about 'ease of use'. And while the Rich Text editor is there for people that do struggle a bit with writing Markdown, that editor doesn't care how the links are written in Markdown, so those people will never have to know.

As such I'd like to ask you to reconsider defaulting to the inline links, for both links and images.

Improve this answer
3
  • 11
    Regardless of which format is used by the editor to create links using the "link" button, changing back and forth between the Markdown view and the Rich Text view should never override the valid Markdown format which the user has chosen.
    – Makyen
    Commented Feb 1, 2021 at 19:01
  • 2
    As to which to use as a default, it's probably a personal preference issue. My personal preference depends on what I'm writing. Sometimes bibliography format is definitely what I want, often because it makes reuse of a link easier (e.g. images with link, or multiple references in long text). Other times, I prefer inline (no scrolling around to find which entry it is I want in the bibliography). Overall, this should be something the user should be able to set. It would probably be a good idea to have a button which allows switching the whole document back and forth from one format to the other.
    – Makyen
    Commented Feb 1, 2021 at 19:04
  • 2
    @Makyen a setting would be fine with me! Overall, if I'm using inline links I know the syntax and just use them, so that's why I prefer the button to default to bibliography... But I see there is a point for making it a preference so people that don't just type out inline links can use the button too.
    – Tinkeringbell Mod
    Commented Feb 1, 2021 at 20:43
22

Bug report opened on GH

The rich text editor does not escape HTML, but displays it in the preview as though it was escaped.

For instance, if I create a post with these contents:

To create a link, use <a href=”https://stackoverflow.com”>text here</a>

It is <this and > that

It will display as:

To create a link, use text here

It is that

Worse yet, converting back and forth corrupts it. Note that it starts with escaped HTML entities, then goes to unescaped HTML, then removes chunks of the (invalid due to smart quotes) HTML. It also breaks the quote formatting.

screen recording of post being corrupted as described above by switching between Markdown and rich text

(I was unable to create this post in the new editor due to these bugs)

Improve this answer
4
  • 3
    A small note - I'm not sure if by "new editor" you mean you disabled the editor before posting this - but what I do (often, to be honest) is to just never look at the preview - the re-rendering of MD only happens when you flip modes, so you can get around that issue by using MD mode only and just posting and then [ab]using the grace period to fix any errors.
    – Catija
    Commented Jan 27, 2021 at 15:02
  • @Catija I did indeed disable the new editor to post this. In this case, given the amount of tricky Markdown and the number of times I had to copy/paste back and forth to get the screen recording right, I wanted the preview for assurance. But for simpler stuff, that's a useful tip that I've used since. Thanks!
    – Ryan M
    Commented Jan 28, 2021 at 7:38
  • 1
    I reported a similar bug with <code> elements (the same?) on the GitHub issue tracker: <code> not rendered correctly; incorrectly escapes when switching
    – chwarr
    Commented Feb 1, 2021 at 23:03
  • This was completed in release Alpha 2
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:16
22

Bug report opened on GH

If you start writing in Rich Text mode and click the ‘Horizontal rule’ button, it’s automatically selected and you can’t deselect it, not even by clicking outside the answer box. Therefore, as soon as you start typing, the horizontal rule disappears.

enter image description here

Improve this answer
3
  • 4
    Oh, interesting. I am able to reproduce locally. The behavior is similar to the prosemirror demo editor, but it handles the clicks as you'd expect. Short term workaround - hitting [enter] gets you a new line. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 22:03
  • 2
    I would expect the HR button to add the horizontal rule and an empty paragraph that you can start typing in.
    – Sebastian Simon
    Commented Jan 29, 2021 at 2:23
  • This was completed in release Alpha 2
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:22
21

Make inserted images clickable (like in the former editor).

The new editor uses ![](https://i.sstatic.net/HvbcS.png), the former uses:

[![enter image description here][1]][1]

  [1]: https://i.sstatic.net/HvbcS.png

Making inserted images clickable is useful for large images.

Improve this answer
2
  • 2
    This is mentioned in the question's body as a known issue. But I sure hope this gets fixed or else editing old posts with images using the new editor will end up creating unnecessary edits.
    – Dan
    Commented Jan 27, 2021 at 15:56
  • @Dan thank you sorry I missed it
    – Franck Dernoncourt
    Commented Jan 27, 2021 at 22:05
19

Feature request opened on GH

Add the ability to easily change the language of a code block.

This was mentioned in another answer I believe, but I would like to add some mock UX for an idea of how it can work and look.

I just added an arrow next to the language to make it look like a selector.

When clicking on the language, a dialogue would appear with possible selection. For example, a list similar to the following.

✓ auto
-------
c#
css
html
javascript
plaintext
python

Another idea would be to show a dialogue similar to the image's details dialogue. Although this can be annoying and would much prefer the option above.

enter image description here

Improve this answer
1
  • 7
    Code blocks in rich text mode have a number of very obvious shortcomings in their current state and we will be working to improve them. A solution very similar to your first mockup is how I personally envisioned supporting this, so it is a little affirming to see someone else suggest it as well. Thanks for the suggestions!
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:12
19

Bug report opened on GH

In Markdown mode, the syntax highlighting doesn't know about *escaped asterisks* - it'll still show the words in between (including the trailing backslash) in italics.

enter image description here

Improve this answer
1
  • 3
    The markdown syntax highlighter is not 100% markdown compliant yet. See my comment above with further explanation. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 22:13
17

Bug report opened on GH

In Rich mode, spoilers don’t have the “Reveal Spoiler” text:

Improve this answer
2
  • 1
    and in Markdown mode, they don't have syntax highlighting (blockquotes do). I guess this falls under 'fine-tuning'.
    – Glorfindel Mod
    Commented Jan 26, 2021 at 20:27
  • 4
    Ah, nice catch! Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 22:06
16

  1. Type some text

  2. Paste something

  3. Press Ctrl/Cmd+z

  4. Watch your typed text being undone, and not your pasted "plaintext"

Improve this answer
3
  • 3
    Ctrl + Z in Firefox has always been strange/unpredictable (typically two undos instead of one).
    – This_is_NOT_a_forum
    Commented Jan 26, 2021 at 21:53
  • @P.Mort.-forgotClayShirky_q I agree, but in this case it just blatently skips the pasted item, no matter how many Ctrl + Z actions you perform
    – Luuklag
    Commented Jan 26, 2021 at 21:54
  • 6
    I'm able to reproduce this issue in Firefox, but not Chrome. I suspect the "something" in "Paste something" will alter the behavior somewhat as well. I'll take a look into this and see if I can't find a root cause. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 26, 2021 at 22:38
16

Discarding a draft doesn’t clear the editor in both modes

  1. Start typing an answer.

  2. Wait until the draft is saved and the Discard button appears.

  3. Click Discard.

  4. It says “Draft discarded” as usual but the text stays in the editor.

  5. When trying to leave the page, a warning message about “losing changes” is displayed.

Draft discarded but the editor is not cleared

Improve this answer
5
  • I wonder if this is a new bug at all. I've seen many inconsistent behaviours with drafts. Sometimes I copy some part of a post in the answer box as a "staging ground" to format it before making an edit or just to experiment (e.g., a stack snippet). I don't intend to post that as an answer but I sometimes find I'm unable to discard. Other times I've started writing an answer I intend to finish later on a different computer but re-visiting the same answer doesn't bring up the draft. I wouldn't be surprised if this is an old bug.
    – VLAZ
    Commented Jan 27, 2021 at 10:31
  • @VLAZ I've had the second issue you describe many times before. Saving drafts is very inconsistent indeed. Regarding the first issue (which is what this bug report is about), I've never experienced it with the old editor. As long as the "Discard" button is visible, clicking it always cleared the text for me.
    – 41686d6564
    Commented Jan 27, 2021 at 10:36
  • 2
    Just to be clear, the first issue I mentioned is that I never actually get a Discard button. So, the text just stays there. I've even occasionally deleted it manually (Ctrl+A -> Delete) only to have it show up again when I open the page again. That last one might have been fixed for a while, I don't think I've seen it within the last year, at least. What you describe is Discard being there and not working. I've not experienced this but I just wonder if it's not an old bug. In either case it probably should be fixed, of course.
    – VLAZ
    Commented Jan 27, 2021 at 10:39
  • 2
    Thanks for the report! Believe it or not, I got the code in to support this just the other day for another dev. They have a fix in their branch, along with other features, but I can get a dedicated fix out for this independently.
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:38
  • 4
    Bug fixed! The change went out earlier today
    – Ben Kelly StaffMod
    Commented Jan 29, 2021 at 22:54
16

Bug report opened on GH

If I want to add some fancy keyboard buttons using <kbd>X</kbd>

X

They show up perfectly in the rich formatting, but when putting your cursor behind the X will make you type inside the kbd element. There is no way to type anything on that same line. Not even forcing your your cursor to appear there by double clicking (as would work in MS Word).

Reproduction steps:

  • Start in markdown mode

  • Add the following text:

    <kbd>X</kbd>

  • Switch to rich text mode

  • Placing the cursor inside the kbd element allows you to edit it, but your cursor is trapped and cannot leave the element

Improve this answer
1
  • 5
    Oh, fun... Thanks for the report! I am able to reproduce the issue. I'm going to edit the post to add a few notes for reproduction purposes.
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:49
16

Bug report opened on GH

Table cells misalign if you add URLs to a cell

I attempted to create this table with URLs in the first column: enter image description here

Adding the URLs to the text causes the table formatting to break. Cells become misaligned. This happens when you are creating/editing the table via rich text and when you are using markdown. enter image description here

Steps to repro: Create table, add URL to text either via markdown or using the "insert link" icon

Column A Column B
Cell 1 Cell 2
Cell 3 Cell 4

Was able to do this successfully in MSE editor, had misalignment issue in Teams editor

Improve this answer
3
  • 2
    How did you do this? I tried to reproduce this because I was curios, I don't seem to able to do this, neither with rich text nor markdown. Not even when I deliberately try to screw the editor up by choosing multiple columns etc.
    – Polygnome
    Commented Feb 19, 2021 at 10:44
  • 3
    Just tried to repro here, and I was able to do it successfully. Failure happened in Teams editor. Added note. @Polygnome
    – Anita Taylor
    Commented Feb 19, 2021 at 23:36
  • This was completed in release Alpha 2
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:26
15

While adding an answer, if I copy text in markdown mode and paste it in rich text editor mode, the text gets pasted as code block. I would rather the text gets copied to the clipboard unformatted while in markdown mode.

I'm using Firefox, but unsure if this is reproducible elsewhere.

Ctrl/Cmd + C the following selection markdown mode

Ctrl/Cmd + V in the rich text editor mode rich text editor mode

Improve this answer
4
  • 3
    The reason for this is that our markdown editor is one large code block. We've had this discussion internally and my personal opinion is that markdown is code and should be treated as such. However, I do definitely see both sides of the argument. Marking as "review" for now. Anyone who disagrees with me can upvote this answer to show support ;). Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 23:08
  • 1
    @BenKelly Ah that makes sense, but it seems that using code is causing several issues. There are at least 2 other answers reporting a bug that seems to be related to the code tag.
    – Dan
    Commented Jan 28, 2021 at 12:19
  • I think we should not mix makrdown mode with RichEdit mode. I mean if you copy yours content in one mode, then you can not expect that pasting them in the other one mode you will get the same results. I mean you could not use both modes at the same time. You have to choose which one you want to use. And you can not pass your content between editor modes. I know for testing you coudl switch from one to the other, but not mix/copy content between them.
    – Michał Lipok
    Commented Jan 28, 2021 at 20:32
  • 6
    @MichałLipok I don't expect the rich text editor to parse the markdown when pasting from the markdown editor, but at least having the same result I would get when pasting the same content from some outside plain text editor, or entering the same text directly via keyboard. In principle, the markdown box is unformatted plain text, not code.
    – Paŭlo Ebermann
    Commented Feb 2, 2021 at 18:47
14

/

I'm not sure if this classifies as a bug but it’s something that has always worked and doesn’t work with the new editor.

So, I’m using a spell/grammar checker Chrome extension which works with most text fields. It works with the old editor, with the new Rich Text editor but for some reason, it does not work when switching to markdown:

Rich Text editor vs Markdown mode

Now, that’s a shame because this extension has been really helpful in writing (and especially, editing) posts, which a lot of it will be done in the Markdown mode.

Is it possible to fix this issue or should I wait until the new editor goes live and then take this “bug report” to Grammarly?

Update:

Checking the element in Chrome’s developer tools shows that the markdown text is wrapped in a <code> tag and that’s likely the cause:

<pre class="s-code-block markdown">
    <code>test</code>
</pre>
Improve this answer
2
  • 1
    Not sure if SE would support this. But if they don't, we may have a shot by asking Grammarly to support the new editor instead.
    – Dan
    Commented Jan 27, 2021 at 15:50
  • 4
    Thanks for the report! My official stance on this is "we don't want to support external extensions/scripts that mess with our page", but realistically, I'll take a peek and see if it isn't something that would be an easy remedy. Your hypothesis about it not spell checking code blocks seems likely to me.
    – Ben Kelly StaffMod
    Commented Jan 27, 2021 at 22:47
14

Feature request opened on GH

If I want to start a post off with a bolded statement (usually a TL;DR), on mobile I can't see what I'm doing if I use the Rich Text editor, as the 'Bold' label doesn't disappear until I tap the white pop-up:

enter image description here

enter image description here

It would be nice if these things a.) weren't put in a place where they block part of the editor or b.) automatically disappeared (perhaps a short time-out?), so that I can start typing without having to manually dismiss them.

Improve this answer
6
  • 4
    Nice catch. I'll add to our bug list. Thanks for the report!
    – Ben Kelly StaffMod
    Commented Jan 29, 2021 at 21:14
  • 5
    @BenKelly Our popover library's trolling us a bit on this. I have it spec'd out that those popovers would appear as top, but they're flipping based on the editor as a container instead of the full page layout. ¯_(ツ)_/¯
    – Aaron Shekey
    Commented Jan 29, 2021 at 22:58
  • @AaronShekey Even if the popups could correctly align themselves beyond the edges of the editor container, what happens if they’re too close to the edges of the viewport, especially when the sticky top bar is disabled?
    – Sebastian Simon
    Commented Feb 3, 2021 at 4:23
  • @AaronShekey Native info bubbles aren't enough? That's what you use on the Markdown toggle. I find the current ones being on my way all the time.. they are also, pretty bulky imo.
    – Capripot
    Commented Feb 6, 2021 at 3:49
  • 1
    We could not repro this on any mobile browser
    – Yaakov Ellis
    Commented Jul 12, 2022 at 14:24
  • 1
    @YaakovEllis I can no longer repro this myself either... after more than a year, I'm guessing something must've changed.
    – Tinkeringbell Mod
    Commented Jul 12, 2022 at 14:27
1
2 3 4

You must log in to answer this question.

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