# Opt-in alpha test for a new Stacks editor

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:

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

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:

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

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

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!

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

Bug report opened on GH

In the current editor using nested <sub></sub> html is supported, and can achieve an extra small fontsize. For example: <sub><sub> Extra Small </sub></sub>

When writing this in the Markdown version of the RT editor, and then switching over to RT the first <sub> gets trimmed, the last </sub> doesn't: <sub>Extra Small</sub> </sub>

Either nested <sub> statements should be supported, or the last closing argument should also be trimmed.

• In the current editor, any HTML-valid combination of <sub></sub> and <sup></sup> is supported (or at least functional), including nesting one element within another. It might result in text which was too small to read, but it produces the correct HTML output. Jan 28, 2021 at 9:23
• Thanks for the report. HTML is... tough and there's still a number of edge cases we're running into. I'll see if I can't get to the bottom of this one, as I'm sure it affects other nested html structures, not just <sub>
– Ben Kelly StaffMod
Jan 29, 2021 at 21:18
• Please tell me, this editor isn’t using regexes to parse HTML… Feb 3, 2021 at 4:25
• Apparently empty elements like <sup></sup> are removed when switching from rich-text to Markdown. Does this also explain why no <code></code> is present when performing the steps to reproduce from It is impossible to place your cursor immediately after an inline code block in rich text mode? Feb 3, 2021 at 4:45

Feature request opened on GH

In the old editor, pressing CtrlL brought up this:

Whereas pressing that in the new editor brings up [text](https://www.stackoverflow.com/). I would like to have this popup in the new editor when I press the keyboard shortcut, since I can simply paste my link in there and edit the link description, not the link and the description.

• Ideally we’d get rid of that hotkey entirely since it masks the (to me) vastly more useful browser hotkey for focussing the address bar. 10 times out of 10 when I press Cmd+L I want that, not to insert a link (I can do that just fine with Markdown, thank you). Jan 27, 2021 at 15:56
• Thanks for the suggestion! We have a few reports asking about a hyperlink "widget" for markdown mode, similar to the old editor. Marking as "review" for now.
– Ben Kelly StaffMod
Jan 27, 2021 at 22:34
• @KonradRudolph I don't often want to focus the address bar while writing a question, and secondly, F6 does the same job in fewer keypresses Feb 3, 2021 at 12:02
• @Pureferret Not in Chrome on macOS. Key combinations OS/browser specific, but web apps generally should never override them, unless they provide a fully-featured substitute for the same function. — Anyway. I do want to focus the address bad while writing answers; quite frequently, in fact. Just because you happen not do to do this doesn’t mean my use-case is any less valid. Feb 3, 2021 at 15:31
• @KonradRudolph I'll be honest, until this question I wasn't even aware of the Ctrl+L command. I completely agree that in general they shouldn't override these, but as this is existing behaviour I wouldn't argue we should take it away. How did you get around this command before? Feb 4, 2021 at 11:47
• @Pureferret I didn’t, I always swore at the stupid editor. Swearing is therapeutic. :-) Feb 4, 2021 at 12:02
• @KonradRudolph then I'll have to do the same if they take it away Feb 4, 2021 at 20:25
• @Pureferret At least in Chromium Edge, I have to press F6 twice to focus the address bar. So it's the same amount of keypresses as Ctrl+L, but IMO the latter is more convenient. Feb 4, 2021 at 21:07
• This was completed in release Beta 1
– Yaakov Ellis StaffMod
Jul 12 at 14:31

# Add <small> formatting

As I’ve argued elsewhere, <small> formatting is eminently useful (for footnotes, side-notes, just generally less important stuff — small print). Furthermore, whether or not it’s officially supported, in practice it is used extensively, using dirty hacks (via <sub>/<sup>), which negatively impact accessibility.

• At this time, we're focusing on parity with our existing markdown support. I'd recommend opening this as its own, separate feature request. Side note: I'd love to support something like this (and sub/sup) first class in Markdown (without html), but there's no official support in the Commonmark spec. That hasn't stopped us from adding our own extensions, along with other popular extensions with a generally agreed on syntax, but it'll take a bit of discovery to ensure we're not inventing our own wacky syntax when nearly everyone else has mostly settled on a single implementation.
– Ben Kelly StaffMod
Jan 27, 2021 at 23:12

Bug report opened on GH

Pasting a network link doesn't automatically make it a link in the preview when in rich mode:

Toggling Markdown On and Off again does make the link look properly formatted:

Link when switched to Markdown mode:

Link when switched back to rich editor from Markdown mode:

• Yup! This is in progress.
– Catija StaffMod
Jan 26, 2021 at 20:27

Bug report opened on GH

Copying quoted text from Markdown mode into a text editor like Visual Studio Code and back invisibly breaks the Markdown to insert extra line breaks between the lines of the quote. Toggling back and forth between rich text and Markdown reveals the extra line breaks.

This isn't a contrived scenario: I often compose longer posts in a separate text editor so that I don't lose them if something happens to the browser tab.

• Interesting... thanks for the report! Copy/pasting from other editors is something I explicitly would like to support, especially in rich-text mode. Not sure why extra / invisible line breaks are being added here, but we'll take a look into it.
– Ben Kelly StaffMod
Jan 27, 2021 at 22:44
• +1 to making edits in a separate editor due to browser paranoia/the possibility that I may have to step away for it for a while. Jan 29, 2021 at 4:10
• We were not able to reproduce this
– Yaakov Ellis StaffMod
Jul 12 at 14:25

Can we add support for inserting a table directly from MS Excel by copy pasting? Right now it gets added as a screenshot, which is less convenient than a table in almost all cases.

This has previously been reported as a here, with reference to this MSO post. The accepted answer there states that you could circumvent uploading as image by using "paste special" Ctrl/Cmd+Shift+v. Doing so on a simple 2x4 Excel range yields the following (indented as code):

Feb Mrt

32  32
10  15


PS: Using MS Excel 16.44 on macOS

• – Rob
Jan 26, 2021 at 19:59
• @Rob even older: meta.stackexchange.com/questions/320162/… Jan 26, 2021 at 20:10
• Luuk, even older than your example is this: meta.stackoverflow.com/q/381951/3648282 - both of those are different Q&A's (not about tables) but the reason is probably the same; any clipboard data is stored, and thus pasted, as an image.
– Rob
Jan 26, 2021 at 20:23
• @rob It is stored in a multitude of formats, the editor just isn't capable of picking anything other then the first (which is Image/PDF) IIRC. Jan 26, 2021 at 20:25
• We do support some amount of content pasting, but tables are "special". Due to how restricted the markdown support is, there's very little that we can do in most cases. A "normal" paste should at least paste text, rather than a screenshot, which is... odd. The only way it could possibly do that is if Excel added image data into the paste data. I'll see what we can do to support basic table pasting from Excel. It works from Google Docs (with limitations), so I'm not sure why we can't support some limited Excel as well.
– Ben Kelly StaffMod
Jan 26, 2021 at 22:17
• Today I checked this with osTicket which use Redactor editor , and it works. I mean I can copy Tablee in OpenOffice Calc and paste to Redactor editor. After saving content to DB this editor show it as a table ( I'm able to select text in rows and in columns ). Jan 28, 2021 at 15:51
• @BenKelly How is it implemented on tablesgenerator.com/markdown_tables ? Mar 10, 2021 at 9:11
• @BenKelly I think Excel programming questions can be split into three subcategories: worksheet functions; Excel-file-as-data; and manipulating the Excel application object model, either using VBA or Office.js. The real value for pasting Excel data as a table is for the first two questions, where generally formatting and the like doesn't matter at all; it is absolutely appropriate to paste just the text without any formatting. For the third category, a screenshot makes more sense. Mar 10, 2021 at 12:45

Bug report opened on GH

Tables - this button will create a default three-row, two-column table

For Markdown mode, this is correct. For Rich Text mode, a four-row, three-column table is created:

(tagging this as because I don't think the difference is intentional, if it is, the introductory post needs to be updated)

• Ooh, good catch. The code that inserts these are different based on which editor you're in, so this was very likely an oversight during implementation. Thanks for the report!
– Ben Kelly StaffMod
Jan 26, 2021 at 22:46
• Off-by-one error. Feb 2, 2021 at 18:02

Bug report opened on GH

After double-clicking a word to highlight it, if you quickly right-click the highlighted word to bring up the context menu, the rest of the paragraph will be highlighted, which should not be the case.

Normal behavior: (Note no new text is highlighted when context menu opens)

New behavior: (Entire paragraph is highlighted before menu opens)

Repro steps:

1. Double-click word in a paragraph
2. Immediately right-click highlighted word

Feature request opened on GH

### Indent code by pressing Tab while in a code block

The Ctrl+K shortcut is what I always used to indent/unindent code blocks but...

• it only worked for one-level indentation,
• not many users knew about it, and...
• currently, pressing Ctrl+K does nothing while in a code block in the Rich Text mode anyway.

Enabling Tab and Shift+Tab in code blocks will be a great addition.

• I assume this will break when they roll this new editor out, but in the meantime, there's a user script for tab indentation that I have found very useful over the years: Better handling of indentation and the TAB key when editing posts Jan 27, 2021 at 18:21
• Agreed! This is a personal pet feature that I'd love to add, but it unfortunately didn't make it in time for the alpha. Thanks for the suggestion!
– Ben Kelly StaffMod
Jan 29, 2021 at 21:52

As the editor currently exists, it allows image Markdown to be typed in rich text mode without any indication that the user is doing something which won't render correctly. This can be problematic.

Take this recent case from a Teams user posted to MSO (image in case the post doesn't stick around). They typed the Markdown for a post image (![image](...link...)) in the rich text mode of the editor, which lead them to believe that the preview just wasn't enabled for the editor. They failed to see that this editor was different than the one across the rest of Stack Exchange, and then were confused by why their (syntactically correct) Markdown image didn't render.

I'm proposing that there be some mechanism in place to guard against this; maybe some sort of warning for when valid markdown is detected in rich text mode. Another possibility would be to automatically translate that image markdown to the WSIWYG equivalent, just like the editor does when you type > for blockquote or #'s for a heading.

Bug report opened on GH

Issue when switching the Markdown setting on and off when there is a new line in a table:

Something else<br />that's rather long


Tested with Windows 7 SP1 x64 Ultimate + Google Chrome Version 88.0.4324.146 (Official Build) (64-bit)

• I suspect this is because tables don't technically support newlines (by spec), but you're "cheating" with an explicit <br> html tag. I'd have to look into it, but I have a feeling this is a combination of bugs that is causing this behavior. Thanks for the report!
– Ben Kelly StaffMod
Feb 8, 2021 at 19:42

GH #49 and GH #64

It is impossible to place your cursor immediately after an inline code block in rich text mode

1. Type in some text, highlight and Ctrl-K to make into an inline code block

2. <Right-Arrow> to deselect the highlighted text and place your cursor immediately after

3. Ctrl-K to turn off the inline code block

4. Start typing (don’t hit the spacebar first no space)

5. Use your arrow keys to place the cursor immediately before your first plaintext character after the inline code block (or just use your mouse)

6. Hit the spacebar or type a character

Expected: you are typing in plain text, and not in the inline code block

Currently: you type inside the inline code block. There is no way to get to the plaintext section immediately after the inline code block. The workaround is to type a space at the end of the inline code block, highlight it, Ctrl-K to toggle the inline code block off for that space. But that is really annoying.

Ideally, if you are at the end of the inline code block, you could use your right arrow key to move out of the inline code block and to the spot right after it in the plaintext area, and then use your left arrow key to move back into the tail of the inline code block. (This is how Slack handles the transition between inline code block and plain text areas).

• Thanks for the report! I'm able to reproduce this issue and I've opened a bug report on our public repo
– Ben Kelly StaffMod
Mar 15, 2021 at 21:54

Bug report opened on GH

TL;DR:

In Markdown mode, inline formatting is still being applied even if the starting token is escaped with backslash

If you are in Markdown mode and use italic and bold inline formatting on text with newlines (which would create block element paragraphs), then switch to rich text, the formatting is removed. That is probably fine and intended since you can't have block level elements within inline elements. However, if you switch back to Markdown mode, the asterisks used to create are escaped with backslashes but the italic formatting is still rendered.

Here are some images to illustrate:

1. In Markdown mode with newlines between the text and wrapped in three asterisks for bold and italic formatting:

2. Switched to rich text mode and formatting is removed (probably expected behavior since we can't have inline formatting on block level elements):

3. After switching back to Markdown mode, asterisks are escaped with backslashes, but it's still rendered with italic formatting:

• Thanks for the report! I commented on a related bug here. The short answer is that our syntax highlighting is not 100% commonmark compliant, but this is something that's currently on our list of things to fix.
– Ben Kelly StaffMod
Jan 29, 2021 at 21:56

Toggling between Rich text and Markdown moves the cursor to the start.
This makes it impossible to switch between modes and continue typing on-the-fly.

• This is explicitly mentioned in the question. Building it so that it remembers cursor location, from what I understand, is not a simple thing, so it was intentionally omitted.
– Catija StaffMod
Jan 27, 2021 at 13:07
• To echo Catija's statement, this is a fairly hard problem to solve, so we decided to focus our efforts elsewhere for the initial release. This is something that I hope to solve in the future, though.
– Ben Kelly StaffMod
Jan 27, 2021 at 23:20
• This makes rich-text mode next to useless as a markdown preview. I'd be OK with not having a live markdown preview if clicking the rich checkbox and then unchecking it was non-destructive, including keeping your cursor position. Feb 10, 2021 at 11:34
• I'm sure why this is "hard." JavaScript has the ability to view and set caret position. stackoverflow.com/questions/512528/… Feb 10, 2021 at 11:44
• @StephenOstermiller I don't think setting/viewing the caret position is the hard part. It's making the editor know that the previous position before switching to markdown at character index X is now at character index Y due to the changes done in the markdown editor, for example. Especially since the changes in characters aren't 1:1 between richtext mode and markdown mode.
– Dan
Feb 18, 2021 at 13:04
• @Dan Thats actually not that hard of a problem, many editors e.g. Overleaf can already do it. StackEdit.io has Scroll Sync, which also syncs positions between Markdown and Rich Text. Keeping caret position is actually easier than scroll sync... Feb 18, 2021 at 14:10

Bug report opened on GH

In Rich Text mode, type some text, click the Blockquote button, then click Bulleted list:

Now when I click the Blockquote button again, I expect the blockquote to disappear (the gray outline indicates it's some kind of toggle, right)? Nope, it's the bulleted list that disappears:

(In Markdown mode, the bulleted list replaces the blockquote formatting, which is OK behaviour IMHO; especially, the buttons don't have a gray outline.)

• Oooh, nice catch! I would definitely agree with your assessment that the blockquote should be toggled off, but the list should stay intact. I can imagine some edge cases, such as "blockquote > list item > blockquote", but ideally clicking "blockquote" in that case would only remove the inner blockquote and leave the outer alone. Thanks for the report!
– Ben Kelly StaffMod
Jan 29, 2021 at 21:48

Bug report opened on GH

## Description

When editing a code block in rich text mode, not all formatting buttons are disabled.

When they are clicked, interesting things happen:

When clicked, nothing seems to happen, but when the "Markdown" switch is toggled (or if the post is submitted), the code block's first line becomes a heading, and the remaining lines appear as regular text in a single line:

• Blockquote

When clicked, nothing seems to happen, except that the language indicator of the code block breaks. When the "Markdown" switch is toggled (or if the post is submitted), the code block gets contained by a blockquote:

• Image

Inserting an image breaks the code block into two parts (separated by the image), the part below the image appears as regular text. When the "Markdown" switch is toggled (or if the post is submitted), the part below the image appears in a single line.

• Table

Inserting an image breaks the code block into two parts (separated by the table). If the table is selected and deleted, the code blocks rejoin (expected).

• Horizontal line

Inserting a horizontal line breaks the code block into two parts (separated by the line). If the line is selected and deleted, the code blocks rejoin (expected).

When some text is selected within the code block, the link button is enabled, clicking it animates the button but does nothing.

I'm sorry for the low-quality GIFs, but I couldn't upload in higher quality because of the 2MB limit. I hope they are good enough to repro.

## Suggestion

All formatting buttons should be disabled in code blocks.

Wrapping the code block in a blockquote might make sense (so it can stay enabled), but it should be fixed to do what it should in this case.

Feature request opened on GH

Tag badges can't be created from rich-text mode.

• Thanks for the suggestion! This is something we'd like to add in the near term, but there needs to be some discovery on how the UI would look first (extra button vs dropdown vs ...)
– Ben Kelly StaffMod
Feb 8, 2021 at 19:39
• @BenKelly It would be nice if it worked similarly to entering a tag in the search box as a first step. My initial expectation was that I would just wrap a known tag name in brackets, and not necessarily get a list of valid tags. A list to choose from would be detrimental if I was trying to suggest a new tag or synonym and I think it's overkill for a text editor. If the brackets are too similar to text, something like [tag:discussion] would work. May 27, 2021 at 13:06

The "Post Your Answer" button can't be reached using the Tab button. If you are writing an answer and press tab, the focus jumps to the togglebox for "Community wiki" and on the next tab it jumps to the "Discard" button, skipping the "Post Your Answer" button.

Bug report opened on GH

Turning Markdown on or off removes any newline character at the beginning of the post.

E.g.:

becomes:

• It probably shouldn't do that, but why would you ever need a newline character at the beginning of a post? Jan 27, 2021 at 9:07
• @P.Mort.-forgotClayShirky_q might happen during editing eg when placing the quote before writing some sentence before the quote. Which is what happened to me when I found the bug. Jan 27, 2021 at 9:11
• Oh, interesting. I agree that it definitely shouldn't be trimming leading whitespace, even though I would also agree that leading whitespace probably isn't ideal in the first place ;). Thanks for the report!
– Ben Kelly StaffMod
Jan 27, 2021 at 23:18
• @BenKelly - Isn't leading/trailing whitespace trimmed on submit anyway? i.e. removing the trimming while switching to/from Rich mode won't negatively affect the final post. Feb 1, 2021 at 0:47
• @Robotnik no but that's annoying when editing the post Feb 1, 2021 at 0:48
• This was completed in release Alpha 2
– Yaakov Ellis StaffMod
Jul 12 at 14:17

Bug report opened on GH

The following Markdown will produce two images next to each other, but the preview will show them under each other:

![enter image description here](https://i.stack.imgur.com/SQfjes.png)
![enter image description here](https://i.stack.imgur.com/E7aHes.png)


This is what the editor shows:

• I didn't even realise you could put images side by side at all. ._.
– Journeyman Geek Mod
Jan 30, 2021 at 13:08
• @BenKelly this is not exclusive to two images following each other, the same happens when your are in rich mode, insert an images, and type under it. The preview will show the text on a new line, while the rendered version will show the text on the same line as the image. Also see: meta.stackexchange.com/a/362260/361484 (deleted now, as it is mostly a dupe of this) Mar 18, 2021 at 15:08
• @BenKelly this is not exclusive to this alpha editor test, see meta.stackexchange.com/questions/362441/… It probably is a problem with how the preview works. Mar 23, 2021 at 8:07
• This was completed in release Alpha 2
– Yaakov Ellis StaffMod
Jul 12 at 14:17

Bug report opened on GH

Pasting into an inline code block doesn’t work

1. Start typing.

2. Copy some text (from anywhere) to your clipboard

3. Use the Ctrl-K shortcut to start a new inline code block or just click the button

4. (Optional) start typing in your inline code block (the bug happens either way)

5. Paste your text (Ctrl-V)

Expected: The text will be pasted into the inline code block, and the cursor will be at the end of the text

Currently: The text is pasted as plain text. If there had been text in the inline block, the block closes and the text appears after it. If there hadn’t been text in the inline block, the block vanishes, never to be seen again (if you toggle to markdown mode, there is no evidence of the block.

The same also happens if you select any text within the inline code block and then paste - if you have three words in the block, and select the middle one, then paste, it will split the inline code block into two (first and third words) and then add your pasted text as plain text between the two inline code blocks.

• Thanks for the report! I am able to reproduce this issue. I've filed an issue on our public repo
– Ben Kelly StaffMod
Mar 15, 2021 at 21:51
• This was completed in release alpha 2
– Yaakov Ellis StaffMod
Jul 12 at 14:27

Feature request opened on GH

Clicking the "Insert image" button opens up the following:

Which used to feature the ability to click the "paste" link to quickly paste an image or link. Here's how it looked in the older editor's tool:

And once you clicked "paste," you were greeted with a user-friendly textbox:

I take a lot of screenshots using third-party snipping tools (which auto-upload them to various image hosting sites, copying the link to my clipboard in the process), and I liked quickly uploading them using the "paste" link in the older tool, as it very quickly uploads them to Stack Exchange's imgur hosting service. Now, the only option available to me is to open a file dialog. I can paste the link directly into the "File name" portion of the open file dialog, but the ability to quickly paste a link without being taken to another window was far more streamlined.

Could you reinstate the ability to paste a link in the image insertion pane?

• I personally use a screenshot program that offers me the option to copy to clipboard directly. I just paste that into my SE editor, saves uploading once. Just for your consideration. Jan 26, 2021 at 19:55
• Yeah, I could easily tweak it to just copy the image itself, but eh. I preferred the original functionality. Jan 26, 2021 at 19:57
• We do support pasting image data into the editor, even outside the image pane, but I can see where we are missing the ability to paste a link to an outside resource. Pasting image data from basically any source (copy/paste an image from your file explorer, right click > copy image in your browser, etc) works. That being said, pasting a text link to an image resource is currently not implemented. I'll see what we can support there. Thanks for the report!
– Ben Kelly StaffMod
Jan 26, 2021 at 22:32
• This was completed in release Beta 1
– Yaakov Ellis StaffMod
Jul 12 at 14:32

Feature request opened on GH

Can we have the toolbar tooltips show the keyboard shortcut for inserting that element into a post, like the previous editor did, so it looks like this:

• Yes! This is currently planned, but the implementation needs a little more work. Thanks for the report!
– Ben Kelly StaffMod
Jan 27, 2021 at 23:13
• @BenKelly More of a request than a report, but thanks anyway ;) Jan 27, 2021 at 23:15
• This was completed in release Beta 1
– Yaakov Ellis StaffMod
Jul 12 at 14:34

Pressing Ctrl+Enter inserts a newline instead of saving the post. In the old editor, this provided a convenient way to save the post from the keyboard. Since one can enter a newline by simply pressing Enter, Ctrl+Enter has no other special functionality, Since the special functionality it has (leaving code blocks) is also handled by Shift+Enter (and could also be addressed in other ways), it would by ideal if Ctrl+Enter continued to save the post as it did previously.

• CTRL+Enter have now special feature, take a look here: meta.stackexchange.com/a/360070/915027 Jan 26, 2021 at 23:12
• Shift+enter also (perhaps counterintuitively?) exits a code block. That said, I think your idea would eliminate the need for either unintuitive key combination to be required to exit a code block. Jan 26, 2021 at 23:15
• Normally/usually Enter and SHIFT+Enter is used to add two different kind of new line, and CTRL+Enter for post message (or to add/jump to next page in "document" editors). Currently there is a problem with SHIFT+Enter (wondering how to describe the issue I notice) Jan 26, 2021 at 23:26
• SHIFT+Enter pasted between two lines makes editor unable to normally use KeyDown and KeyUp key’s to go up/down between the entered text. Jan 26, 2021 at 23:40
• In Rich Text Mode, Enter starts a new paragraph, while Ctrl+Enter is only a newline. This is pretty standard for rich text editing and follows how most text editing software does it. Jan 28, 2021 at 9:01
• @Polygnome That's not my experience. A lot of text-editing software uses Shift+Enter to enter a newline. Ctrl+Enter creates a page break in both Microsoft Word and Google Docs. Jan 28, 2021 at 9:07

Fine-tuning images: resizing or adding links to sources or full-sized images will need Markdown mode.

That'd be convenient to have a way to resize images in the non-Markdown mode, as I've seen many people resizing images by lowering the resolution instead of using the HTML to change the image's dimension (which is a bit of a pain to type).

• Thanks for the suggestion! We actually had a rough implementation of this really early on in the development cycle, but we removed it since there's no standards compliant way to set size attributes on an image in Commonmark (other than using html, which I prefer to avoid if possible). I'd love to get some sort of support for this use case in place though, so marking as "review" for now.
– Ben Kelly StaffMod
Jan 27, 2021 at 23:05
• @BenKelly It may be helpful to mention that, on public, unlike on Teams, the fact we upload to imgur allows for us to use imgur's resizing links - if you add certain letters to the URL, it will display the image in different sizes or formats. Since this is just a change to the URL rather than any sort of HTML, perhaps it might be easier to implement? Here's the list of letters that will change the image size - meta.stackexchange.com/questions/298818/…
– Catija StaffMod
Jan 27, 2021 at 23:15
• @Catija thanks the issue with these links is that they have images with lower resolution. Jan 27, 2021 at 23:30
• @BenKelly that'd be very cool, thanks! Jan 27, 2021 at 23:30
• @FranckDernoncourt Personally, anyway, this is why I always default the linked image to the full-size image. This is simple in our current scheme - I copy the image URL and add it to the list at the bottom a second time. Then I change the number for the second one, add an m to the first link, and then change the reference link in the post body to refer to the second link as the image link... if that all makes sense. :D If we implemented this well, that would all be automatic when uploading, say - I upload, pick a size and the MD automatically links to the full size image.
– Catija StaffMod
Jan 27, 2021 at 23:33
• @Catija thanks, got it, makes sense but I think it is preferable to display the image with the highest resolution but rescaled to a lower dimension Jan 27, 2021 at 23:39
• Good to know - I guess I've been lucky. I don't tend to have issues with the resized images being legible on my end but I think I have heard that some do have issues with it. I don't have a great solution - but, as the person who's written our internal guide on using HTML to resize images on our Team - I know it can be janky to try and do manually. :D
– Catija StaffMod
Jan 27, 2021 at 23:41

Bug report opened on GH

On mobile, with a touch screen, there's no obvious way to continue a post if the last element is a image. While I can tap on text to bring up a cursor, without arrow keys there's no intuitive way to move it.

On Desktops *if* the only element is an image, you can’t bring up the cursor, but if there’s any text on top, you can can navigate past the image with the down arrow.

As such there's no way to continue a post past and embedded image unless you you switch to markdown or insert it between text blocks on mobile, or if there’s already text on the desktop views

• If I understand correctly, the same happens on PC (i.e., you can't get to the end of the post using the mouse cursor, or even with arrows). Jan 29, 2021 at 1:58
• Thanks for the report. There's a bit of a trend I'm seeing regarding being unable to continuing editing when the final element is a selectable block. Hopefully we can address all these in one fell swoop
– Ben Kelly StaffMod
Jan 29, 2021 at 21:34

Feature request opened on GH

When trying to select a row of a table in the rich editor, you select only the contents of a single cell. If you drag further you select the contents of the next cell, etc. There is no way to select the entire row.

Can we please make it such that we can do the intuitive thing here and select an entire row and remove it by pressing backspace / delete. Instead of having to go through the dropdown-menu to remove a row.

• Thanks for the suggestion! We do have plans to give the table functionality some extra love, but it unfortunately didn't make it in time for the alpha launch. Row/column selection is something we'd like to look into supporting in the future.
– Ben Kelly StaffMod
Jan 29, 2021 at 21:51
• Thanks for all your work and open communication @BenKelly. Much appreciated. Jan 29, 2021 at 21:53

I'm not sure if this is an artifact of the transition phase, but when I open an edit screen in a new tab (just like non-2k users would), e.g. with this link, I can't resize the question preview anymore, and only the first few lines are visible:

### Old situation

• Ooh, nice find! This resizer was initialized in the editor code and I missed it when testing out the non-inline edit screens. I have a quick fix ready to go that will go out sometime later today. We haven't decided yet if we're going to move away from the "grippie" (existing style) of resizable or move forward with the css native resize like you see in the new editor now. For a quick fix, I've simply added resize to the original question body to match the editor, but I have a bug filed internally to revisit this before full launch. Thanks for the report!
– Ben Kelly StaffMod
Mar 16, 2021 at 14:55

Bug report opened on GH

The video below shows what happens if one holds the key. I think it'd be preferable if it doesn't loop around, especially since holding the key doesn't loop.

Markdown used in the demo:

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


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

• Nice find! I was able to reproduce locally. I logged on issue on our public repo to track this. Thanks for the report!
– Ben Kelly StaffMod
Mar 16, 2021 at 15:12

Feature request opened on GH

It's not obvious how to switch between modes on mobile/narrower screens

Would it be possible/desirable to have the mode switch on the left or bottom of the text input?

• Maybe have the mode switch fixed on the right side and the other buttons scrollable. Jan 29, 2021 at 3:28
• Jan 29, 2021 at 4:41
• Thanks for the report. This issue is very similar to the one linked by @FranckDernoncourt. I'm follow up with our designers to see if we can't come up with a better long term solution to the horizontal scrolling
– Ben Kelly StaffMod
Jan 29, 2021 at 21:32