Announcing the Stacks Editor Beta release!

TL;DR: The Stacks Editor Beta release rolled out on July 5, 2022! To see what we've been working on, what we are working on, and what we plan to work on, check out the Stacks Editor repo on GitHub. The editor is still an opt-in feature, and there is currently no timeline for a network-wide deployment.

This question is no longer being monitored for new answers. If you have further bug reports or feature requests for the new Stacks Editor, please post them as new questions tagged stacks-editor.

Back in early 2021, we announced the launch of the Alpha version for a new Stacks Editor. The announcement post saw a lot of activity, and after a lot of work by our Stacks Team, we're ready to launch the Stacks Editor into its Beta version!

In the original announcement for the Alpha Version of the new editor, Catija highlighted some of the reasons why we needed to create a new editor, ranging from meeting our Teams users' needs to simplifying future dev work on the public sites (you can read more in the original announcement). We asked you to test it and provide feedback — and you did. The post gathered 110+ answers with bug reports, feature requests, and more general feedback provided by you.

The team worked hard to respond to your feedback, but after a while, public feedback from the team about what was being worked on slowed to a near halt. While the team was still working silently on the Stacks Editor during this time, they had to balance this work with other priorities on their plate. More importantly, though, and as I mentioned above, we ended up not updating you on where work on the editor was and where we were planning on going with it: this doesn't reflect well on us, and we apologize. We'll aim to be more proactive and frequent with communications on this going forward. This brings us to this post.

As Yaakov mentioned earlier in June, the Stacks Editor is the main editor used in the new Ask Question Wizard, which will be made available on Stack Overflow sometime after the Beta 2 release goes out. The new Wizard, in turn, will later be a central piece of the Staging Ground project. So where are we going next?

You can have a look at the Stacks Editor repo on GitHub to see a breakdown by feature of what's been worked on and what is still to come (issues in the “No Milestone” section are backlogged, with no projected pick-up date). To give you a high-level overview:

• Alpha 2: This is what the team's been silently building and shipping since the original Alpha release of the editor. The editors used on network sites were updated to include this release on June 21, 2022. The team’s worked to fix many of the issues reported by you, including:

• Beta 1: This was released on July 5, 2022 and is in production as of July 12. Full release notes are available. The main accomplishment of this release is to ensure the back-end library is feature-complete as compared to the old editor — meaning the Stacks team laid the groundwork that’ll allow the dev teams responsible for the Public Q&A sites to work on Stack Exchange-specific functionality. With this, the latter teams will be able in the future to build plugins into the editor, with the goal of reaching feature-parity (for all sites) to the old editor available on the network. Some of the issues addressed on this release were:

• adding initial support for a Markdown preview pane — we know this was a big pain point for many of our power users. Some integration work with the product still remains to be done before this is usable on the sites — we will post a separate update detailing this when it’s ready;

• enhancements to link insertion and editing, as per the issues reported here and here;

• and adding official external plugin support, which will be required for supporting various extra editor features across the Stack Exchange network, such as poker, go, chess, code snippets, and MathJax.

• Beta 2: This was released on July 28, 2022, and the editor was released on participating sites on August 8, 2022. For this release, we identified some issues we feel should be addressed before launching the Ask Wizard and Staging Ground projects. This release also included some issues that were reported in answers to this post. Some of the highlights for this release are (full release notes also available):

• An overhaul to the code highlighting system that addresses a number of issues reported with highlights to Markdown mode when text isn’t CommonMark compliant, as reported here, here, and here.

• A change in the toggle between Rich Text and MarkDown modes - the toggle is now icon-based, instead of the on-off switch that had been in place up until now.

• Bug fixes with image-uploads (here and here), code block serialization.

• Block elements are now allowed inside list items.

• Note: while the preview pane plugin is working in the editor code, some work remains with integrating this into the site. We'll post a separate update detailing this when it’s ready.

• Beta 3: These are issues that would be beneficial to address, but not required for baseline functionality. Once these are addressed, the Stacks Editor should be ready for a network-wide deployment (though we don’t currently have any plans to do that; more on that below). There isn’t a timeline for addressing these issues, and the team will tackle them as their bandwidth permits. Highlights for this release include:

Until the end of July 2022, we have members of the Stacks team as well as devs from one of the teams responsible for Public Q&A assigned to working on the issues marked as essential for the Beta 2 release. Additionally, there’s some flexibility on that roadmap to account for high-priority issues reported in response to this post, and though we can’t guarantee we’ll be able to address every single thing reported, we’ll be responding to all feedback as we triage it and, all applicable unique issues will be logged in the Stacks-Editor repo. Once July’s over, we’ll still be monitoring and responding to issues and feature requests surrounding the Stacks editor, be them reported on MSO or MSE (which can be brought to staff attention using this process), or on GitHub (more on how to report issues at the bottom of the post). These will be triaged based on severity and developer availability to prioritize issues for the Beta 2 release.

FAQ

What was that about a network-wide deployment?

As I mentioned above, the Stacks Editor is a central piece of the new Ask Question Wizard and Staging Ground, so for now we’re committing resources to ensure the work needed to support that project is successful. Additionally, we’re expecting you will report many more issues that have yet to be identified, and have to be prepared to be able to address those issues and respond to those reports. For that reason, at the moment we don’t have any timeline to roll out the Stacks Editor network-wide, and are instead focusing on ensuring we can undertake the near term work required to support the Ask Question Wizard and Staging Ground project. When we get to the point where it looks like extending the opt-in testing to questions, or even a network-wide deployment might be in sight, we’ll make sure to loop you in.

Is this still opt-in?

Yes! The editor will continue to be available on Stack Overflow for Teams, and for answering questions on Meta Stack Overflow and Meta Stack Exchange — this is reached via an opt-in on the Profile > Settings page labeled “Enable new editor” (the text here will be updated soon to change the “Alpha” label into a “Beta” label). When the Ask Wizard is released on Stack Overflow, all users will be able to toggle into this question asking mode, where they’ll be able to try out the Editor in that context as well (more details around this will be shared on MSO when the release is made).

How to provide feedback

We will be monitoring this post for responses until the end of July 2022. If you have feedback, bugs to report, or feature requests, please post them as an answer under this question — with one issue per answer. Please make sure what you’re posting here hasn’t been posted already, and do not report issues in comments. Please provide steps needed to reliably reproduce a bug, along with which browser/s you're experiencing the bug in. If an issue on the Alpha Release post doesn't have a link to an active case on GitHub (GH) feel free to repost here and link to the original in the report. If it does have a link to an active case it is being worked on so there is no need to repost here. Additionally, since this is an open-source project, you can also use the GitHub repo for the editor to submit new issues if you feel comfortable doing so — we'll cross-link stuff reported here and in the GH repo. As mentioned above, you can also use the repo to check out the issues still scheduled for work. After July 2022, issues should be reported as separate questions tagged .

• I have updated the statuses on all old posts/answers to reflect what was completed and released in Alpha 2 and Beta 1.
– Yaakov Ellis StaffMod
Jul 12 at 14:40
• I am a bit annoyed. How did I miss that y'all finally decided to include a preview pane, which is the main thing I miss from the old editor 😁
– Journeyman Geek Mod
Jul 12 at 18:44
• @JourneymanGeek You didn't miss it. This is the first time that we announced a preview pane. It is built into the editor not (you can try it out here), but it still needs some tweaks and integration work to get it to work on the sites. There will be a separate post about it when it is ready to go.
– Yaakov Ellis StaffMod
Jul 13 at 8:54
• Not quite a feature request proper - and more for the future but for the sake of clarity - especially during the beta phase, and as/when the new editor is more widely used, would it be sensible to have the current version somewhere for the ease of classification of bug reports between versions?
– Journeyman Geek Mod
Jul 14 at 12:56
• @JourneymanGeek you can always try out the current version at editor.stackoverflow.design (this will always be the same version as on-site, except for the slight lag between when a new version is released for the editor and has not yet hit the site).
– Yaakov Ellis StaffMod
Jul 14 at 13:01
• can implement fira code or any font with ligature in code??? i.imgur.com/mOO2sOM.png Aug 5 at 17:21
• @ArcanisGK507 we don't have plans for custom font support in the code editor.
– Yaakov Ellis StaffMod
Aug 7 at 13:41

Using the Markdown editor, if you try to quote a table the leading pipes are removed on all lines except the separator row. First click:

>
> Column A | Column B |
> | -------- | -------- |
> Cell 1   | Cell 2   |
> Cell 3   | Cell 4   |
>


If next you try to unquote the greater than > quote character isn't removed from the separator row. Further clicks of the quote button will repeat the process, adding more quote characters to the separator row. After 7 clicks:

>
> Column A | Column B |
> > > > | -------- | -------- |
> Cell 1   | Cell 2   |
> Cell 3   | Cell 4   |
>


GIF for reference

Let’s say you wanted to quote a source fence. If you press the quote button, having the source fence selected, it has a double effect:

• It keeps adding quotes on the triple backtick lines ;
• It adds and removes the quotes on the remaining lines.

The result after six clicks looks like this:

>
> > > 
> some text
> > > 


• Is the trailing space in the first line with > intentional? Is it crucial for this example? Jul 13 at 10:30
• @This_is_NOT_a_forum the space is added by the system when you press quote, the system adds >  not just > which is consistent with CommonMark to add a space between quote and text. But you have to select the empty line before pressing the quote button. (I think the space and empty line add depth to the example.) Jul 13 at 10:34

Headings created by dashes or equal signs under the line are only shown as headings in Markdown mode if there are at least two such characters

The rich-text mode previews this as a heading, regardless of the number of such characters. This is the correct behavior, per the relevant section of the CommonMark spec.

Note that no editing is required in the above demonstration of this bug, as toggling Markdown mode collapses the heading underline into a single character (thus greatly increasing the likelihood of this bug being hit).

When I went to edit my answer on MSO. When in preview mode (not markdown) the bare links in a list were prefixed with a loading spinner.

Toggling between markdown and back does not resolve this:

I let it spin for 12 minutes so it doesn't seem like it is going to resolve. (It also doesn't look like any type of request was made to be resolved?) If this is supposed to indicate that these links will be changed when submitted we should really have a different indicator than a loading spinner.

This only seems to impact bare links in lists.

Here's another example:

Removing the list removes the spinner. Putting the list back restores the spinner (whether the lists are restored through markdown or with the UI):

Curiously, I was unable to reproduce this in a new answer on MSE (nor in this answer itself):

Either on the initial post:

Or on an edit after:

When trying to delete multiple tables in the rich text view, only one table is deleted at a time.

Here's a GIF demonstrating the deletion of multiple tables at once (using manual selection):

Using Ctrl+A to delete all the tables works.

If there is text above the first table, then all the tables can be deleted at the same time, as intended:

Also reported in this answer to Opt-in alpha test for a new Stacks editor.

Pressing the down arrow key in a code block with multiple lines moves out of the code block, instead of down to the next line in the code block:

In this video I pressed these keys: Down Up Up

As I asked here, tag markdown displays differently in Stacks Editor than it does in Meta SO:

When I typed [tag:*-faq] in the new stacks editor, it rendered as a tag (like ), but then when I posted my answer, the unrendered Markdown was displayed.

Further, the Markdown following the asterisk was also italic.

Screenshot showing Stacks editor Markdown:

Screenshot showing Stacks editor rendered Markdown:

Screenshot showing how Markdown was rendered on Meta SO:

• You would probably need to escape the asterix, as it being a markdown character in itself. Don't know if this is status-by-design though. Jul 18 at 11:58
• @Luuklag If it's status-bydesign, it's inconsistent. If it's going to render correctly in Stacks Editor, it should render correctly on the site. I've got no qualms either way whether it's valid syntax or not, the rendering just needs to be consistent after you've clicked the submit button. Jul 18 at 12:52
• That is a whole separate topic. Server side rendering, and client side rendering are two different things, there have been inconsistencies between the two as long as I can remember. But yeah, ideally they should both do the same things with the same syntax. Jul 18 at 12:57

Cursor disappears in long posts

(Reposting from Can't use Stacks editor for long posts on iOS because the cursor disappears because there is no GitHub issue yet.)

This is really a serious bug. When I try to edit text towards the end of a long post (or sometimes middle, for very long posts), my cursor disappears. Where exactly this happens seems to depend on where the scroll bar is.

I can't see where I'm typing except that text appears (or disappears, when backspacing), and trying to move around my cursor is hopeless because tapping doesn't make it appear and neither does holding the spacebar. I can't see if I have any text selected either (as I sometimes end up deleting the entire body of the post). Examples of a few answers where this happened:

Cursor is between community and the period when I was backspacing:

I tested it on two different browsers (iOS Chrome and iOS Safari) on different devices and it happens on both. It also happens on the preview editor. (I have not encountered this on desktop, which is the device I have to switch to in order to make edits.) It doesn't happen on every answer, only when the answer is long or maybe has some complicated formatting. It also seems to happen in both editor modes.

Significantly, this is preventing me from editing something on a private Team (where this is the only editor, and I also see this happening on questions), so it should be fixed.

• Please add the iOS version you are using and the versions of Chrome and Safari. Given the relatively large number of issues with iOS and browsers not rendering things correctly, it would be quite helpful for you to be explicit about which versions of those you're using, so people can clearly see that you're using a version which is officially supported by SE. Alternately, that they are able to know things are broken on older browsers/iOS versions and that can be taken into account with respect to choices for what to support and documenting what is supported/known not working. Jul 20 at 19:31
• iOS 15.5-15.6 (possibly earlier), Google Chrome 103.0.5060.63, and I didn't think Safari has its own version, so it's just whatever comes with those iOS versions. I can't really put this information where I want in the answer :/ Jul 20 at 20:26

Allow saving edits to a post using Ctrl+Enter, like in the old editor.

Users used to using Ctrl+Enter would be quite annoyed every time a newline is entered instead...

Also requested in this answer to Opt-in alpha test for a new Stacks editor.

• I continue to mess this up regularly (i.e., nearly every time I try to save a post on Teams). Jul 13 at 0:22

Preview does not support lang-* notation for syntax highlighting specification:

However all highlight correctly when it is posted:

print('test')

print('test')

System.out.println("test");

System.out.println("test");


Inserting a horizontal rule in Markdown mode makes the previous line a header

Dashes under a line in Markdown apply header formatting. There needs to be a blank line between the text and the row of dashes. The existing editor handles this correctly.

Also, minor related note: toggling between Markdown mode and regular mode changes the number of dashes from three to one (not a meaningful change).

• Just to add context here– hyphens - (or equal signs =) below any text are supposed to create a header per CommonMark spec. I think it gets used accidentally more often than intentionally, but it's still valid Markdown all the same. Jul 13 at 15:09
• I think a good solution here would be for the horizontal rule button to insert a line break before the ---, which would avoid creating an accidental heading. Jul 13 at 15:09

Various oddities occur when a numbered item is a child of a bulleted item

This is based on the following Markdown:

- Bulleted item
1. Numbered item


The following problems occur:

1. Selecting the bulleted item and pressing the bullet button does nothing. This may or may not be expected.
2. Selecting the numbered item shows both the bullet button and the number button selected. This may or may not be expected, as it is technically within a bulleted item . Pressing the number button removes the number, as expected.
3. Unexpectedly, pressing the bullet button also removes the number. Pressing it a second time removes it from the parent bulleted item, as expected.
4. The first bullet cannot be backspaced. Doing so with something else before the bullet (not shown in this video) causes the cursor to move to that. This may or may not be expected, as it's somewhat unclear what should happen to the child when the parent bullet is removed. However, if it is not the first item in the bulleted list, then the bullet can be backspaced. The behavior should be consistent.
5. Backspacing the bullet in this scenario results in the rich-text editor showing the formerly bulleted item's text indented until Markdown mode is toggled on and off, at which point it is no longer indented.

• This is a tricky scenario, and we will try overall to make things more consistent. However, I am pretty sure that it is by design that you cannot backspace to cancel the root list item when there are nested items beneath it (will update if it should be changed).
– Yaakov Ellis StaffMod
Jul 17 at 12:06
• And in the case where you are removing the second list item that has a sub-item, the sub-item now is a child item of the first bullet item (but the cursor is still in the intervening row), which is the reason for #5.
– Yaakov Ellis StaffMod
Jul 17 at 12:07

Undo/Redo buttons don't always work

I guess this could be considered one bug or two, but I'm just reporting it once.

In the editor currently on SE, switching modes destroys the undo/redo stack.

I can undo and redo changes in the mode I used to make them, but switching to the other mode resets the undo/redo stack so pressing the undo/redo buttons do nothing.

For example, you type some text in markdown mode and undo and redo work. The second you flip the switch to preview mode, pressing undo and redo no longer do anything. If you type more now, you can undo to what it looked like when you switched but not before that.

In the most up to date editor, the undo/redo buttons do nothing

They just don't work.

There is an issue with undo/redo on the demo editor, but it works fine on the site. — Yaakov Ellis

Reproduced in iOS Chrome, Windows 11 Chrome, MacOS Chrome. Leave a comment if you can reproduce elsewhere. Note that you will need to be in "narrow mode" to see the undo/redo buttons.

• Due to the way in which the editor works in both modes, losing the undo/redo stack is a known issue but one that we are not planning on addressing. Maintaining the same stack untouched would not be good, as it would not be able to handle properly all scenarios where changes were made in the other mode. And there is no reliable way for us to change the stack in the non-active mode based on changes made in the current mode.
– Yaakov Ellis StaffMod
Jul 17 at 11:35
• I'll see if possible for us to only lose the stack if changes are made in the other mode, and maintain it when a double-toggle is made with no other changes. Will update here if that is possible.
– Yaakov Ellis StaffMod
Jul 17 at 11:36
• There is an issue with undo/redo on the demo editor, but it works fine on the site.
– Yaakov Ellis StaffMod
Jul 17 at 11:36

Applying a [numbered / bulleted] list to multiple lines works differently in each mode

Steps to reproduce:

1. Type text on multiple lines with single line breaks.
2. Select all lines.
3. Apply [Numbered / Bulleted] list to the selected text in Markdown mode.
4. Repeat using double line breaks.
5. Repeat the above in rich text mode.
6. Observe the difference.

GIFs for reference:

1. Single line break applied:

2. Double line break applied:

What's happening in Markdown mode?

• After selecting and applying a numbered list, the numbers assigned to each line are the same. Switching to rich text [and back to Markdown] fixes the numbering. This is not a bug, as Marijn notes below, but it would be nice to have it apply the proper numbering in the first go itself.

• Compared to rich text mode (and the old editor), the numbering is applied to all the lines. In the case of bulleted lists, the bullet points are also applied to all the lines in Markdown mode.

• In the case of double line breaks, the [numbers / bullet points] are applied to blank spaces as well (as shown in the GIF above).

What's happening in rich text mode?

• After selecting all the lines, with either single or double line breaks, and applying a numbered list in rich text mode, the numbering is only applied to the first item in the list, as is the case in the old editor. This is also the case with bulleted lists.

Comparison with the old editor

• The numbers in Markdown being the same (all 1) is not a bug, that is in the spec (see markdownguide.org/basic-syntax/#lists-1 for examples). It is however somewhat annoying (but not harmful in this specific case afaics) that going from Markdown to rich text and back does not preserve the original input. Jul 23 at 13:48

When editing an answer on mobile, and opening the image uploader there isn't enough room for all contents:

Switching from Markdown to rich text mode strips blank lines in a variety of cases. For example writing this in Markdown mode:

<!-- some HTML comment -->

paragraph


has the empty line stripped when switching to rich text mode:

<!-- some HTML comment -->
paragraph


According to CommonMark specification blank lines don't break blocks, so the editor should keep blank lines when switching modes because the users may want to use them to visually break walls of text in the source.

Not sure if this is intended or not, but only one spoiler can be revealed at a time in the rich text view:

This does not happen after posting the answer.

Test:

I can

see

multiple spoilers

at the same time

but only after

Compare with the old editor (it's possible to see all the spoilers at the same time in the preview itself):

• This is by design. If spoilers permanently revealed themselves when entered you wouldn't know if you were editing a spoiler or a blockquote. This is ultimately a consequence of the same design being used for both nodes, so this might be something we can revisit if/when we update the spoiler design.
– Ben Kelly StaffMod
Jul 13 at 21:20

In rich text mode if you click to edit and cancel a link the tool is left at the bottom and doesn't reset its position back to under the link. Steps to reproduce:

1. Next click Cancel

1. The link edit tool didn't reset its position back to underneath the link where the cursor is; it's left dangling where the previously expanded tool dialog ended.

GIF for reference:

System specific info: Firefox 102.0.1 (64-bit) on Windows 10. Rev at the time that I originally posted this.

Make the resize tool more (visually) accessible.

In the new editor, the resize tool is denoted by two small diagonal lines in the bottom right corner of the editor:

This can be quite easy to miss. For users using the non-inline edit screen, in some cases, the resize tool (for resizing to see more of the question) is barely visible:

In the old editor, the resize tool is more visible:

Related to this answer to Opt-in alpha test for a new Stacks editor.

• Just FYI: While I haven't checked, those look like the browser-based resize indicator which is displayed based on the resize CSS property. It's drawn on the inside of the element on which the property exists. In order for there not to be overlap between it and the contents of the element, there needs to be space specifically allocated to it within the element's layout. The easiest way to do so is to have some padding which leaves space for the indicator, although it's possible to use other methods of excluding, or pre-using, the necessary space. Jul 15 at 19:35
• The above is just information. IMO, the "grippie" bar (SE's name for it in the HTML/CSS), which exists on the current editor, provides a better UX. Jul 15 at 19:38

In rich text mode having an HTML comment at the top of a post causes the editor to display a blue horizontal bar -if you move the cursor on that line in the editor- for example:

<!-- some HTML comment -->
paragraph


Causes the blue bar:

This shouldn't happen since a comment shouldn't cause a visual queue in the editor?!

Adding a link to text with a space at the end causes the space to be included in the link text

This can happen, for instance, when you double-click a word to select it. The old editor handles this correctly, trimming the portion that gets the link applied to not have any whitespace at the end.

Either the help icon shouldn't direct you to Markdown help in rich text mode, or the help page should mention both Markdown and rich text.

In rich text mode a horizontal rule, <hr>, does not have a selection highlight whereas surrounding paragraphs have it. (This can be compared to this report where an HTML comment does have a selection highlight.)

When translating a combination of p tag element and HTML comment on the MD mode, RT mode display transcribes texts weirdly:

• Overlap with the placeholder text
• Wrap in a blue border box
• Uneditable. Inserting new words make the whole text deleted.

In MD mode, insert this:

<p>A paragraph.</p>
<!--This is a comment -->


Result in RT mode:

Even back to the MD mode and deleting the HTML comment, the issue is still remaining.

Expect: Having a HTML comment shouldn't affect displaying the text in RT mode.

• Jul 24 at 16:06
• I guess the overlap with the placeholder text would (currently) only be an issue in the demo editor, not in the editor that is being used on this site, which doesn't have placeholder text. Jul 24 at 16:08

It would be nice if in rich text the language code shown in the upper right corner of a source fence could be correctly stylized as Python, CSS, JavaScript instead of python, css, javascript, etc...

I know the tags are all lower case but I haven't found a post with explicit rules about casing because apparently writing Python instead of python in the language code of the source fence works all the same. But writing Python in sentence case still makes the language code show in lower case in the editor.

• We dont have a programmatic way of determining the proper casing for language names (and some languages define themselves with all lower-case names), so would rather not get into a scenario where the language names have to be manually mapped. Would rather stay consistent here, and even with lower-case, it should be understandable what language is being used.
– Yaakov Ellis StaffMod
Jul 14 at 5:52

Bolded message in Markdown is already bolded.

Shouldn't it be unbolded when in Markdown?

• This is entirely intentional. The Markdown view displays as much formatting as it can while still displaying the actual Markdown. Many other styles will also appear as you type in Markdown view (like the links directly above the bolded text).
– animuson StaffMod
Jul 16 at 5:58
• @animuson While I understand it's intentional, what this report indicates is that showing is as formatted can be confusing to users expecting to see Markdown text without formatting. Users may think things either aren't working correctly and/or that they need to remove what appears to be redundant Markdown formatting (it's already bold, right?). What this report should be taken as is indicating a need to document and explain how it's supposed to work somewhere within the UI (or that any currently existing documentation/explanation doesn't effectively communicate to some number of users). Jul 16 at 17:45
• @animuson I, also, had at least a moment of confusion when first using this editor due to it applying some formatting to text in Markdown mode. It was resolved by experimenting enough to see that the editor was applying some of the Markdown formatting. However, it was counter to my expectations for a Markdown editor, and still gives a "that's strange" feeling, even after 2 years of intermittent use, because nearly every other place where I see Markdown used (i.e. not just SE) doesn't do that, so there's a strong counter-expectation, which results in "something's wrong" feeling. Jul 16 at 17:55
• @Makyen Most Markdown editors I've ever used actually do format in this manner, so SE was the exception from most of my personal experiences. I get it's an adjustment for people who aren't used to it, but once you are, there are many benefits to showing some of the formatting in Markdown mode too. If you have suggestions for how to make it clear that it's intentional, we're all ears, but I can't really think of any ways to emphasize that.
– animuson StaffMod
Jul 16 at 19:08

This bug is the opposite of GitHub issue#41.

In rich text mode, if the first element in a post is a source fence, there's no way to insert a blank line before it, anything you type gets inserted inside the fence. (The proposed Shift + Enter workaround escapes the fence downward but not upward.)

I consider this a breaking bug since the only obvious workaround for rich text users is deleting the entire fence to be able to insert something else at the beginning of the post.

In rich text mode, having an horizontal rule after a source fence, if you move the cursor down it visually pushes the <hr> down one line each time you go over it. Start like this:


text in fence

---


After passing the cursor over the <hr>` twice by pressing here's a picture of the horizontal rule having moved 2 lines, if you switch to Markdown no blank lines were introduced.

In rich text mode, when selecting a link and moving upwards, the link dialogue is also moved up vertically to under blocks that aren't links.

Start like this:

Then move up:

GIF for reference

• @Justin good point, the dialogue gets moved onto empty lines also. Jul 15 at 8:55

When uploading an image the license is written in small case cc by-sa but for consistent styling with the rest of SE it should be capitalized as CC BY-SA.

I've written a previous post about the same bug in the footer cc by-sa in footer should be capitalized