Test our new composer on Meta!

[volanar]

Will we ever see color text support?

[Don]

Thanks, this is looks awesome. I’ve noticed an issue. On my phone the switch is not working (when I tap it nothing happens, it keep the switch on Markdown).

iPhone 6s
iOS 15.8.3

This is the error appears in console when I tap it.

[Jagster (Jakke Lehtonen)]

15 and 18.3.something works.

[renato (Renato Atilio)]

A fix has been merged and is being was deployed here on Meta – please let us know if it still doesn’t work for you.

[Don]

Thanks Renato, but unfortunately it doesn’t seem to fix for me

[lindsey (Lindsey Fogle)]

@Jagster

It’s funny. My users were complaining about markdown and the lack of WYSIWYG earlier. Now, none of them have switched to the new system. I almost know why. Almost everyone is using mobiles and they were actually complaining about images and couldn’t see anything but markdown.

They don’t use anything else, and we’re back to my old claim: we need a tool to hide and show the toolbar.

We are planning improvements to the toolbar and composer container, specifically focused on making writing more enjoyable and familiar on mobile (in addition to desktop improvements).

Let’s please keep feedback focused on the editor changes themselves — which will not fix all issues related to writing on Discourse, but is the area we’re actively seeking feedback for right now.

[Milenski (Milen Valov)]

I’m not really sure… maybe I like it better with the preview because at the moment I can see where, what and how to change it. But… it’s not bad anyway

[meglio (Anton)]

One thing that irritates a lot in the new wysiwyg composer is that Enter now creates a new paragraph.

---

@Canapin

Only 1 thing for now: it looks bizarre to have such a narrow textarea to write our post.

I second this.

If you want to keep it that small, as a bare minimum, I’d align the in-composer post with the existing posts:

[meglio (Anton)]

@Arkshine

You can do shift + enter to avoid the double-line break, though it doesn’t work for lists.
I agree this behavior change should not be the default.

Yeah… we had a similar battle about Enter/Shift+Enter in the Chats feature already:

Enter to newline, Shift+Enter to submit message in chat

We love writing multi-paragraph messages. However, it is very annoying to press Shift+Enter for a line break, and easy to press Enter by mistake and submit the message. Please add a configuration to switch the two.

… I second the opinion that Enter should make a single line break in the new wysiwyg editor.

[meglio (Anton)]

@sam

I have shared this privately, but I think it is important to share publicly. I am extremely excited about this change, it is transformative to Discourse and opens the door for an enormous amount of communities

ALL of the three communities I manage, including a one used by software developers for all project management and development workflows, have been expressing their feedback/opinion throughout years of using it that the only weird thing in Discourse that makes them freak out ( and makes some actively dislike the whole Discourse just because of this one thing) is the markdown composer.

I am personally extremely happy that the understanding of the need of wysiwyg prevailed at the end of the day.

As soon as it is out, I’ll make wysiwyg the default editor mode in all those three communities.

Btw, here is my request for two more settings:

1. Allow to make wysiwyg the default editor mode

2. Allow to switch off the markdown editor altogether (if not, I’ll still switch it off by disabling the toggler via css, but please consider making it a proper setting).

P.S. Might be a weird idea, but I encourage those who’s betting on wysiwyg big time to compare the metrics of how many people post and reply in their communities - before and after rolling out the new wysiwyg composer. My gut feeling is that the metric will see an increse.

[StefanoCecere]

it’s very strange that i can’t edit an hyperlink (if i edit one it appears blank)

i tried firefox and chrome

this apart, if you keep a source mode / markdown toggle, it’s perfect

[robbie.morrison]

I have not got time to test this new facility. But support for Creative Commons licensing may be in order. Such that a site can opt‑in to gain explicit consent for CC‑BY‑4.0 or similar before each saving. And especially for each image upload. Discourse could even test for suitable metadata. Not sure if this fits with your design, but it could be useful for me. Please ignore if not relevant here!

[tobiaseigen]

What you are describing is not at all related to this new composer. And is not likely to be implemented in core discourse. You could do something in a plugin if it’s really important important to you, or look for someone to do it for you in Marketplace.

Creative Commons licensing belongs in the terms of use and enforcement is handled by moderators. If you have repeat offenders you can warn and then silence them.

If you want to keep talking about it please start a new topic or look for an existing related topic using the search.

[Jon_Halle]

Agree with this. The new editor is great and will be much easier for members of our community to use. We definitely want new users to see it as the default editor and we don’t want to confuse them with the toggler. The loss of some power user capabilities through the markdown editor for a very small subset of community members is a small price to pay. Ideally I think the default editor should be set at a site level but with individual members ability to choose the ‘old’ editor through their settings (not with a toggle in the composer window).

[Jon_Halle]

I agree that the alignment seems weird. I’m not 100% sure why the composer needs to pop up. The ‘old’ one needed to because it was quite a heavyweight environment with the two panes. Now that it’s much more svelte I think it could appear inline below the posts. I think that’s a more widely understood convention. The resize arrow could pop it out at a larger size for those who are composing a more epic post.

[j127]

@lindsey

This is looking a little further into the future than we have fully planned. I think it’s likely that we’ll offer a user preference to enable the Markdown toggle, but that is not set in stone at this point. Appreciate you sharing your opinion here though, it’s helpful input.

Please don’t remove the option to use markdown-only. Having a default setting and a markdown toggle would be ideal and keep all users happy.

I think WYSIWYG-only would be a disaster for some users, including me. I probably wouldn’t have chosen Discourse if all it had was a WYSIWYG editor, and I would strongly prefer no WYSIWYG on the site for any users than to be forced to use WYSIWYG.

The current editor is one of Discourse’s best features. Several times in the past I’ve even checked to see if it’s a separate open source package, because I would have used it myself on projects (and still would).

For people who have spent decades in raw text and are very fast with keyboards, there are many annoyances with WYSIWYG. Small bits of friction while editing can be especially frustrating.

I don’t want to say anything negative about the WYSIWYG editor, because it’s built really well and most users will like it, but I don’t want to be forced to use it, and I know I’m going to get complaints about it from some users too.

Slack tried removing their markdown editor in the early days and there was such a large outcry that they quickly added a user setting to restore it.

Here’s another topic with arguments against WYSIWYG with a hint of what the reaction will be from some users if it is forced on them:

@omfg

No WYSWYG garbage please!

This topic only has feedback from about 30 people, but once the feature goes live, I would expect a wider range of reactions. Imagine how people would react if GitHub issues suddenly went WYSIWYG. That’s the user base of many Discourse forums, and they are probably going to be very loud.

There are people with different kinds of workflows. If you write markdown content outside of Discourse and paste it in to WYSIWYG, and then need to edit the markdown externally again, you can’t copy markdown back out to get it back into the external editor.

With the markdown editor it’s easy to copy/paste back and forth between Discourse and things like other sites, code editors, documentation, and README.md files. 

When I inspect what people are posting in the forum, I want to be able to see every character with one click, without having to go into the database.

For example, this post contains a (simulated) spam link that can’t be seen unless you inspect the raw input. If moderators can’t view the raw text easily, spammers will quickly learn to exploit it. I regularly click the “edit” icon on suspicious new users’ posts to check for hidden links like that before I lock the editing of the posts.

There are other situations where hidden things get pasted into WYSIWYG editors, like when copying/pasting from emails that have tracking pixels in them.

(The more I think about that, the more I would prefer just turning off WYSIWYG sitewide to avoid the extra moderation burden, but I understand if that isn’t possible. This post also contains a 1x1 simulated remote tracking pixel, just to demonstrate. Edit: the forum just downloaded a copy of the remote pixel, so that probably wouldn’t be a problem on sites that have that setting on.)

@Jon_Halle

with individual members ability to choose the ‘old’ editor through their settings (not with a toggle in the composer window).

I would prefer having a toggle even if it’s put under the gear icon (as well as a per-user setting), but a per-user setting alone would be tolerable, as long as it isn’t removed.

Many WYSIWYG editors (like tinymce) have an HTML toggle, because when things go wrong with WYSIWYG and the cursor gets stuck inside a formatting tag, it’s easier to drop into the raw text to fix it than to have to cut the problem section onto the clipboard, paste it into a plain-text editor, copy it back into the WYSIWYG, and then reformat it.

[lindsey (Lindsey Fogle)]

We don’t have plans to remove the Markdown-only mode.

Initially, this will be controlled by a site setting, where admins can turn on the toggle to switch between rich text editor / Markdown-only editor, or leave it off to keep their composer Markdown-only. At this point, we do not have specifics on how both versions of the composer will be supported longterm (e.g., whether composer type will continue to be controlled by site setting, left up to user preference, or something else).

[j127]

@lindsey

We don’t have plans to remove the Markdown-only mode.

Initially, this will be controlled by a site setting, where admins can turn on the toggle to switch between rich text editor / Markdown-only editor, or leave it off to keep their composer Markdown-only.

Sounds great. Thanks for leaving a setting.

[schneeland]

Also glad that Markdown is here to stay! Being able to format my text in a keyboard-friendly way is something that makes it notably more pleasant for me to write posts on Discourse (especially when comparing it to older software with BBCode).

To small things I found after the last test:

1. When trying to create code segments via backticks, entering the backticks first and then typing something in between does not trigger the auto-formatting (doing backtick space code backtick space works).

2. Code segments created via backticks have the same problem as tables reported above (unable to enter an unformatted white space).