22

Following the alpha release of the Stacks Editor, we got lots of feedback (including three out of the top four answers on the post, as well as other answers below and many comments) asking for a way to preview the rendered HTML generated from the Markdown being written, without having to switch the editor mode to rich text.

As promised in the post announcing the beta release, we are now happy to announce that a preview mode is now live in any places where it is available for testing: answers on MSO and MSE for users who have opted in. When in preview mode, the editor itself will be in Markdown mode and a live preview of the HTML (generate from the Markdown in the editor) will be rendered beneath. The HTML will be generated in the same way that it works today, including special Markdown extensions that we offer, like spoilers, auto-link generation, and tags (MathJax integration is not done yet, but it will be included before we offer the Stacks Editor on any site that has MathJax enabled).

Here is how it looks:

Screenshot of Markdown and preview mode in the Stacks Editor, showcasing many of the different styles and Markdown features rendered in preview mode

Just as it works today, whatever mode a user selects for the editor will be saved as a user preference and used the next time that they load the editor.

Though we do not have any dates or concrete plans yet in place for continuing the implementation and testing of the editor, our next steps will be:

  • Graduation of the Ask Wizard for new askers on Stack Overflow, which features the Stacks Editor as its only editor option.
  • Begin to offer the Stacks Editor for question asking to beta testers on MSO and MSE.
  • Following completion of the different plugins needed to support Markdown extensions that are offered on sites across the network, begin offer users of additional sites the option to opt-in to beta-testing.

If you have feedback on preview mode or would like to report any issues that you see with it, please do so in answers below. General bugs or feature requests for the Stacks Editor should be reported in their own questions (tagged with ) and/or as issues in GitHub (if possible, please check the list of issues reported in the beta announcement post before doing so, in order to avoid duplicates).

Improve this question
8
  • 4
    The preview is finally back, yes! Switching back and forth broke all kind of things to a point where many people didn't want to use the new editor. I hope we can put that behind us once the preview is fully rolled out.
    – Mast
    Sep 21, 2022 at 19:26
  • 1
    @Mast hopefully the fix for things breaking isn't this new view of the editor. I bet there still will be plenty of people switching between editor modes.
    – Luuklag
    Sep 21, 2022 at 20:08
  • 5
    @Luuklag This isn't in place of fixes for RT<>MD transition issues. If you have been following along in the beta announcement post, you'll see that we have already addressed all of the most pressing of these issues. Some edge cases remain, are status-planned and we will continue to address these through regular maintenance releases moving forward.
    – Yaakov Ellis StaffMod
    Sep 21, 2022 at 21:23
  • 3
    My only regret is one cannot give a bounty on a question 😁. This is very much appreciated
    – Journeyman Geek Mod
    Sep 21, 2022 at 23:01
  • Is this still being monitored for new answers? There's no timeline mentioned as to when issues should be posted as new questions instead.
    – Sonic the Anonymous Hedgehog
    Dec 8, 2022 at 20:35
  • @SonictheAnonymousHedgehog not actively monitoring this - any new issues should go in new posts
    – Yaakov Ellis StaffMod
    Dec 11, 2022 at 10:32
  • Okay, good to know. If I choose to submit a bug or FR by directly filing an issue in GitHub, is that being monitored for issues, or do I need to ask a new question here so the issue gets noticed?
    – Sonic the Anonymous Hedgehog
    Dec 11, 2022 at 11:27
  • @SonictheAnonymousHedgehog GH is being monitored and triaged by one team. If it is causing active pain on the site, feel free to also post on MSE as well (and link to GH if it is available).
    – Yaakov Ellis StaffMod
    Dec 11, 2022 at 14:16

5 Answers 5

Reset to default
10

Meta tags ([meta-tag:tag-name]) don't render in the preview:

enter image description here

They do render in the old editor, and regular tags render fine as well.

Improve this answer
5

When is this intended to be implemented on Stack Overflow for Teams?

Improve this answer
1
  • 3
    No timeline on that. The feature has been shared with Product leadership for SO for Teams, who will make a decision about if/when/how a rollout there will happen.
    – Yaakov Ellis StaffMod
    Sep 22, 2022 at 10:16
5

Please improve communication when it comes to keeping people updated as to important requests

As the author of the most upvoted answer to the alpha announcement requesting the addition of a preview pane, it's very nice to see this come up at all, and it was also nice to hear that it was planned during the beta announcement in July.

However, I really don't like that there was no communication in the time between the alpha and beta threads regarding its implementation. Essentially, what happened is that for around 18 months there was no indication that it was at all being considered. It seemed like it had been just swept away and ignored, or possibly de facto declined since it garnered some negative-sounding comments from staff.

Ideally, what should have happened here is that some update to the effect of the below should have been posted during this period, either as a question edit or as a comment on my or someone else's answer:

After having read over everyone's concerns, we are doing some exploration and discussion as to whether or not this should be included in the as-of-yet not planned beta release.

Once an idea begins to be internally considered for implementation, especially if it's garnered a lot of support and either no response or a negative-sounding response from the team, it would be nice if staff left a comment on it stating such. It would also be nice to have another comment posted once it clears discussion, such as the following:

We've discussed this internally and think this is a good idea, and our developers agree too. This will be included in our future beta release, coming in 6-8 weeks.

Again, it's nice to see this being ultimately implemented, even if it took a long time, but please give us better communication so as to avoid bad tastes or false impressions!

Improve this answer
3
  • 1
    I understand what you're asking and I think it's generally fair but in this specific case, you're asking us to say something when such things had not been determined. Due to shifting plans (which I feel were explained in the interim between the alpha and beta posts), the editor went through a period with little or no development and the teams working on it were asked to focus on other work. There was no discussion or decision that we could have shared that would have satisfied your request here.
    – Catija StaffMod
    Sep 22, 2022 at 19:24
  • @Catija Even so, due to the negative-sounding comments left by staff, there was a false impression that it had been effectively declined. A simple comment at the time saying that "just because we don't consider it useful now doesn't mean we won't explore it later" would have greatly reduced that bad taste. Also, since the project is on a public GitHub repository, I can see that it was ultimately brought up a couple months before the beta announcement, but no comment was immediately posted indicating such.
    – Sonic the Anonymous Hedgehog
    Sep 22, 2022 at 19:38
  • 1
    In other words, once the GitHub issue was opened in April, the first of my comments should have been posted, followed by the second in early June when it was added to the Beta milestone and the first proposed code change to add it was submitted. Despite this activity, we weren't notified of the change until the July announcement. The former of these comments should have also included a note to the effect of, "as you may be aware, the developers have been assigned to work on other things for the past year".
    – Sonic the Anonymous Hedgehog
    Sep 22, 2022 at 19:44
4

Syntax highlighting isn't being applied in the preview

It seems syntax highlight isn't being applied in the preview (click edit on this post to try it). I think this is important, when editing your or other's posts (or just reviewing them in the editor) having syntax highlight considerably helps readability.

JavaScript example (taken from this snippet):

const summaryAnswerID = 380354; // ID of the summary answer
const key = "U4DMV*8nvpm3EOpvf69Rxw(("; // taken from API documentation

SQL example (taken from this query):

SELECT TOP 100 Id as [Post Link], Title
FROM Posts
ORDER BY LEN(Posts.Title) DESC

Using Windows 10, Firefox 104.0.2 (64-bit), 1920x1080, rev 2022.9.22.32478

Improve this answer
4
  • 1
    This bug may seem like a simple design bug, but it has further implications. The syntax highlighter will strip out any HTML formatting inside code blocks, so posts that make use of such formatting will render correctly in the preview but be broken in the actual post. The current system is not perfect (it initially renders but doesn't once syntax highlighting is applied), but that's still better than the new editor not showing any indication at all.
    – Sonic the Anonymous Hedgehog
    Sep 23, 2022 at 0:55
  • Also, if one's using a language that isn't supported by SE, one may want to try out different supported ones to see which one is most suitable for that specific block. Currently, one can see it in the preview with the old editor, but the new editor requires that the post be saved every time.
    – Sonic the Anonymous Hedgehog
    Sep 23, 2022 at 0:56
  • @SonictheAnonymousHedgehog this post is not about the issue you linked in the 1st comment. I used a well formed Markdown source fences. It is also not about your 2nd comment, the source fences were written using language codes supported on MSE.
    – bad_coder
    Sep 23, 2022 at 0:59
  • 2
    I'm just adding further arguments as to why this bug should be fixed. Without these, there's a greater chance that SE will deem the bug low-priority or decline to fix it.
    – Sonic the Anonymous Hedgehog
    Sep 23, 2022 at 1:00
3

I found a post where a snippet inside a table works (I hadn't been able to get it working myself). However the preview does not show it correctly, the snippet is previewed as being outside the table:

A snippet in a table (taken from this post):

Name Email Order Price
Sam [email protected] Chips $12
Jim [email protected] 
<h1>Unicorns</h1>
<p>Unicorns are amazing.</p>
Improve this answer

You must log in to answer this question.

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